draft-ietf-quic-transport-20.txt   draft-ietf-quic-transport-21.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: October 25, 2019 Mozilla Expires: January 9, 2020 Mozilla
April 23, 2019 July 08, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-20 draft-ietf-quic-transport-21
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 October 25, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 10 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 11 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 12
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 13 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 14
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 16 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 17
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 20
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 21
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 22
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 23
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 25
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 26
5.2. Matching Packets to Connections . . . . . . . . . . . . . 26 5.2. Matching Packets to Connections . . . . . . . . . . . . . 27
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 27 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 27
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 27 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 28
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 28 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 29
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 28 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 29
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 29
6.2. Handling Version Negotiation Packets . . . . . . . . . . 29 6.2. Handling Version Negotiation Packets . . . . . . . . . . 29
6.2.1. Version Negotiation Between Draft Versions . . . . . 29 6.2.1. Version Negotiation Between Draft Versions . . . . . 30
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 30
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 30 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 31
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 31 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 32
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 33
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 34 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 35
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 35
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 37
7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 36 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 37
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 36 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37
8.1. Address Validation During Connection Establishment . . . 37 8.1. Address Validation During Connection Establishment . . . 38
8.1.1. Address Validation using Retry Packets . . . . . . . 37 8.1.1. Address Validation using Retry Packets . . . . . . . 39
8.1.2. Address Validation for Future Connections . . . . . . 38 8.1.2. Address Validation for Future Connections . . . . . . 39
8.1.3. Address Validation Token Integrity . . . . . . . . . 40 8.1.3. Address Validation Token Integrity . . . . . . . . . 41
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 40 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 42
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 41 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 43
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 42 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 43
8.5. Successful Path Validation . . . . . . . . . . . . . . . 42 8.5. Successful Path Validation . . . . . . . . . . . . . . . 43
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 42 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 43 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 44
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 44 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 45
9.2. Initiating Connection Migration . . . . . . . . . . . . . 44 9.2. Initiating Connection Migration . . . . . . . . . . . . . 45
9.3. Responding to Connection Migration . . . . . . . . . . . 45 9.3. Responding to Connection Migration . . . . . . . . . . . 46
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 45 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 47
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 46 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 47
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 47 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 48
9.4. Loss Detection and Congestion Control . . . . . . . . . . 48 9.4. Loss Detection and Congestion Control . . . . . . . . . . 49
9.5. Privacy Implications of Connection Migration . . . . . . 49 9.5. Privacy Implications of Connection Migration . . . . . . 50
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 49 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 50
9.6.1. Communicating A Preferred Address . . . . . . . . . . 50 9.6.1. Communicating a Preferred Address . . . . . . . . . . 51
9.6.2. Responding to Connection Migration . . . . . . . . . 50 9.6.2. Responding to Connection Migration . . . . . . . . . 51
9.6.3. Interaction of Client Migration and Preferred Address 51 9.6.3. Interaction of Client Migration and Preferred Address 52
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 51 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 52
10. Connection Termination . . . . . . . . . . . . . . . . . . . 52 10. Connection Termination . . . . . . . . . . . . . . . . . . . 53
10.1. Closing and Draining Connection States . . . . . . . . . 52 10.1. Closing and Draining Connection States . . . . . . . . . 53
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 53 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 54
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 54 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 55
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 55 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 56
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 58 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 59
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 58 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 59
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 59 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 60
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 60 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 61
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 60 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 61
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 61 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 62
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 61 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 62
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 61 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 63
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 62 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 63
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 63 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 64
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 64 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 66
13. Packetization and Reliability . . . . . . . . . . . . . . . . 67 13. Packetization and Reliability . . . . . . . . . . . . . . . . 68
13.1. Packet Processing and Acknowledgment . . . . . . . . . . 68 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 69
13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 68 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 69
13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 69 13.1.2. Limiting ACK Ranges . . . . . . . . . . . . . . . . 70
13.1.3. ACK Frames and Packet Protection . . . . . . . . . . 70
13.2. Retransmission of Information . . . . . . . . . . . . . 69 13.2. Retransmission of Information . . . . . . . . . . . . . 71
13.3. Explicit Congestion Notification . . . . . . . . . . . . 72 13.3. Explicit Congestion Notification . . . . . . . . . . . . 73
13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 72 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 73
13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 73 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 74
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 74 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 75
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 75 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 76
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 76 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 77
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 77 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 78
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 77 14.3.1. PMTU Probes Containing Source Connection ID . . . . 78
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 78 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 79
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 79 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 80
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 79 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 80
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 80 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 81
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 83 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 82
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 84 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 84
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 87 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 86
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 88 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 88
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 89 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 89
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 91 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 90
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 93 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 93
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 94 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 94
18.1. Transport Parameter Definitions . . . . . . . . . . . . 95 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 96
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 98 18.1. Transport Parameter Definitions . . . . . . . . . . . . 97
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 98 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 100
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 99 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 100
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 99 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 100
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 101 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 101
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 102 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 102
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 103 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 104
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 104 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 105
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 104 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 105
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 105 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 106
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 106 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 107
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 107 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 107
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 108 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 109
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 109 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 109
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 110 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 110
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 110 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 111
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 111 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 112
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 111 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 112
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 113 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 113
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 114 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 115
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 114 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 115
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 114 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 116
19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 115 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 116
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 116 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 117
20.1. Application Protocol Error Codes . . . . . . . . . . . . 117 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 118
21. Security Considerations . . . . . . . . . . . . . . . . . . . 117 20.1. Application Protocol Error Codes . . . . . . . . . . . . 119
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 117 21. Security Considerations . . . . . . . . . . . . . . . . . . . 119
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 118 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 119
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 119 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 120
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 119 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 121
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 119 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 121
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 120 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 121
21.7. Explicit Congestion Notification Attacks . . . . . . . . 120 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 122
21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 121 21.7. Explicit Congestion Notification Attacks . . . . . . . . 122
21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 121 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 123
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 121 21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 123
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 121 21.10. Targeted Attacks by Routing . . . . . . . . . . . . . . 123
22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 123 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 124 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 124
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 126 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 125
23.1. Normative References . . . . . . . . . . . . . . . . . . 126 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 126
23.2. Informative References . . . . . . . . . . . . . . . . . 127 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 128
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 129 23.1. Normative References . . . . . . . . . . . . . . . . . . 129
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 129 23.2. Informative References . . . . . . . . . . . . . . . . . 130
B.1. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 130 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 132
B.2. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 130 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 132
B.3. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 131 B.1. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 133
B.4. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 131 B.2. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 134
B.5. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 133 B.3. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 134
B.6. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 133 B.4. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 135
B.7. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 133 B.5. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 135
B.8. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 134 B.6. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 137
B.9. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 135 B.7. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 137
B.10. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 135 B.8. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 137
B.11. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 136 B.9. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 138
B.12. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 136 B.10. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 139
B.13. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 137 B.11. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 139
B.14. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 138 B.12. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 140
B.15. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 138 B.13. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 140
B.16. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 138 B.14. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 141
B.17. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 139 B.15. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 142
B.18. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 139 B.16. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 142
B.19. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 140 B.17. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 142
B.20. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 142 B.18. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 143
B.21. Since draft-hamilton-quic-transport-protocol-01 . . . . . 142 B.19. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 143
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 143 B.20. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 144
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 143 B.21. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 146
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143 B.22. Since draft-hamilton-quic-transport-protocol-01 . . . . . 146
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 147
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 147
1. Introduction 1. Introduction
QUIC is a multiplexed and secure general-purpose transport protocol QUIC is a multiplexed and secure general-purpose transport protocol
that provides: that provides:
o Stream multiplexing o Stream multiplexing
o Stream and connection-level flow control o Stream and connection-level flow control
skipping to change at page 7, line 47 skipping to change at page 8, line 5
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Commonly used terms in the document are described below. Commonly used terms in the document are described below.
QUIC: The transport protocol described by this document. QUIC is a QUIC: The transport protocol described by this document. QUIC is a
name, not an acronym. name, not an acronym.
QUIC packet: The smallest unit of QUIC that can be encapsulated in a QUIC packet: A complete processable unit of QUIC that can be
UDP datagram. Multiple QUIC packets can be encapsulated in a encapsulated in a UDP datagram. Multiple QUIC packets can be
single UDP datagram. encapsulated in a single UDP datagram.
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 initiating a QUIC connection.
Server: The endpoint accepting incoming QUIC connections. Server: The endpoint accepting incoming QUIC connections.
Connection ID: An opaque identifier that is used to identify a QUIC Connection ID: An opaque identifier that is used to identify a QUIC
skipping to change at page 8, line 43 skipping to change at page 8, line 47
x (A/B/C) ...: Indicates that x is one of A, B, or C bits long x (A/B/C) ...: Indicates that x is one of A, B, or C 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 (*) ...: Indicates that x is variable-length x (*) ...: Indicates that x is variable-length
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. An alternative view of QUIC streams abstraction to an application. Streams can be unidirectional or
is as an elastic "message" abstraction. bidirecational. An alternative view of QUIC unidirectional streams
is 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 9, line 23 skipping to change at page 9, line 27
stream limits. stream limits.
2.1. Stream Types and Identifiers 2.1. Stream Types and Identifiers
Streams can be unidirectional or bidirectional. Unidirectional Streams can be unidirectional or bidirectional. Unidirectional
streams carry data in one direction: from the initiator of the stream streams carry data in one direction: from the initiator of the stream
to its peer. Bidirectional streams allow for data to be sent in both to its peer. Bidirectional streams allow for data to be sent in both
directions. directions.
Streams are identified within a connection by a numeric value, Streams are identified within a connection by a numeric value,
referred to as the stream ID. Stream IDs are unique to a stream. A referred to as the stream ID. A stream ID is a 62-bit integer (0 to
QUIC endpoint MUST NOT reuse a stream ID within a connection. Stream 2^62-1) that is unique for all streams on a connection. Stream IDs
IDs are encoded as variable-length integers (see Section 16). are encoded as variable-length integers (see Section 16). A QUIC
endpoint MUST NOT reuse a stream ID within a connection.
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).
skipping to change at page 10, line 36 skipping to change at page 10, line 50
deliver data out of order to a receiving application. deliver data out of order to a receiving application.
An endpoint could receive data for a stream at the same stream offset An endpoint could receive data for a stream at the same stream offset
multiple times. Data that has already been received can be multiple times. Data that has already been received can be
discarded. The data at a given offset MUST NOT change if it is sent discarded. The data at a given offset MUST NOT change if it is sent
multiple times; an endpoint MAY treat receipt of different data at multiple times; an endpoint MAY treat receipt of different data at
the same offset within a stream as a connection error of type the same offset within a stream as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
Streams are an ordered byte-stream abstraction with no other Streams are an ordered byte-stream abstraction with no other
structure that is visible to QUIC. STREAM frame boundaries are not structure visible to QUIC. STREAM frame boundaries are not expected
expected to be preserved when data is transmitted, when data is to be preserved when data is transmitted, retransmitted after packet
retransmitted after packet loss, or when data is delivered to the loss, or delivered to the application at a receiver.
application at a receiver.
An endpoint MUST NOT send data on any stream without ensuring that it An endpoint MUST NOT send data on any stream without ensuring that it
is within the flow control limits set by its peer. Flow control is is within the flow control limits set by its peer. Flow control is
described in detail in Section 4. described in detail in Section 4.
2.3. Stream Prioritization 2.3. Stream Prioritization
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 frames 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 which indicate the relative priority of streams. When deciding which
streams to dedicate resources to, the implementation SHOULD use the streams to dedicate resources to, the implementation SHOULD use the
information provided by the application. information provided by the application.
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
skipping to change at page 12, line 50 skipping to change at page 13, line 8
The sending part of stream that the endpoint initiates (types 0 and 2 The sending part of stream that the endpoint initiates (types 0 and 2
for clients, 1 and 3 for servers) is opened by the application. The for clients, 1 and 3 for servers) is opened by the application. The
"Ready" state represents a newly created stream that is able to "Ready" state represents a newly created stream that is able to
accept data from the application. Stream data might be buffered in accept data from the application. Stream data might be buffered in
this state in preparation for sending. this state in preparation for sending.
Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a
sending part of a stream to enter the "Send" state. An sending part of a stream to enter the "Send" state. An
implementation might choose to defer allocating a stream ID to a implementation might choose to defer allocating a stream ID to a
stream until it sends the first frame and enters this state, which stream until it sends the first STREAM frame and enters this state,
can allow for better stream prioritization. which can allow for better stream prioritization.
The sending part of a bidirectional stream initiated by a peer (type The sending part of a bidirectional stream initiated by a peer (type
0 for a server, type 1 for a client) enters the "Ready" state then 0 for a server, type 1 for a client) enters the "Ready" state then
immediately transitions to the "Send" state if the receiving part immediately transitions to the "Send" state if the receiving part
enters the "Recv" state (Section 3.2). enters the "Recv" state (Section 3.2).
In the "Send" state, an endpoint transmits - and retransmits as In the "Send" state, an endpoint transmits - and retransmits as
necessary - stream data in STREAM frames. The endpoint respects the necessary - stream data in STREAM frames. The endpoint respects the
flow control limits set by its peer, and continues to accept and flow control limits set by its peer, and continues to accept and
process MAX_STREAM_DATA frames. An endpoint in the "Send" state process MAX_STREAM_DATA frames. An endpoint in the "Send" state
skipping to change at page 15, line 18 skipping to change at page 15, line 21
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
stream indicates that the remote peer no longer wishes to receive stream indicates that the remote peer no longer wishes to receive
data on this stream. Either frame might arrive before a STREAM or data on this stream. Either frame might arrive before a STREAM or
STREAM_DATA_BLOCKED frame if packets are lost or reordered. STREAM_DATA_BLOCKED frame if packets are lost or reordered.
Before creating a stream, all streams of the same type with lower- Before a stream is created, all streams of the same type with lower-
numbered stream IDs MUST be created. This ensures that the creation numbered stream IDs MUST be created. This ensures that the creation
order for streams is consistent on both endpoints. order for streams is consistent on both endpoints.
In the "Recv" state, the endpoint receives STREAM and In the "Recv" state, the endpoint receives STREAM and
STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be
reassembled into the correct order for delivery to the application. reassembled into the correct order for delivery to the application.
As data is consumed by the application and buffer space becomes As data is consumed by the application and buffer space becomes
available, the endpoint sends MAX_STREAM_DATA frames to allow the available, the endpoint sends MAX_STREAM_DATA frames to allow the
peer to send more data. peer to send more data.
When a STREAM frame with a FIN bit is received, the final size of the When a STREAM frame with a FIN bit is received, the final size of the
stream is known (see Section 4.4). The receiving part of the stream stream is known (see Section 4.4). The receiving part of the stream
then enters the "Size Known" state. In this state, the endpoint no then enters the "Size Known" state. In this state, the endpoint no
longer needs to send MAX_STREAM_DATA frames, it only receives any longer needs to send MAX_STREAM_DATA frames, it only receives any
retransmissions of stream data. retransmissions of stream data.
Once all data for the stream has been received, the receiving part Once all data for the stream has been received, the receiving part
enters the "Data Recvd" state. This might happen as a result of enters the "Data Recvd" state. This might happen as a result of
receiving the same STREAM frame that causes the transition to "Size receiving the same STREAM frame that causes the transition to "Size
Known". In this state, the endpoint has all stream data. Any STREAM Known". After all data has been received, any STREAM or
or STREAM_DATA_BLOCKED frames it receives for the stream can be STREAM_DATA_BLOCKED frames for the stream can be discarded.
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 is received when a RESET_STREAM
skipping to change at page 16, line 17 skipping to change at page 16, line 21
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".
Once the application has been delivered the signal indicating that Once the application receives the signal indicating that the stream
the stream was reset, the receiving part of the stream transitions to was reset, the receiving part of the stream transitions to the "Reset
the "Reset Read" state, which is a terminal state. Read" state, which is a terminal state.
3.3. Permitted Frame Types 3.3. Permitted Frame Types
The sender of a stream sends just three frame types that affect the The sender of a stream sends just three frame types that affect the
state of a stream at either sender or receiver: STREAM state of a stream at either sender or receiver: STREAM
(Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM (Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM
(Section 19.4). (Section 19.4).
A sender MUST NOT send any of these frames from a terminal state A sender MUST NOT send any of these frames from a terminal state
("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or
skipping to change at page 18, line 16 skipping to change at page 19, line 7
If an endpoint is no longer interested in the data it is receiving on If an endpoint is no longer interested in the data it is receiving on
a stream, it MAY send a STOP_SENDING frame identifying that stream to a stream, it MAY send a STOP_SENDING frame identifying that stream to
prompt closure of the stream in the opposite direction. This prompt closure of the stream in the opposite direction. This
typically indicates that the receiving application is no longer typically indicates that the receiving application is no longer
reading data it receives from the stream, but it is not a guarantee reading data it receives from the stream, but it is not a guarantee
that incoming data will be ignored. that incoming data will be ignored.
STREAM frames received after sending STOP_SENDING are still counted STREAM frames received after sending STOP_SENDING are still counted
toward connection and stream flow control, even though these frames toward connection and stream flow control, even though these frames
will be discarded upon receipt. 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 and any outstanding
data is declared lost, an endpoint SHOULD send a RESET_STREAM frame data is declared lost, an endpoint SHOULD send a RESET_STREAM frame
in lieu of a retransmission. in lieu of a retransmission.
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
skipping to change at page 19, line 15 skipping to change at page 20, line 4
4. Flow Control 4. Flow Control
It is necessary to limit the amount of data that a receiver could It is necessary to limit the amount of data that a receiver could
buffer, to prevent a fast sender from overwhelming a slow receiver, buffer, to prevent a fast sender from overwhelming a slow receiver,
or to prevent a malicious sender from consuming a large amount of or to prevent a malicious sender from consuming a large amount of
memory at a receiver. To enable a receiver to limit memory memory at a receiver. To enable a receiver to limit memory
commitment to a connection and to apply back pressure on the sender, commitment to a connection and to apply back pressure on the sender,
streams are flow controlled both individually and as an aggregate. A streams are flow controlled both individually and as an aggregate. A
QUIC receiver controls the maximum amount of data the sender can send QUIC receiver controls the maximum amount of data the sender can send
on a stream at any time, as described in Section 4.1 and Section 4.2 on a stream at any time, as described in Section 4.1 and Section 4.2
Similarly, to limit concurrency within a connection, a QUIC endpoint Similarly, to limit concurrency within a connection, a QUIC endpoint
controls the maximum cumulative number of streams that its peer can controls the maximum cumulative number of streams that its peer can
initiate, as described in Section 4.5. initiate, as described in Section 4.5.
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 credit-based flow-control scheme similar to that in
HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is
prepared to receive on a given stream and for the entire connection. prepared to receive on a given stream and for the entire connection.
This leads to two levels of data flow control in QUIC: This leads to two levels of data flow control in QUIC:
skipping to change at page 20, line 15 skipping to change at page 21, line 6
credit, even if one of the packets is lost. credit, even if one of the packets is lost.
A receiver advertises credit for a connection by sending a MAX_DATA A receiver advertises credit for a connection by sending a MAX_DATA
frame, which indicates the maximum of the sum of the absolute byte frame, which indicates the maximum of the sum of the absolute byte
offsets of all streams. A receiver maintains a cumulative sum of offsets of all streams. A receiver maintains a cumulative sum of
bytes received on all streams, which is used to check for flow bytes received on all streams, which is used to check for flow
control violations. A receiver might use a sum of bytes consumed on control violations. A receiver might use a sum of bytes consumed on
all streams to determine the maximum data limit to be advertised. all streams to determine the maximum data limit to be advertised.
A receiver can advertise a larger offset by sending MAX_STREAM_DATA A receiver can advertise a larger offset by sending MAX_STREAM_DATA
or MAX_DATA frames at any time during the connection. A receiver or MAX_DATA frames. Once a receiver advertises an offset, it MAY
cannot renege on an advertisement however. That is, once a receiver advertise a smaller offset, but this has no effect.
advertises an offset, it MAY 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 runs out of flow control credit, it will be unable to
send new data and is considered blocked. A sender SHOULD send send new data and is considered blocked. A sender SHOULD send a
STREAM_DATA_BLOCKED or DATA_BLOCKED frames 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. These frames are write but is blocked by flow control limits. These frames are
expected to be sent infrequently in common cases, but they are expected to be sent infrequently in common cases, but they are
considered useful for debugging and monitoring purposes. considered useful for debugging and monitoring purposes.
A sender sends a single STREAM_DATA_BLOCKED or DATA_BLOCKED frame A sender SHOULD NOT send multiple STREAM_DATA_BLOCKED or DATA_BLOCKED
only once when it reaches a data limit. A sender SHOULD NOT send frames for the same data limit, unless the original frame is
multiple STREAM_DATA_BLOCKED or DATA_BLOCKED frames for the same data determined to be lost. Another STREAM_DATA_BLOCKED or DATA_BLOCKED
limit, unless the original frame is determined to be lost. Another frame can be sent after the data limit is increased.
STREAM_DATA_BLOCKED or DATA_BLOCKED frame can be sent after the data
limit is increased.
4.2. Flow Credit Increments 4.2. Flow Credit Increments
This document leaves when and how many bytes to advertise in a This document leaves when and how many bytes to advertise in a
MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a
few considerations. These frames contribute to connection overhead. few considerations. These frames contribute to connection overhead.
Therefore frequently sending frames with small changes is Therefore frequently sending frames with small changes is
undesirable. At the same time, larger increments to limits are undesirable. At the same time, larger increments to limits are
necessary to avoid blocking if updates are less frequent, requiring necessary to avoid blocking if updates are less frequent, requiring
larger resource commitments at the receiver. Thus there is a trade- larger resource commitments at the receiver. Thus there is a trade-
skipping to change at page 21, line 34 skipping to change at page 22, line 21
STREAM_DATA_BLOCKED or DATA_BLOCKED frames. STREAM_DATA_BLOCKED or DATA_BLOCKED frames.
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. If a RESET_STREAM frame is reordered with stream data for stream. Without the offset included in RESET_STREAM, the two
the same stream, the receiver's estimate of the number of bytes endpoints could disagree on the number of bytes that count towards
received on that stream can be lower than the sender's estimate of connection flow control.
the number sent. As a result, the two 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 To remedy this issue, a RESET_STREAM frame (Section 19.4) includes
the final size of data sent on the stream. On receiving a the final size of data sent on the stream. On receiving a
RESET_STREAM frame, a receiver definitively knows how many bytes were RESET_STREAM frame, a receiver definitively knows how many bytes were
sent on that stream before the RESET_STREAM frame, and the receiver 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 MUST use the final size of the stream to account for all bytes sent
on the stream in its connection level flow controller. 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
skipping to change at page 23, line 6 skipping to change at page 23, line 41
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 STREAM_LIMIT_ERROR (see
Section 10.3). Section 10.3).
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 STREAM frame with a stream ID exceeding the limit it that receives a frame with a stream ID exceeding the limit it has
has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR
(Section 11). (Section 11).
A receiver cannot renege on an advertisement. That is, once a Once a receiver advertises a stream limit using the MAX_STREAMS
receiver advertises a stream limit using the MAX_STREAMS frame, frame, advertising a smaller limit has no effect. A receiver MUST
advertising a smaller limit has no effect. A receiver MUST ignore ignore any MAX_STREAMS frame that does not increase the stream limit.
any MAX_STREAMS frame that does not increase the stream limit.
As with stream and connection flow control, this document leaves when As with stream and connection flow control, this document leaves when
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
skipping to change at page 24, line 13 skipping to change at page 24, line 47
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 to correlate them with other connection IDs for an external observer to correlate them with other connection IDs for
the same connection. As a trivial example, this means the same the same connection. As a trivial example, this means the same
connection ID MUST NOT be issued more than once on the same connection ID MUST NOT be issued more than once on the same
connection. 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.
Packets with short headers (Section 17.3) only include the Packets with short headers (Section 17.3) only include the
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.
skipping to change at page 25, line 18 skipping to change at page 26, line 5
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). frame (Section 19.16).
Endpoints store received connection IDs for future use. An endpoint
that receives excessive connection IDs MAY discard those it cannot
store without sending a RETIRE_CONNECTION_ID frame. An endpoint that
issues connection IDs cannot expect its peer to store and use all
issued connection IDs.
An endpoint SHOULD ensure that its peer has a sufficient number of An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs. While each endpoint available and unused connection IDs. Endpoints store received
independently chooses how many connection IDs to issue, endpoints connection IDs for future use and advertise the number of connection
SHOULD provide and maintain at least eight connection IDs. The IDs they are willing to store with the active_connection_id_limit
endpoint SHOULD do this by supplying a new connection ID when a transport parameter. An endpoint SHOULD NOT provide more connection
connection ID is retired by its peer or when the endpoint receives a IDs than the peer's limit.
packet with a previously unused connection ID. However, it MAY limit
the frequency or the total number of connection IDs issued for each An endpoint SHOULD supply a new connection ID when it receives a
connection to avoid the risk of running out of connection IDs (see packet with a previously unused connection ID or when the peer
Section 10.4.2). retires one, unless providing the new connection ID would exceed the
peer's limit. An endpoint MAY limit the frequency or the total
number of connection IDs issued for each connection to avoid the risk
of running out of connection IDs; see Section 10.4.2.
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 close the connection 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,
any of which it can use when sending packets. When the endpoint any of which it can use when sending packets. When the endpoint
wishes to remove a connection ID from use, it sends a wishes to remove a connection ID from use, it sends a
RETIRE_CONNECTION_ID frame to its peer. Sending a RETIRE_CONNECTION_ID frame to its peer. Sending a
RETIRE_CONNECTION_ID frame indicates that the connection ID won't be RETIRE_CONNECTION_ID frame indicates that the connection ID will not
used again and requests that the peer replace it with a new be used again and requests that the peer replace it with a new
connection ID using a NEW_CONNECTION_ID frame. connection ID using a NEW_CONNECTION_ID frame.
As discussed in Section 9.5, each connection ID MUST be used on As discussed in Section 9.5, each connection ID MUST be used on
packets sent from only one local address. An endpoint that migrates packets sent from only one local address. An endpoint that migrates
away from a local address SHOULD retire all connection IDs used on away from a local address SHOULD retire all connection IDs used on
that address once it no longer plans to use that address. that address once it no longer plans to use that address.
An endpoint can request that its peer retire connection IDs by
sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
field. Upon receipt, the peer SHOULD retire the corresponding
connection IDs and send the corresponding RETIRE_CONNECTION_ID frames
in a timely manner. Failing to do so can cause packets to be
delayed, lost, or cause the original endpoint to send a stateless
reset in response to a connection ID it can no longer route
correctly.
An endpoint MAY discard a connection ID for which retirement has been
requested once an interval of no less than 3 PTO has elapsed since an
acknowledgement is received for the NEW_CONNECTION_ID frame
requesting that retirement. Subsequent incoming packets using that
connection ID could elicit a response with the corresponding
stateless reset token.
5.2. Matching Packets to Connections 5.2. Matching Packets to Connections
Incoming packets are classified on receipt. Packets can either be Incoming packets are classified on receipt. Packets can either be
associated with an existing connection, or - for servers - associated with an existing connection, or - for servers -
potentially create a new connection. potentially create a new connection.
Hosts try to associate a packet with an existing connection. If the Hosts try to associate a packet with an existing connection. If the
packet has a Destination Connection ID corresponding to an existing packet has a Destination Connection ID corresponding to an existing
connection, QUIC processes that packet accordingly. Note that more connection, QUIC processes that packet accordingly. Note that more
than one connection ID can be associated with a connection; see than one connection ID can be associated with a connection; see
skipping to change at page 27, line 13 skipping to change at page 28, line 7
error. error.
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 address/port tuple to receive zero-length connection IDs can use the address/port tuple to
identify a connection. Packets that don't match an existing identify a connection. Packets that don't match an existing
connection are discarded. connection are discarded.
Due to packet reordering or loss, clients might receive packets for a Due to packet reordering or loss, a client might receive packets for
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.
Clients MAY drop these packets, or MAY buffer them in anticipation of The client MAY drop these packets, or MAY buffer them in anticipation
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 has an unsupported version, but If a server receives a packet that has an unsupported version, but
the packet is sufficiently large to initiate a new connection for any the packet is sufficiently large to initiate a new connection for any
version supported by the server, it SHOULD send a Version Negotiation version supported by the server, it SHOULD send a Version Negotiation
packet as described in Section 6.1. Servers MAY rate control these packet as described in Section 6.1. Servers MAY rate control these
packets to avoid storms of Version Negotiation packets. packets to avoid storms of Version Negotiation packets. Otherwise,
servers MUST drop 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.
Servers SHOULD NOT attempt to decode or decrypt a packet from an Servers SHOULD NOT attempt to decode or decrypt a packet from an
unknown version, but instead send a Version Negotiation packet, unknown version, but instead send a Version Negotiation packet,
provided that the packet is sufficiently long. provided that the packet is sufficiently long.
Servers MUST drop other packets that contain unsupported versions.
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 address tuple. If the packet doesn't length connection IDs - the address tuple. If the packet doesn't
match an existing connection, the server continues below. match an existing connection, 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 isn't currently accepting any new connections, it SHOULD If a server isn't currently accepting any new connections, it SHOULD
send an Initial packet containing a CONNECTION_CLOSE frame with error send an Initial packet containing a CONNECTION_CLOSE frame with error
code SERVER_BUSY. code SERVER_BUSY.
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
number of these packets in anticipation of a late-arriving Initial number of these packets in anticipation of a late-arriving Initial
Packet. Clients are forbidden from sending Handshake packets prior packet. Clients are not able to send Handshake packets prior to
to receiving a server response, so servers SHOULD ignore any such receiving a server response, so servers SHOULD ignore any such
packets. packets.
Servers MUST drop incoming packets under all other circumstances. Servers MUST drop incoming packets under all other circumstances.
5.3. Life of a QUIC Connection 5.3. Life of a QUIC Connection
TBD. TBD.
6. Version Negotiation 6. Version Negotiation
Version negotiation ensures that client and server agree to a QUIC Version negotiation ensures that client and server agree to a QUIC
version that is mutually supported. A server sends a Version version that is mutually supported. 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 packet they send to the
largest of the minimum packet sizes across all versions they support. largest of the minimum packet sizes across all versions they support.
This ensures that the server responds if there is a mutually This ensures that the server responds if there is a mutually
supported version. supported version.
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
versions without retaining state. Though either the Initial packet versions without retaining state. Though either the Initial packet
or the Version Negotiation packet that is sent in response could be or the Version Negotiation packet that is sent in response could be
lost, the client will send new packets until it successfully receives lost, the client will send new packets until it successfully receives
a response or it abandons the connection attempt. a response or it abandons the connection attempt. As a result, the
client discards all state for the connection and does not send any
more packets on the connection.
A server MAY limit the number of Version Negotiation packets it A server MAY limit the number of Version Negotiation packets it
sends. For instance, a server that is able to recognize packets as sends. For instance, a server that is able to recognize packets as
0-RTT might choose not to send Version Negotiation packets in 0-RTT might choose not to send Version Negotiation packets in
response to 0-RTT packets with the expectation that it will response to 0-RTT packets with the expectation that it will
eventually receive an Initial packet. eventually receive an Initial packet.
6.2. Handling Version Negotiation Packets 6.2. Handling Version Negotiation Packets
When a client receives a Version Negotiation packet, it MUST abandon When a client receives a Version Negotiation packet, it MUST abandon
skipping to change at page 33, line 15 skipping to change at page 34, line 15
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 ID that each endpoint uses. Each used to establish the connection ID that each endpoint uses. 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. Upon receiving a packet, each endpoint
sets the Destination Connection ID it sends to match the value of the sets the Destination Connection ID it sends to match the value of the
Source Connection ID that they receive. Source Connection ID that they receive.
When an Initial packet is sent by a client which has not previously When an Initial packet is sent by a client that has not previously
received a Retry packet from the server, it populates the Destination received an Initial or Retry packet from the server, it populates the
Connection ID field with an unpredictable value. This MUST be at Destination Connection ID field with an unpredictable value. This
least 8 bytes in length. Until a packet is received from the server, MUST be at least 8 bytes in length. Until a packet is received from
the client MUST use the same value unless it abandons the connection the server, the client MUST use the same value unless it abandons the
attempt and starts a new one. The initial Destination Connection ID connection attempt and starts a new one. The initial Destination
is used to determine packet protection keys for Initial packets. Connection ID is used to determine packet protection keys for Initial
packets.
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 SCIL field to indicate the length. its choosing and sets the SCIL field to indicate the length. The
first flight of 0-RTT packets use the same Destination and Source
The first flight of 0-RTT packets use the same Destination and Source
Connection ID values as the client's first Initial. Connection ID values as the client's first Initial.
The Destination Connection ID field in the server's Initial packet Upon first receiving an Initial or Retry packet from the server, the
contains a connection ID that is chosen by the recipient of the
packet (i.e., the client); the Source Connection ID includes the
connection ID that the sender of the packet wishes to use (see
Section 5.1). The server MUST use consistent Source Connection IDs
during the handshake.
On first receiving an Initial or Retry packet from the server, the
client uses the Source Connection ID supplied by the server as the client uses the Source Connection ID supplied by the server as the
Destination Connection ID for subsequent packets, including any Destination Connection ID for subsequent packets, including any
subsequent 0-RTT packets. That means that a client might change the subsequent 0-RTT packets. That means that a client might change the
Destination Connection ID twice during connection establishment, once Destination Connection ID twice during connection establishment, once
in response to a Retry and once in response to the first Initial in response to a Retry and once in response to the first Initial
packet from the server. Once a client has received an Initial packet packet from the server. Once a client has received an Initial packet
from the server, it MUST discard any packet it receives with a from the server, it MUST discard any packet it receives with a
different Source Connection ID. different Source Connection ID.
A client MUST only change the value it sends in the Destination A client MUST only change the value it sends in the Destination
Connection ID in response to the first packet of each type it Connection ID in response to the first packet of each type it
receives from the server (Retry or Initial); a server MUST set its receives from the server (Retry or Initial); a server MUST set its
value based on the Initial packet. Any additional changes are not value based on the Initial packet. Any additional changes are not
permitted; if subsequent packets of those types include a different permitted; if subsequent packets of those types include a different
Source Connection ID, they MUST be discarded. This avoids problems Source Connection ID, they MUST be discarded. This avoids problems
that might arise from stateless processing of multiple Initial that might arise from stateless processing of multiple Initial
packets producing different connection IDs. packets producing different connection IDs.
The connection ID can change over the lifetime of a connection, The connection ID can change over the lifetime of a connection,
especially in response to connection migration (Section 9), see especially in response to connection migration (Section 9); see
Section 5.1.1 for details. Section 5.1.1 for details.
7.3. Transport Parameters 7.3. Transport Parameters
During connection establishment, both endpoints make authenticated During connection establishment, both endpoints make authenticated
declarations of their transport parameters. These declarations are declarations of their transport parameters. These declarations are
made unilaterally by each endpoint. Endpoints are required to comply made unilaterally by each endpoint. Endpoints are required to comply
with the restrictions implied by these parameters; the description of with the restrictions implied by these parameters; the description of
each parameter includes rules for its handling. each parameter includes rules for its handling.
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. value 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.1. An endpoint MUST treat receipt of a transport in Section 18.1.
parameter with an invalid value as a connection error of type
TRANSPORT_PARAMETER_ERROR. Any given parameter MUST appear at most An endpoint MUST treat receipt of a transport parameter with an
once in a given transport parameters extension. An endpoint MUST invalid value as a connection error of type
treat receipt of duplicate transport parameters as a connection error TRANSPORT_PARAMETER_ERROR.
of type TRANSPORT_PARAMETER_ERROR.
An endpoint MUST NOT send a parameter more than once in a given
transport parameters extension. An endpoint SHOULD treat receipt of
duplicate transport parameters as a connection error of type
TRANSPORT_PARAMETER_ERROR.
A server MUST include the original_connection_id transport parameter A server MUST include the original_connection_id transport parameter
(Section 18.1) if it sent a Retry packet to enable validation of the (Section 18.1) if it sent a Retry packet to enable validation of the
Retry, as described in Section 17.2.5. Retry, as described in Section 17.2.5.
7.3.1. Values of Transport Parameters for 0-RTT 7.3.1. Values of Transport Parameters for 0-RTT
Both endpoints store the value of the server transport parameters Both endpoints store the value of the server transport parameters
from a connection and apply them to any 0-RTT packets that are sent from a connection and apply them to any 0-RTT packets that are sent
in subsequent connections to that peer, except for transport in subsequent connections to that peer, except for transport
skipping to change at page 35, line 6 skipping to change at page 35, line 52
parameters apply to the new connection until the handshake completes parameters apply to the new connection until the handshake completes
and the client starts sending 1-RTT packets. Once the handshake and the client starts sending 1-RTT packets. Once the handshake
completes, the client uses the transport parameters established in completes, the client uses the transport parameters established in
the handshake. the handshake.
The definition of new transport parameters (Section 7.3.2) MUST The definition of new transport parameters (Section 7.3.2) MUST
specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A
client need not store a transport parameter it cannot process. 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:
original_connection_id, preferred_address, stateless_reset_token, and original_connection_id, preferred_address, stateless_reset_token,
ack_delay_exponent. The client MUST use the server's new values in ack_delay_exponent and active_connection_id_limit. The client MUST
the handshake instead, and absent new values from the server, the use the server's new values in the handshake instead, and absent new
default value. values from the server, the default value.
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 35, line 47 skipping to change at page 36, line 44
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 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
remembered transport parameters; importantly, it MUST NOT use updated
values that it learns from the server's updated transport parameters
or from frames received in 1-RTT packets. Updated values of
transport parameters from the handshake apply only to 1-RTT packets.
For instance, flow control limits from remembered transport
parameters apply to all 0-RTT packets even if those values are
increased by the handshake or by frames sent in 1-RTT packets. A
server MAY treat use of updated transport parameters in 0-RTT as a
connection error of type PROTOCOL_VIOLATION.
7.3.2. New Transport Parameters 7.3.2. New Transport Parameters
New transport parameters can be used to negotiate new protocol New transport parameters can be used to negotiate new protocol
behavior. An endpoint MUST ignore transport parameters that it does behavior. An endpoint MUST ignore transport parameters that it does
not support. Absence of a transport parameter therefore disables any not support. Absence of a transport parameter therefore disables any
optional protocol feature that is negotiated using the parameter. optional protocol feature that is negotiated using the parameter.
New transport parameters can be registered according to the rules in New transport parameters can be registered according to the rules in
Section 22.1. Section 22.1.
skipping to change at page 36, line 31 skipping to change at page 37, line 40
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.
Once the handshake completes, if an endpoint is unable to buffer all Once the handshake completes, if an endpoint is unable to buffer all
data in a CRYPTO frame, it MAY discard that CRYPTO frame and all data in a CRYPTO frame, it MAY discard that CRYPTO frame and all
CRYPTO frames received in the future, or it MAY close the connection CRYPTO frames received in the future, or it MAY close the connection
with an CRYPTO_BUFFER_EXCEEDED error code. Packets containing with a CRYPTO_BUFFER_EXCEEDED error code. Packets containing
discarded CRYPTO frames MUST be acknowledged because the packet has discarded CRYPTO frames MUST be acknowledged because the packet has
been received and processed by the transport even though the CRYPTO been received and processed by the transport even though the CRYPTO
frame was discarded. frame was discarded.
8. Address Validation 8. Address Validation
Address validation is used by QUIC to avoid being used for a traffic Address validation is used by QUIC to avoid being used for a traffic
amplification attack. In such an attack, a packet is sent to a amplification attack. In such an attack, a packet is sent to a
server with spoofed source address information that identifies a server with spoofed source address information that identifies a
victim. If a server generates more or larger packets in response to victim. If a server generates more or larger packets in response to
skipping to change at page 38, line 49 skipping to change at page 40, line 12
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. The client includes this token in Initial
packets to provide address validation in a future connection. The packets to provide address validation in a future connection. The
client MUST include the token in all Initial packets it sends, unless client MUST include the token in all Initial packets it sends, unless
a Retry or NEW_TOKEN frame replaces the token with a newer one. The a Retry replaces the token with a newer one. The client MUST NOT use
client MUST NOT use the token provided in a Retry for future the token provided in a Retry for future connections. Servers MAY
connections. Servers MAY discard any Initial packet that does not discard any Initial packet that does not carry the expected token.
carry the expected token.
A token SHOULD be constructed for the server to easily distinguish it
from tokens that are sent in Retry packets as they are carried in the
same field.
The token MUST NOT include information that would allow it to be
linked by an on-path observer to the connection on which it was
issued. For example, it cannot include the connection ID or
addressing information unless the values are encrypted.
Unlike the token that is created for a Retry packet, there might be Unlike the token that is created for a Retry packet, there might be
some time between when the token is created and when the token is some time between when the token is created and when the token is
subsequently used. Thus, a token SHOULD include an expiration time. subsequently used. Thus, a token SHOULD have an expiration time,
The server MAY include either an explicit expiration time or an which could be either an explicit expiration time or an issued
issued timestamp and dynamically calculate the expiration time. It timestamp that can be used to dynamically calculate the expiration
is also unlikely that the client port number is the same on two time. A server can store the expiration time or include it in an
encrypted form in the token.
It is unlikely that the client port number is the same on two
different connections; validating the port is therefore unlikely to different connections; validating the port is therefore unlikely to
be successful. be successful.
A token SHOULD be constructed for the server to easily distinguish it
from tokens that are sent in Retry packets as they are carried in the
same field.
If the client has a token received in a NEW_TOKEN frame on a previous If the client has a token received in a NEW_TOKEN frame on a previous
connection to what it believes to be the same server, it SHOULD connection to what it believes to be the same server, it SHOULD
include that value in the Token field of its Initial packet. include that value in the Token field of its Initial packet.
Including a token might allow the server to validate the client Including a token might allow the server to validate the client
address without an additional round trip. address without an additional round trip.
A token allows a server to correlate activity between the connection A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used. where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server MAY Clients that want to break continuity of identity with a server MAY
discard tokens provided using the NEW_TOKEN frame. A token obtained discard tokens provided using the NEW_TOKEN frame. A token obtained
skipping to change at page 41, line 41 skipping to change at page 43, line 11
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 a random 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. An endpoint SHOULD NOT send a PATH_CHALLENGE more packet loss, however an endpoint SHOULD NOT send multiple
frequently than it would an Initial packet, ensuring that connection PATH_CHALLENGE frames in a single packet. An endpoint SHOULD NOT
migration is no more load on a new path than establishing a new send a PATH_CHALLENGE more frequently than it would an Initial
connection. packet, ensuring that connection migration is no more load on a new
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
immediately by echoing the data contained in the PATH_CHALLENGE frame immediately by echoing the data contained in the PATH_CHALLENGE frame
in a PATH_RESPONSE frame. in a PATH_RESPONSE frame.
To ensure that packets can be both sent to and received from the An endpoint MUST NOT send more than one PATH_RESPONSE frame in
peer, the PATH_RESPONSE MUST be sent on the same path as the response to one PATH_CHALLENGE frame (see Section 13.2). The peer is
triggering PATH_CHALLENGE. That is, from the same local address on expected to send more PATH_CHALLENGE frames as necessary to evoke
which the PATH_CHALLENGE was received, to the same remote address additional PATH_RESPONSE frames.
from which the PATH_CHALLENGE was received.
8.5. Successful Path Validation 8.5. Successful Path Validation
A new address is considered valid when a PATH_RESPONSE frame is A new address is considered valid when a PATH_RESPONSE frame is
received that meets the following criteria: received that contains the data that was sent in a previous
PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing
o It contains the data that was sent in a previous PATH_CHALLENGE. a PATH_CHALLENGE frame is not adequate validation, since the
Receipt of an acknowledgment for a packet containing a acknowledgment can be spoofed by a malicious peer.
PATH_CHALLENGE frame is not adequate validation, since the
acknowledgment can be spoofed by a malicious peer.
o It was sent from the same remote address to which the
corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame
is received from a different remote address than the one to which
the PATH_CHALLENGE was sent, path validation is considered to have
failed, even if the data matches that sent in the PATH_CHALLENGE.
o It was received on the same local address from which the
corresponding PATH_CHALLENGE was sent.
Note that receipt on a different local address does not result in Note that receipt on a different local address does not result in
path validation failure, as it might be a result of a forwarded path validation failure, as it might be a result of a forwarded
packet (see Section 9.3.3) or misrouting. It is possible that a packet (see Section 9.3.3) or misrouting. It is possible that a
valid PATH_RESPONSE might be received in the future. 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.
skipping to change at page 43, line 25 skipping to change at page 44, line 28
a new path to become available or close the connection. a new path to become available or close the connection.
A path validation might be abandoned for other reasons besides A path validation might be abandoned for other reasons besides
failure. Primarily, this happens if a connection migration to a new failure. Primarily, this happens if a connection migration to a new
path is initiated while a path validation on the old path is in path is initiated while a path validation on the old path is in
progress. progress.
9. Connection Migration 9. Connection Migration
The use of a connection ID allows connections to survive changes to The use of a connection ID allows connections to survive changes to
endpoint addresses (that is, IP address and/or port), such as those endpoint addresses (IP address and port), such as those caused by an
caused by an endpoint migrating to a new network. This section endpoint migrating to a new network. This section describes the
describes the process by which an endpoint migrates to a new address. process by which an endpoint migrates to a new address.
An endpoint MUST NOT initiate connection migration before the The design of QUIC relies on endpoints retaining a stable address for
handshake is finished and the endpoint has 1-RTT keys. The design of the duration of the handshake. An endpoint MUST NOT initiate
QUIC relies on endpoints retaining a stable address for the duration connection migration before the handshake is confirmed, as defined in
of the handshake. section 4.1.2 of [QUIC-TLS].
An endpoint also MUST NOT initiate connection migration if the peer An endpoint also MUST NOT initiate connection migration if the peer
sent the "disable_migration" transport parameter during the sent the "disable_migration" transport parameter during the
handshake. An endpoint which has sent this transport parameter, but handshake. An endpoint which has sent this transport parameter, but
detects that a peer has nonetheless migrated to a different network detects that a peer has nonetheless migrated to a different network
MAY treat this as a connection error of type INVALID_MIGRATION. MAY treat this as a connection error of type INVALID_MIGRATION.
Similarly, an endpoint MUST NOT initiate migration if its peer Similarly, an endpoint MUST NOT initiate migration if its peer
supplies a zero-length connection ID as packets without a Destination supplies a zero-length connection ID as packets without a Destination
Connection ID cannot be attributed to a connection based on address Connection ID cannot be attributed to a connection based on address
tuple. tuple.
Not all changes of peer address are intentional migrations. The peer Not all changes of peer address are intentional migrations. The peer
could experience NAT rebinding: a change of address due to a could experience NAT rebinding: a change of address due to a
middlebox, usually a NAT, allocating a new outgoing port or even a middlebox, usually a NAT, allocating a new outgoing port or even a
new outgoing IP address for a flow. NAT rebinding is not connection new outgoing IP address for a flow. An endpoint MUST perform path
migration as defined in this section, though an endpoint SHOULD validation (Section 8.2) if it detects any change to a peer's
perform path validation (Section 8.2) if it detects a change in the address, unless it has previously validated that address.
IP address of its peer.
When an endpoint has no validated path on which to send packets, it When an endpoint has no validated path on which to send packets, it
MAY discard connection state. An endpoint capable of connection MAY discard connection state. An endpoint capable of connection
migration MAY wait for a new path to become available before migration MAY wait for a new path to become available before
discarding connection state. discarding connection state.
This document limits migration of connections to new client This document limits migration of connections to new client
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
skipping to change at page 50, line 13 skipping to change at page 51, line 13
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 left
for future work. If a client receives packets from a new server for future work. If a client receives packets from a new server
address not indicated by the preferred_address transport parameter, address not indicated by the preferred_address transport parameter,
the client SHOULD discard these packets. 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 finished, the client SHOULD select one of the Once the handshake is finished, the client SHOULD select one of the
two server's preferred addresses and initiate path validation (see two server's preferred addresses and initiate path validation (see
skipping to change at page 53, line 8 skipping to change at page 54, line 8
connection is in the draining state. connection is in the draining state.
An endpoint MAY transition from the closing period to the draining An endpoint MAY transition from the closing period to the draining
period if it receives a CONNECTION_CLOSE frame or stateless reset, period if it receives a CONNECTION_CLOSE frame or stateless reset,
both of which indicate that the peer is also closing or draining. both of which indicate that the peer is also closing or draining.
The draining period SHOULD end when the closing period would have The draining period SHOULD end when the closing period would have
ended. In other words, the endpoint can use the same end time, but ended. In other words, the endpoint can use the same end time, but
cease retransmission of the closing packet. cease retransmission of the closing packet.
Disposing of connection state prior to the end of the closing or Disposing of connection state prior to the end of the closing or
draining period could cause delayed or reordered packets to be draining period could cause delayed or reordered packets to generate
handled poorly. Endpoints that have some alternative means to ensure an unnecessary stateless reset. Endpoints that have some alternative
that late-arriving packets on the connection do not create QUIC means to ensure that late-arriving packets on the connection do not
state, such as those that are able to close the UDP socket, MAY use induce a response, such as those that are able to close the UDP
an abbreviated draining period which can allow for faster resource socket, MAY use an abbreviated draining period which can allow for
recovery. Servers that retain an open socket for accepting new faster resource recovery. Servers that retain an open socket for
connections SHOULD NOT exit the closing or draining period early. accepting new connections SHOULD NOT exit the closing or draining
period early.
Once the closing or draining period has ended, an endpoint SHOULD Once the closing or draining period has ended, an endpoint SHOULD
discard all connection state. This results in new packets on the discard all connection state. This results in new packets on the
connection being handled generically. For instance, an endpoint MAY connection being handled generically. For instance, an endpoint MAY
send a stateless reset in response to any further incoming packets. send a stateless reset in response to any further incoming packets.
The draining and closing periods do not apply when a stateless reset The draining and closing periods do not apply when a stateless reset
(Section 10.4) is sent. (Section 10.4) is sent.
An endpoint is not expected to handle key updates when it is closing An endpoint is not expected to handle key updates when it is closing
skipping to change at page 53, line 46 skipping to change at page 54, line 47
If the idle timeout is enabled, a connection is silently closed and If the idle timeout is enabled, a connection is silently closed and
the state is discarded when it remains idle for longer than both the the state is discarded when it remains idle for longer than both the
advertised idle timeout (see Section 18.1) and three times the advertised idle timeout (see Section 18.1) and three times the
current Probe Timeout (PTO). current Probe Timeout (PTO).
Each endpoint advertises its own idle timeout to its peer. An Each endpoint advertises its own idle timeout to its peer. An
endpoint restarts any timer it maintains when a packet from its peer endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully. The timer is also restarted is received and processed successfully. The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an when sending a packet containing frames other than ACK or PADDING (an
ACK-eliciting packet, see [QUIC-RECOVERY]), but only if no other ACK- ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK-
eliciting packets have been sent since last receiving a packet. eliciting packets have been sent since last receiving a packet.
Restarting when sending packets ensures that connections do not Restarting when sending packets ensures that connections do not
prematurely time out when initiating new activity. prematurely time out when initiating new activity.
The value for an idle timeout can be asymmetric. The value The value for an idle timeout can be asymmetric. The value
advertised by an endpoint is only used to determine whether the advertised by an endpoint is only used to determine whether the
connection is live at that endpoint. An endpoint that sends packets connection is live at that endpoint. An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the packets discarded if its peer enters the draining state before the
packets arrive. If a peer could timeout within an Probe Timeout packets arrive. If a peer could timeout within a Probe Timeout (PTO;
(PTO, see Section 6.2.2 of [QUIC-RECOVERY]), it is advisable to test see Section 6.3 of [QUIC-RECOVERY]), it is advisable to test for
for liveness before sending any data that cannot be retried safely. liveness before sending any data that cannot be retried safely. Note
Note that it is likely that only applications or application that it is likely that only applications or application protocols
protocols will know what information can be retried. will know what information can be retried.
10.3. Immediate Close 10.3. 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, endpoints immediately enter After sending a CONNECTION_CLOSE frame, endpoints immediately enter
the closing state. During the closing period, an endpoint that sends the closing state. During the closing period, an endpoint that sends
skipping to change at page 55, line 13 skipping to change at page 56, line 13
packets, which could result in a constant exchange of packets, which could result in a constant exchange of
CONNECTION_CLOSE frames until the closing period on either peer CONNECTION_CLOSE frames until the closing period on either peer
ended. ended.
An immediate close can be used after an application protocol has An immediate close can be used after an application protocol has
arranged to close a connection. This might be after the application arranged to close a connection. This might be after the application
protocols negotiates a graceful shutdown. The application protocol protocols negotiates a graceful shutdown. The application protocol
exchanges whatever messages that are needed to cause both endpoints exchanges whatever messages that are needed to cause both endpoints
to agree to close the connection, after which the application to agree to close the connection, after which the application
requests that the connection be closed. The application protocol can requests that the connection be closed. The application protocol can
use an CONNECTION_CLOSE frame with an appropriate error code to use a CONNECTION_CLOSE frame with an appropriate error code to signal
signal closure. closure.
If the connection has been successfully established, endpoints MUST When sending CONNECTION_CLOSE, the goal is to ensure that the peer
send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to will process the frame. Generally, this means sending the frame in a
connection establishment a peer might not have 1-RTT keys, so packet with the highest level of packet protection to avoid the
endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake packet. packet being discarded. However, during the handshake, it is
If the endpoint does not have Handshake keys, or it is not certain possible that more advanced packet protection keys are not available
that the peer has Handshake keys, it MAY send CONNECTION_CLOSE frames to the peer, so the frame MAY be replicated in a packet that uses a
in an Initial packet. If multiple packets are sent, they can be lower packet protection level.
coalesced (see Section 12.2) to facilitate retransmission.
After the handshake is confirmed, an endpoint MUST send any
CONNECTION_CLOSE frames in a 1-RTT packet. Prior to handshake
confirmation, the peer might not have 1-RTT keys, so the endpoint
SHOULD send CONNECTION_CLOSE frames in a Handshake packet. If the
endpoint does not have Handshake keys, it SHOULD send
CONNECTION_CLOSE frames in an Initial packet.
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 know
whether the client has Handshake keys. Under these circumstances, a
server SHOULD send a CONNECTION_CLOSE frame in both Handshake and
Initial packets to ensure that at least one of them is processable by
the client. These packets can be coalesced into a single UDP
datagram (see Section 12.2).
10.4. Stateless Reset 10.4. 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. A endpoint that is unable to properly continue the connection. An
stateless reset is not appropriate for signaling error conditions. endpoint MAY send a stateless reset in response to receiving a packet
that it cannot associate with an active connection.
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 NEW_CONNECTION_ID frame sent by either peer, and carried in the NEW_CONNECTION_ID frame sent by either peer, and
servers can specify the stateless_reset_token transport parameter servers can specify the stateless_reset_token transport parameter
during the handshake (clients cannot because their transport during the handshake (clients cannot because their transport
parameters don't have confidentiality protection). This value is parameters don't have confidentiality protection). This value is
protected by encryption, so only client and server know this value. protected by encryption, so only client and server know this value.
Tokens are invalidated when their associated connection ID is retired Tokens are invalidated when their associated connection ID is retired
skipping to change at page 56, line 32 skipping to change at page 57, line 44
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 that are set to
unpredictable values. The last 16 bytes of the datagram contain a unpredictable values. The last 16 bytes of the datagram contain a
Stateless Reset Token. 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
be appear to be a packet with a short header. For the packet to appear to be a packet with a short header. For the packet to appear
appear as valid, the Unpredictable Bits field needs to include at as valid, the Unpredictable Bits field needs to include at least 182
least 182 bits of data (or 23 bytes, less the two fixed bits). This bits of data (or 23 bytes, less the two fixed bits). This is
is intended to allow for a Destination Connection ID of the maximum intended to allow for a Destination Connection ID of the maximum
length permitted, with a minimal packet number, and payload. The length permitted, with a minimal packet number, and payload. The
Stateless Reset Token corresponds to the minimum expansion of the Stateless Reset Token corresponds to the minimum expansion of the
packet protection AEAD. More unpredictable bytes might be necessary packet protection AEAD. More unpredictable bytes might be necessary
if the endpoint could have negotiated a packet protection scheme with if the endpoint could have negotiated a packet protection scheme with
a larger minimum AEAD expansion. a larger minimum AEAD expansion.
An endpoint SHOULD NOT send a stateless reset that is significantly An endpoint SHOULD NOT send a stateless reset that is significantly
larger than the packet it receives. Endpoints MUST discard packets larger than the packet it receives. Endpoints MUST discard packets
that are too small to be valid QUIC packets. With the set of AEAD that are too small to be valid QUIC packets. With the set of AEAD
functions defined in [QUIC-TLS], packets that are smaller than 21 functions defined in [QUIC-TLS], packets that are smaller than 21
skipping to change at page 57, line 12 skipping to change at page 58, line 23
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.
An endpoint MAY send a stateless reset in response to a packet with a An endpoint MAY send a stateless reset in response to a packet with a
long header. Sending a stateless reset is not effective prior to the long header. Sending a stateless reset is not effective prior to the
stateless reset token being available to a peer. In this QUIC stateless reset token being available to a peer. In this QUIC
version, packets with a long header are only used during connection version, packets with a long header are only used during connection
establishment. Because the stateless reset token is not available establishment. Because the stateless reset token is not available
until connection establishment is complete or near completion, until connection establishment is complete or near completion,
ignoring an unknown packet with a long header might be as effective ignoring an unknown packet with a long header might be as effective
than sending a stateless reset. as sending a stateless reset.
An endpoint cannot determine the Source Connection ID from a packet An endpoint cannot determine the Source Connection ID from a packet
with a short header, therefore it cannot set the Destination with a short header, therefore it cannot set the Destination
Connection ID in the stateless reset packet. The Destination Connection ID in the stateless reset packet. The Destination
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:
o The packet might not reach the peer. If the Destination o 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.4.3. A
Stateless Reset that is not correctly routed is an ineffective Stateless Reset that is not correctly routed is an ineffective
error detection and recovery mechanism. In this case, endpoints error detection and recovery mechanism. In this case, endpoints
will need to rely on other methods - such as timers - to detect will need to rely on other methods - such as timers - to detect
that the connection has failed. that the connection has failed.
o The randomly generated connection ID can be used by entities other o 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.
skipping to change at page 58, line 11 skipping to change at page 59, line 19
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.4.1. Detecting a Stateless Reset
An endpoint detects a potential stateless reset when an incoming An endpoint detects a potential stateless reset when an incoming
packet either cannot be associated with a connection, cannot be packet either cannot be associated with a connection, cannot be
decrypted, or is marked as a duplicate packet. The endpoint MUST decrypted, or is marked as a duplicate packet. The endpoint MUST
then compare the last 16 bytes of the packet with all Stateless Reset then compare the last 16 bytes of the packet with all Stateless Reset
Tokens that are associated with connection IDs that are currently in Tokens that are associated with connection IDs that the endpoint
use. This includes Stateless Reset Tokens from NEW_CONNECTION_ID recently used to send packets from the IP address and port on which
frames and the server's transport parameters. An endpoint MUST NOT the datagram is received. This includes Stateless Reset Tokens from
check for any Stateless Reset Tokens associated with connection IDs NEW_CONNECTION_ID frames and the server's transport parameters. An
it has not used or for connection IDs that have been retired. endpoint MUST NOT check for any Stateless Reset Tokens associated
with connection IDs it has not used or for connection IDs that have
been retired.
If the last 16 bytes of the packet values are identical to a If the last 16 bytes of the packet values are identical 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. If the and not send any further packets on this connection. If the
comparison fails, the packet can be discarded. comparison fails, the packet can be discarded.
10.4.2. Calculating a Stateless Reset Token 10.4.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
skipping to change at page 59, line 12 skipping to change at page 60, line 24
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.8). A connection ID from a same static key; see Section 21.8. A connection ID from a connection
connection that is reset by revealing the Stateless Reset Token MUST that is reset by revealing the Stateless Reset Token MUST NOT be
NOT be reused for new connections at nodes that share a static key. reused for new connections at nodes that share a static key.
The same Stateless Reset Token MAY be used for multiple connection
IDs on the same connection. However, reuse of a Stateless Reset
Token might expose an endpoint to denial of service if associated
connection IDs are forgotten while the associated token is still
active at a peer. An endpoint MUST ensure that packets with
Destination Connection ID field values that correspond to a reused
Stateless Reset Token are attributed to the same connection as long
as the Stateless Reset Token is still usable, even when the
connection ID has been retired. Otherwise, an attacker might be able
to send a packet with a retired connection ID and cause the endpoint
to produce a Stateless Reset that it can use to disrupt the
connection, just as with the attacks in Section 21.8.
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.4.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
skipping to change at page 60, line 35 skipping to change at page 62, line 10
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 protocols can signal application-specific protocol errors
using the application-specific variant of the CONNECTION_CLOSE frame. using the application-specific variant of the CONNECTION_CLOSE frame.
Errors that are specific to the transport, including all those Errors that are specific to the transport, including all those
described in this document, are carried the QUIC-specific variant of described in this document, are carried in the QUIC-specific variant
the CONNECTION_CLOSE frame. of the CONNECTION_CLOSE frame.
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.
skipping to change at page 62, line 18 skipping to change at page 63, line 42
encryption level - and therefore the keys - that are used. Packets encryption level - and therefore the keys - that are used. Packets
protected with 0-RTT and 1-RTT keys are expected to have protected with 0-RTT and 1-RTT keys are expected to have
confidentiality and data origin authentication; the cryptographic confidentiality and data origin authentication; the cryptographic
handshake ensures that only the communicating endpoints receive the handshake ensures that only the communicating endpoints receive the
corresponding keys. corresponding keys.
The packet number field contains a packet number, which has The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet additional confidentiality protection that is applied after packet
protection is applied (see [QUIC-TLS] for details). The underlying protection is applied (see [QUIC-TLS] for details). The underlying
packet number increases with each packet sent in a given packet packet number increases with each packet sent in a given packet
number space, see Section 12.3 for details. 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, which 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 starting sending needed to complete the cryptographic handshake and start sending
data. Receivers MUST be able to process coalesced packets. data. This can also be used to construct PMTU probes (see
Section 14.3.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) makes it more likely the receiver will be 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be
able to process all the packets in a single pass. A packet with a able to process all the packets in a single pass. A packet with a
short header does not include a length, so it can only be the last short header does not include a length, so it can only be the last
packet included in a UDP datagram. packet included in a UDP datagram. An endpoint SHOULD NOT coalesce
multiple packets at the same encryption level.
Senders MUST NOT coalesce QUIC packets for different connections into Senders MUST NOT coalesce QUIC packets for different connections into
a single UDP datagram. Receivers SHOULD ignore any subsequent a single UDP datagram. Receivers SHOULD ignore any subsequent
packets with a different Destination Connection ID than the first packets with a different Destination Connection ID than the first
packet in the datagram. 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. Though the values of some fields in the separate and complete. Though the values of some fields in the
packet header might be redundant, no fields are omitted. The packet header might be redundant, no fields are omitted. The
receiver of coalesced QUIC packets MUST individually process each receiver of coalesced QUIC packets MUST individually process each
skipping to change at page 68, line 19 skipping to change at page 69, line 19
processed. For STREAM frames, this means the data has been enqueued processed. For STREAM frames, this means the data has been enqueued
in preparation to be received by the application protocol, but it in preparation to be received by the application protocol, but it
does not require that data is delivered and consumed. does not require that data is delivered and consumed.
Once the packet has been fully processed, a receiver acknowledges Once the packet has been fully processed, a receiver acknowledges
receipt by sending one or more ACK frames containing the packet receipt by sending one or more ACK frames containing the packet
number of the received packet. number of the received packet.
13.1.1. Sending ACK Frames 13.1.1. Sending ACK Frames
An endpoint MUST NOT send more than one packet containing only an ACK An endpoint sends ACK frames to acknowledge packets it has received
frame per received packet that contains frames other than ACK and and processed.
PADDING frames. An endpoint MUST NOT send a packet containing only
an ACK frame in response to a packet containing only ACK or PADDING Packets containing only ACK frames are not congestion controlled, so
frames, even if there are packet gaps which precede the received there are limits on how frequently they can be sent. An endpoint
packet. This prevents an indefinite feedback loop of ACKs. The MUST NOT send more than one ACK-frame-only packet in response to
endpoint MUST however acknowledge packets containing only ACK or receiving an ACK-eliciting packet (one containing frames other than
PADDING frames when sending ACK frames in response to other packets. ACK and/or PADDING). An endpoint MUST NOT send a packet containing
only an ACK frame in response to a non-ACK-eliciting packet (one
containing only ACK and/or PADDING frames), even if there are packet
gaps which precede the received packet. Limiting ACK frames avoids
an infinite feedback loop of acknowledgements, which could prevent
the connection from ever becoming idle. However, the endpoint
acknowledges non-ACK-eliciting packets when it sends an ACK frame.
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]. Sending only PADDING congestion control purposes [QUIC-RECOVERY]. Sending only PADDING
frames might cause the sender to become limited by the congestion frames might cause the sender to become limited by the congestion
controller (as described in [QUIC-RECOVERY]) with no acknowledgments controller (as described in [QUIC-RECOVERY]) with no acknowledgments
forthcoming from the receiver. Therefore, a sender SHOULD ensure forthcoming from the receiver. Therefore, a sender SHOULD ensure
that other frames are sent in addition to PADDING frames to elicit that other frames are sent in addition to PADDING frames to elicit
acknowledgments from the receiver. acknowledgments from the receiver.
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are
included in packets with ACK-eliciting frames. An endpoint SHOULD
bundle ACK frames with other frames when there are new ACK-eliciting
packets to acknowledge. When only non-ACK-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ACK-eliciting packet
has been received to bundle an ACK frame with outgoing frames.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it
did not send as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition.
The receiver's delayed acknowledgment timer SHOULD NOT exceed the The receiver's delayed acknowledgment timer SHOULD NOT exceed the
current RTT estimate or the value it indicates in the "max_ack_delay" current RTT estimate or the value it indicates in the "max_ack_delay"
transport parameter. This ensures an acknowledgment is sent at least transport parameter. This ensures an acknowledgment is sent at least
once per RTT when packets needing acknowledgement are received. The once per RTT when packets needing acknowledgement are received. The
sender can use the receiver's "max_ack_delay" value in determining sender can use the receiver's "max_ack_delay" value in determining
timeouts for timer-based retransmission. timeouts for timer-based retransmission.
Strategies and implications of the frequency of generating Strategies and implications of the frequency of generating
acknowledgments are discussed in more detail in [QUIC-RECOVERY]. acknowledgments are discussed in more detail in [QUIC-RECOVERY].
13.1.2. Limiting ACK Ranges
To limit ACK Ranges (see Section 19.3.1) to those that have not yet To limit ACK Ranges (see Section 19.3.1) to those that have not yet
been received by the sender, the receiver SHOULD track which ACK been received by the sender, the receiver SHOULD track which ACK
frames have been acknowledged by its peer. The receiver SHOULD frames have been acknowledged by its peer. The receiver SHOULD
exclude already acknowledged packets from future ACK frames whenever exclude already acknowledged packets from future ACK frames whenever
these packets would unnecessarily contribute to the ACK frame size. these packets would unnecessarily contribute to the ACK frame size.
When the receiver is only sending non-ACK-eliciting packets, it can
Because ACK frames are not sent in response to ACK-only packets, a bundle a PING or other small ACK-eliciting frame with a fraction of
receiver that is only sending ACK frames will only receive them, such as once per round trip, to enable dropping unnecessary ACK
acknowledgements for its packets if the sender includes them in ranges and any state for previously sent packets. The receiver MUST
packets with non-ACK frames. A sender SHOULD bundle ACK frames with NOT bundle an ACK-elicing frame, such as a PING, with all packets
other frames when possible. that would otherwise be non-ACK-eliciting, in order to avoid an
infinite feedback loop of acknowledgements.
To limit receiver state or the size of ACK frames, a receiver MAY To limit receiver state or the size of ACK frames, a receiver MAY
limit the number of ACK Ranges it sends. A receiver can do this even limit the number of ACK Ranges it sends. A receiver can do this even
without receiving acknowledgment of its ACK frames, with the without receiving acknowledgment of its ACK frames, with the
knowledge this could cause the sender to unnecessarily retransmit knowledge this could cause the sender to unnecessarily retransmit
some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare
lost after sufficiently newer packets are acknowledged. Therefore, packets lost after sufficiently newer packets are acknowledged.
the receiver SHOULD repeatedly acknowledge newly received packets in Therefore, the receiver SHOULD repeatedly acknowledge newly received
preference to packets received in the past. packets in preference to packets received in the past.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it
did not send as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition.
13.1.2. ACK Frames and Packet Protection 13.1.3. 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 ACKed (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.
Endpoints SHOULD send acknowledgments for packets containing CRYPTO Endpoints SHOULD send acknowledgments for packets containing CRYPTO
frames with a reduced delay; see Section 6.2.1 of [QUIC-RECOVERY]. frames with a reduced delay; see Section 6.2 of [QUIC-RECOVERY].
13.2. Retransmission of Information 13.2. Retransmission of Information
QUIC packets that are determined to be lost are not retransmitted QUIC packets that are determined to be lost are not retransmitted
whole. The same applies to the frames that are contained within lost whole. The same applies to the frames that are contained within lost
packets. Instead, the information that might be carried in frames is packets. Instead, the information that might be carried in frames is
sent again in new frames as needed. sent again in new frames as needed.
New frames and packets are used to carry information that is New frames and packets are used to carry information that is
determined to have been lost. In general, information is sent again determined to have been lost. In general, information is sent again
skipping to change at page 70, line 28 skipping to change at page 71, line 44
o Cancellation of stream transmission, as carried in a RESET_STREAM o Cancellation of stream transmission, as carried in a RESET_STREAM
frame, is sent until acknowledged or until all stream data is frame, is sent until acknowledged or until all stream data is
acknowledged by the peer (that is, either the "Reset Recvd" or acknowledged by the peer (that is, either the "Reset Recvd" or
"Data Recvd" state is reached on the sending part of the stream). "Data Recvd" state is reached on the sending part of the stream).
The content of a RESET_STREAM frame MUST NOT change when it is The content of a RESET_STREAM frame MUST NOT change when it is
sent again. sent again.
o Similarly, a request to cancel stream transmission, as encoded in o Similarly, a request to cancel stream transmission, as encoded in
a STOP_SENDING frame, is sent until the receiving part of the a STOP_SENDING frame, is sent until the receiving part of the
stream enters either a "Data Recvd" or "Reset Recvd" state, see stream enters either a "Data Recvd" or "Reset Recvd" state; see
Section 3.5. Section 3.5.
o Connection close signals, including packets that contain o 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.
o The current connection maximum data is sent in MAX_DATA frames. o 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
skipping to change at page 71, line 24 skipping to change at page 72, line 40
corresponding limit. These frames always include the limit that corresponding limit. These frames always include the limit that
is causing blocking at the time that they are transmitted. is causing blocking at the time that they are transmitted.
o A liveness or path validation check using PATH_CHALLENGE frames is o A liveness or path validation check using PATH_CHALLENGE frames is
sent periodically until a matching PATH_RESPONSE frame is received sent periodically until a matching PATH_RESPONSE frame is received
or until there is no remaining need for liveness or path or until there is no remaining need for liveness or path
validation checking. PATH_CHALLENGE frames include a different validation checking. PATH_CHALLENGE frames include a different
payload each time they are sent. payload each time they are sent.
o Responses to path validation using PATH_RESPONSE frames are sent o Responses to path validation using PATH_RESPONSE frames are sent
just once. A new PATH_CHALLENGE frame will be sent if another just once. The peer is expected to send more PATH_CHALLENGE
PATH_RESPONSE frame is needed. frames as necessary to evoke additional PATH_RESPONSE frames.
o New connection IDs are sent in NEW_CONNECTION_ID frames and o New connection IDs are sent in NEW_CONNECTION_ID frames and
retransmitted if the packet containing them is lost. retransmitted if the packet containing them is lost.
Retransmissions of this frame carry the same sequence number Retransmissions of this frame carry the same sequence number
value. Likewise, retired connection IDs are sent in value. Likewise, retired connection IDs are sent in
RETIRE_CONNECTION_ID frames and retransmitted if the packet RETIRE_CONNECTION_ID frames and retransmitted if the packet
containing them is lost. containing them is lost.
o PING and PADDING frames contain no information, so lost PING or o PING and PADDING frames contain no information, so lost PING or
PADDING frames do not require repair. PADDING frames do not require repair.
skipping to change at page 74, line 37 skipping to change at page 76, line 4
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 header. but not the UDP or IP header.
Clients MUST ensure they send the first Initial packet in a single IP Clients MUST ensure they send the first Initial packet in a single IP
packet. Similarly, the first Initial packet sent after receiving a packet. Similarly, the first Initial packet sent after receiving a
Retry packet MUST be sent in a single IP packet. Retry packet MUST be sent in a single IP packet.
The payload of a UDP datagram carrying the first Initial packet MUST The payload of a UDP datagram carrying the first Initial packet MUST
be expanded to at least 1200 bytes, by adding PADDING frames to the be expanded to at least 1200 bytes, by adding PADDING frames to the
Initial packet and/or by combining the Initial packet with a 0-RTT Initial packet and/or by coalescing the Initial packet (see
packet (see Section 12.2). Sending a UDP datagram of this size Section 12.2). Sending a UDP datagram of this size ensures that the
ensures that the network path supports a reasonable Maximum network path supports a reasonable Maximum Transmission Unit (MTU),
Transmission Unit (MTU), and helps reduce the amplitude of and helps reduce the amplitude of amplification attacks caused by
amplification attacks caused by server responses toward an unverified server responses toward an unverified client address; see Section 8.
client address, see Section 8.
The datagram containing the first Initial packet from a client MAY The datagram containing the first Initial packet from a client MAY
exceed 1200 bytes if the client believes that the Path Maximum exceed 1200 bytes if the client believes that the Path Maximum
Transmission Unit (PMTU) supports the size that it chooses. Transmission Unit (PMTU) supports the size that it chooses.
A server MAY send a CONNECTION_CLOSE frame with error code A server MAY send a CONNECTION_CLOSE frame with error code
PROTOCOL_VIOLATION in response to the first Initial packet it PROTOCOL_VIOLATION in response to the first Initial packet it
receives from a client if the UDP datagram is smaller than 1200 receives from a client if the UDP datagram is smaller than 1200
bytes. It MUST NOT send any other frame type in response, or bytes. It MUST NOT send any other frame type in response, or
otherwise behave as if any part of the offending packet was processed otherwise behave as if any part of the offending packet was processed
as valid. as valid.
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.1. Path Maximum Transmission Unit (PMTU) 14.1. Path Maximum Transmission Unit (PMTU)
The PMTU is the maximum size of the entire IP packet including the IP The PMTU is the maximum size of the entire IP packet including the IP
header, UDP header, and UDP payload. The UDP payload includes the header, UDP header, and UDP payload. The UDP payload includes the
QUIC packet header, protected payload, and any authentication fields. QUIC packet header, protected payload, and any authentication fields.
The PMTU can depend upon the current path characteristics. The PMTU can depend upon the current path characteristics.
Therefore, the current largest UDP payload an implementation will Therefore, the current largest UDP payload an implementation will
send is referred to as the QUIC maximum packet size. send is referred to as the QUIC maximum packet size.
skipping to change at page 77, line 25 skipping to change at page 78, line 36
These frames might not be retransmitted if a probe packet containing These frames might not be retransmitted if a probe packet containing
them is lost. However, these frames do consume congestion window, them is lost. However, these frames do consume congestion window,
which could delay the transmission of subsequent application data. which could delay the transmission of subsequent application data.
A PING frame can be included in a PMTU probe to ensure that a valid A PING frame can be included in a PMTU probe to ensure that a valid
probe is acknowledged. probe is acknowledged.
The considerations for processing ICMP messages in the previous The considerations for processing ICMP messages in the previous
section also apply if these messages are used by DPLPMTUD. section also apply if these messages are used by DPLPMTUD.
14.3.1. PMTU Probes Containing Source Connection ID
Endpoints that rely on the destination connection ID for routing QUIC
packets are likely to require that the connection ID be included in
PMTU probe packets to route any resulting ICMP messages
(Section 14.2) back to the correct endpoint. However, only long
header packets (Section 17.2) contain source connection IDs, and long
header packets are not decrypted or acknowledged by the peer once the
handshake is complete. One way to construct a PMTU probe is to
coalesce (see Section 12.2) a Handshake packet (Section 17.2.4) with
a short header packet in a single UDP datagram. If the UDP datagram
reaches the endpoint, the Handshake packet will be ignored, but the
short header packet will be acknowledged. If the UDP datagram
elicits an ICMP message, that message will likely contain the source
connection ID within the quoted portion of the UDP datagram.
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 to this
version. The properties of QUIC that are guaranteed to be consistent version. The properties of QUIC that are guaranteed to be consistent
skipping to change at page 81, line 25 skipping to change at page 83, line 9
DCIL and SCIL: The byte following the version contains the lengths DCIL and SCIL: The byte following the version contains the lengths
of the two connection ID fields that follow it. These lengths are of the two connection ID fields that follow it. These lengths are
encoded as two 4-bit unsigned integers. The Destination encoded as two 4-bit unsigned integers. The Destination
Connection ID Length (DCIL) field occupies the 4 high bits of the Connection ID Length (DCIL) field occupies the 4 high bits of the
byte and the Source Connection ID Length (SCIL) field occupies the byte and the Source Connection ID Length (SCIL) field occupies the
4 low bits of the byte. An encoded length of 0 indicates that the 4 low bits of the byte. An encoded length of 0 indicates that the
connection ID is also 0 bytes in length. Non-zero encoded lengths connection ID is also 0 bytes in length. Non-zero encoded lengths
are increased by 3 to get the full length of the connection ID, are increased by 3 to get the full length of the connection ID,
producing a length between 4 and 18 bytes inclusive. For example, producing a length between 4 and 18 bytes inclusive. For example,
an byte with the value 0x50 describes an 8-byte Destination a byte with the value 0x50 describes an 8-byte Destination
Connection ID and a zero-length Source Connection ID. Connection ID and a zero-length Source Connection ID.
Destination Connection ID: The Destination Connection ID field Destination Connection ID: The Destination Connection ID field
follows the connection ID lengths and is either 0 bytes in length follows the connection ID lengths and is either 0 bytes in length
or between 4 and 18 bytes. Section 7.2 describes the use of this or between 4 and 18 bytes. Section 7.2 describes the use of this
field in more detail. field in more detail.
Source Connection ID: The Source Connection ID field follows the Source Connection ID: The Source Connection ID field follows the
Destination Connection ID and is either 0 bytes in length or Destination Connection ID and is either 0 bytes in length or
between 4 and 18 bytes. Section 7.2 describes the use of this between 4 and 18 bytes. Section 7.2 describes the use of this
skipping to change at page 86, line 43 skipping to change at page 88, line 13
first do not need to fit within a single UDP datagram. first do not need to fit within a single UDP datagram.
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.10 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 Sections 5.3.1.2 and 6.9 of congestion control state (see Section 6.5 of [QUIC-RECOVERY]).
[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. The first byte contains the
Reserved and Packet Number Length bits. It is used to carry "early" Reserved and Packet Number Length bits. It is used to carry "early"
data from the client to the server as part of the first flight, prior data from the client to the server as part of the first flight, prior
skipping to change at page 87, line 44 skipping to change at page 89, line 9
0-RTT Packet 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 MAY attempt to have been lost or discarded by the server. A client MAY attempt to
resend data in 0-RTT packets after it sends a new Initial packet. resend data in 0-RTT packets after it sends a new Initial packet.
A client MUST NOT reset the packet number it uses for 0-RTT packets. A client MUST NOT reset the packet number it uses for 0-RTT packets,
The keys used to protect 0-RTT packets will not change as a result of since the keys used to protect 0-RTT packets will not change as a
responding to a Retry packet unless the client also regenerates the result of responding to a Retry packet. Sending packets with the
cryptographic handshake message. Sending packets with the same same packet number in that case is likely to compromise the packet
packet number in that case is likely to compromise the packet
protection for all 0-RTT packets because the same key and nonce could protection for all 0-RTT packets because the same key and nonce could
be used to protect different content. be used to protect different content.
Receiving a Retry packet, especially a Retry that changes the A client only receives acknowledgments for its 0-RTT packets once the
connection ID used for subsequent packets, indicates a strong handshake is complete. Consequently, a server might expect 0-RTT
possibility that 0-RTT packets could be lost. A client only receives packets to start with a packet number of 0. Therefore, in
acknowledgments for its 0-RTT packets once the handshake is complete. determining the length of the packet number encoding for 0-RTT
Consequently, a server might expect 0-RTT packets to start with a packets, a client MUST assume that all packets up to the current
packet number of 0. Therefore, in determining the length of the packet number are in flight, starting from a packet number of 0.
packet number encoding for 0-RTT packets, a client MUST assume that Thus, 0-RTT packets could need to use a longer packet number
all packets up to the current packet number are in flight, starting encoding.
from a packet number of 0. Thus, 0-RTT packets could need to use a
longer packet number encoding.
A client SHOULD instead generate a fresh cryptographic handshake A client MUST NOT send 0-RTT packets once it starts processing 1-RTT
message and start packet numbers from 0. This ensures that new 0-RTT packets from the server. This means that 0-RTT packets cannot
packets will not use the same keys, avoiding any risk of key and contain any response to frames from 1-RTT packets. For instance, a
nonce reuse; this also prevents 0-RTT packets from previous handshake client cannot send an ACK frame in a 0-RTT packet, because that can
attempts from being accepted as part of the connection. only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT
packet MUST be carried in a 1-RTT packet.
A server SHOULD treat a violation of remembered limits as a
connection error of an appropriate type (for 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. The first byte
contains the Reserved and Packet Number Length bits. It is used to contains the Reserved and Packet Number Length bits. It is used to
carry acknowledgments and cryptographic handshake messages from the carry acknowledgments and cryptographic handshake messages from the
server and client. server and client.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 89, line 27 skipping to change at page 90, line 51
packets with other frames as a connection error. packets with other frames as a connection error.
Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at
the Handshake encryption level is discarded - and no longer the Handshake encryption level is discarded - and no longer
retransmitted - when Handshake protection keys are discarded. retransmitted - when Handshake protection keys are discarded.
17.2.5. Retry Packet 17.2.5. Retry Packet
A Retry packet uses a long packet header with a type value of 0x3. A Retry packet uses a long packet header with a type value of 0x3.
It carries an address validation token created by the server. It is It carries an address validation token created by the server. It is
used by a server that wishes to perform a stateless retry (see used by a server that wishes to perform a retry (see Section 8.1).
Section 8.1).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|1| 3 | ODCIL | |1|1| 3 | ODCIL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) | | Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)| |DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 91, line 13 skipping to change at page 92, line 37
packet. Changing Destination Connection ID also results in a change packet. Changing Destination Connection ID also results in a change
to the keys used to protect the Initial packet. It also sets the to the keys used to protect the Initial packet. It also sets the
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.3). Section 8.1.3).
The next Initial packet from the client uses the connection ID and The next Initial packet from the client uses the connection ID and
token values from the Retry packet (see Section 7.2). Aside from token values from the Retry packet (see Section 7.2). Aside from
this, the Initial packet sent by the client is subject to the same this, the Initial packet sent by the client is subject to the same
restrictions as the first Initial packet. A client can either reuse restrictions as the first Initial packet. A client MUST use the same
the cryptographic handshake message or construct a new one at its cryptographic handshake message it includes in this packet. A server
discretion. MAY treat a packet that contains a different cryptographic handshake
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
that sends additional 0-RTT packets without constructing a new MUST NOT change the cryptographic handshake message it sends in
cryptographic handshake message MUST NOT reset the packet number to 0 response to receiving a Retry.
after a Retry packet, see Section 17.2.3.
A client MUST NOT reset the packet number for any packet number space
after processing a Retry packet; Section 17.2.3 contains more
information on this.
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 original_connection_id transport parameter (see using the original_connection_id transport parameter (see
Section 18.1). If the server sends a Retry packet, it MUST include Section 18.1). If the server sends a Retry packet, it MUST include
the value of the Original Destination Connection ID field of the the value of the Original Destination Connection ID field of the
Retry packet (that is, the Destination Connection ID field from the Retry packet (that is, the Destination Connection ID field from the
client's first Initial packet) in the transport parameter. client's first Initial packet) in the transport 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 original_connection_id transport parameter is present and that the original_connection_id transport parameter is present and
skipping to change at page 93, line 48 skipping to change at page 95, line 20
chooses to support the spin bit MUST implement it as specified in chooses to support the spin bit MUST implement it as specified in
this section. this section.
Each endpoint unilaterally decides if the spin bit is enabled or Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection. Implementations MUST allow administrators disabled for a connection. Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on of clients and servers to disable the spin bit either globally or on
a per-connection basis. Even when the spin bit is not disabled by a per-connection basis. Even when the spin bit is not disabled by
the administrator, implementations MUST disable the spin bit for a the administrator, implementations MUST disable the spin bit for a
given connection with a certain likelihood. The random selection given connection with a certain likelihood. The random selection
process SHOULD be designed such that on average the spin bit is process SHOULD be designed such that on average the spin bit is
disabled for at least one eighth of connections. The selection disabled for at least one eighth of network paths. The selection
process performed at the beginning of the connection SHOULD be process performed at the beginning of the connection SHOULD be
applied for all paths used by the connection. applied for all paths used by the connection.
In case multiple connections share the same five-tuple, that is, have In case multiple connections share the same network path, as
the same source and destination IP address and UDP ports, endpoints determined by having the same source and destination IP address and
should try to co-ordinate across all connections to ensure a clear UDP ports, endpoints should try to co-ordinate across all connections
signal to any on-path measurement points. to ensure a clear signal to any on-path measurement points.
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 and sets the spin bit in the short header to the
currently stored value when a packet with a short header is sent out. currently stored value when a packet with a short header is sent out.
skipping to change at page 95, line 20 skipping to change at page 96, line 33
initial_max_data(4), initial_max_data(4),
initial_max_stream_data_bidi_local(5), initial_max_stream_data_bidi_local(5),
initial_max_stream_data_bidi_remote(6), initial_max_stream_data_bidi_remote(6),
initial_max_stream_data_uni(7), initial_max_stream_data_uni(7),
initial_max_streams_bidi(8), initial_max_streams_bidi(8),
initial_max_streams_uni(9), initial_max_streams_uni(9),
ack_delay_exponent(10), ack_delay_exponent(10),
max_ack_delay(11), max_ack_delay(11),
disable_migration(12), disable_migration(12),
preferred_address(13), preferred_address(13),
active_connection_id_limit(14),
(65535) (65535)
} TransportParameterId; } TransportParameterId;
struct { struct {
TransportParameterId parameter; TransportParameterId parameter;
opaque value<0..2^16-1>; opaque value<0..2^16-1>;
} TransportParameter; } TransportParameter;
TransportParameter TransportParameters<0..2^16-1>; TransportParameter TransportParameters<0..2^16-1>;
skipping to change at page 96, line 12 skipping to change at page 97, line 27
The following transport parameters are defined: The following transport parameters are defined:
original_connection_id (0x0000): The value of the Destination original_connection_id (0x0000): The value of the Destination
Connection ID field from the first Initial packet sent by the Connection ID field from the first Initial packet sent by the
client. This transport parameter is only sent by a server. A client. This transport parameter is only sent by a server. A
server MUST include the original_connection_id transport parameter server MUST include the original_connection_id transport parameter
if it sent a Retry packet. if it sent a Retry packet.
idle_timeout (0x0001): The idle timeout is a value in milliseconds idle_timeout (0x0001): The idle timeout is a value in milliseconds
that is encoded as an integer, see (Section 10.2). If this that is encoded as an integer; see (Section 10.2). If this
parameter is absent or zero then the idle timeout is disabled. parameter is absent or zero then the idle timeout is disabled.
stateless_reset_token (0x0002): A stateless reset token is used in stateless_reset_token (0x0002): 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.4. This parameter is
a sequence of 16 bytes. This transport parameter is only sent by a sequence of 16 bytes. This transport parameter MUST NOT be sent
a server. by a client, but MAY be sent by a server. A server that does not
send this transport parameter cannot use stateless reset
(Section 10.4) for the connection ID negotiated during the
handshake.
max_packet_size (0x0003): The maximum packet size parameter is an max_packet_size (0x0003): The maximum packet size parameter is an
integer value that limits the size of packets that the endpoint is integer value that limits the size of packets that the endpoint is
willing to receive. This indicates that packets larger than this willing to receive. This indicates that packets larger than this
limit will be dropped. The default for this parameter is the limit will be dropped. The default for this parameter is the
maximum permitted UDP payload of 65527. Values below 1200 are maximum permitted UDP payload of 65527. Values below 1200 are
invalid. This limit only applies to protected packets invalid. This limit only applies to protected packets
(Section 12.1). (Section 12.1).
initial_max_data (0x0004): The initial maximum data parameter is an initial_max_data (0x0004): The initial maximum data parameter is an
skipping to change at page 97, line 33 skipping to change at page 99, line 4
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 (0x000a): The ACK delay exponent is an integer ack_delay_exponent (0x000a): The ACK delay exponent is an integer
value indicating an exponent used to decode the ACK Delay field in value indicating an exponent used to decode the ACK Delay field in
the ACK frame (Section 19.3). If this value is absent, a default the ACK frame (Section 19.3). If this value is absent, a default
value of 3 is assumed (indicating a multiplier of 8). The default value of 3 is assumed (indicating a multiplier of 8). Values
value is also used for ACK frames that are sent in Initial and above 20 are invalid.
Handshake packets. Values above 20 are invalid.
max_ack_delay (0x000b): The maximum ACK delay is an integer value max_ack_delay (0x000b): The maximum ACK delay is an integer value
indicating the maximum amount of time in milliseconds by which the indicating the maximum amount of time in milliseconds by which the
endpoint will delay sending acknowledgments. This value SHOULD endpoint will delay sending acknowledgments. This value SHOULD
include the receiver's expected delays in alarms firing. For include the receiver's expected delays in alarms firing. For
example, if a receiver sets a timer for 5ms and alarms commonly example, if a receiver sets a timer for 5ms and alarms commonly
fire up to 1ms late, then it should send a max_ack_delay of 6ms. fire up to 1ms late, then it should send a max_ack_delay of 6ms.
If this value is absent, a default of 25 milliseconds is assumed. If this value is absent, a default of 25 milliseconds is assumed.
Values of 2^14 or greater are invalid. Values of 2^14 or greater are invalid.
skipping to change at page 98, line 25 skipping to change at page 99, line 44
opaque ipv4Address[4]; opaque ipv4Address[4];
uint16 ipv4Port; uint16 ipv4Port;
opaque ipv6Address[16]; opaque ipv6Address[16];
uint16 ipv6Port; uint16 ipv6Port;
opaque connectionId<0..18>; opaque connectionId<0..18>;
opaque statelessResetToken[16]; opaque statelessResetToken[16];
} PreferredAddress; } PreferredAddress;
Figure 16: Preferred Address format Figure 16: Preferred Address format
active_connection_id_limit (0x000e): The maximum number of
connection IDs from the peer that an endpoint is willing to store.
This value includes only connection IDs sent in NEW_CONNECTION_ID
frames. If this parameter is absent, a default of 0 is assumed.
If present, transport parameters that set initial flow control limits If present, transport parameters that set initial flow control limits
(initial_max_stream_data_bidi_local, (initial_max_stream_data_bidi_local,
initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni)
are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on
every stream of the corresponding type immediately after opening. If every stream of the corresponding type immediately after opening. If
the transport parameter is absent, streams of that type start with a the transport parameter is absent, streams of that type start with a
flow control limit of 0. flow control limit of 0.
A client MUST NOT include an original connection ID, a stateless A client MUST NOT include an original connection ID, a stateless
reset token, or a preferred address. A server MUST treat receipt of reset token, or a preferred address. A server MUST treat receipt of
skipping to change at page 100, line 41 skipping to change at page 102, line 19
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 representing the time delta in
microseconds between when this ACK was sent and when the largest microseconds between when this ACK was sent and when the largest
acknowledged packet, as indicated in the Largest Acknowledged acknowledged packet, as indicated in the Largest Acknowledged
field, was received by this peer. The value of the ACK Delay field, was received by this peer. The value of the ACK Delay
field is scaled by multiplying the encoded value by 2 to the power field is scaled by multiplying the encoded value by 2 to the power
of the value of the "ack_delay_exponent" transport parameter set of the value of the "ack_delay_exponent" transport parameter set
by the sender of the ACK frame. The "ack_delay_exponent" defaults by the sender of the ACK frame (see Section 18.1). Scaling in
to 3, or a multiplier of 8 (see Section 18.1). Scaling in this this fashion allows for a larger range of values with a shorter
fashion allows for a larger range of values with a shorter encoding at the cost of lower resolution. Because the receiver
encoding at the cost of lower resolution. 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 which 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
The ACK Ranges field consists of alternating Gap and ACK Range values The ACK Ranges field consists of alternating Gap and ACK Range values
in descending packet number order. The number of Gap and ACK Range in descending packet number order. The number of Gap and ACK Range
values is determined by the ACK Range Count field; one of each value values is determined by the ACK Range Count field; one of each value
is present for each value in the ACK Range Count field. is present for each value in the ACK Range Count field.
ACK Ranges are structured as follows: ACK Ranges are structured as follows:
skipping to change at page 103, line 48 skipping to change at page 105, line 25
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 as follows: The RESET_STREAM frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Error Code (16) | | Application Error Code (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Final Size (i) ... | Final Size (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 16-bit application protocol error Application Protocol Error Code: A variable-length integer
code (see Section 20.1) which indicates why the stream is being containing the application protocol error code (see Section 20.1)
closed. which 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.
19.5. STOP_SENDING Frame 19.5. STOP_SENDING Frame
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.
skipping to change at page 104, line 36 skipping to change at page 106, line 14
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 as follows: The STOP_SENDING frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Error Code (16) | | Application Error Code (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Error Code: A 16-bit, application-specified reason the Application Error Code: A variable-length integer containing the
sender is ignoring the stream (see Section 20.1). application-specified reason the sender is ignoring the stream
(see Section 20.1).
19.6. CRYPTO Frame 19.6. CRYPTO Frame
The CRYPTO frame (type=0x06) is used to transmit cryptographic The CRYPTO frame (type=0x06) is used to transmit cryptographic
handshake messages. It can be sent in all packet types. The CRYPTO handshake messages. It can be sent in all packet types. The CRYPTO
frame offers the cryptographic protocol an in-order stream of bytes. frame offers the cryptographic protocol an in-order stream of bytes.
CRYPTO frames are functionally identical to STREAM frames, except CRYPTO frames are functionally identical to STREAM frames, except
that they do not bear a stream identifier; they are not flow 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 as follows: The CRYPTO frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 106, line 8 skipping to change at page 107, line 34
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 as follows: The NEW_TOKEN frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Length (i) ... | Token Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (*) ... | Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. packet.
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 takes the form 0b00001XXX (or the set of values from
0x08 to 0x0f). The value of the three low-order bits of the frame 0x08 to 0x0f). The value of the three low-order bits of the frame
type determine the fields that are present in the frame. type determines the fields that are present in the frame.
o The OFF bit (0x04) in the frame type is set to indicate that there o The OFF bit (0x04) in the frame type is set to indicate that there
is an Offset field present. When set to 1, the Offset field is is an Offset field present. When set to 1, the Offset field is
present. When set to 0, the Offset field is absent and the Stream present. When set to 0, the Offset field is absent and the Stream
Data starts at an offset of 0 (that is, the frame contains the Data starts at an offset of 0 (that is, the frame contains the
first bytes of the stream, or the end of a stream that includes no first bytes of the stream, or the end of a stream that includes no
data). data).
o The LEN bit (0x02) in the frame type is set to indicate that there o 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 112, line 10 skipping to change at page 113, line 29
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 as follows: The NEW_CONNECTION_ID frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (i) ... | Sequence Number (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retire Prior To (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (8) | | | Length (8) | |
+-+-+-+-+-+-+-+-+ Connection ID (32..144) + +-+-+-+-+-+-+-+-+ Connection ID (32..144) +
| ... | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Stateless Reset Token (128) + + Stateless Reset Token (128) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. See Section 5.1.1.
Retire Prior To: A variable-length integer indicating which
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 4 and greater than 18 are invalid connection ID. Values less than 4 and greater than 18 are invalid
and MUST be treated as a connection error of type and MUST be treated as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
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.4).
skipping to change at page 113, line 11 skipping to change at page 114, line 36
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 identify new connection IDs from old ones.
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 is a request for the peer to retire all
connection IDs with a sequence number less than the specified value.
This includes the initial and preferred_address transport parameter
connection IDs. The peer SHOULD retire the corresponding connection
IDs and send the corresponding RETIRE_CONNECTION_ID frames in a
timely manner.
The Retire Prior To field MUST be less than or equal to the Sequence
Number field. Receiving a value greater than the Sequence Number
MUST be treated as a connection error of type PROTOCOL_VIOLATION.
Once a sender indicates a Retire Prior To value, smaller values sent
in subsequent NEW_CONNECTION_ID frames have no effect. A receiver
MUST ignore any Retire Prior To fields that do not increase the
largest received Retire Prior To value.
19.16. RETIRE_CONNECTION_ID Frame 19.16. RETIRE_CONNECTION_ID Frame
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 (see Section 5.1). New connection IDs can be delivered to a peer
using the NEW_CONNECTION_ID frame (Section 19.15). using the NEW_CONNECTION_ID frame (Section 19.15).
skipping to change at page 115, line 10 skipping to change at page 117, line 8
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 haven't 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 as follows: The CONNECTION_CLOSE frames are as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (16) | [ Frame Type (i) ] ... | Error Code (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Frame Type (i) ] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase Length (i) ... | Reason Phrase Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (*) ... | Reason Phrase (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CONNECTION_CLOSE frames contain the following fields: CONNECTION_CLOSE frames contain the following fields:
Error Code: A 16-bit error code which indicates the reason for Error Code: A variable length integer error code which indicates the
closing this connection. A CONNECTION_CLOSE frame of type 0x1c reason for closing this connection. A CONNECTION_CLOSE frame of
uses codes from the space defined in Section 20. A type 0x1c uses codes from the space defined in Section 20. 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.1
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
skipping to change at page 116, line 12 skipping to change at page 118, line 12
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 one or more extension frame types with the one transport
parameter. parameter.
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.2. Section 22.2.
20. Transport Error Codes 20. Transport Error Codes
QUIC error codes are 16-bit unsigned integers. QUIC error codes are 62-bit unsigned integers.
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. These errors apply to the entire
connection. 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
skipping to change at page 117, line 35 skipping to change at page 119, line 35
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.3 for details of registering new error codes. See Section 22.3 for details of registering new error codes.
20.1. Application Protocol Error Codes 20.1. Application Protocol Error Codes
Application protocol error codes are 16-bit unsigned integers, but Application protocol error codes are 62-bit unsigned integers, but
the management of application error codes are 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
skipping to change at page 120, line 45 skipping to change at page 122, line 45
21.7. Explicit Congestion Notification Attacks 21.7. 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 receivers ignore ECN codepoints set in attack. Therefore, QUIC endpoints ignore the ECN codepoint field on
duplicate packets (see Section 13.3). an IP packet unless at least one QUIC packet in that IP packet is
successfully processed; see Section 13.3.
21.8. Stateless Reset Oracle 21.8. 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.
skipping to change at page 121, line 43 skipping to change at page 123, line 43
This document defines QUIC Version Negotiation packets Section 6, This document defines QUIC Version Negotiation packets Section 6,
which can be used to negotiate the QUIC version used between two which 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.10. Targeted Attacks by Routing
Deployments should limit the ability of an attacker to target a new
connection to a particular server instance. This means that client-
controlled fields, such as the initial Destination Connection ID used
on Initial and 0-RTT packets SHOULD NOT be used by themselves to make
routing decisions. Ideally, routing decisions are made independently
of client-selected values; a Source Connection ID can be selected to
route later packets to the same server.
22. IANA Considerations 22. IANA Considerations
22.1. QUIC Transport Parameter Registry 22.1. 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 Protocol" heading. under a "QUIC Protocol" heading.
The "QUIC Transport Parameters" registry governs a 16-bit space. The "QUIC Transport Parameters" registry governs a 16-bit space.
This space is split into two spaces that are governed by different This space is split into two spaces that are governed by different
policies. Values with the first byte in the range 0x00 to 0xfe (in policies. Values with the first byte in the range 0x00 to 0xfe (in
skipping to change at page 123, line 35 skipping to change at page 125, line 35
| | | | | | | |
| 0x0009 | initial_max_streams_uni | Section 18.1 | | 0x0009 | initial_max_streams_uni | Section 18.1 |
| | | | | | | |
| 0x000a | ack_delay_exponent | Section 18.1 | | 0x000a | ack_delay_exponent | Section 18.1 |
| | | | | | | |
| 0x000b | max_ack_delay | Section 18.1 | | 0x000b | max_ack_delay | Section 18.1 |
| | | | | | | |
| 0x000c | disable_migration | Section 18.1 | | 0x000c | disable_migration | Section 18.1 |
| | | | | | | |
| 0x000d | preferred_address | Section 18.1 | | 0x000d | preferred_address | Section 18.1 |
| | | |
| 0x000e | active_connection_id_limit | Section 18.1 |
+--------+-------------------------------------+---------------+ +--------+-------------------------------------+---------------+
Table 6: Initial QUIC Transport Parameters Entries Table 6: Initial QUIC Transport Parameters Entries
22.2. QUIC Frame Type Registry 22.2. QUIC Frame Type 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 Protocol" heading. "QUIC Protocol" heading.
The "QUIC Frame Types" registry governs a 62-bit space. This space The "QUIC Frame Types" registry governs a 62-bit space. This space
skipping to change at page 124, line 32 skipping to change at page 126, line 34
unless they are abusive, frivolous, or actively harmful (not merely unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious). aesthetically displeasing, or architecturally dubious).
The initial contents of this registry are tabulated in Table 3. The initial contents of this registry are tabulated in Table 3.
22.3. QUIC Transport Error Codes Registry 22.3. 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 Protocol" heading. Codes" under a "QUIC Protocol" heading.
The "QUIC Transport Error Codes" registry governs a 16-bit space. The "QUIC Transport Error Codes" registry governs a 62-bit space.
This space is split into two spaces that are governed by different This space is split into three spaces that are governed by different
policies. Values with the first byte in the range 0x00 to 0xfe (in policies. Values between 0x00 and 0x3f (in hexadecimal) are assigned
hexadecimal) are assigned via the Specification Required policy via the Standards Action or IESG Review policies [RFC8126]. Values
[RFC8126]. Values with the first byte 0xff are reserved for Private from 0x40 to 0x3fff operate on the Specification Required policy
Use [RFC8126]. [RFC8126]. All other values are assigned to Private Use [RFC8126].
Registrations MUST include the following fields: Registrations MUST include the following fields:
Value: The numeric value of the assignment (registrations will be Value: The numeric value of the assignment (registrations will be
between 0x0000 and 0xfeff). between 0x0000 and 0x3fff).
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.
Specification: A reference to a publicly available specification for Specification: A reference to a publicly available specification for
the value. the value.
The initial contents of this registry are shown in Table 7. Values The nominated expert(s) verify that a specification exists and is
from 0xFF00 to 0xFFFF are reserved for Private Use [RFC8126]. readily accessible. Expert(s) are encouraged to be biased towards
approving registrations unless they are abusive, frivolous, or
actively harmful (not merely aesthetically displeasing, or
architecturally dubious).
The initial contents of this registry are shown in Table 7.
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| Valu | Error | Description | Specification | | Valu | Error | Description | Specification |
| e | | | | | e | | | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 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 | |
| | | | | | | | | |
skipping to change at page 126, line 6 skipping to change at page 129, line 4
| | | violation | | | | | violation | |
| | | | | | | | | |
| 0xC | INVALID_MIGRATION | Violated | Section 20 | | 0xC | INVALID_MIGRATION | Violated | Section 20 |
| | | disabled | | | | | disabled | |
| | | migration | | | | | migration | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
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] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and 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", draft-ietf-tsvwg-datagram-plpmtud-07 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08
(work in progress), February 2019. (work in progress), June 2019.
[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", draft-ietf-quic-recovery-20 (work and Congestion Control", draft-ietf-quic-recovery-21 (work
in progress), April 2019. in progress), July 2019.
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
tls-20 (work in progress), April 2019. tls-21 (work in progress), July 2019.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/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 127, line 50 skipping to change at page 130, line 50
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[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>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-04 (work in progress), April draft-ietf-quic-invariants-05 (work in progress), July
2019. 2019.
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-03 Transport Protocol", draft-ietf-quic-manageability-05
(work in progress), October 2018. (work in progress), July 2019.
[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>.
[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>.
skipping to change at page 130, line 5 skipping to change at page 133, line 5
return candidate_pn - pn_win return candidate_pn - pn_win
return candidate_pn return candidate_pn
Appendix B. Change Log Appendix B. 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.
B.1. Since draft-ietf-quic-transport-19 B.1. Since draft-ietf-quic-transport-20
o Connection ID lengths are now one octet, but limited in version 1
to 20 octets of length (#2736, #2749)
o Error codes are encoded as variable-length integers (#2672, #2680)
o NEW_CONNECTION_ID includes a request to retire old connection IDs
(#2645, #2769)
o Tighter rules for generating and explicitly eliciting ACK frames
(#2546, #2794)
o Recommend having only one packet per encryption level in a
datagram (#2308, #2747)
o More normative language about use of stateless reset (#2471,
#2574)
o Allow reuse of stateless reset tokens (#2732, #2733)
o Allow, but not require, enforcing non-duplicate transport
parameters (#2689, #2691)
o Added a active_connection_id_limit transport parameter (#1994,
#1998)
o max_ack_delay transport parameter defaults to 0 (#2638, #2646)
o When sending 0-RTT, only remembered transport parameters apply
(#2458, #2360, #2466, #2461)
o Define handshake completion and confirmation; define clearer rules
when it encryption keys should be discarded (#2214, #2267, #2673)
o Prohibit path migration prior to handshake confirmation (#2309,
#2370)
o PATH_RESPONSE no longer needs to be received on the validated path
(#2582, #2580, #2579, #2637)
o PATH_RESPONSE frames are not stored and retransmitted (#2724,
#2729)
o Document hack for enabling routing of ICMP when doing PMTU probing
(#1243, #2402)
B.2. Since draft-ietf-quic-transport-19
o Refine discussion of 0-RTT transport parameters (#2467, #2464) o Refine discussion of 0-RTT transport parameters (#2467, #2464)
o Fewer transport parameters need to be remembered for 0-RTT (#2624, o Fewer transport parameters need to be remembered for 0-RTT (#2624,
#2467) #2467)
o Spin bit text incorporated (#2564) o Spin bit text incorporated (#2564)
o Close the connection when maximum stream ID in MAX_STREAMS exceeds o Close the connection when maximum stream ID in MAX_STREAMS exceeds
2^62 - 1 (#2499, #2487) 2^62 - 1 (#2499, #2487)
skipping to change at page 130, line 32 skipping to change at page 134, line 32
o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
o Initial packets from clients need to be padded to 1200 unless a o 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)
o CRYPTO frames can be discarded if too much data is buffered o CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524) (#1834, #2524)
o Stateless reset uses a short header packet (#2599, #2600) o Stateless reset uses a short header packet (#2599, #2600)
B.2. Since draft-ietf-quic-transport-18 B.3. Since draft-ietf-quic-transport-18
o Removed version negotation; version negotiation, including o 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)
o Added discussion of the use of IPv6 flow labels (#2348, #2399) o Added discussion of the use of IPv6 flow labels (#2348, #2399)
o A connection ID can't be retired in a packet that uses that o A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420) connection ID (#2101, #2420)
o Idle timeout transport parameter is in milliseconds (from seconds) o Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454) (#2453, #2454)
o Endpoints are required to use new connnection IDs when they use o Endpoints are required to use new connection IDs when they use new
new network paths (#2413, #2414) network paths (#2413, #2414)
o Increased the set of permissible frames in 0-RTT (#2344, #2355) o Increased the set of permissible frames in 0-RTT (#2344, #2355)
B.3. Since draft-ietf-quic-transport-17 B.4. Since draft-ietf-quic-transport-17
o Stream-related errors now use STREAM_STATE_ERROR (#2305) o Stream-related errors now use STREAM_STATE_ERROR (#2305)
o Endpoints discard initial keys as soon as handshake keys are o Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
o Expanded conditions for ignoring ICMP packet too big messages o Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161) (#2108, #2161)
o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
skipping to change at page 131, line 44 skipping to change at page 135, line 44
#2301) #2301)
o Allow server preferred address for both IPv4 and IPv6 (#2122, o Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296) #2296)
o Corrected requirements for migration to a preferred address o Corrected requirements for migration to a preferred address
(#2146, #2349) (#2146, #2349)
o ACK of non-existent packet is illegal (#2298, #2302) o ACK of non-existent packet is illegal (#2298, #2302)
B.4. Since draft-ietf-quic-transport-16 B.5. Since draft-ietf-quic-transport-16
o Stream limits are defined as counts, not maximums (#1850, #1906) o Stream limits are defined as counts, not maximums (#1850, #1906)
o Require amplification attack defense after closing (#1905, #1911) o Require amplification attack defense after closing (#1905, #1911)
o Remove reservation of application error code 0 for STOPPING o Remove reservation of application error code 0 for STOPPING
(#1804, #1922) (#1804, #1922)
o Renumbered frames (#1945) o Renumbered frames (#1945)
skipping to change at page 133, line 5 skipping to change at page 137, line 5
o Tokens are repeated in all Initial packets (#2089) o Tokens are repeated in all Initial packets (#2089)
o Clarified how PING frames are sent after loss (#2094) o Clarified how PING frames are sent after loss (#2094)
o Initial keys are discarded once Handshake are available (#1951, o Initial keys are discarded once Handshake are available (#1951,
#2045) #2045)
o ICMP PTB validation clarifications (#2161, #2109, #2108) o ICMP PTB validation clarifications (#2161, #2109, #2108)
B.5. Since draft-ietf-quic-transport-15 B.6. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
B.6. Since draft-ietf-quic-transport-14 B.7. Since draft-ietf-quic-transport-14
o Merge ACK and ACK_ECN (#1778, #1801) o Merge ACK and ACK_ECN (#1778, #1801)
o Explicitly communicate max_ack_delay (#981, #1781) o Explicitly communicate max_ack_delay (#981, #1781)
o Validate original connection ID after Retry packets (#1710, #1486, o Validate original connection ID after Retry packets (#1710, #1486,
#1793) #1793)
o Idle timeout is optional and has no specified maximum (#1765) o Idle timeout is optional and has no specified maximum (#1765)
o Update connection ID handling; add RETIRE_CONNECTION_ID type o 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)
o Include a Token in all Initial packets (#1649, #1794) o Include a Token in all Initial packets (#1649, #1794)
o Prevent handshake deadlock (#1764, #1824) o Prevent handshake deadlock (#1764, #1824)
B.7. Since draft-ietf-quic-transport-13 B.8. Since draft-ietf-quic-transport-13
o Streams open when higher-numbered streams of the same type open o Streams open when higher-numbered streams of the same type open
(#1342, #1549) (#1342, #1549)
o Split initial stream flow control limit into 3 transport o Split initial stream flow control limit into 3 transport
parameters (#1016, #1542) parameters (#1016, #1542)
o All flow control transport parameters are optional (#1610) o All flow control transport parameters are optional (#1610)
o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
skipping to change at page 134, line 17 skipping to change at page 138, line 17
o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, o Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621) #1514, #1621)
o Permit Retry in response to 0-RTT (#1547, #1552) o Permit Retry in response to 0-RTT (#1547, #1552)
o Looser verification of ECN counters to account for ACK loss o Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565) (#1555, #1481, #1565)
o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) o Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
B.8. Since draft-ietf-quic-transport-12 B.9. Since draft-ietf-quic-transport-12
o Changes to integration of the TLS handshake (#829, #1018, #1094, o 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 135, line 14 skipping to change at page 139, line 14
o Fixed sampling method for packet number encryption; the length o 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)
o Stateless Reset is now symmetric and subject to size constraints o Stateless Reset is now symmetric and subject to size constraints
(#466, #1346) (#466, #1346)
o Added frame type extension mechanism (#58, #1473) o Added frame type extension mechanism (#58, #1473)
B.9. Since draft-ietf-quic-transport-11 B.10. Since draft-ietf-quic-transport-11
o Enable server to transition connections to a preferred address o Enable server to transition connections to a preferred address
(#560, #1251) (#560, #1251)
o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
#990, #734, #1317, #1267, #1079) #990, #734, #1317, #1267, #1079)
o Packet numbers use a variable-length encoding (#989, #1334) o Packet numbers use a variable-length encoding (#989, #1334)
o STREAM frames can now be empty (#1350) o STREAM frames can now be empty (#1350)
B.10. Since draft-ietf-quic-transport-10 B.11. Since draft-ietf-quic-transport-10
o Swap payload length and packed number fields in long header o Swap payload length and packed number fields in long header
(#1294) (#1294)
o Clarified that CONNECTION_CLOSE is allowed in Handshake packet o Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
o Spin bit reserved (#1283) o Spin bit reserved (#1283)
o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
skipping to change at page 136, line 12 skipping to change at page 140, line 12
o STOP_SENDING is now prohibited before streams are used (#1050) o STOP_SENDING is now prohibited before streams are used (#1050)
o Recommend including ACK in Retry packets and allow PADDING (#1067, o Recommend including ACK in Retry packets and allow PADDING (#1067,
#882) #882)
o Endpoints now become closing after an idle timeout (#1178, #1179) o Endpoints now become closing after an idle timeout (#1178, #1179)
o Remove implication that Version Negotiation is sent when a packet o Remove implication that Version Negotiation is sent when a packet
of the wrong version is received (#1197) of the wrong version is received (#1197)
B.11. Since draft-ietf-quic-transport-09 B.12. Since draft-ietf-quic-transport-09
o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with o 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)
o A server can now only send 3 packets without validating the client o A server can now only send 3 packets without validating the client
address (#38, #1090) address (#38, #1090)
o Delivery order of stream data is no longer strongly specified o Delivery order of stream data is no longer strongly specified
(#252, #1070) (#252, #1070)
skipping to change at page 136, line 39 skipping to change at page 140, line 39
o Improved retransmission rules for all frame types: information is o 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)
o Added an error code for server busy signals (#1137) o Added an error code for server busy signals (#1137)
o Endpoints now set the connection ID that their peer uses. o 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)
B.12. Since draft-ietf-quic-transport-08 B.13. Since draft-ietf-quic-transport-08
o Clarified requirements for BLOCKED usage (#65, #924) o Clarified requirements for BLOCKED usage (#65, #924)
o BLOCKED frame now includes reason for blocking (#452, #924, #927, o BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
o GAP limitation in ACK Frame (#613) o GAP limitation in ACK Frame (#613)
o Improved PMTUD description (#614, #1036) o Improved PMTUD description (#614, #1036)
skipping to change at page 137, line 19 skipping to change at page 141, line 19
o Stateless reset clarified as version-specific (#930, #986) o Stateless reset clarified as version-specific (#930, #986)
o initial_max_stream_id_x transport parameters are optional (#970, o initial_max_stream_id_x transport parameters are optional (#970,
#971) #971)
o Ack Delay assumes a default value during the handshake (#1007, o Ack Delay assumes a default value during the handshake (#1007,
#1009) #1009)
o Removed transport parameters from NewSessionTicket (#1015) o Removed transport parameters from NewSessionTicket (#1015)
B.13. Since draft-ietf-quic-transport-07 B.14. Since draft-ietf-quic-transport-07
o The long header now has version before packet number (#926, #939) o The long header now has version before packet number (#926, #939)
o Rename and consolidate packet types (#846, #822, #847) o Rename and consolidate packet types (#846, #822, #847)
o Packet types are assigned new codepoints and the Connection ID o Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956) Flag is inverted (#426, #956)
o Removed type for Version Negotiation and use Version 0 (#963, o Removed type for Version Negotiation and use Version 0 (#963,
#968) #968)
skipping to change at page 138, line 15 skipping to change at page 142, line 15
o Address validation for connection migration (#161, #732, #878) o Address validation for connection migration (#161, #732, #878)
o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) o Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
o negotiated_version is sent in server transport parameters (#710, o negotiated_version is sent in server transport parameters (#710,
#959) #959)
o Increased the range over which packet numbers are randomized o Increased the range over which packet numbers are randomized
(#864, #850, #964) (#864, #850, #964)
B.14. Since draft-ietf-quic-transport-06 B.15. Since draft-ietf-quic-transport-06
o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
o Split error code space between application and transport (#485) o Split error code space between application and transport (#485)
o Stateless reset token moved to end (#820) o Stateless reset token moved to end (#820)
o 1-RTT-protected long header types removed (#848) o 1-RTT-protected long header types removed (#848)
o No acknowledgments during draining period (#852) o No acknowledgments during draining period (#852)
o Remove "application close" as a separate close type (#854) o Remove "application close" as a separate close type (#854)
o Remove timestamps from the ACK frame (#841) o Remove timestamps from the ACK frame (#841)
o Require transport parameters to only appear once (#792) o Require transport parameters to only appear once (#792)
B.15. Since draft-ietf-quic-transport-05 B.16. Since draft-ietf-quic-transport-05
o Stateless token is server-only (#726) o Stateless token is server-only (#726)
o Refactor section on connection termination (#733, #748, #328, o Refactor section on connection termination (#733, #748, #328,
#177) #177)
o Limit size of Version Negotiation packet (#585) o Limit size of Version Negotiation packet (#585)
o Clarify when and what to ack (#736) o Clarify when and what to ack (#736)
o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
o Clarify Keep-alive requirements (#729) o Clarify Keep-alive requirements (#729)
B.16. Since draft-ietf-quic-transport-04 B.17. Since draft-ietf-quic-transport-04
o Introduce STOP_SENDING frame, RESET_STREAM only resets in one o Introduce STOP_SENDING frame, RESET_STREAM only resets in one
direction (#165) direction (#165)
o Removed GOAWAY; application protocols are responsible for graceful o Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696) shutdown (#696)
o Reduced the number of error codes (#96, #177, #184, #211) o Reduced the number of error codes (#96, #177, #184, #211)
o Version validation fields can't move or change (#121) o Version validation fields can't move or change (#121)
skipping to change at page 139, line 34 skipping to change at page 143, line 34
o Increased the maximum length of the Largest Acknowledged field in o Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
o truncate_connection_id is renamed to omit_connection_id (#659) o truncate_connection_id is renamed to omit_connection_id (#659)
o CONNECTION_CLOSE terminates the connection like TCP RST (#330, o CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
B.17. Since draft-ietf-quic-transport-03 B.18. Since draft-ietf-quic-transport-03
o Change STREAM and RESET_STREAM layout o Change STREAM and RESET_STREAM layout
o Add MAX_STREAM_ID settings o Add MAX_STREAM_ID settings
B.18. Since draft-ietf-quic-transport-02 B.19. Since draft-ietf-quic-transport-02
o The size of the initial packet payload has a fixed minimum (#267, o The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
o Define when Version Negotiation packets are ignored (#284, #294, o Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
o The 64-bit FNV-1a algorithm is used for integrity protection of o 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 140, line 37 skipping to change at page 144, line 37
linkability (#232, #491, #496) linkability (#232, #491, #496)
o Transport parameters for 0-RTT are retained from a previous o 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)
o Expanded security considerations (#440, #444, #445, #448) o Expanded security considerations (#440, #444, #445, #448)
B.19. Since draft-ietf-quic-transport-01 B.20. Since draft-ietf-quic-transport-01
o Defined short and long packet headers (#40, #148, #361) o Defined short and long packet headers (#40, #148, #361)
o Defined a versioning scheme and stable fields (#51, #361) o Defined a versioning scheme and stable fields (#51, #361)
o Define reserved version values for "greasing" negotiation (#112, o Define reserved version values for "greasing" negotiation (#112,
#278) #278)
o The initial packet number is randomized (#35, #283) o The initial packet number is randomized (#35, #283)
skipping to change at page 142, line 36 skipping to change at page 146, line 36
o Remove error code and reason phrase from GOAWAY (#352, #355) o Remove error code and reason phrase from GOAWAY (#352, #355)
o GOAWAY includes a final stream number for both directions (#347) o GOAWAY includes a final stream number for both directions (#347)
o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
o Defined priority as the responsibility of the application protocol o Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
B.20. Since draft-ietf-quic-transport-00 B.21. Since draft-ietf-quic-transport-00
o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
o Defined versioning o Defined versioning
o Reworked description of packet and frame layout o Reworked description of packet and frame layout
o Error code space is divided into regions for each component o Error code space is divided into regions for each component
o Use big endian for all numeric values o Use big endian for all numeric values
B.21. Since draft-hamilton-quic-transport-protocol-01 B.22. Since draft-hamilton-quic-transport-protocol-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added IANA Considerations section o Added IANA Considerations section
o Moved Contributors and Acknowledgments to appendices o Moved Contributors and Acknowledgments to appendices
Acknowledgments Acknowledgments
 End of changes. 156 change blocks. 
516 lines changed or deleted 697 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/