draft-ietf-quic-transport-28.txt   draft-ietf-quic-transport-29.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: 21 November 2020 Mozilla Expires: 12 December 2020 Mozilla
20 May 2020 10 June 2020
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-28 draft-ietf-quic-transport-29
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 21 November 2020. This Internet-Draft will expire on 12 December 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 7 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 7
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 11 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 11
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 12 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 12
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 12 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13
2.4. Required Operations on Streams . . . . . . . . . . . . . 13 2.4. Required Operations on Streams . . . . . . . . . . . . . 13
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 14 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 14
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 17 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 17
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 19 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 19
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 20 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 20
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 21 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 21
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 23 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 23
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 24 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 24
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 25 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 25
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 26 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 26
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 26 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 27
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 27 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 28
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 29 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 29
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 30 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 30
5.2. Matching Packets to Connections . . . . . . . . . . . . . 31 5.2. Matching Packets to Connections . . . . . . . . . . . . . 31
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 32 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 32
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 32 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 32
5.2.3. Considerations for Simple Load Balancers . . . . . . 33 5.2.3. Considerations for Simple Load Balancers . . . . . . 33
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 33 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 34
5.4. Required Operations on Connections . . . . . . . . . . . 34 5.4. Required Operations on Connections . . . . . . . . . . . 35
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 35 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 36
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 35 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 36
6.2. Handling Version Negotiation Packets . . . . . . . . . . 36 6.2. Handling Version Negotiation Packets . . . . . . . . . . 36
6.2.1. Version Negotiation Between Draft Versions . . . . . 36 6.2.1. Version Negotiation Between Draft Versions . . . . . 37
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 37 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 37
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 37 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 38
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 38 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 39
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 39 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 40
7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 41 7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 41
7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 43 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 43
7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 43 7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 44
7.4.2. New Transport Parameters . . . . . . . . . . . . . . 45 7.4.2. New Transport Parameters . . . . . . . . . . . . . . 46
7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 45 7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 46
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 46 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 46
8.1. Address Validation During Connection Establishment . . . 46 8.1. Address Validation During Connection Establishment . . . 47
8.1.1. Token Construction . . . . . . . . . . . . . . . . . 47 8.1.1. Token Construction . . . . . . . . . . . . . . . . . 48
8.1.2. Address Validation using Retry Packets . . . . . . . 47 8.1.2. Address Validation using Retry Packets . . . . . . . 48
8.1.3. Address Validation for Future Connections . . . . . . 48 8.1.3. Address Validation for Future Connections . . . . . . 49
8.1.4. Address Validation Token Integrity . . . . . . . . . 51 8.1.4. Address Validation Token Integrity . . . . . . . . . 51
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 51 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 52
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 52 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 53
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 52 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 53
8.5. Successful Path Validation . . . . . . . . . . . . . . . 53 8.5. Successful Path Validation . . . . . . . . . . . . . . . 54
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 53 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 54
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 54 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 54
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 55 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 55
9.2. Initiating Connection Migration . . . . . . . . . . . . . 55 9.2. Initiating Connection Migration . . . . . . . . . . . . . 56
9.3. Responding to Connection Migration . . . . . . . . . . . 56 9.3. Responding to Connection Migration . . . . . . . . . . . 56
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 56 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 57
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 57 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 58
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 58 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 58
9.4. Loss Detection and Congestion Control . . . . . . . . . . 59 9.4. Loss Detection and Congestion Control . . . . . . . . . . 59
9.5. Privacy Implications of Connection Migration . . . . . . 60 9.5. Privacy Implications of Connection Migration . . . . . . 60
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 61 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 62
9.6.1. Communicating a Preferred Address . . . . . . . . . . 61 9.6.1. Communicating a Preferred Address . . . . . . . . . . 62
9.6.2. Responding to Connection Migration . . . . . . . . . 62 9.6.2. Responding to Connection Migration . . . . . . . . . 63
9.6.3. Interaction of Client Migration and Preferred 9.6.3. Interaction of Client Migration and Preferred
Address . . . . . . . . . . . . . . . . . . . . . . . 62 Address . . . . . . . . . . . . . . . . . . . . . . . 63
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 63 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 64
10. Connection Termination . . . . . . . . . . . . . . . . . . . 63 10. Connection Termination . . . . . . . . . . . . . . . . . . . 64
10.1. Closing and Draining Connection States . . . . . . . . . 64 10.1. Closing and Draining Connection States . . . . . . . . . 65
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 65 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 66
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 66 10.2.1. Liveness Testing . . . . . . . . . . . . . . . . . . 66
10.3.1. Immediate Close During the Handshake . . . . . . . . 67 10.2.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 67
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 69 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 67
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 71 10.3.1. Immediate Close During the Handshake . . . . . . . . 69
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 72 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 70
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 73 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 73
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 74 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 74
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 74 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 75
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 75 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 75
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 75 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 76
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 76 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 76
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 76 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 77
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 77 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 77
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 78 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 78
13. Packetization and Reliability . . . . . . . . . . . . . . . . 81 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 79
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 82 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 80
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 82 13. Packetization and Reliability . . . . . . . . . . . . . . . . 83
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 83 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 84
13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 84 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 84
13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 85 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 85
13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 85 13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 86
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 86 13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 86
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 86 13.2.4. Receiver Tracking of ACK Frames . . . . . . . . . . 87
13.3. Retransmission of Information . . . . . . . . . . . . . 87 13.2.5. Limiting ACK Ranges . . . . . . . . . . . . . . . . 87
13.4. Explicit Congestion Notification . . . . . . . . . . . . 89 13.2.6. Measuring and Reporting Host Delay . . . . . . . . . 88
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 90 13.2.7. ACK Frames and Packet Protection . . . . . . . . . . 88
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 90 13.2.8. PADDING Frames Consume Congestion Window . . . . . . 89
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 92 13.3. Retransmission of Information . . . . . . . . . . . . . 89
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 93 13.4. Explicit Congestion Notification . . . . . . . . . . . . 92
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 94 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 92
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 95 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 93
14.3.1. PMTU Probes Containing Source Connection ID . . . . 95 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 95
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 96 14.1. Initial Packet Size . . . . . . . . . . . . . . . . . . 95
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 97 14.2. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 96
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 97 14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 97
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 98 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 97
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 99 14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 98
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 101 14.3.2. Validating the QUIC Path with DPLPMTUD . . . . . . . 98
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 103 14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 98
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 105 14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 98
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 106 14.4.1. PMTU Probes Containing Source Connection ID . . . . 99
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 107 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 99
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 109 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 100
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 111 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 101
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 112 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 101
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 113 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 102
18.2. Transport Parameter Definitions . . . . . . . . . . . . 113 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 105
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 117 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 107
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 117 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 109
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 118 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 110
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 118 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 111
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 120 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 113
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 121 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 115
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 122 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 116
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 123 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 117
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 123 18.2. Transport Parameter Definitions . . . . . . . . . . . . 117
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 124 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 121
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 125 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 121
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 127 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 122
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 127 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 122
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 128 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 124
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 129 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 125
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 130 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 126
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 130 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 127
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 131 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 127
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 132 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 128
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 133 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 129
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 134 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 131
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 134 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 131
19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 135 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 132
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 136 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 133
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 136 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 134
20.1. Application Protocol Error Codes . . . . . . . . . . . . 138 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 134
21. Security Considerations . . . . . . . . . . . . . . . . . . . 138 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 135
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 138 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 136
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 139 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 137
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 140 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 138
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 140 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 138
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 140 19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 139
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 141 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 140
21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 141 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 140
21.8. Explicit Congestion Notification Attacks . . . . . . . . 142 20.1. Application Protocol Error Codes . . . . . . . . . . . . 142
21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 142 21. Security Considerations . . . . . . . . . . . . . . . . . . . 142
21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 143 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 142
21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 143 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 143
21.12. Overview of Security Properties . . . . . . . . . . . . 143 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 144
21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 144 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 144
21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 145 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 144
21.12.3. Connection Migration . . . . . . . . . . . . . . . 146 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 145
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 150 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 145
22.1. Registration Policies for QUIC Registries . . . . . . . 150 21.8. Explicit Congestion Notification Attacks . . . . . . . . 146
22.1.1. Provisional Registrations . . . . . . . . . . . . . 150 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 146
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 151 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 147
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 152 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 147
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 153 21.12. Overview of Security Properties . . . . . . . . . . . . 147
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 153 21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 148
22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 154 21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 149
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 155 21.12.3. Connection Migration . . . . . . . . . . . . . . . 150
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 157 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154
23.1. Normative References . . . . . . . . . . . . . . . . . . 157 22.1. Registration Policies for QUIC Registries . . . . . . . 154
23.2. Informative References . . . . . . . . . . . . . . . . . 158 22.1.1. Provisional Registrations . . . . . . . . . . . . . 154
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 160 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 155
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 161 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 156
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 162 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 157
C.1. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 162 22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 157
C.2. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 163 22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 158
C.3. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 163 22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 159
C.4. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 163 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 161
C.5. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 165 23.1. Normative References . . . . . . . . . . . . . . . . . . 161
C.6. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 165 23.2. Informative References . . . . . . . . . . . . . . . . . 162
C.7. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 166 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 164
C.8. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 167 Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 165
C.9. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 167 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 166
C.10. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 168 C.1. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 166
C.11. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 168 C.2. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 166
C.12. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 169 C.3. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 168
C.13. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 170 C.4. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 168
C.14. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 170 C.5. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 168
C.15. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 171 C.6. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 169
C.16. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 172 C.7. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 170
C.17. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 172 C.8. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 171
C.18. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 173 C.9. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 171
C.19. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 173 C.10. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 172
C.20. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 174 C.11. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 172
C.21. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 175 C.12. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 173
C.22. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 176 C.13. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 174
C.23. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 176 C.14. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 175
C.24. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 176 C.15. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 175
C.25. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 177 C.16. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 175
C.26. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 177 C.17. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 176
C.27. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 178 C.18. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 177
C.28. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 180 C.19. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 177
C.29. Since draft-hamilton-quic-transport-protocol-01 . . . . . 180 C.20. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 178
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 180 C.21. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 179
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 182 C.22. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 179
C.23. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 180
C.24. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 180
C.25. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 181
C.26. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 181
C.27. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 182
C.28. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 182
C.29. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 184
C.30. Since draft-hamilton-quic-transport-protocol-01 . . . . . 185
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 186
1. Introduction 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:
* Stream multiplexing * Stream multiplexing
* Stream and connection-level flow control * Stream and connection-level flow control
skipping to change at page 8, line 4 skipping to change at page 8, line 13
and acknowledgement of data, and and acknowledgement of data, and
- Section 14 specifies rules for managing the size of packets. - Section 14 specifies rules for managing the size of packets.
* Finally, encoding details of QUIC protocol elements are described * Finally, encoding details of QUIC protocol elements are described
in: in:
- Section 15 (Versions), - Section 15 (Versions),
- Section 16 (Integer Encoding), - Section 16 (Integer Encoding),
- Section 17 (Packet Headers), - Section 17 (Packet Headers),
- Section 18 (Transport Parameters), - Section 18 (Transport Parameters),
- Section 19 (Frames), and - Section 19 (Frames), and
- Section 20 (Errors). - Section 20 (Errors).
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control [QUIC-RECOVERY], and the use of TLS for key negotiation control [QUIC-RECOVERY], and the use of TLS for key negotiation
[QUIC-TLS]. [QUIC-TLS].
This document defines QUIC version 1, which conforms to the protocol This document defines QUIC version 1, which conforms to the protocol
invariants in [QUIC-INVARIANTS]. invariants in [QUIC-INVARIANTS].
To refer to QUIC version 1, cite this document. References to the
limited set of version-independent properties of QUIC can cite
[QUIC-INVARIANTS].
1.2. Terms and Definitions 1.2. Terms and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 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.
skipping to change at page 10, line 4 skipping to change at page 10, line 16
omitted to indicate a minimum of zero bits and B can be omitted to omitted to indicate a minimum of zero bits and B can be omitted to
indicate no set upper limit; values in this format always end on indicate no set upper limit; values in this format always end on
an octet boundary an octet boundary
x (?) = C: Indicates that x has a fixed value of C x (?) = C: Indicates that x has a fixed value of C
x (?) = C..D: Indicates that x has a value in the range from C to D, x (?) = C..D: Indicates that x has a value in the range from C to D,
inclusive inclusive
[x (E)]: Indicates that x is optional (and has length of E) [x (E)]: Indicates that x is optional (and has length of E)
x (E) ...: Indicates that x is repeated zero or more times (and that x (E) ...: Indicates that x is repeated zero or more times (and that
each instance is length E) each instance is length E)
This document uses network byte order (that is, big endian) values.
Fields are placed starting from the high-order bits of each byte.
By convention, individual fields reference a complex field by using By convention, individual fields reference a complex field by using
the name of the complex field. the name of the complex field.
For example: For example:
Example Structure { Example Structure {
One-bit Field (1), One-bit Field (1),
7-bit Field with Fixed Value (7) = 61, 7-bit Field with Fixed Value (7) = 61,
Field with Variable-Length Integer (i),
Arbitrary-Length Field (..), Arbitrary-Length Field (..),
Variable-Length Field (8..24), Variable-Length Field (8..24),
Field With Minimum Length (16..), Field With Minimum Length (16..),
Field With Maximum Length (..128), Field With Maximum Length (..128),
[Optional Field (64)], [Optional Field (64)],
Repeated Field (8) ..., Repeated Field (8) ...,
} }
Figure 1: Example Format Figure 1: Example Format
skipping to change at page 12, line 47 skipping to change at page 13, line 20
Stream multiplexing can have a significant effect on application Stream multiplexing can have a significant effect on application
performance if resources allocated to streams are correctly performance if resources allocated to streams are correctly
prioritized. prioritized.
QUIC does not provide a mechanism for exchanging prioritization QUIC does not provide a mechanism for exchanging prioritization
information. Instead, it relies on receiving priority information information. Instead, it relies on receiving priority information
from the application that uses QUIC. from the application that uses QUIC.
A QUIC implementation SHOULD provide ways in which an application can A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams. When deciding which indicate the relative priority of streams. When deciding the streams
streams to dedicate resources to, the implementation SHOULD use the to which resources are dedicated, the implementation SHOULD use the
information provided by the application. information provided by the application.
2.4. Required Operations on Streams 2.4. Required Operations on Streams
There are certain operations which an application MUST be able to There are certain operations that an application MUST be able to
perform when interacting with QUIC streams. This document does not perform when interacting with QUIC streams. This document does not
specify an API, but any implementation of this version of QUIC MUST specify an API, but any implementation of this version of QUIC MUST
expose the ability to perform the operations described in this expose the ability to perform the operations described in this
section on a QUIC stream. section on a QUIC stream.
On the sending part of a stream, application protocols need to be On the sending part of a stream, application protocols need to be
able to: able to:
* write data, understanding when stream flow control credit * write data, understanding when stream flow control credit
(Section 4.1) has successfully been reserved to send the written (Section 4.1) has successfully been reserved to send the written
skipping to change at page 14, line 10 skipping to change at page 14, line 22
This section describes streams in terms of their send or receive This section describes streams in terms of their send or receive
components. Two state machines are described: one for the streams on components. Two state machines are described: one for the streams on
which an endpoint transmits data (Section 3.1), and another for which an endpoint transmits data (Section 3.1), and another for
streams on which an endpoint receives data (Section 3.2). streams on which an endpoint receives data (Section 3.2).
Unidirectional streams use the applicable state machine directly. Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines. For the most part, Bidirectional streams use both state machines. For the most part,
the use of these state machines is the same whether the stream is the use of these state machines is the same whether the stream is
unidirectional or bidirectional. The conditions for opening a stream unidirectional or bidirectional. The conditions for opening a stream
are slightly more complex for a bidirectional stream because the are slightly more complex for a bidirectional stream because the
opening of either send or receive sides causes the stream to open in opening of either the send or receive side causes the stream to open
both directions. in both directions.
An endpoint MUST open streams of the same type in increasing order of An endpoint MUST open streams of the same type in increasing order of
stream ID. stream ID.
Note: These states are largely informative. This document uses Note: These states are largely informative. This document uses
stream states to describe rules for when and how different types stream states to describe rules for when and how different types
of frames can be sent and the reactions that are expected when of frames can be sent and the reactions that are expected when
different types of frames are received. Though these state different types of frames are received. Though these state
machines are intended to be useful in implementing QUIC, these machines are intended to be useful in implementing QUIC, these
states aren't intended to constrain implementations. An states aren't intended to constrain implementations. An
skipping to change at page 15, line 41 skipping to change at page 15, line 41
| | | |
| Recv All ACKs | Recv ACK | Recv All ACKs | Recv ACK
v v v v
+-------+ +-------+ +-------+ +-------+
| Data | | Reset | | Data | | Reset |
| Recvd | | Recvd | | Recvd | | Recvd |
+-------+ +-------+ +-------+ +-------+
Figure 2: States for Sending Parts of Streams Figure 2: States for Sending Parts of Streams
The sending part of stream that the endpoint initiates (types 0 and 2 The sending part of a stream that the endpoint initiates (types 0 and
for clients, 1 and 3 for servers) is opened by the application. The 2 for clients, 1 and 3 for servers) is opened by the application.
"Ready" state represents a newly created stream that is able to The "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 STREAM frame and enters this state, stream until it sends the first STREAM frame and enters this state,
which 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
skipping to change at page 17, line 51 skipping to change at page 17, line 51
v v v v
+-------+ +-------+ +-------+ +-------+
| Data | | Reset | | Data | | Reset |
| Read | | Read | | Read | | Read |
+-------+ +-------+ +-------+ +-------+
Figure 3: States for Receiving Parts of Streams Figure 3: States for Receiving Parts of Streams
The receiving part of a stream initiated by a peer (types 1 and 3 for The receiving part of a stream initiated by a peer (types 1 and 3 for
a client, or 0 and 2 for a server) is created when the first STREAM, a client, or 0 and 2 for a server) is created when the first STREAM,
STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream. STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that
For bidirectional streams initiated by a peer, receipt of a stream. For bidirectional streams initiated by a peer, receipt of a
MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the
stream also creates the receiving part. The initial state for the stream also creates the receiving part. The initial state for the
receiving part of stream is "Recv". receiving part of stream is "Recv".
The receiving part of a stream enters the "Recv" state when the The receiving part of a stream enters the "Recv" state when the
sending part of a bidirectional stream initiated by the endpoint sending part of a bidirectional stream initiated by the endpoint
(type 0 for a client, type 1 for a server) enters the "Ready" state. (type 0 for a client, type 1 for a server) enters the "Ready" state.
An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or
STOP_SENDING frame is received from the peer for that stream. STOP_SENDING frame is received from the peer for that stream.
skipping to change at page 19, line 33 skipping to change at page 19, line 33
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 a STREAM or
STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the STREAM_DATA_BLOCKED frame for a stream in the "Reset Sent" state or
terminal states and in the "Reset Sent" state. A receiver could any terminal state, that is, after sending a RESET_STREAM frame. A
receive any of these three frames in any state, due to the receiver could receive any of these three frames in any state, due to
possibility of delayed delivery of packets carrying them. the possibility of delayed delivery of packets carrying them.
The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and
STOP_SENDING frames (Section 19.5). STOP_SENDING frames (Section 19.5).
The receiver only sends MAX_STREAM_DATA in the "Recv" state. A The receiver only sends MAX_STREAM_DATA in the "Recv" state. A
receiver can send STOP_SENDING in any state where it has not received receiver MAY send STOP_SENDING in any state where it has not received
a RESET_STREAM frame; that is states other than "Reset Recvd" or a RESET_STREAM frame; that is states other than "Reset Recvd" or
"Reset Read". However there is little value in sending a "Reset Read". However there is little value in sending a
STOP_SENDING frame in the "Data Recvd" state, since all stream data STOP_SENDING frame in the "Data Recvd" state, since all stream data
has been received. A sender could receive either of these two frames has been received. A sender could receive either of these two frames
in any state as a result of delayed delivery of packets. in any state as a result of delayed delivery of packets.
3.4. Bidirectional Stream States 3.4. Bidirectional Stream States
A bidirectional stream is composed of sending and receiving parts. A bidirectional stream is composed of sending and receiving parts.
Implementations may represent states of the bidirectional stream as Implementations may represent states of the bidirectional stream as
skipping to change at page 22, line 12 skipping to change at page 22, line 12
on a stream, it can abort reading the stream and specify an on a stream, it can abort reading the stream and specify an
application error code. application error code.
If the stream is in the "Recv" or "Size Known" states, the transport If the stream is in the "Recv" or "Size Known" states, the transport
SHOULD signal this by sending a STOP_SENDING frame to prompt closure SHOULD signal this by sending a STOP_SENDING frame to prompt closure
of the stream in the opposite direction. This typically indicates of the stream in the opposite direction. This typically indicates
that the receiving application is no longer reading data it receives that the receiving application is no longer reading data it receives
from the stream, but it is not a guarantee that incoming data will be from the stream, but it is not a guarantee that incoming data will be
ignored. ignored.
STREAM frames received after sending STOP_SENDING are still counted STREAM frames received after sending a STOP_SENDING frame are still
toward connection and stream flow control, even though these frames counted toward connection and stream flow control, even though these
can be discarded upon receipt. frames can be discarded upon receipt.
A STOP_SENDING frame requests that the receiving endpoint send a A STOP_SENDING frame requests that the receiving endpoint send a
RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame
MUST send a RESET_STREAM frame if the stream is in the Ready or Send MUST send a RESET_STREAM frame if the stream is in the Ready or Send
state. If the stream is in the Data Sent state and any outstanding state. If the stream is in the Data Sent state 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 22, line 45 skipping to change at page 22, line 45
or "Size Known" states. or "Size Known" states.
An endpoint is expected to send another STOP_SENDING frame if a An endpoint is expected to send another STOP_SENDING frame if a
packet containing a previous STOP_SENDING is lost. However, once packet containing a previous STOP_SENDING is lost. However, once
either all stream data or a RESET_STREAM frame has been received for either all stream data or a RESET_STREAM frame has been received for
the stream - that is, the stream is in any state other than "Recv" or the stream - that is, the stream is in any state other than "Recv" or
"Size Known" - sending a STOP_SENDING frame is unnecessary. "Size Known" - sending a STOP_SENDING frame is unnecessary.
An endpoint that wishes to terminate both directions of a An endpoint that wishes to terminate both directions of a
bidirectional stream can terminate one direction by sending a bidirectional stream can terminate one direction by sending a
RESET_STREAM, and it can encourage prompt termination in the opposite RESET_STREAM frame, and it can encourage prompt termination in the
direction by sending a STOP_SENDING frame. opposite direction by sending a STOP_SENDING frame.
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
skipping to change at page 26, line 20 skipping to change at page 26, line 20
CONNECTION_CLOSE. CONNECTION_CLOSE.
4.4. Stream Final Size 4.4. Stream Final Size
The final size is the amount of flow control credit that is consumed The final size is the amount of flow control credit that is consumed
by a stream. Assuming that every contiguous byte on the stream was by a stream. Assuming that every contiguous byte on the stream was
sent once, the final size is the number of bytes sent. More sent once, the final size is the number of bytes sent. More
generally, this is one higher than the offset of the byte with the generally, this is one higher than the offset of the byte with the
largest offset sent on the stream, or zero if no bytes were sent. largest offset sent on the stream, or zero if no bytes were sent.
For a stream that is reset, the final size is carried explicitly in a The final size of a stream is always signaled to the recipient. The
RESET_STREAM frame. Otherwise, the final size is the offset plus the final size is the sum of the Offset and Length fields of a STREAM
length of a STREAM frame marked with a FIN flag, or 0 in the case of frame with a FIN flag, noting that these fields might be implicit.
incoming unidirectional streams. Alternatively, the Final Size field of a RESET_STREAM frame carries
this value. This ensures that all ways that a stream can be closed
result in the number of bytes on the stream being reliably
transmitted. This guarantees that both endpoints agree on how much
flow control credit was consumed by the stream.
An endpoint will know the final size for a stream when the receiving An endpoint will know the final size for a stream when the receiving
part of the stream enters the "Size Known" or "Reset Recvd" state part of the stream enters the "Size Known" or "Reset Recvd" state
(Section 3). (Section 3).
An endpoint MUST NOT send data on a stream at or beyond the final An endpoint MUST NOT send data on a stream at or beyond the final
size. size.
Once a final size for a stream is known, it cannot change. If a Once a final size for a stream is known, it cannot change. If a
RESET_STREAM or STREAM frame is received indicating a change in the RESET_STREAM or STREAM frame is received indicating a change in the
skipping to change at page 28, line 10 skipping to change at page 28, line 17
Each connection possesses a set of connection identifiers, or Each connection possesses a set of connection identifiers, or
connection IDs, each of which can identify the connection. connection IDs, each of which can identify the connection.
Connection IDs are independently selected by endpoints; each endpoint Connection IDs are independently selected by endpoints; each endpoint
selects the connection IDs that its peer uses. selects the connection IDs that its peer uses.
The primary function of a connection ID is to ensure that changes in The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP) don't cause packets for addressing at lower protocol layers (UDP, IP) don't cause packets for
a QUIC connection to be delivered to the wrong endpoint. Each a QUIC connection to be delivered to the wrong endpoint. Each
endpoint selects connection IDs using an implementation-specific (and endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method which will allow packets with perhaps deployment-specific) method which will allow packets with
that connection ID to be routed back to the endpoint and identified that connection ID to be routed back to the endpoint and to be
by the endpoint upon receipt. identified by the endpoint upon receipt.
Connection IDs MUST NOT contain any information that can be used by Connection IDs MUST NOT contain any information that can be used by
an external observer (that is, one that does not cooperate with the an external observer (that is, one that does not cooperate with the
issuer) to correlate them with other connection IDs for the same issuer) to correlate them with other connection IDs for the same
connection. As a trivial example, this means the same connection ID connection. As a trivial example, this means the same connection ID
MUST NOT be issued more than once on the same connection. MUST NOT be issued more than once on the same connection.
Packets with long headers include Source Connection ID and Packets with long headers include Source Connection ID and
Destination Connection ID fields. These fields are used to set the Destination Connection ID fields. These fields are used to set the
connection IDs for new connections; see Section 7.2 for details. connection IDs for new connections; see Section 7.2 for details.
skipping to change at page 29, line 8 skipping to change at page 29, line 14
When an endpoint uses a non-zero-length connection ID, it needs to When an endpoint uses a non-zero-length connection ID, it needs to
ensure that the peer has a supply of connection IDs from which to ensure that the peer has a supply of connection IDs from which to
choose for packets sent to the endpoint. These connection IDs are choose for packets sent to the endpoint. These connection IDs are
supplied by the endpoint using the NEW_CONNECTION_ID frame supplied by the endpoint using the NEW_CONNECTION_ID frame
(Section 19.15). (Section 19.15).
5.1.1. Issuing Connection IDs 5.1.1. Issuing Connection IDs
Each Connection ID has an associated sequence number to assist in Each Connection ID has an associated sequence number to assist in
deduplicating messages. The initial connection ID issued by an detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer
endpoint is sent in the Source Connection ID field of the long packet to the same value. The initial connection ID issued by an endpoint
header (Section 17.2) during the handshake. The sequence number of is sent in the Source Connection ID field of the long packet header
the initial connection ID is 0. If the preferred_address transport (Section 17.2) during the handshake. The sequence number of the
initial connection ID is 0. If the preferred_address transport
parameter is sent, the sequence number of the supplied connection ID parameter is sent, the sequence number of the supplied connection ID
is 1. is 1.
Additional connection IDs are communicated to the peer using Additional connection IDs are communicated to the peer using
NEW_CONNECTION_ID frames (Section 19.15). The sequence number on NEW_CONNECTION_ID frames (Section 19.15). The sequence number on
each newly-issued connection ID MUST increase by 1. The connection each newly-issued connection ID MUST increase by 1. The connection
ID randomly selected by the client in the Initial packet and any ID randomly selected by the client in the Initial packet and any
connection ID provided by a Retry packet are not assigned sequence connection ID provided by a Retry packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection numbers unless a server opts to retain them as its initial connection
ID. ID.
skipping to change at page 32, line 28 skipping to change at page 32, line 42
Due to packet reordering or loss, a client might receive packets for Due to packet reordering or loss, a client might receive packets for
a connection that are encrypted with a key it has not yet computed. a connection that are encrypted with a key it has not yet computed.
The client MAY drop these packets, or MAY buffer them in anticipation The client MAY drop these packets, or MAY buffer them in anticipation
of later packets that allow it to compute the key. of later packets that allow it to compute the key.
If a client receives a packet that has an unsupported version, it If a client receives a packet that has an unsupported version, it
MUST discard that packet. MUST discard that packet.
5.2.2. Server Packet Handling 5.2.2. Server Packet Handling
If a server receives a packet that has an unsupported version, but If a server receives a packet that indicates an unsupported version
the packet is sufficiently large to initiate a new connection for any but is large enough to initiate a new connection for any one
version supported by the server, it SHOULD send a Version Negotiation supported version, the server 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 limit the number of
packets to avoid storms of Version Negotiation packets. Otherwise, packets that it responds to with a Version Negotiation packet.
servers MUST drop packets that specify unsupported versions. Servers MUST drop smaller packets that specify unsupported versions.
The first packet for an unsupported version can use different The first packet for an unsupported version can use different
semantics and encodings for any version-specific field. In semantics and encodings for any version-specific field. In
particular, different packet protection keys might be used for particular, different packet protection keys might be used for
different versions. Servers that do not support a particular version different versions. Servers that do not support a particular version
are unlikely to be able to decrypt the payload of the packet. are unlikely to be able to decrypt the payload of the packet.
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.
Packets with a supported version, or no version field, are matched to Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero- a connection using the connection ID or - for packets with zero-
length connection IDs - the local address and port. If the packet length connection IDs - the local address and port. If the packet
doesn't match an existing connection, the server continues below. doesn't 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 refuses to accept a new connection, it SHOULD send an
send an Initial packet containing a CONNECTION_CLOSE frame with error Initial packet containing a CONNECTION_CLOSE frame with error code
code SERVER_BUSY. CONNECTION_REFUSED.
If the packet is a 0-RTT packet, the server MAY buffer a limited If the packet is a 0-RTT packet, the server MAY buffer a limited
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 not able to send Handshake packets prior to packet. Clients are not able to send Handshake packets prior 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.2.3. Considerations for Simple Load Balancers 5.2.3. Considerations for Simple Load Balancers
skipping to change at page 33, line 36 skipping to change at page 33, line 50
* Servers could use an out-of-band mechanism to forward packets to * Servers could use an out-of-band mechanism to forward packets to
the correct server based on Connection ID. the correct server based on Connection ID.
* If servers can use a dedicated server IP address or port, other * If servers can use a dedicated server IP address or port, other
than the one that the client initially connects to, they could use than the one that the client initially connects to, they could use
the preferred_address transport parameter to request that clients the preferred_address transport parameter to request that clients
move connections to that dedicated address. Note that clients move connections to that dedicated address. Note that clients
could choose not to use the preferred address. could choose not to use the preferred address.
A server in a deployment that does not implement a solution to A server in a deployment that does not implement a solution to
maintain connection continuity during connection migration SHOULD maintain connection continuity when the client address changes SHOULD
disallow migration using the disable_active_migration transport indicate migration is not supported using the
parameter. disable_active_migration transport parameter. The
disable_active_migration transport parameter does not prohibit
connection migration after a client has acted on a preferred_address
transport parameter.
Server deployments that use this simple form of load balancing MUST Server deployments that use this simple form of load balancing MUST
avoid the creation of a stateless reset oracle; see Section 21.9. avoid the creation of a stateless reset oracle; see Section 21.9.
5.3. Life of a QUIC Connection 5.3. Life of a QUIC Connection
A QUIC connection is a stateful interaction between a client and A QUIC connection is a stateful interaction between a client and
server, the primary purpose of which is to support the exchange of server, the primary purpose of which is to support the exchange of
data by an application protocol. Streams (Section 2) are the primary data by an application protocol. Streams (Section 2) are the primary
means by which an application protocol exchanges information. means by which an application protocol exchanges information.
skipping to change at page 34, line 4 skipping to change at page 34, line 22
5.3. Life of a QUIC Connection 5.3. Life of a QUIC Connection
A QUIC connection is a stateful interaction between a client and A QUIC connection is a stateful interaction between a client and
server, the primary purpose of which is to support the exchange of server, the primary purpose of which is to support the exchange of
data by an application protocol. Streams (Section 2) are the primary data by an application protocol. Streams (Section 2) are the primary
means by which an application protocol exchanges information. means by which an application protocol exchanges information.
Each connection starts with a handshake phase, during which client Each connection starts with a handshake phase, during which client
and server establish a shared secret using the cryptographic and server establish a shared secret using the cryptographic
handshake protocol [QUIC-TLS] and negotiate the application protocol. handshake protocol [QUIC-TLS] and negotiate the application protocol.
The handshake (Section 7) confirms that both endpoints are willing to The handshake (Section 7) confirms that both endpoints are willing to
communicate (Section 8.1) and establishes parameters for the communicate (Section 8.1) and establishes parameters for the
connection (Section 7.4). connection (Section 7.4).
An application protocol can also operate in a limited fashion during An application protocol can also operate in a limited fashion during
the handshake phase. 0-RTT allows application messages to be sent by the handshake phase. 0-RTT allows application data to be sent by a
a client before receiving any messages from the server. However, client before receiving any response from the server. However, 0-RTT
0-RTT lacks certain key security guarantees. In particular, there is lacks certain key security guarantees. In particular, there is no
no protection against replay attacks in 0-RTT; see [QUIC-TLS]. protection against replay attacks in 0-RTT; see [QUIC-TLS].
Separately, a server can also send application data to a client Separately, a server can also send application data to a client
before it receives the final cryptographic handshake messages that before it receives the final cryptographic handshake messages that
allow it to confirm the identity and liveness of the client. These allow it to confirm the identity and liveness of the client. These
capabilities allow an application protocol to offer the option to capabilities allow an application protocol to offer the option to
trade some security guarantees for reduced latency. trade some security guarantees for reduced latency.
The use of connection IDs (Section 5.1) allows connections to migrate The use of connection IDs (Section 5.1) allows connections to migrate
to a new network path, both as a direct choice of an endpoint and to a new network path, both as a direct choice of an endpoint and
when forced by a change in a middlebox. Section 9 describes when forced by a change in a middlebox. Section 9 describes
mitigations for the security and privacy issues associated with mitigations for the security and privacy issues associated with
migration. migration.
For connections that are no longer needed or desired, there are For connections that are no longer needed or desired, there are
several ways for a client and server to terminate a connection several ways for a client and server to terminate a connection
(Section 10). (Section 10).
5.4. Required Operations on Connections 5.4. Required Operations on Connections
There are certain operations which an application MUST be able to There are certain operations that an application MUST be able to
perform when interacting with the QUIC transport. This document does perform when interacting with the QUIC transport. This document does
not specify an API, but any implementation of this version of QUIC not specify an API, but any implementation of this version of QUIC
MUST expose the ability to perform the operations described in this MUST expose the ability to perform the operations described in this
section on a QUIC connection. section on a QUIC connection.
When implementing the client role, applications need to be able to: When implementing the client role, applications need to be able to:
* open a connection, which begins the exchange described in * open a connection, which begins the exchange described in
Section 7; Section 7;
skipping to change at page 38, line 18 skipping to change at page 38, line 43
and confidentiality protection for server transport parameters and confidentiality protection for server transport parameters
(see Section 7.4) (see Section 7.4)
* authenticated negotiation of an application protocol (TLS uses * authenticated negotiation of an application protocol (TLS uses
ALPN [RFC7301] for this purpose) ALPN [RFC7301] for this purpose)
An endpoint can verify support for Explicit Congestion Notification An endpoint can verify support for Explicit Congestion Notification
(ECN) in the first packets it sends, as described in Section 13.4.2. (ECN) in the first packets it sends, as described in Section 13.4.2.
The CRYPTO frame can be sent in different packet number spaces The CRYPTO frame can be sent in different packet number spaces
(Section 12.3). The sequence numbers used by CRYPTO frames to ensure (Section 12.3). The offsets used by CRYPTO frames to ensure ordered
ordered delivery of cryptographic handshake data start from zero in delivery of cryptographic handshake data start from zero in each
each packet number space. packet number space.
Endpoints MUST explicitly negotiate an application protocol. This Endpoints MUST explicitly negotiate an application protocol. This
avoids situations where there is a disagreement about the protocol avoids situations where there is a disagreement about the protocol
that is in use. that is in use.
7.1. Example Handshake Flows 7.1. Example Handshake Flows
Details of how TLS is integrated with QUIC are provided in Details of how TLS is integrated with QUIC are provided in
[QUIC-TLS], but some examples are provided here. An extension of [QUIC-TLS], but some examples are provided here. An extension of
this exchange to support client address validation is shown in this exchange to support client address validation is shown in
skipping to change at page 38, line 45 skipping to change at page 39, line 24
handshake is carried in Initial (Section 17.2.2) and Handshake handshake is carried in Initial (Section 17.2.2) and Handshake
(Section 17.2.4) packets. (Section 17.2.4) packets.
Figure 4 provides an overview of the 1-RTT handshake. Each line Figure 4 provides an overview of the 1-RTT handshake. Each line
shows a QUIC packet with the packet type and packet number shown shows a QUIC packet with the packet type and packet number shown
first, followed by the frames that are typically contained in those first, followed by the frames that are typically contained in those
packets. So, for instance the first packet is of type Initial, with packets. So, for instance the first packet is of type Initial, with
packet number 0, and contains a CRYPTO frame carrying the packet number 0, and contains a CRYPTO frame carrying the
ClientHello. ClientHello.
Note that multiple QUIC packets - even of different packet types - Multiple QUIC packets - even of different packet types - can be
can be coalesced into a single UDP datagram; see Section 12.2). As a coalesced into a single UDP datagram; see Section 12.2. As a result,
result, this handshake may consist of as few as 4 UDP datagrams, or this handshake may consist of as few as 4 UDP datagrams, or any
any number more. For instance, the server's first flight contains number more (subject to limits inherent to the protocol, such as
Initial packets, Handshake packets, and "0.5-RTT data" in 1-RTT congestion control or anti-amplification). For instance, the
packets with a short header. server's first flight contains Initial packets, Handshake packets,
and "0.5-RTT data" in 1-RTT packets with a short header.
Client Server Client Server
Initial[0]: CRYPTO[CH] -> Initial[0]: CRYPTO[CH] ->
Initial[0]: CRYPTO[SH] ACK[0] Initial[0]: CRYPTO[SH] ACK[0]
Handshake[0]: CRYPTO[EE, CERT, CV, FIN] Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
<- 1-RTT[0]: STREAM[1, "..."] <- 1-RTT[0]: STREAM[1, "..."]
Initial[1]: ACK[0] Initial[1]: ACK[0]
skipping to change at page 40, line 23 skipping to change at page 40, line 50
When an Initial packet is sent by a client that has not previously When an Initial packet is sent by a client that has not previously
received an Initial or Retry packet from the server, the client received an Initial or Retry packet from the server, the client
populates the Destination Connection ID field with an unpredictable populates the Destination Connection ID field with an unpredictable
value. This Destination Connection ID MUST be at least 8 bytes in value. This Destination Connection ID MUST be at least 8 bytes in
length. Until a packet is received from the server, the client MUST length. Until a packet is received from the server, the client MUST
use the same Destination Connection ID value on all packets in this use the same Destination Connection ID value on all packets in this
connection. This Destination Connection ID is used to determine connection. This Destination Connection ID is used to determine
packet protection keys for Initial packets. 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 SCID Length field to indicate the length. its choosing and sets the Source Connection ID Length field to
indicate the length.
The first flight of 0-RTT packets use the same Destination Connection The first flight of 0-RTT packets use the same Destination Connection
ID and Source Connection ID values as the client's first Initial ID and Source Connection ID values as the client's first Initial
packet. packet.
Upon first receiving an Initial or Retry packet from the server, the Upon first receiving an Initial or Retry packet from the server, the
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 0-RTT Destination Connection ID for subsequent packets, including any 0-RTT
packets. This means that a client might have to change the packets. This means that a client might have to change the
connection ID it sets in the Destination Connection ID field twice connection ID it sets in the Destination Connection ID field twice
skipping to change at page 41, line 34 skipping to change at page 42, line 11
before sending the Retry packet. If it sends a Retry packet, a before sending the Retry packet. If it sends a Retry packet, a
server also includes the Source Connection ID field from the Retry server also includes the Source Connection ID field from the Retry
packet in the retry_source_connection_id transport parameter. packet in the retry_source_connection_id transport parameter.
The values provided by a peer for these transport parameters MUST The values provided by a peer for these transport parameters MUST
match the values that an endpoint used in the Destination and Source match the values that an endpoint used in the Destination and Source
Connection ID fields of Initial packets that it sent. Including Connection ID fields of Initial packets that it sent. Including
connection ID values in transport parameters and verifying them connection ID values in transport parameters and verifying them
ensures that that an attacker cannot influence the choice of ensures that that an attacker cannot influence the choice of
connection ID for a successful connection by injecting packets connection ID for a successful connection by injecting packets
carrying attacker-chosen connection IDs during the handshake. An carrying attacker-chosen connection IDs during the handshake.
endpoint MUST treat any of the following as a connection error of
type PROTOCOL_VIOLATION:
* absence of the initial_source_connection_id transport parameter An endpoint MUST treat absence of the initial_source_connection_id
from either endpoint, transport parameter from either endpoint or absence of the
original_destination_connection_id transport parameter from the
server as a connection error of type TRANSPORT_PARAMETER_ERROR.
* absence of the original_destination_connection_id transport An endpoint MUST treat the following as a connection error of type
parameter from the server, TRANSPORT_PARAMETER_ERROR or PROTOCOL_VIOLATION:
* absence of the retry_source_connection_id transport parameter from * absence of the retry_source_connection_id transport parameter from
the server after receiving a Retry packet, the server after receiving a Retry packet,
* presence of the retry_source_connection_id transport parameter * presence of the retry_source_connection_id transport parameter
when no Retry packet was received, or when no Retry packet was received, or
* a mismatch between values received from a peer in these transport * a mismatch between values received from a peer in these transport
parameters and the value sent in the corresponding Destination or parameters and the value sent in the corresponding Destination or
Source Connection ID fields of Initial packets. Source Connection ID fields of Initial packets.
If a zero-length connection ID is selected, the corresponding If a zero-length connection ID is selected, the corresponding
transport parameter is included with a zero-length value. transport parameter is included with a zero-length value.
Figure 6 shows the connection IDs that are used in a complete Figure 6 shows the connection IDs (with DCID=Destination Connection
handshake. The exchange of Initial packets is shown, plus the later ID, SCID=Source Connection ID) that are used in a complete handshake.
exchange of 1-RTT packets that includes the connection ID established The exchange of Initial packets is shown, plus the later exchange of
during the handshake. 1-RTT packets that includes the connection ID established during the
handshake.
Client Server Client Server
Initial: DCID=S1, SCID=C1 -> Initial: DCID=S1, SCID=C1 ->
<- Initial: DCID=C1, SCID=S3 <- Initial: DCID=C1, SCID=S3
... ...
1-RTT: DCID=S3 -> 1-RTT: DCID=S3 ->
<- 1-RTT: DCID=C1 <- 1-RTT: DCID=C1
Figure 6: Use of Connection IDs in a Handshake Figure 6: Use of Connection IDs in a Handshake
skipping to change at page 42, line 37 skipping to change at page 43, line 17
Initial: DCID=S1, SCID=C1 -> Initial: DCID=S1, SCID=C1 ->
<- Retry: DCID=C1, SCID=S2 <- Retry: DCID=C1, SCID=S2
Initial: DCID=S2, SCID=C1 -> Initial: DCID=S2, SCID=C1 ->
<- Initial: DCID=C1, SCID=S3 <- Initial: DCID=C1, SCID=S3
... ...
1-RTT: DCID=S3 -> 1-RTT: DCID=S3 ->
<- 1-RTT: DCID=C1 <- 1-RTT: DCID=C1
Figure 7: Use of Connection IDs in a Handshake with Retry Figure 7: Use of Connection IDs in a Handshake with Retry
For the handshakes in Figure 6 and Figure 7 the client sets the value In both cases (Figure 6 and Figure 7), the client sets the value of
of the initial_source_connection_id transport parameter to "C1". In the initial_source_connection_id transport parameter to "C1".
Figure 7, the server sets original_destination_connection_id to "S1",
retry_source_connection_id to "S2", and initial_source_connection_id When the handshake does not include a Retry (Figure 6), the server
to "S3". In Figure 6, the server sets sets original_destination_connection_id to "S1" and
initial_source_connection_id to "S3". In this case, the server does
not include a retry_source_connection_id transport parameter.
When the handshake includes a Retry (Figure 7), the server sets
original_destination_connection_id to "S1", original_destination_connection_id to "S1",
initial_source_connection_id to "S3", and does not include retry_source_connection_id to "S2", and initial_source_connection_id
retry_source_connection_id. Each endpoint validates the transport to "S3".
parameters set by their peer, including the client confirming that
retry_source_connection_id is absent if no Retry packet was Each endpoint validates transport parameters set by the peer. The
processed. client confirms that the retry_source_connection_id transport
parameter is absent if it did not process a Retry packet.
7.4. Transport Parameters 7.4. Transport Parameters
During connection establishment, both endpoints make authenticated During connection establishment, both endpoints make authenticated
declarations of their transport parameters. Endpoints are required declarations of their transport parameters. Endpoints are required
to comply with the restrictions implied by these parameters; the to comply with the restrictions that each parameter defines; the
description of each parameter includes rules for its handling. description of each parameter includes rules for its handling.
Transport parameters are declarations that are made unilaterally by Transport parameters are declarations that are made unilaterally by
each endpoint. Each endpoint can choose values for transport each endpoint. Each endpoint can choose values for transport
parameters independent of the values chosen by its peer. parameters independent of the values chosen by its peer.
The encoding of the transport parameters is detailed in Section 18. The encoding of the transport parameters is detailed in Section 18.
QUIC includes the encoded transport parameters in the cryptographic QUIC includes the encoded transport parameters in the cryptographic
handshake. Once the handshake completes, the transport parameters handshake. Once the handshake completes, the transport parameters
skipping to change at page 45, line 32 skipping to change at page 46, line 25
Section 22.2. Section 22.2.
7.5. Cryptographic Message Buffering 7.5. Cryptographic Message Buffering
Implementations need to maintain a buffer of CRYPTO data received out Implementations need to maintain a buffer of CRYPTO data received out
of order. Because there is no flow control of CRYPTO frames, an of order. Because there is no flow control of CRYPTO frames, an
endpoint could potentially force its peer to buffer an unbounded endpoint could potentially force its peer to buffer an unbounded
amount of data. amount of data.
Implementations MUST support buffering at least 4096 bytes of data Implementations MUST support buffering at least 4096 bytes of data
received in CRYPTO frames out of order. Endpoints MAY choose to received in out of order CRYPTO frames. Endpoints MAY choose to
allow more data to be buffered during the handshake. A larger limit allow more data to be buffered during the handshake. A larger limit
during the handshake could allow for larger keys or credentials to be during the handshake could allow for larger keys or credentials to be
exchanged. An endpoint's buffer size does not need to remain exchanged. An endpoint's buffer size does not need to remain
constant during the life of the connection. constant during the life of the connection.
Being unable to buffer CRYPTO frames during the handshake can lead to Being unable to buffer CRYPTO frames during the handshake can lead to
a connection failure. If an endpoint's buffer is exceeded during the a connection failure. If an endpoint's buffer is exceeded during the
handshake, it can expand its buffer temporarily to complete the handshake, it can expand its buffer temporarily to complete the
handshake. If an endpoint does not expand its buffer, it MUST close handshake. If an endpoint does not expand its buffer, it MUST close
the connection with a CRYPTO_BUFFER_EXCEEDED error code. the connection with a CRYPTO_BUFFER_EXCEEDED error code.
skipping to change at page 46, line 7 skipping to change at page 46, line 47
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 a 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 ensures that an endpoint cannot be used for a
amplification attack. In such an attack, a packet is sent to a traffic amplification attack. In such an attack, a packet is sent to
server with spoofed source address information that identifies a 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
that packet, the attacker can use the server to send more data toward that packet, the attacker can use the server to send more data toward
the victim than it would be able to send on its own. the victim than it would be able to send on its own.
The primary defense against amplification attack is verifying that an The primary defense against amplification attack is verifying that an
endpoint is able to receive packets at the transport address that it endpoint is able to receive packets at the transport address that it
claims. Address validation is performed both during connection claims. Address validation is performed both during connection
establishment (see Section 8.1) and during connection migration (see establishment (see Section 8.1) and during connection migration (see
Section 8.2). Section 8.2).
skipping to change at page 46, line 41 skipping to change at page 47, line 32
received. This limits the magnitude of any amplification attack that received. This limits the magnitude of any amplification attack that
can be mounted using spoofed source addresses. For the purposes of can be mounted using spoofed source addresses. For the purposes of
avoiding amplification prior to address validation, servers MUST avoiding amplification prior to address validation, servers MUST
count all of the payload bytes received in datagrams that are count all of the payload bytes received in datagrams that are
uniquely attributed to a single connection. This includes datagrams uniquely attributed to a single connection. This includes datagrams
that contain packets that are successfully processed and datagrams that contain packets that are successfully processed and datagrams
that contain packets that are all discarded. that contain packets that are all discarded.
Clients MUST ensure that UDP datagrams containing Initial packets Clients MUST ensure that UDP datagrams containing Initial packets
have UDP payloads of at least 1200 bytes, adding padding to packets have UDP payloads of at least 1200 bytes, adding padding to packets
in the datagram as necessary. Sending padded datagrams ensures that in the datagram as necessary. A client that sends padded datagrams
the server is not overly constrained by the amplification allows the server to send more data prior to completing address
restriction. validation.
Loss of an Initial or Handshake packet from the server can cause a Loss of an Initial or Handshake packet from the server can cause a
deadlock if the client does not send additional Initial or Handshake deadlock if the client does not send additional Initial or Handshake
packets. A deadlock could occur when the server reaches its anti- packets. A deadlock could occur when the server reaches its anti-
amplification limit and the client has received acknowledgements for amplification limit and the client has received acknowledgements for
all the data it has sent. In this case, when the client has no all the data it has sent. In this case, when the client has no
reason to send additional packets, the server will be unable to send reason to send additional packets, the server will be unable to send
more data because it has not validated the client's address. To more data because it has not validated the client's address. To
prevent this deadlock, clients MUST send a packet on a probe timeout prevent this deadlock, clients MUST send a packet on a probe timeout
(PTO, see Section 5.3 of [QUIC-RECOVERY]). Specifically, the client (PTO, see Section 6.2 of [QUIC-RECOVERY]). Specifically, the client
MUST send an Initial packet in a UDP datagram of at least 1200 bytes MUST send an Initial packet in a UDP datagram that contains at least
if it does not have Handshake keys, and otherwise send a Handshake 1200 bytes if it does not have Handshake keys, and otherwise send a
packet. Handshake packet.
A server might wish to validate the client address before starting A server might wish to validate the client address before starting
the cryptographic handshake. QUIC uses a token in the Initial packet the cryptographic handshake. QUIC uses a token in the Initial packet
to provide address validation prior to completing the handshake. to provide address validation prior to completing the handshake.
This token is delivered to the client during connection establishment This token is delivered to the client during connection establishment
with a Retry packet (see Section 8.1.2) or in a previous connection with a Retry packet (see Section 8.1.2) or in a previous connection
using the NEW_TOKEN frame (see Section 8.1.3). using the NEW_TOKEN frame (see Section 8.1.3).
In addition to sending limits imposed prior to address validation, In addition to sending limits imposed prior to address validation,
servers are also constrained in what they can send by the limits set servers are also constrained in what they can send by the limits set
skipping to change at page 50, line 19 skipping to change at page 51, line 9
tokens that might become invalid. For a client, this ambiguity means tokens that might become invalid. For a client, this ambiguity means
that sending the most recent unused token is most likely to be that sending the most recent unused token is most likely to be
effective. Though saving and using older tokens has no negative effective. Though saving and using older tokens has no negative
consequences, clients can regard older tokens as being less likely be consequences, clients can regard older tokens as being less likely be
useful to the server for address validation. useful to the server for address validation.
When a server receives an Initial packet with an address validation When a server receives an Initial packet with an address validation
token, it MUST attempt to validate the token, unless it has already token, it MUST attempt to validate the token, unless it has already
completed address validation. If the token is invalid then the completed address validation. If the token is invalid then the
server SHOULD proceed as if the client did not have a validated server SHOULD proceed as if the client did not have a validated
address, including potentially sending a Retry. If the validation address, including potentially sending a Retry. A server SHOULD
succeeds, the server SHOULD then allow the handshake to proceed. encode tokens provided with NEW_TOKEN frames and Retry packets
differently, and validate the latter more strictly. If the
validation succeeds, the server SHOULD then allow the handshake to
proceed.
Note: The rationale for treating the client as unvalidated rather Note: The rationale for treating the client as unvalidated rather
than discarding the packet is that the client might have received than discarding the packet is that the client might have received
the token in a previous connection using the NEW_TOKEN frame, and the token in a previous connection using the NEW_TOKEN frame, and
if the server has lost state, it might be unable to validate the if the server has lost state, it might be unable to validate the
token at all, leading to connection failure if the packet is token at all, leading to connection failure if the packet is
discarded. A server SHOULD encode tokens provided with NEW_TOKEN discarded.
frames and Retry packets differently, and validate the latter more
strictly.
In a stateless design, a server can use encrypted and authenticated In a stateless design, a server can use encrypted and authenticated
tokens to pass information to clients that the server can later tokens to pass information to clients that the server can later
recover and use to validate a client address. Tokens are not recover and use to validate a client address. Tokens are not
integrated into the cryptographic handshake and so they are not integrated into the cryptographic handshake and so they are not
authenticated. For instance, a client might be able to reuse a authenticated. For instance, a client might be able to reuse a
token. To avoid attacks that exploit this property, a server can token. To avoid attacks that exploit this property, a server can
limit its use of tokens to only the information needed to validate limit its use of tokens to only the information needed to validate
client addresses. client addresses.
skipping to change at page 51, line 23 skipping to change at page 52, line 17
the token MUST be covered by integrity protection against the token MUST be covered by integrity protection against
modification or falsification by clients. Without integrity modification or falsification by clients. Without integrity
protection, malicious clients could generate or guess values for protection, malicious clients could generate or guess values for
tokens that would be accepted by the server. Only the server tokens that would be accepted by the server. Only the server
requires access to the integrity protection key for tokens. requires access to the integrity protection key for tokens.
There is no need for a single well-defined format for the token There is no need for a single well-defined format for the token
because the server that generates the token also consumes it. Tokens because the server that generates the token also consumes it. Tokens
sent in Retry packets SHOULD include information that allows the sent in Retry packets SHOULD include information that allows the
server to verify that the source IP address and port in client server to verify that the source IP address and port in client
packets remains constant. packets remain constant.
Tokens sent in NEW_TOKEN frames MUST include information that allows Tokens sent in NEW_TOKEN frames MUST include information that allows
the server to verify that the client IP address has not changed from the server to verify that the client IP address has not changed from
when the token was issued. Servers can use tokens from NEW_TOKEN in when the token was issued. Servers can use tokens from NEW_TOKEN in
deciding not to send a Retry packet, even if the client address has deciding not to send a Retry packet, even if the client address has
changed. If the client IP address has changed, the server MUST changed. If the client IP address has changed, the server MUST
adhere to the anti-amplification limits found in Section 8.1. Note adhere to the anti-amplification limits found in Section 8.1. Note
that in the presence of NAT, this requirement might be insufficient that in the presence of NAT, this requirement might be insufficient
to protect other hosts that share the NAT from amplification attack. to protect other hosts that share the NAT from amplification attack.
skipping to change at page 54, line 17 skipping to change at page 55, line 10
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 (IP address and port), such as those caused by an endpoint addresses (IP address and port), such as those caused by an
endpoint migrating to a new network. This section describes the endpoint migrating to a new network. This section describes the
process by which an endpoint migrates to a new address. process by which an endpoint migrates to a new address.
The design of QUIC relies on endpoints retaining a stable address for The design of QUIC relies on endpoints retaining a stable address for
the duration of the handshake. An endpoint MUST NOT initiate the duration of the handshake. An endpoint MUST NOT initiate
connection migration before the handshake is confirmed, as defined in connection migration before the handshake is confirmed, as defined in
section 4.1.2 of [QUIC-TLS]. section 4.1.2 of [QUIC-TLS].
An endpoint also MUST NOT send packets from a different local If the peer sent the disable_active_migration transport parameter, an
address, actively initiating migration, if the peer sent the endpoint also MUST NOT send packets (including probing packets; see
disable_active_migration transport parameter during the handshake. Section 9.1) from a different local address to the address the peer
An endpoint which has sent this transport parameter, but detects that used during the handshake. An endpoint that has sent this transport
a peer has nonetheless migrated to a different network MUST either parameter, but detects that a peer has nonetheless migrated to a
drop the incoming packets on that path without generating a stateless different remote address MUST either drop the incoming packets on
reset or proceed with path validation and allow the peer to migrate. that path without generating a stateless reset or proceed with path
Generating a stateless reset or closing the connection would allow validation and allow the peer to migrate. Generating a stateless
third parties in the network to cause connections to close by reset or closing the connection would allow third parties in the
spoofing or otherwise manipulating observed traffic. network to cause connections to close by spoofing or otherwise
manipulating observed traffic.
Not all changes of peer address are intentional, or active, Not all changes of peer address are intentional, or active,
migrations. The peer could experience NAT rebinding: a change of migrations. The peer could experience NAT rebinding: a change of
address due to a middlebox, usually a NAT, allocating a new outgoing address due to a middlebox, usually a NAT, allocating a new outgoing
port or even a new outgoing IP address for a flow. An endpoint MUST port or even a new outgoing IP address for a flow. An endpoint MUST
perform path validation (Section 8.2) if it detects any change to a perform path validation (Section 8.2) if it detects any change to a
peer's address, unless it has previously validated that address. peer's address, unless it has previously validated that address.
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
skipping to change at page 59, line 51 skipping to change at page 60, line 38
until it is confirmed that an old path is no longer needed (such as until it is confirmed that an old path is no longer needed (such as
the case in Section 9.3.3). the case in Section 9.3.3).
A sender can make exceptions for probe packets so that their loss A sender can make exceptions for probe packets so that their loss
detection is independent and does not unduly cause the congestion detection is independent and does not unduly cause the congestion
controller to reduce its sending rate. An endpoint might set a controller to reduce its sending rate. An endpoint might set a
separate timer when a PATH_CHALLENGE is sent, which is cancelled if separate timer when a PATH_CHALLENGE is sent, which is cancelled if
the corresponding PATH_RESPONSE is received. If the timer fires the corresponding PATH_RESPONSE is received. If the timer fires
before the PATH_RESPONSE is received, the endpoint might send a new before the PATH_RESPONSE is received, the endpoint might send a new
PATH_CHALLENGE, and restart the timer for a longer period of time. PATH_CHALLENGE, and restart the timer for a longer period of time.
This timer SHOULD be set as described in Section 5.3 of This timer SHOULD be set as described in Section 6.2.1 of
[QUIC-RECOVERY] and MUST NOT be more aggressive. [QUIC-RECOVERY] and MUST NOT be more aggressive.
9.5. Privacy Implications of Connection Migration 9.5. Privacy Implications of Connection Migration
Using a stable connection ID on multiple network paths allows a Using a stable connection ID on multiple network paths allows a
passive observer to correlate activity between those paths. An passive observer to correlate activity between those paths. An
endpoint that moves between networks might not wish to have their endpoint that moves between networks might not wish to have their
activity correlated by any entity other than their peer, so different activity correlated by any entity other than their peer, so different
connection IDs are used when sending from different local addresses, connection IDs are used when sending from different local addresses,
as discussed in Section 5.1. For this to be effective endpoints need as discussed in Section 5.1. For this to be effective endpoints need
skipping to change at page 65, line 48 skipping to change at page 66, line 45
initiating an immediate close (Section 10.3) if it abandons the initiating an immediate close (Section 10.3) if it abandons the
connection prior to the effective value. connection prior to the effective value.
An endpoint restarts its idle timer when a packet from its peer is An endpoint restarts its idle timer when a packet from its peer is
received and processed successfully. An endpoint also restarts its received and processed successfully. An endpoint also restarts its
idle timer when sending an ack-eliciting packet if no other ack- idle timer when sending an ack-eliciting packet if no other ack-
eliciting packets have been sent since last receiving and processing eliciting packets have been sent since last receiving and processing
a packet. Restarting this timer when sending a packet ensures that a packet. Restarting this timer when sending a packet ensures that
connections are not closed after new activity is initiated. connections are not closed after new activity is initiated.
10.2.1. Liveness Testing
An endpoint that sends packets close to the effective timeout risks
having them be discarded at the peer, since the peer might enter its
draining state before these packets arrive.
An endpoint can send a PING or another ack-eliciting frame to test
the connection for liveness if the peer could time out soon, such as
within a PTO; see Section 6.2 of [QUIC-RECOVERY]. This is especially
useful if any available application data cannot be safely retried.
Note that the application determines what data is safe to retry.
10.2.2. Deferring Idle Timeout
An endpoint might need to send ack-eliciting packets to avoid an idle An endpoint might need to send ack-eliciting packets to avoid an idle
timeout if it is expecting response data, but does not have or is timeout if it is expecting response data, but does not have or is
unable to send application data. unable to send application data.
An endpoint that sends packets close to the effective timeout risks An implementation of QUIC might provide applications with an option
having them be discarded at the peer, since the peer might enter its to defer an idle timeout. This facility could be used when the
draining state before these packets arrive. An endpoint can send a application wishes to avoid losing state that has been associated
PING or another ack-eliciting frame to test the connection for with an open connection, but does not expect to exchange application
liveness if the peer could time out soon, such as within a PTO; see data for some time. With this option, an endpoint could send a PING
Section 6.6 of [QUIC-RECOVERY]. This is especially useful if any frame periodically to defer an idle timeout; see Section 19.2.
available application data cannot be safely retried. Note that the
application determines what data is safe to retry. Application protocols that use QUIC SHOULD provide guidance on when
deferring an idle timeout is appropriate. Unnecessary sending of
PING frames could have a detrimental effect on performance.
A connection will time out if no packets are sent or received for a
period longer than the time negotiated using the max_idle_timeout
transport parameter; see Section 10. However, state in middleboxes
might time out earlier than that. Though REQ-5 in [RFC4787]
recommends a 2 minute timeout interval, experience shows that sending
packets every 15 to 30 seconds is necessary to prevent the majority
of middleboxes from losing state for UDP flows.
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, an endpoint immediately After sending a CONNECTION_CLOSE frame, an endpoint immediately
enters the closing state. enters the closing state.
skipping to change at page 70, line 17 skipping to change at page 71, line 27
to appear as a valid QUIC packet, the Unpredictable Bits field needs to appear as a valid QUIC packet, the Unpredictable Bits field needs
to include at least 38 bits of data (or 5 bytes, less the two fixed to include at least 38 bits of data (or 5 bytes, less the two fixed
bits). bits).
A minimum size of 21 bytes does not guarantee that a stateless reset A minimum size of 21 bytes does not guarantee that a stateless reset
is difficult to distinguish from other packets if the recipient is difficult to distinguish from other packets if the recipient
requires the use of a connection ID. To prevent a resulting requires the use of a connection ID. To prevent a resulting
stateless reset from being trivially distinguishable from a valid stateless reset from being trivially distinguishable from a valid
packet, all packets sent by an endpoint SHOULD be padded to at least packet, all packets sent by an endpoint SHOULD be padded to at least
22 bytes longer than the minimum connection ID that the endpoint 22 bytes longer than the minimum connection ID that the endpoint
might use. An endpoint that sends a stateless reset in response to might use. An endpoint that sends a stateless reset in response to a
packet that is 43 bytes or less in length SHOULD send a stateless packet that is 43 bytes or less in length SHOULD send a stateless
reset that is one byte shorter than the packet it responds to. reset that is one byte shorter than the packet it responds to.
These values assume that the Stateless Reset Token is the same as the These values assume that the Stateless Reset Token is the same length
minimum expansion of the packet protection AEAD. Additional as the minimum expansion of the packet protection AEAD. Additional
unpredictable bytes are necessary if the endpoint could have unpredictable bytes are necessary if the endpoint could have
negotiated a packet protection scheme with a larger minimum negotiated a packet protection scheme with a larger minimum
expansion. expansion.
An endpoint MUST NOT send a stateless reset that is three times or An endpoint MUST NOT send a stateless reset that is three times or
more larger than the packet it receives to avoid being used for more larger than the packet it receives to avoid being used for
amplification. Section 10.4.3 describes additional limits on amplification. Section 10.4.3 describes additional limits on
stateless reset size. stateless reset size.
Endpoints MUST discard packets that are too small to be valid QUIC Endpoints MUST discard packets that are too small to be valid QUIC
skipping to change at page 76, line 48 skipping to change at page 78, line 24
(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 start sending needed to complete the cryptographic handshake and start sending
data. This can also be used to construct PMTU probes; see data. This can also be used to construct PMTU probes; see
Section 14.3.1. Receivers MUST be able to process coalesced packets. Section 14.4.1. Receivers MUST be able to process coalesced packets.
Coalescing packets in order of increasing encryption levels (Initial, Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it
more likely the receiver will be able to process all the packets in a more likely the receiver will be able to process all the packets in a
single pass. A packet with a short header does not include a length, single pass. A packet with a short header does not include a length,
so it can only be the last packet included in a UDP datagram. An so it can only be the last packet included in a UDP datagram. An
endpoint SHOULD NOT coalesce multiple packets at the same encryption endpoint SHOULD NOT coalesce multiple packets at the same encryption
level. level.
Senders MUST NOT coalesce QUIC packets for different connections into Senders MUST NOT coalesce QUIC packets for different connections into
skipping to change at page 78, line 22 skipping to change at page 79, line 50
protection keys. protection keys.
Conceptually, a packet number space is the context in which a packet Conceptually, a packet number space is the context in which a packet
can be processed and acknowledged. Initial packets can only be sent can be processed and acknowledged. Initial packets can only be sent
with Initial packet protection keys and acknowledged in packets which with Initial packet protection keys and acknowledged in packets which
are also Initial packets. Similarly, Handshake packets are sent at are also Initial packets. Similarly, Handshake packets are sent at
the Handshake encryption level and can only be acknowledged in the Handshake encryption level and can only be acknowledged in
Handshake packets. Handshake packets.
This enforces cryptographic separation between the data sent in the This enforces cryptographic separation between the data sent in the
different packet sequence number spaces. Packet numbers in each different packet number spaces. Packet numbers in each space start
space start at packet number 0. Subsequent packets sent in the same at packet number 0. Subsequent packets sent in the same packet
packet number space MUST increase the packet number by at least one. number space MUST increase the packet number by at least one.
0-RTT and 1-RTT data exist in the same packet number space to make 0-RTT and 1-RTT data exist in the same packet number space to make
loss recovery algorithms easier to implement between the two packet loss recovery algorithms easier to implement between the two packet
types. types.
A QUIC endpoint MUST NOT reuse a packet number within the same packet A QUIC endpoint MUST NOT reuse a packet number within the same packet
number space in one connection. If the packet number for sending number space in one connection. If the packet number for sending
reaches 2^62 - 1, the sender MUST close the connection without reaches 2^62 - 1, the sender MUST close the connection without
sending a CONNECTION_CLOSE frame or any further packets; an endpoint sending a CONNECTION_CLOSE frame or any further packets; an endpoint
MAY send a Stateless Reset (Section 10.4) in response to further MAY send a Stateless Reset (Section 10.4) in response to further
packets that it receives. packets that it receives.
A receiver MUST discard a newly unprotected packet unless it is A receiver MUST discard a newly unprotected packet unless it is
certain that it has not processed another packet with the same packet certain that it has not processed another packet with the same packet
number from the same packet number space. Duplicate suppression MUST number from the same packet number space. Duplicate suppression MUST
happen after removing packet protection for the reasons described in happen after removing packet protection for the reasons described in
Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate Section 9.3 of [QUIC-TLS].
suppression can be found in Section 3.4.3 of [RFC4303].
Endpoints that track all individual packets for the purposes of
detecting duplicates are at risk of accumulating excessive state.
The data required for detecting duplicates can be limited by
maintaining a minimum packet number below which all packets are
immediately dropped. Any minimum needs to account for large
variations in round trip time, which includes the possibility that a
peer might probe network paths with a much larger round trip times;
see Section 9.
Packet number encoding at a sender and decoding at a receiver are Packet number encoding at a sender and decoding at a receiver are
described in Section 17.1. described in Section 17.1.
12.4. Frames and Frame Types 12.4. Frames and Frame Types
The payload of QUIC packets, after removing packet protection, The payload of QUIC packets, after removing packet protection,
consists of a sequence of complete frames, as shown in Figure 10. consists of a sequence of complete frames, as shown in Figure 10.
Version Negotiation, Stateless Reset, and Retry packets do not Version Negotiation, Stateless Reset, and Retry packets do not
contain frames. contain frames.
skipping to change at page 81, line 50 skipping to change at page 83, line 50
all current and future QUIC frame types. An endpoint MAY treat the all current and future QUIC frame types. An endpoint MAY treat the
receipt of a frame type that uses a longer encoding than necessary as receipt of a frame type that uses a longer encoding than necessary as
a connection error of type PROTOCOL_VIOLATION. a connection error of type PROTOCOL_VIOLATION.
13. Packetization and Reliability 13. Packetization and Reliability
A sender bundles one or more frames in a QUIC packet; see A sender bundles one or more frames in a QUIC packet; see
Section 12.4. Section 12.4.
A sender can minimize per-packet bandwidth and computational costs by A sender can minimize per-packet bandwidth and computational costs by
bundling as many frames as possible within a QUIC packet. A sender including as many frames as possible in each QUIC packet. A sender
MAY wait for a short period of time to bundle multiple frames before MAY wait for a short period of time to collect multiple frames before
sending a packet that is not maximally packed, to avoid sending out sending a packet that is not maximally packed, to avoid sending out
large numbers of small packets. An implementation MAY use knowledge large numbers of small packets. An implementation MAY use knowledge
about application sending behavior or heuristics to determine whether about application sending behavior or heuristics to determine whether
and for how long to wait. This waiting period is an implementation and for how long to wait. This waiting period is an implementation
decision, and an implementation should be careful to delay decision, and an implementation should be careful to delay
conservatively, since any delay is likely to increase application- conservatively, since any delay is likely to increase application-
visible latency. visible latency.
Stream multiplexing is achieved by interleaving STREAM frames from Stream multiplexing is achieved by interleaving STREAM frames from
multiple streams into one or more QUIC packets. A single QUIC packet multiple streams into one or more QUIC packets. A single QUIC packet
can include multiple STREAM frames from one or more streams. can include multiple STREAM frames from one or more streams.
One of the benefits of QUIC is avoidance of head-of-line blocking One of the benefits of QUIC is avoidance of head-of-line blocking
across multiple streams. When a packet loss occurs, only streams across multiple streams. When a packet loss occurs, only streams
with data in that packet are blocked waiting for a retransmission to with data in that packet are blocked waiting for a retransmission to
be received, while other streams can continue making progress. Note be received, while other streams can continue making progress. Note
that when data from multiple streams is bundled into a single QUIC that when data from multiple streams is included in a single QUIC
packet, loss of that packet blocks all those streams from making packet, loss of that packet blocks all those streams from making
progress. Implementations are advised to bundle as few streams as progress. Implementations are advised to include as few streams as
necessary in outgoing packets without losing transmission efficiency necessary in outgoing packets without losing transmission efficiency
to underfilled packets. to underfilled packets.
13.1. Packet Processing 13.1. Packet Processing
A packet MUST NOT be acknowledged until packet protection has been A packet MUST NOT be acknowledged until packet protection has been
successfully removed and all frames contained in the packet have been successfully removed and all frames contained in the packet have been
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.
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.2. Generating Acknowledgements 13.2. Generating Acknowledgements
Endpoints acknowledge all packets they receive and process. However, Endpoints acknowledge all packets they receive and process. However,
only ack-eliciting packets cause an ACK frame to be sent within the only ack-eliciting packets cause an ACK frame to be sent within the
maximum ack delay. Packets that are not ack-eliciting are only maximum ack delay. Packets that are not ack-eliciting are only
acknowledged when an ACK frame is sent for other reasons. acknowledged when an ACK frame is sent for other reasons.
When sending a packet for any reason, an endpoint SHOULD attempt to When sending a packet for any reason, an endpoint SHOULD attempt to
bundle an ACK frame if one has not been sent recently. Doing so bundle an ACK frame if one has not been sent recently. Doing so
helps with timely loss detection at the peer. helps with timely loss detection at the peer.
skipping to change at page 83, line 24 skipping to change at page 85, line 24
packets MUST be acknowledged at least once within the maximum ack packets MUST be acknowledged at least once within the maximum ack
delay. An endpoint communicates its maximum delay using the delay. An endpoint communicates its maximum delay using the
max_ack_delay transport parameter; see Section 18.2. max_ack_delay max_ack_delay transport parameter; see Section 18.2. max_ack_delay
declares an explicit contract: an endpoint promises to never declares an explicit contract: an endpoint promises to never
intentionally delay acknowledgments of an ack-eliciting packet by intentionally delay acknowledgments of an ack-eliciting packet by
more than the indicated value. If it does, any excess accrues to the more than the indicated value. If it does, any excess accrues to the
RTT estimate and could result in spurious or delayed retransmissions RTT estimate and could result in spurious or delayed retransmissions
from the peer. For Initial and Handshake packets, a max_ack_delay of from the peer. For Initial and Handshake packets, a max_ack_delay of
0 is used. The sender uses the receiver's max_ack_delay value in 0 is used. The sender uses the receiver's max_ack_delay value in
determining timeouts for timer-based retransmission, as detailed in determining timeouts for timer-based retransmission, as detailed in
Section 5.2.1 of [QUIC-RECOVERY]. Section 6.2 of [QUIC-RECOVERY].
An ACK frame SHOULD be generated for at least every second ack- Since packets containing only ACK frames are not congestion
eliciting packet. This recommendation is in keeping with standard controlled, an endpoint MUST NOT send more than one such packet in
practice for TCP [RFC5681]. A receiver could decide to send an ACK response to receiving an ack-eliciting packet.
frame less frequently if it has information about how frequently the
sender's congestion controller needs feedback, or if the receiver is An endpoint MUST NOT send a non-ack-eliciting packet in response to a
CPU or bandwidth constrained. non-ack-eliciting packet, even if there are packet gaps which precede
the received packet. This avoids an infinite feedback loop of
acknowledgements, which could prevent the connection from ever
becoming idle. Non-ack-eliciting packets are eventually acknowledged
when the endpoint sends an ACK frame in response to other events.
In order to assist loss detection at the sender, an endpoint SHOULD In order to assist loss detection at the sender, an endpoint SHOULD
send an ACK frame immediately on receiving an ack-eliciting packet send an ACK frame immediately on receiving an ack-eliciting packet
that is out of order. The endpoint SHOULD NOT continue sending ACK that is out of order. The endpoint SHOULD NOT continue sending ACK
frames immediately unless more ack-eliciting packets are received out frames immediately unless more ack-eliciting packets are received out
of order. If every subsequent ack-eliciting packet arrives out of of order. If every subsequent ack-eliciting packet arrives out of
order, then an ACK frame SHOULD be sent immediately for every order, then an ACK frame SHOULD be sent immediately for every
received ack-eliciting packet. received ack-eliciting packet.
Similarly, packets marked with the ECN Congestion Experienced (CE) Similarly, packets marked with the ECN Congestion Experienced (CE)
codepoint in the IP header SHOULD be acknowledged immediately, to codepoint in the IP header SHOULD be acknowledged immediately, to
reduce the peer's response time to congestion events. reduce the peer's response time to congestion events.
As an optimization, a receiver MAY process multiple packets before The algorithms in [QUIC-RECOVERY] are expected to be resilient to
sending any ACK frames in response. In this case the receiver can receivers that do not follow guidance offered above. However, an
determine whether an immediate or delayed acknowledgement should be implementer should only deviate from these requirements after careful
generated after processing incoming packets. consideration of the performance implications of doing so.
Packets containing PADDING frames are considered to be in flight for
congestion control purposes [QUIC-RECOVERY]. Sending only PADDING
frames might cause the sender to become limited by the congestion
controller with no acknowledgments forthcoming from the receiver.
Therefore, a sender SHOULD ensure that other frames are sent in
addition to PADDING frames to elicit acknowledgments from the
receiver.
An endpoint that is only sending ACK frames will not receive An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are acknowledgments from its peer unless those acknowledgements are
included in packets with ack-eliciting frames. An endpoint SHOULD included in packets with ack-eliciting frames. An endpoint SHOULD
bundle ACK frames with other frames when there are new ack-eliciting bundle ACK frames with other frames when there are new ack-eliciting
packets to acknowledge. When only non-ack-eliciting packets need to packets to acknowledge. When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ack-eliciting packet be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to bundle an ACK frame with outgoing frames. has been received to bundle an ACK frame with outgoing frames.
The algorithms in [QUIC-RECOVERY] are resilient to receivers that do 13.2.2. Acknowledgement Frequency
not follow guidance offered above. However, an implementor should
only deviate from these requirements after careful consideration of
the performance implications of doing so.
Packets containing only ACK frames are not congestion controlled, so A receiver determines how frequently to send acknowledgements in
there are limits on how frequently they can be sent. An endpoint response to ack-eliciting packets. This determination involves a
MUST NOT send more than one ACK-frame-only packet in response to tradeoff.
receiving an ack-eliciting packet. An endpoint MUST NOT send a non-
ack-eliciting packet in response to a non-ack-eliciting packet, even
if there are packet gaps which precede 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.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it Endpoints rely on timely acknowledgment to detect loss; see Section 6
did not send as a connection error of type PROTOCOL_VIOLATION, if it of [QUIC-RECOVERY]. Window-based congestion controllers, such as the
is able to detect the condition. one in Section 7 of [QUIC-RECOVERY], rely on acknowledgments to
manage their congestion window. In both cases, delaying
acknowledgments can adversely affect performance.
13.2.2. Managing ACK Ranges On the other hand, reducing the frequency of packets that carry only
acknowledgements reduces packet transmission and processing cost at
both endpoints. It can also improve connection throughput on
severely asymmetric links; see Section 3 of [RFC3449].
A receiver SHOULD send an ACK frame after receiving at least two ack-
eliciting packets. This recommendation is general in nature and
consistent with recommendations for TCP endpoint behavior [RFC5681].
Knowledge of network conditions, knowledge of the peer's congestion
controller, or further research and experimentation might suggest
alternative acknowledgment strategies with better performance
characteristics.
A receiver MAY process multiple available packets before determining
whether to send an ACK frame in response.
13.2.3. Managing ACK Ranges
When an ACK frame is sent, one or more ranges of acknowledged packets When an ACK frame is sent, one or more ranges of acknowledged packets
are included. Including older packets reduces the chance of spurious are included. Including older packets reduces the chance of spurious
retransmits caused by losing previously sent ACK frames, at the cost retransmits caused by losing previously sent ACK frames, at the cost
of larger ACK frames. of larger ACK frames.
ACK frames SHOULD always acknowledge the most recently received ACK frames SHOULD always acknowledge the most recently received
packets, and the more out-of-order the packets are, the more packets, and the more out-of-order the packets are, the more
important it is to send an updated ACK frame quickly, to prevent the important it is to send an updated ACK frame quickly, to prevent the
peer from declaring a packet as lost and spuriously retransmitting peer from declaring a packet as lost and spuriously retransmitting
the frames it contains. An ACK frame is expected to fit within a the frames it contains. An ACK frame is expected to fit within a
single QUIC packet. If it does not, then older ranges (those with single QUIC packet. If it does not, then older ranges (those with
the smallest packet numbers) are omitted. the smallest packet numbers) are omitted.
Section 13.2.3 and Section 13.2.4 describe an exemplary approach for Section 13.2.4 and Section 13.2.5 describe an exemplary approach for
determining what packets to acknowledge in each ACK frame. Though determining what packets to acknowledge in each ACK frame. Though
the goal of these algorithms is to generate an acknowledgment for the goal of these algorithms is to generate an acknowledgment for
every packet that is processed, it is still possible for every packet that is processed, it is still possible for
acknowledgments to be lost. A sender cannot expect to receive an acknowledgments to be lost. A sender cannot expect to receive an
acknowledgment for every packet that the receiver processes. acknowledgment for every packet that the receiver processes.
13.2.3. Receiver Tracking of ACK Frames 13.2.4. Receiver Tracking of ACK Frames
When a packet containing an ACK frame is sent, the largest When a packet containing an ACK frame is sent, the largest
acknowledged in that frame may be saved. When a packet containing an acknowledged in that frame may be saved. When a packet containing an
ACK frame is acknowledged, the receiver can stop acknowledging ACK frame is acknowledged, the receiver can stop acknowledging
packets less than or equal to the largest acknowledged in the sent packets less than or equal to the largest acknowledged in the sent
ACK frame. ACK frame.
In cases without ACK frame loss, this algorithm allows for a minimum In cases without ACK frame loss, this algorithm allows for a minimum
of 1 RTT of reordering. In cases with ACK frame loss and reordering, of 1 RTT of reordering. In cases with ACK frame loss and reordering,
this approach does not guarantee that every acknowledgement is seen this approach does not guarantee that every acknowledgement is seen
by the sender before it is no longer included in the ACK frame. by the sender before it is no longer included in the ACK frame.
Packets could be received out of order and all subsequent ACK frames Packets could be received out of order and all subsequent ACK frames
containing them could be lost. In this case, the loss recovery containing them could be lost. In this case, the loss recovery
algorithm could cause spurious retransmits, but the sender will algorithm could cause spurious retransmits, but the sender will
continue making forward progress. continue making forward progress.
13.2.4. Limiting ACK Ranges 13.2.5. Limiting ACK Ranges
A receiver limits the number of ACK Ranges (Section 19.3.1) it A receiver limits the number of ACK Ranges (Section 19.3.1) it
remembers and sends in ACK frames, both to limit the size of ACK remembers and sends in ACK frames, both to limit the size of ACK
frames and to avoid resource exhaustion. After receiving frames and to avoid resource exhaustion. After receiving
acknowledgments for an ACK frame, the receiver SHOULD stop tracking acknowledgments for an ACK frame, the receiver SHOULD stop tracking
those acknowledged ACK Ranges. those acknowledged ACK Ranges.
It is possible that retaining many ACK Ranges could cause an ACK It is possible that retaining many ACK Ranges could cause an ACK
frame to become too large. A receiver can discard unacknowledged ACK frame to become too large. A receiver can discard unacknowledged ACK
Ranges to limit ACK frame size, at the cost of increased Ranges to limit ACK frame size, at the cost of increased
skipping to change at page 86, line 23 skipping to change at page 88, line 33
time. This could cause the receiver to maintain state for a large time. This could cause the receiver to maintain state for a large
number of ACK frames for a long period of time, and ACK frames it number of ACK frames for a long period of time, and ACK frames it
sends could be unnecessarily large. In such a case, a receiver could sends could be unnecessarily large. In such a case, a receiver could
bundle a PING or other small ack-eliciting frame occasionally, such bundle a PING or other small ack-eliciting frame occasionally, such
as once per round trip, to elicit an ACK from the peer. as once per round trip, to elicit an ACK from the peer.
A receiver MUST NOT bundle an ack-eliciting frame with all packets A receiver MUST NOT bundle an ack-eliciting frame with all packets
that would otherwise be non-ack-eliciting, to avoid an infinite that would otherwise be non-ack-eliciting, to avoid an infinite
feedback loop of acknowledgements. feedback loop of acknowledgements.
13.2.5. Measuring and Reporting Host Delay 13.2.6. Measuring and Reporting Host Delay
An endpoint measures the delays intentionally introduced between the An endpoint measures the delays intentionally introduced between the
time the packet with the largest packet number is received and the time the packet with the largest packet number is received and the
time an acknowledgment is sent. The endpoint encodes this delay in time an acknowledgment is sent. The endpoint encodes this delay in
the Ack Delay field of an ACK frame; see Section 19.3. This allows the Ack Delay field of an ACK frame; see Section 19.3. This allows
the receiver of the ACK to adjust for any intentional delays, which the receiver of the ACK to adjust for any intentional delays, which
is important for getting a better estimate of the path RTT when is important for getting a better estimate of the path RTT when
acknowledgments are delayed. A packet might be held in the OS kernel acknowledgments are delayed. A packet might be held in the OS kernel
or elsewhere on the host before being processed. An endpoint MUST or elsewhere on the host before being processed. An endpoint MUST
NOT include delays that it does not control when populating the Ack NOT include delays that it does not control when populating the Ack
Delay field in an ACK frame. Delay field in an ACK frame.
13.2.6. ACK Frames and Packet Protection 13.2.7. 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.
13.2.8. PADDING Frames Consume Congestion Window
Packets containing PADDING frames are considered to be in flight for
congestion control purposes [QUIC-RECOVERY]. Packets containing only
PADDING frames therefore consume congestion window but do not
generate acknowledgments that will open the congestion window. To
avoid a deadlock, a sender SHOULD ensure that other frames are sent
periodically in addition to PADDING frames to elicit acknowledgments
from the receiver.
13.3. Retransmission of Information 13.3. 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
when a packet containing that information is determined to be lost when a packet containing that information is determined to be lost
skipping to change at page 90, line 15 skipping to change at page 92, line 31
13.4.1. ECN Counts 13.4.1. ECN Counts
On receiving a QUIC packet with an ECT or CE codepoint, an ECN- On receiving a QUIC packet with an ECT or CE codepoint, an ECN-
enabled endpoint that can access the ECN codepoints from the enabled endpoint that can access the ECN codepoints from the
enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE
count, and includes these counts in subsequent ACK frames; see count, and includes these counts in subsequent ACK frames; see
Section 13.2 and Section 19.3. Note that this requires being able to Section 13.2 and Section 19.3. Note that this requires being able to
read the ECN codepoints from the enclosing IP packet, which is not read the ECN codepoints from the enclosing IP packet, which is not
possible on all platforms. possible on all platforms.
A packet detected by a receiver as a duplicate does not affect the An IP packet that results in no QUIC packets being processed does not
receiver's local ECN codepoint counts; see (Section 21.8) for increase ECN counts. A QUIC packet detected by a receiver as a
relevant security concerns. duplicate does not affect the receiver's local ECN codepoint counts;
see Section 21.8 for relevant security concerns.
If an endpoint receives a QUIC packet without an ECT or CE codepoint If an endpoint receives a QUIC packet without an ECT or CE codepoint
in the IP packet header, it responds per Section 13.2 with an ACK in the IP packet header, it responds per Section 13.2 with an ACK
frame without increasing any ECN counts. If an endpoint does not frame without increasing any ECN counts. If an endpoint does not
implement ECN support or does not have access to received ECN implement ECN support or does not have access to received ECN
codepoints, it does not increase ECN counts. codepoints, it does not increase ECN counts.
Coalesced packets (see Section 12.2) mean that several packets can Coalesced packets (see Section 12.2) mean that several packets can
share the same IP header. The ECN counter for the ECN codepoint share the same IP header. The ECN counts for the ECN codepoint
received in the associated IP header are incremented once for each received in the associated IP header are incremented once for each
QUIC packet, not per enclosing IP packet or UDP datagram. QUIC packet, not per enclosing IP packet or UDP datagram.
Each packet number space maintains separate acknowledgement state and Each packet number space maintains separate acknowledgement state and
separate ECN counts. For example, if one each of an Initial, 0-RTT, separate ECN counts. For example, if one each of an Initial, 0-RTT,
Handshake, and 1-RTT QUIC packet are coalesced, the corresponding Handshake, and 1-RTT QUIC packet are coalesced, the corresponding
counts for the Initial and Handshake packet number space will be counts for the Initial and Handshake packet number space will be
incremented by one and the counts for the 1-RTT packet number space incremented by one and the counts for the 1-RTT packet number space
will be increased by two. will be increased by two.
skipping to change at page 91, line 24 skipping to change at page 93, line 37
* Set the ECT(0) codepoint in the IP header of early outgoing * Set the ECT(0) codepoint in the IP header of early outgoing
packets sent on a new path to the peer [RFC8311]. packets sent on a new path to the peer [RFC8311].
* If all packets that were sent with the ECT(0) codepoint are * If all packets that were sent with the ECT(0) codepoint are
eventually deemed lost [QUIC-RECOVERY], validation is deemed to eventually deemed lost [QUIC-RECOVERY], validation is deemed to
have failed. have failed.
To reduce the chances of misinterpreting congestive loss as packets To reduce the chances of misinterpreting congestive loss as packets
dropped by a faulty network element, an endpoint could set the ECT(0) dropped by a faulty network element, an endpoint could set the ECT(0)
codepoint in the first ten outgoing packets on a path, or for a codepoint for only the first ten outgoing packets on a path, or for a
period of three RTTs, whichever occurs first. period of three RTTs, whichever occurs first.
Implementations MAY experiment with and use other strategies for use Other methods of probing paths for ECN support are possible, as are
of ECN. Other methods of probing paths for ECN support are possible, different marking strategies. Implementations MAY use other methods
as are different marking strategies. Implementations can also use defined in RFCs; see [RFC8311]. Implementations that use the ECT(1)
the ECT(1) codepoint, as specified in [RFC8311]. codepoint need to perform ECN validation using ECT(1) counts.
13.4.2.2. Receiving ACK Frames 13.4.2.2. Receiving ACK Frames
An endpoint that sets ECT(0) or ECT(1) codepoints on packets it An endpoint that sets ECT(0) or ECT(1) codepoints on packets it
transmits MUST use the following steps on receiving an ACK frame to transmits MUST use the following steps on receiving an ACK frame to
validate ECN. validate ECN.
* If this ACK frame newly acknowledges a packet that the endpoint * If this ACK frame newly acknowledges a packet that the endpoint
sent with either ECT(0) or ECT(1) codepoints set, and if no ECN sent with either ECT(0) or ECT(1) codepoints set, and if no ECN
feedback is present in the ACK frame, validation fails. This step feedback is present in the ACK frame, validation fails. This step
skipping to change at page 92, line 41 skipping to change at page 95, line 8
is ECN-capable. Network routing and path elements can change mid- is ECN-capable. Network routing and path elements can change mid-
connection however; an endpoint MUST disable ECN if validation fails connection however; an endpoint MUST disable ECN if validation fails
at any point in the connection. at any point in the connection.
Even if validation fails, an endpoint MAY revalidate ECN on the same Even if validation fails, an endpoint MAY revalidate ECN on the same
path at any later time in the connection. path at any later time in the connection.
14. Packet Size 14. Packet Size
The QUIC packet size includes the QUIC header and protected payload, The QUIC packet size includes the QUIC header and protected payload,
but not the UDP or IP header. but not the UDP or IP headers.
A client MUST expand the payload of all UDP datagrams carrying QUIC depends upon a minimum IP packet size of at least 1280 bytes.
Initial packets to at least 1200 bytes, by adding PADDING frames to This is the IPv6 minimum size [RFC8200] and is also supported by most
the Initial packet or by coalescing the Initial packet; see modern IPv4 networks. Assuming the minimum IP header size, this
Section 12.2. Sending a UDP datagram of this size ensures that the results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252
network path from the client to the server supports a reasonable bytes for IPv4.
Maximum Transmission Unit (MTU). Padding datagrams also helps reduce
the amplitude of amplification attacks caused by server responses The QUIC maximum packet size is the largest size of QUIC packet that
toward an unverified client address; see Section 8. can be sent across a network path using a single packet. Any maximum
packet size larger than 1200 bytes can be discovered using Path
Maximum Transmission Unit Discovery (PMTUD; see Section 14.2.1) or
Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see
Section 14.3).
Enforcement of the max_udp_payload_size transport parameter Enforcement of the max_udp_payload_size transport parameter
(Section 18.2) might act as an additional limit on packet size. (Section 18.2) might act as an additional limit on the maximum packet
Exceeding this limit can be avoided once the value is known. size. A sender can avoid exceeding this limit, once the value is
However, prior to learning the value of the transport parameter, known. However, prior to learning the value of the transport
endpoints risk datagrams being lost if they send packets larger than parameter, endpoints risk datagrams being lost if they send packets
1200 bytes. larger than the smallest allowed maximum packet size of 1200 bytes.
UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4
[IPv4], the DF bit MUST be set to prevent fragmentation on the path.
14.1. Initial Packet Size
A client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least the smallest allowed maximum packet size
(1200 bytes) by adding PADDING frames to the Initial packet or by
coalescing the Initial packet; see Section 12.2. Sending a UDP
datagram of this size ensures that the network path from the client
to the server supports a reasonable Path Maximum Transmission Unit
(PMTU). This also helps reduce the amplitude of amplification
attacks caused by server responses toward an unverified client
address; see Section 8.
Datagrams containing Initial packets MAY exceed 1200 bytes if the Datagrams containing Initial packets MAY exceed 1200 bytes if the
client believes that the network path and peer both support the size client believes that the network path and peer both support the size
that it chooses. that it chooses.
UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4
[IPv4], the DF bit MUST be set to prevent fragmentation on the path.
A server MUST discard an Initial packet that is carried in a UDP A server MUST discard an Initial packet that is carried in a UDP
datagram with a payload that is less than 1200 bytes. A server MAY datagram with a payload that is less than the smallest allowed
also immediately close the connection by sending a CONNECTION_CLOSE maximum packet size of 1200 bytes. A server MAY also immediately
frame with an error code of PROTOCOL_VIOLATION; see Section 10.3.1. close the connection by sending a CONNECTION_CLOSE frame with an
error code of PROTOCOL_VIOLATION; see Section 10.3.1.
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.2. Path Maximum Transmission Unit (PMTU)
The Path Maximum Transmission Unit (PMTU) is the maximum size of the The Path Maximum Transmission Unit (PMTU) is the maximum size of the
entire IP packet including the IP header, UDP header, and UDP entire IP packet including the IP header, UDP header, and UDP
payload. The UDP payload includes the QUIC packet header, protected payload. The UDP payload includes the QUIC packet header, protected
payload, and any authentication fields. The PMTU can depend on path payload, and any authentication fields. The PMTU can depend on path
characteristics, and can therefore change over time. The largest UDP characteristics, and can therefore change over time. The largest UDP
payload an endpoint sends at any given time is referred to as the payload an endpoint sends at any given time is referred to as the
endpoint's maximum packet size. endpoint's maximum packet size.
QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 An endpoint SHOULD use DPLPMTUD (Section 14.3) or PMTUD
minimum size [RFC8200] and is also supported by most modern IPv4 (Section 14.2.1) to determine whether the path to a destination will
networks. All QUIC packets (except for PMTU probe packets) SHOULD be support a desired maximum packet size without fragmentation. In the
sized to fit within the maximum packet size to avoid the packet being absence of these mechanisms, QUIC endpoints SHOULD NOT send IP
fragmented or dropped [RFC8085]. packets larger than the smallest allowed maximum packet size.
An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery Both DPLPMTUD and PMTUD send IP packets that are larger than the
([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191] current maximum packet size. We refer to these as PMTU probes. All
[RFC8201] to determine whether the path to a destination will support QUIC packets that are not sent in a PMTU probe SHOULD be sized to fit
a desired message size without fragmentation. within the maximum packet size to avoid the packet being fragmented
or dropped [RFC8085].
In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP If a QUIC endpoint determines that the PMTU between any pair of local
packets larger than 1280 bytes. Assuming the minimum IP header size, and remote IP addresses has fallen below the smallest allowed maximum
this results in a QUIC maximum packet size of 1232 bytes for IPv6 and packet size of 1200 bytes, it MUST immediately cease sending QUIC
1252 bytes for IPv4. A QUIC implementation MAY be more conservative packets, except for those in PMTU probes or those containing
in computing the QUIC maximum packet size to allow for unknown tunnel CONNECTION_CLOSE frames, on the affected path. An endpoint MAY
overheads or IP header options/extensions. terminate the connection if an alternative path cannot be found.
Each pair of local and remote addresses could have a different PMTU. Each pair of local and remote addresses could have a different PMTU.
QUIC implementations that implement any kind of PMTU discovery QUIC implementations that implement any kind of PMTU discovery
therefore SHOULD maintain a maximum packet size for each combination therefore SHOULD maintain a maximum packet size for each combination
of local and remote IP addresses. of local and remote IP addresses.
If a QUIC endpoint determines that the PMTU between any pair of local A QUIC implementation MAY be more conservative in computing the
and remote IP addresses has fallen below the size needed to support maximum packet size to allow for unknown tunnel overheads or IP
the smallest allowed maximum packet size, it MUST immediately cease header options/extensions.
sending QUIC packets, except for PMTU probe packets, on the affected
path. An endpoint MAY terminate the connection if an alternative
path cannot be found.
14.2. ICMP Packet Too Big Messages 14.2.1. Handling of ICMP Messages by PMTUD
PMTU discovery [RFC1191] [RFC8201] relies on reception of ICMP Path Maximum Transmission Unit Discovery (PMTUD; [RFC1191],
messages (e.g., IPv6 Packet Too Big messages) that indicate when a [RFC8201]) relies on reception of ICMP messages (e.g., IPv6 Packet
packet is dropped because it is larger than the local router MTU. Too Big messages) that indicate when a packet is dropped because it
DPLPMTUD can also optionally use these messages. This use of ICMP is larger than the local router MTU. DPLPMTUD can also optionally
messages is potentially vulnerable to off-path attacks that use these messages. This use of ICMP messages is potentially
successfully guess the addresses used on the path and reduce the PMTU vulnerable to off-path attacks that successfully guess the addresses
to a bandwidth-inefficient value. used on the path and reduce the PMTU to a bandwidth-inefficient
value.
An endpoint MUST ignore an ICMP message that claims the PMTU has An endpoint MUST ignore an ICMP message that claims the PMTU has
decreased below 1280 bytes. decreased below the minimum QUIC packet size.
The requirements for generating ICMP ([RFC1812], [RFC4443]) state The requirements for generating ICMP ([RFC1812], [RFC4443]) state
that the quoted packet should contain as much of the original packet that the quoted packet should contain as much of the original packet
as possible without exceeding the minimum MTU for the IP version. as possible without exceeding the minimum MTU for the IP version.
The size of the quoted packet can actually be smaller, or the The size of the quoted packet can actually be smaller, or the
information unintelligible, as described in Section 1.1 of information unintelligible, as described in Section 1.1 of
[DPLPMTUD]. [DPLPMTUD].
QUIC endpoints SHOULD validate ICMP messages to protect from off-path QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
injection as specified in [RFC8201] and Section 5.2 of [RFC8085]. from off-path injection as specified in [RFC8201] and Section 5.2 of
This validation SHOULD use the quoted packet supplied in the payload [RFC8085]. This validation SHOULD use the quoted packet supplied in
of an ICMP message to associate the message with a corresponding the payload of an ICMP message to associate the message with a
transport connection [DPLPMTUD]. corresponding transport connection (see Section 4.6.1 of [DPLPMTUD]).
ICMP message validation MUST include matching IP addresses and UDP ICMP message validation MUST include matching IP addresses and UDP
ports [RFC8085] and, when possible, connection IDs to an active QUIC ports [RFC8085] and, when possible, connection IDs to an active QUIC
session. session. The endpoint SHOULD ignore all ICMP messages that fail
validation.
The endpoint SHOULD ignore all ICMP messages that fail validation.
An endpoint MUST NOT increase PMTU based on ICMP messages; see An endpoint MUST NOT increase PMTU based on ICMP messages; see
Section 3, clause 6 of [DPLPMTUD]. Any reduction in the QUIC maximum Section 3, clause 6 of [DPLPMTUD]. Any reduction in the QUIC maximum
packet size in response to ICMP messages MAY be provisional until packet size in response to ICMP messages MAY be provisional until
QUIC's loss detection algorithm determines that the quoted packet has QUIC's loss detection algorithm determines that the quoted packet has
actually been lost. actually been lost.
14.3. Datagram Packetization Layer PMTU Discovery 14.3. Datagram Packetization Layer PMTU Discovery
Section 6.3 of [DPLPMTUD] provides considerations for implementing Datagram Packetization Layer PMTU Discovery (DPLPMTUD; [DPLPMTUD])
Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC. relies on tracking loss or acknowledgment of QUIC packets that are
carried in PMTU probes. PMTU probes for DPLPMTUD that use the
PADDING frame implement "Probing using padding data", as defined in
Section 4.1 of [DPLPMTUD].
When implementing the algorithm in Section 5 of [DPLPMTUD], the Endpoints SHOULD set the initial value of BASE_PMTU (see Section 5.1
initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC of [DPLPMTUD]) to be consistent with the minimum QUIC packet size.
packet size (1232 bytes for IPv6 and 1252 bytes for IPv4). The MIN_PLPMTU is the same as the BASE_PMTU.
PING and PADDING frames can be used to generate PMTU probe packets. QUIC endpoints implementing DPLPMTUD maintain a maximum packet size
These frames might not be retransmitted if a probe packet containing (DPLPMTUD MPS) for each combination of local and remote IP addresses.
them is lost. However, these frames do consume congestion window,
which could delay the transmission of subsequent application data.
A PING frame can be included in a PMTU probe to ensure that a valid 14.3.1. DPLPMTUD and Initial Connectivity
probe is acknowledged.
The considerations for processing ICMP messages in the previous From the perspective of DPLPMTUD, QUIC transport is an acknowledged
section also apply if these messages are used by DPLPMTUD. packetization layer (PL). A sender can therefore enter the DPLPMTUD
BASE state when the QUIC connection handshake has been completed.
14.3.1. PMTU Probes Containing Source Connection ID 14.3.2. Validating the QUIC Path with DPLPMTUD
QUIC provides an acknowledged PL, therefore a sender does not
implement the DPLPMTUD CONFIRMATION_TIMER while in the
SEARCH_COMPLETE state; see Section 5.2 of [DPLPMTUD].
14.3.3. Handling of ICMP Messages by DPLPMTUD
An endpoint using DPLPMTUD requires the validation of any received
ICMP Packet Too Big (PTB) message before using the PTB information,
as defined in Section 4.6 of [DPLPMTUD]. In addition to UDP port
validation, QUIC validates an ICMP message by using other PL
information (e.g., validation of connection IDs in the quoted packet
of any received ICMP message).
The considerations for processing ICMP messages described in
Section 14.2.1 also apply if these messages are used by DPLPMTUD.
14.4. Sending QUIC PMTU Probes
PMTU probes are ack-eliciting packets.
Endpoints could limit the content of PMTU probes to PING and PADDING
frames as packets that are larger than the current maximum packet
size are more likely to be dropped by the network. Loss of a QUIC
packet that is carried in a PMTU probe is therefore not a reliable
indication of congestion and SHOULD NOT trigger a congestion control
reaction; see Section 3, Bullet 7 of [DPLPMTUD]. However, PMTU
probes consume congestion window, which could delay subsequent
transmission by an application.
14.4.1. PMTU Probes Containing Source Connection ID
Endpoints that rely on the destination connection ID for routing Endpoints that rely on the destination connection ID for routing
incoming QUIC packets are likely to require that the connection ID be incoming QUIC packets are likely to require that the connection ID be
included in PMTU probe packets to route any resulting ICMP messages included in PMTU probes to route any resulting ICMP messages
(Section 14.2) back to the correct endpoint. However, only long (Section 14.2.1) back to the correct endpoint. However, only long
header packets (Section 17.2) contain source connection IDs, and long header packets (Section 17.2) contain the Source Connection ID field,
header packets are not decrypted or acknowledged by the peer once the and long header packets are not decrypted or acknowledged by the peer
handshake is complete. once the handshake is complete.
One way to construct a probe for the path MTU is to coalesce (see One way to construct a PMTU probe is to coalesce (see Section 12.2) a
Section 12.2) a Handshake packet (Section 17.2.4) with a short header packet with a long header, such as a Handshake or 0-RTT packet
packet in a single UDP datagram. If the UDP datagram reaches the (Section 17.2), with a short header packet in a single UDP datagram.
endpoint, the Handshake packet will be ignored, but the short header If the resulting PMTU probe reaches the endpoint, the packet with the
packet will be acknowledged. If the UDP datagram causes an ICMP long header will be ignored, but the short header packet will be
message to be sent, the first part of the datagram will be quoted in acknowledged. If the PMTU probe causes an ICMP message to be sent,
that message. If the source connection ID is within the quoted the first part of the probe will be quoted in that message. If the
portion of the UDP datagram, that could be used for routing. Source Connection ID field is within the quoted portion of the probe,
that could be used for routing or validation of the ICMP message.
Note: The purpose of using a packet with a long header is only to
ensure that the quoted packet contained in the ICMP message
contains a Source Connection ID field. This packet does not need
to be a valid packet and it can be sent even if there is no
current use for packets of that type.
15. Versions 15. Versions
QUIC versions are identified using a 32-bit unsigned number. QUIC versions are identified using a 32-bit unsigned number.
The version 0x00000000 is reserved to represent version negotiation. The version 0x00000000 is reserved to represent version negotiation.
This version of the specification is identified by the number This version of the specification is identified by the number
0x00000001. 0x00000001.
Other versions of QUIC might have different properties to this Other versions of QUIC might have different properties to this
skipping to change at page 99, line 6 skipping to change at page 103, line 4
Once header protection is removed, the packet number is decoded by Once header protection is removed, the packet number is decoded by
finding the packet number value that is closest to the next expected finding the packet number value that is closest to the next expected
packet. The next expected packet is the highest received packet packet. The next expected packet is the highest received packet
number plus one. For example, if the highest successfully number plus one. For example, if the highest successfully
authenticated packet had a packet number of 0xa82f30ea, then a packet authenticated packet had a packet number of 0xa82f30ea, then a packet
containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32.
Example pseudo-code for packet number decoding can be found in Example pseudo-code for packet number decoding can be found in
Appendix A. Appendix A.
17.2. Long Header Packets 17.2. Long Header Packets
Long Header Packet { Long Header Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2), Long Packet Type (2),
Type-Specific Bits (4), Type-Specific Bits (4),
Version (32), Version (32),
DCID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
SCID Length (8), Source Connection ID Length (8),
Source Connection ID (0..160), Source Connection ID (0..160),
} }
Figure 12: Long Header Packet Format Figure 12: Long Header Packet Format
Long headers are used for packets that are sent prior to the Long headers are used for packets that are sent prior to the
establishment of 1-RTT keys. Once 1-RTT keys are available, a sender establishment of 1-RTT keys. Once 1-RTT keys are available, a sender
switches to sending packets using the short header (Section 17.3). switches to sending packets using the short header (Section 17.3).
The long form allows for special packets - such as the Version The long form allows for special packets - such as the Version
Negotiation packet - to be represented in this uniform fixed-length Negotiation packet - to be represented in this uniform fixed-length
skipping to change at page 100, line 5 skipping to change at page 103, line 43
Long Packet Type: The next two bits (those with a mask of 0x30) of Long Packet Type: The next two bits (those with a mask of 0x30) of
byte 0 contain a packet type. Packet types are listed in Table 5. byte 0 contain a packet type. Packet types are listed in Table 5.
Type-Specific Bits: The lower four bits (those with a mask of 0x0f) Type-Specific Bits: The lower four bits (those with a mask of 0x0f)
of byte 0 are type-specific. of byte 0 are type-specific.
Version: The QUIC Version is a 32-bit field that follows the first Version: The QUIC Version is a 32-bit field that follows the first
byte. This field indicates which version of QUIC is in use and byte. This field indicates which version of QUIC is in use and
determines how the rest of the protocol fields are interpreted. determines how the rest of the protocol fields are interpreted.
DCID Length: The byte following the version contains the length in Destination Connection ID Length: The byte following the version
bytes of the Destination Connection ID field that follows it. contains the length in bytes of the Destination Connection ID
This length is encoded as an 8-bit unsigned integer. In QUIC field that follows it. This length is encoded as an 8-bit
version 1, this value MUST NOT exceed 20. Endpoints that receive unsigned integer. In QUIC version 1, this value MUST NOT exceed
a version 1 long header with a value larger than 20 MUST drop the 20. Endpoints that receive a version 1 long header with a value
packet. Servers SHOULD be able to read longer connection IDs from larger than 20 MUST drop the packet. Servers SHOULD be able to
other QUIC versions in order to properly form a version read longer connection IDs from other QUIC versions in order to
negotiation packet. properly form a version negotiation packet.
Destination Connection ID: The Destination Connection ID field Destination Connection ID: The Destination Connection ID field
follows the DCID Length field and is between 0 and 20 bytes in follows the Destination Connection ID Length field and is between
length. Section 7.2 describes the use of this field in more 0 and 20 bytes in length. Section 7.2 describes the use of this
detail. field in more detail.
SCID Length: The byte following the Destination Connection ID Source Connection ID Length: The byte following the Destination
contains the length in bytes of the Source Connection ID field Connection ID contains the length in bytes of the Source
that follows it. This length is encoded as a 8-bit unsigned Connection ID field that follows it. This length is encoded as a
integer. In QUIC version 1, this value MUST NOT exceed 20 bytes. 8-bit unsigned integer. In QUIC version 1, this value MUST NOT
Endpoints that receive a version 1 long header with a value larger exceed 20 bytes. Endpoints that receive a version 1 long header
than 20 MUST drop the packet. Servers SHOULD be able to read with a value larger than 20 MUST drop the packet. Servers SHOULD
longer connection IDs from other QUIC versions in order to be able to read longer connection IDs from other QUIC versions in
properly form a version negotiation packet. order to properly form a version negotiation packet.
Source Connection ID: The Source Connection ID field follows the Source Connection ID: The Source Connection ID field follows the
SCID Length field and is between 0 and 20 bytes in length. Source Connection ID Length field and is between 0 and 20 bytes in
Section 7.2 describes the use of this field in more detail. length. Section 7.2 describes the use of this field in more
detail.
In this version of QUIC, the following packet types with the long In this version of QUIC, the following packet types with the long
header are defined: header are defined:
+------+-----------+----------------+ +------+-----------+----------------+
| Type | Name | Section | | Type | Name | Section |
+======+===========+================+ +======+===========+================+
| 0x0 | Initial | Section 17.2.2 | | 0x0 | Initial | Section 17.2.2 |
+------+-----------+----------------+ +------+-----------+----------------+
| 0x1 | 0-RTT | Section 17.2.3 | | 0x1 | 0-RTT | Section 17.2.3 |
skipping to change at page 102, line 11 skipping to change at page 106, line 9
The Version Negotiation packet is a response to a client packet that The Version Negotiation packet is a response to a client packet that
contains a version that is not supported by the server, and is only contains a version that is not supported by the server, and is only
sent by servers. sent by servers.
The layout of a Version Negotiation packet is: The layout of a Version Negotiation packet is:
Version Negotiation Packet { Version Negotiation Packet {
Header Form (1) = 1, Header Form (1) = 1,
Unused (7), Unused (7),
Version (32) = 0, Version (32) = 0,
DCID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..2040), Destination Connection ID (0..2040),
SCID Length (8), Source Connection ID Length (8),
Source Connection ID (0..2040), Source Connection ID (0..2040),
Supported Version (32) ..., Supported Version (32) ...,
} }
Figure 13: Version Negotiation Packet Figure 13: Version Negotiation Packet
The value in the Unused field is selected randomly by the server. The value in the Unused field is selected randomly by the server.
Clients MUST ignore the value of this field. Servers SHOULD set the Clients MUST ignore the value of this field. Servers SHOULD set the
most significant bit of this field (0x40) to 1 so that Version most significant bit of this field (0x40) to 1 so that Version
Negotiation packets appear to have the Fixed Bit field. Negotiation packets appear to have the Fixed Bit field.
skipping to change at page 103, line 23 skipping to change at page 107, line 20
carries the first CRYPTO frames sent by the client and server to carries the first CRYPTO frames sent by the client and server to
perform key exchange, and carries ACKs in either direction. perform key exchange, and carries ACKs in either direction.
Initial Packet { Initial Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 0, Long Packet Type (2) = 0,
Reserved Bits (2), Reserved Bits (2),
Packet Number Length (2), Packet Number Length (2),
Version (32), Version (32),
DCID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
SCID Length (8), Source Connection ID Length (8),
Source Connection ID (0..160), Source Connection ID (0..160),
Token Length (i), Token Length (i),
Token (..), Token (..),
Length (i), Length (i),
Packet Number (8..32), Packet Number (8..32),
Packet Payload (..), Packet Payload (..),
} }
Figure 14: Initial Packet Figure 14: Initial Packet
The Initial packet contains a long header as well as the Length and The Initial packet contains a long header as well as the Length and
Packet Number fields. The first byte contains the Reserved and Packet Number fields. The first byte contains the Reserved and
Packet Number Length bits. Between the SCID and Length fields, there Packet Number Length bits. Between the Source Connection ID and
are two additional fields specific to the Initial packet. Length fields, there are two additional fields specific to the
Initial packet.
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
Token field, in bytes. This value is zero if no token is present. Token field, in bytes. This value is zero if no token is present.
Initial packets sent by the server MUST set the Token Length field Initial packets sent by the server MUST set the Token Length field
to zero; clients that receive an Initial packet with a non-zero to zero; clients that receive an Initial packet with a non-zero
Token Length field MUST either discard the packet or generate a Token Length field MUST either discard the packet or generate a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
Token: The value of the token that was previously provided in a Token: The value of the token that was previously provided in a
Retry packet or NEW_TOKEN frame. Retry packet or NEW_TOKEN frame.
skipping to change at page 104, line 24 skipping to change at page 108, line 24
message needs to be created, such as the packets sent after receiving message needs to be created, such as the packets sent after receiving
a Retry packet (Section 17.2.5). a Retry packet (Section 17.2.5).
A server sends its first Initial packet in response to a client A server sends its first Initial packet in response to a client
Initial. A server may send multiple Initial packets. The Initial. A server may send multiple Initial packets. The
cryptographic key exchange could require multiple round trips or cryptographic key exchange could require multiple round trips or
retransmissions of this data. retransmissions of this data.
The payload of an Initial packet includes a CRYPTO frame (or frames) The payload of an Initial packet includes a CRYPTO frame (or frames)
containing a cryptographic handshake message, ACK frames, or both. containing a cryptographic handshake message, ACK frames, or both.
PING, PADDING, and CONNECTION_CLOSE frames are also permitted. An PING, PADDING, and CONNECTION_CLOSE frames of type 0x1c are also
endpoint that receives an Initial packet containing other frames can permitted. An endpoint that receives an Initial packet containing
either discard the packet as spurious or treat it as a connection other frames can either discard the packet as spurious or treat it as
error. a connection error.
The first packet sent by a client always includes a CRYPTO frame that The first packet sent by a client always includes a CRYPTO frame that
contains the start or all of the first cryptographic handshake contains the start or all of the first cryptographic handshake
message. The first CRYPTO frame sent always begins at an offset of message. The first CRYPTO frame sent always begins at an offset of
0; see Section 7. 0; see Section 7.
Note that if the server sends a HelloRetryRequest, the client will Note that if the server sends a HelloRetryRequest, the client will
send another series of Initial packets. These Initial packets will send another series of Initial packets. These Initial packets will
continue the cryptographic handshake and will contain CRYPTO frames continue the cryptographic handshake and will contain CRYPTO frames
starting at an offset matching the size of the CRYPTO frames sent in starting at an offset matching the size of the CRYPTO frames sent in
the first flight of Initial packets. the first flight of Initial packets.
17.2.2.1. Abandoning Initial Packets 17.2.2.1. Abandoning Initial Packets
A client stops both sending and processing Initial packets when it A client stops both sending and processing Initial packets when it
sends its first Handshake packet. A server stops sending and sends its first Handshake packet. A server stops sending and
processing Initial packets when it receives its first Handshake processing Initial packets when it receives its first Handshake
packet. Though packets might still be in flight or awaiting packet. Though packets might still be in flight or awaiting
acknowledgment, no further Initial packets need to be exchanged acknowledgment, no further Initial packets need to be exchanged
beyond this point. Initial packet protection keys are discarded (see beyond this point. Initial packet protection keys are discarded (see
Section 4.10.1 of [QUIC-TLS]) along with any loss recovery and Section 4.11.1 of [QUIC-TLS]) along with any loss recovery and
congestion control state; see Section 6.5 of [QUIC-RECOVERY]. congestion control state; see Section 6.4 of [QUIC-RECOVERY].
Any data in CRYPTO frames is discarded - and no longer retransmitted Any data in CRYPTO frames is discarded - and no longer retransmitted
- when Initial keys are discarded. - when Initial keys are discarded.
17.2.3. 0-RTT 17.2.3. 0-RTT
A 0-RTT packet uses long headers with a type value of 0x1, followed A 0-RTT packet uses long headers with a type value of 0x1, followed
by the Length and Packet Number fields. The first byte contains the by the Length and Packet Number fields. 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 105, line 24 skipping to change at page 109, line 24
See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its
limitations. limitations.
0-RTT Packet { 0-RTT Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 1, Long Packet Type (2) = 1,
Reserved Bits (2), Reserved Bits (2),
Packet Number Length (2), Packet Number Length (2),
Version (32), Version (32),
DCID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
SCID Length (8), Source Connection ID Length (8),
Source Connection ID (0..160), Source Connection ID (0..160),
Length (i), Length (i),
Packet Number (8..32), Packet Number (8..32),
Packet Payload (..), Packet Payload (..),
} }
Figure 15: 0-RTT Packet Figure 15: 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.
skipping to change at page 106, line 35 skipping to change at page 110, line 35
carry acknowledgments and cryptographic handshake messages from the carry acknowledgments and cryptographic handshake messages from the
server and client. server and client.
Handshake Packet { Handshake Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 2, Long Packet Type (2) = 2,
Reserved Bits (2), Reserved Bits (2),
Packet Number Length (2), Packet Number Length (2),
Version (32), Version (32),
DCID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
SCID Length (8), Source Connection ID Length (8),
Source Connection ID (0..160), Source Connection ID (0..160),
Length (i), Length (i),
Packet Number (8..32), Packet Number (8..32),
Packet Payload (..), Packet Payload (..),
} }
Figure 16: Handshake Protected Packet Figure 16: Handshake Protected Packet
Once a client has received a Handshake packet from a server, it uses Once a client has received a Handshake packet from a server, it uses
Handshake packets to send subsequent cryptographic handshake messages Handshake packets to send subsequent cryptographic handshake messages
skipping to change at page 107, line 16 skipping to change at page 111, line 16
connection ID that is chosen by the recipient of the packet; the connection ID that is chosen by the recipient of the packet; the
Source Connection ID includes the connection ID that the sender of Source Connection ID includes the connection ID that the sender of
the packet wishes to use; see Section 7.2. the packet wishes to use; see Section 7.2.
Handshake packets are their own packet number space, and thus the Handshake packets are their own packet number space, and thus the
first Handshake packet sent by a server contains a packet number of first Handshake packet sent by a server contains a packet number of
0. 0.
The payload of this packet contains CRYPTO frames and could contain The payload of this packet contains CRYPTO frames and could contain
PING, PADDING, or ACK frames. Handshake packets MAY contain PING, PADDING, or ACK frames. Handshake packets MAY contain
CONNECTION_CLOSE frames. Endpoints MUST treat receipt of Handshake CONNECTION_CLOSE frames of type 0x1c. Endpoints MUST treat receipt
packets with other frames as a connection error. of Handshake packets with other frames as a connection error.
Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames
for Handshake packets is discarded - and no longer retransmitted - for Handshake packets is discarded - and no longer retransmitted -
when Handshake protection keys are discarded. when Handshake protection keys are discarded.
17.2.5. Retry Packet 17.2.5. Retry Packet
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 retry; see Section 8.1. used by a server that wishes to perform a retry; see Section 8.1.
Retry Packet { Retry Packet {
Header Form (1) = 1, Header Form (1) = 1,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Long Packet Type (2) = 3, Long Packet Type (2) = 3,
Unused (4), Unused (4),
Version (32), Version (32),
DCID Length (8), Destination Connection ID Length (8),
Destination Connection ID (0..160), Destination Connection ID (0..160),
SCID Length (8), Source Connection ID Length (8),
Source Connection ID (0..160), Source Connection ID (0..160),
Retry Token (..), Retry Token (..),
Retry Integrity Tag (128), Retry Integrity Tag (128),
} }
Figure 17: Retry Packet Figure 17: Retry Packet
A Retry packet (shown in Figure 17) does not contain any protected A Retry packet (shown in Figure 17) does not contain any protected
fields. The value in the Unused field is selected randomly by the fields. The value in the Unused field is selected randomly by the
server. In addition to the fields from the long header, it contains server. In addition to the fields from the long header, it contains
skipping to change at page 108, line 15 skipping to change at page 112, line 15
Retry Integrity Tag: See the Retry Packet Integrity section of Retry Integrity Tag: See the Retry Packet Integrity section of
[QUIC-TLS]. [QUIC-TLS].
17.2.5.1. Sending a Retry Packet 17.2.5.1. Sending a Retry Packet
The server populates the Destination Connection ID with the The server populates the Destination Connection ID with the
connection ID that the client included in the Source Connection ID of connection ID that the client included in the Source Connection ID of
the Initial packet. the Initial packet.
The server includes a connection ID of its choice in the Source The server includes a connection ID of its choice in the Source
Connection ID field. This value MUST not be equal to the Destination Connection ID field. This value MUST NOT be equal to the Destination
Connection ID field of the packet sent by the client. A client MUST Connection ID field of the packet sent by the client. A client MUST
discard a Retry packet that contains a Source Connection ID field discard a Retry packet that contains a Source Connection ID field
that is identical to the Destination Connection ID field of its that is identical to the Destination Connection ID field of its
Initial packet. The client MUST use the value from the Source Initial packet. The client MUST use the value from the Source
Connection ID field of the Retry packet in the Destination Connection Connection ID field of the Retry packet in the Destination Connection
ID field of subsequent packets that it sends. ID field of subsequent packets that it sends.
A server MAY send Retry packets in response to Initial and 0-RTT A server MAY send Retry packets in response to Initial and 0-RTT
packets. A server can either discard or buffer 0-RTT packets that it packets. A server can either discard or buffer 0-RTT packets that it
receives. A server can send multiple Retry packets as it receives receives. A server can send multiple Retry packets as it receives
skipping to change at page 114, line 18 skipping to change at page 118, line 18
max_udp_payload_size (0x03): The maximum UDP payload size parameter max_udp_payload_size (0x03): The maximum UDP payload size parameter
is an integer value that limits the size of UDP payloads that the is an integer value that limits the size of UDP payloads that the
endpoint is willing to receive. UDP packets with payloads larger endpoint is willing to receive. UDP packets with payloads larger
than this limit are not likely to be processed by the receiver. than this limit are not likely to be processed by the receiver.
The default for this parameter is the maximum permitted UDP The default for this parameter is the maximum permitted UDP
payload of 65527. Values below 1200 are invalid. payload of 65527. Values below 1200 are invalid.
This limit does act as an additional constraint on datagram size This limit does act as an additional constraint on datagram size
in the same way as the path MTU, but it is a property of the in the same way as the path MTU, but it is a property of the
endpoint and not the path. It is expected that this is the space endpoint and not the path; see Section 14. It is expected that
an endpoint dedicates to holding incoming packets. this is the space an endpoint dedicates to holding incoming
packets.
initial_max_data (0x04): The initial maximum data parameter is an initial_max_data (0x04): The initial maximum data parameter is an
integer value that contains the initial value for the maximum integer value that contains the initial value for the maximum
amount of data that can be sent on the connection. This is amount of data that can be sent on the connection. This is
equivalent to sending a MAX_DATA (Section 19.9) for the connection equivalent to sending a MAX_DATA (Section 19.9) for the connection
immediately after completing the handshake. immediately after completing the handshake.
initial_max_stream_data_bidi_local (0x05): This parameter is an initial_max_stream_data_bidi_local (0x05): This parameter is an
integer value specifying the initial flow control limit for integer value specifying the initial flow control limit for
locally-initiated bidirectional streams. This limit applies to locally-initiated bidirectional streams. This limit applies to
skipping to change at page 115, line 47 skipping to change at page 119, line 41
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.
disable_active_migration (0x0c): The disable active migration disable_active_migration (0x0c): The disable active migration
transport parameter is included if the endpoint does not support transport parameter is included if the endpoint does not support
active connection migration (Section 9). Peers of an endpoint active connection migration (Section 9) on the address being used
that sets this transport parameter MUST NOT send any packets, during the handshake. When a peer sets this transport parameter,
including probing packets (Section 9.1), from a local address or an endpoint MUST NOT use a new local address when sending to the
port other than that used to perform the handshake. This address that the peer used during the handshake. This transport
parameter does not prohibit connection migration after a client
has acted on a preferred_address transport parameter. This
parameter is a zero-length value. parameter is a zero-length value.
preferred_address (0x0d): The server's preferred address is used to preferred_address (0x0d): The server's preferred address is used to
effect a change in server address at the end of the handshake, as effect a change in server address at the end of the handshake, as
described in Section 9.6. The format of this transport parameter described in Section 9.6. The format of this transport parameter
is shown in Figure 21. This transport parameter is only sent by a is shown in Figure 21. This transport parameter is only sent by a
server. Servers MAY choose to only send a preferred address of server. Servers MAY choose to only send a preferred address of
one address family by sending an all-zero address and port one address family by sending an all-zero address and port
(0.0.0.0:0 or ::.0) for the other family. IP addresses are (0.0.0.0:0 or ::.0) for the other family. IP addresses are
encoded in network byte order. encoded in network byte order.
skipping to change at page 117, line 23 skipping to change at page 121, line 21
connection with an error of type TRANSPORT_PARAMETER_ERROR. If connection with an error of type TRANSPORT_PARAMETER_ERROR. If
this transport parameter is absent, a default of 2 is assumed. If this transport parameter is absent, a default of 2 is assumed. If
an endpoint issues a zero-length connection ID, it will never send an endpoint issues a zero-length connection ID, it will never send
a NEW_CONNECTION_ID frame and therefore ignores the a NEW_CONNECTION_ID frame and therefore ignores the
active_connection_id_limit value received from its peer. active_connection_id_limit value received from its peer.
initial_source_connection_id (0x0f): The value that the endpoint initial_source_connection_id (0x0f): The value that the endpoint
included in the Source Connection ID field of the first Initial included in the Source Connection ID field of the first Initial
packet it sends for the connection; see Section 7.3. packet it sends for the connection; see Section 7.3.
retry_source_connection_id (0x10): The value that the the server retry_source_connection_id (0x10): The value that the server
included in the Source Connection ID field of a Retry packet; see included in the Source Connection ID field of a Retry packet; see
Section 7.3. This transport parameter is only sent by a server. Section 7.3. This transport parameter is only sent by a server.
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.
skipping to change at page 118, line 5 skipping to change at page 122, line 5
This section describes the format and semantics of the core QUIC This section describes the format and semantics of the core QUIC
frame types. frame types.
19.1. PADDING Frame 19.1. PADDING Frame
The PADDING frame (type=0x00) has no semantic value. PADDING frames The PADDING frame (type=0x00) has no semantic value. PADDING frames
can be used to increase the size of a packet. Padding can be used to can be used to increase the size of a packet. Padding can be used to
increase an initial client packet to the minimum required size, or to increase an initial client packet to the minimum required size, or to
provide protection against traffic analysis for protected packets. provide protection against traffic analysis for protected packets.
A PADDING frame has no content. That is, a PADDING frame consists of As shown in Figure 22, a PADDING frame has no content. That is, a
the single byte that identifies the frame as a PADDING frame. PADDING frame consists of the single byte that identifies the frame
as a PADDING frame.
PADDING Frame {
Type (i) = 0x00,
}
Figure 22: PADDING Frame Format
19.2. PING Frame 19.2. PING Frame
Endpoints can use PING frames (type=0x01) to verify that their peers Endpoints can use PING frames (type=0x01) to verify that their peers
are still alive or to check reachability to the peer. The PING frame are still alive or to check reachability to the peer. As shown in
contains no additional fields. Figure 23 a PING frame contains no content.
PING Frame {
Type (i) = 0x01,
}
Figure 23: PING Frame Format
The receiver of a PING frame simply needs to acknowledge the packet The receiver of a PING frame simply needs to acknowledge the packet
containing this frame. containing this frame.
The PING frame can be used to keep a connection alive when an The PING frame can be used to keep a connection alive when an
application or application protocol wishes to prevent the connection application or application protocol wishes to prevent the connection
from timing out. An application protocol SHOULD provide guidance from timing out; see Section 10.2.2.
about the conditions under which generating a PING is recommended.
This guidance SHOULD indicate whether it is the client or the server
that is expected to send the PING. Having both endpoints send PING
frames without coordination can produce an excessive number of
packets and poor performance.
A connection will time out if no packets are sent or received for a
period longer than the time negotiated using the max_idle_timeout
transport parameter; see Section 10. However, state in middleboxes
might time out earlier than that. Though REQ-5 in [RFC4787]
recommends a 2 minute timeout interval, experience shows that sending
packets every 15 to 30 seconds is necessary to prevent the majority
of middleboxes from losing state for UDP flows.
19.3. ACK Frames 19.3. ACK Frames
Receivers send ACK frames (types 0x02 and 0x03) to inform senders of Receivers send ACK frames (types 0x02 and 0x03) to inform senders of
packets they have received and processed. The ACK frame contains one packets they have received and processed. The ACK frame contains one
or more ACK Ranges. ACK Ranges identify acknowledged packets. If or more ACK Ranges. ACK Ranges identify acknowledged packets. If
the frame type is 0x03, ACK frames also contain the sum of QUIC the frame type is 0x03, ACK frames also contain the sum of QUIC
packets with associated ECN marks received on the connection up until packets with associated ECN marks received on the connection up until
this point. QUIC implementations MUST properly handle both types this point. QUIC implementations MUST properly handle both types
and, if they have enabled ECN for packets they send, they SHOULD use and, if they have enabled ECN for packets they send, they SHOULD use
skipping to change at page 119, line 16 skipping to change at page 123, line 16
the same numeric value. An acknowledgment for a packet needs to the same numeric value. An acknowledgment for a packet needs to
indicate both a packet number and a packet number space. This is indicate both a packet number and a packet number space. This is
accomplished by having each ACK frame only acknowledge packet numbers accomplished by having each ACK frame only acknowledge packet numbers
in the same space as the packet in which the ACK frame is contained. in the same space as the packet in which the ACK frame is contained.
Version Negotiation and Retry packets cannot be acknowledged because Version Negotiation and Retry packets cannot be acknowledged because
they do not contain a packet number. Rather than relying on ACK they do not contain a packet number. Rather than relying on ACK
frames, these packets are implicitly acknowledged by the next Initial frames, these packets are implicitly acknowledged by the next Initial
packet sent by the client. packet sent by the client.
An ACK frame is shown in Figure 22. An ACK frame is shown in Figure 24.
ACK Frame { ACK Frame {
Type (i) = 0x02..0x03, Type (i) = 0x02..0x03,
Largest Acknowledged (i), Largest Acknowledged (i),
ACK Delay (i), ACK Delay (i),
ACK Range Count (i), ACK Range Count (i),
First ACK Range (i), First ACK Range (i),
ACK Range (..) ..., ACK Range (..) ...,
[ECN Counts (..)], [ECN Counts (..)],
} }
Figure 22: ACK Frame Format Figure 24: ACK Frame Format
ACK frames contain the following fields: ACK frames contain the following fields:
Largest Acknowledged: A variable-length integer representing the Largest Acknowledged: A variable-length integer representing the
largest packet number the peer is acknowledging; this is usually largest packet number the peer is acknowledging; this is usually
the largest packet number that the peer has received prior to the largest packet number that the peer has received prior to
generating the ACK frame. Unlike the packet number in the QUIC generating the ACK frame. Unlike the packet number in the QUIC
long or short header, the value in an ACK frame is not truncated. long or short header, the value in an ACK frame is not truncated.
ACK Delay: A variable-length integer representing the time delta in ACK Delay: A variable-length integer representing the time delta in
skipping to change at page 120, line 27 skipping to change at page 124, line 27
ECN Counts: The three ECN Counts; see Section 19.3.2. ECN Counts: The three ECN Counts; see Section 19.3.2.
19.3.1. ACK Ranges 19.3.1. ACK Ranges
Each ACK Range consists of alternating Gap and ACK Range values in Each ACK Range consists of alternating Gap and ACK Range values in
descending packet number order. ACK Ranges can be repeated. The descending packet number order. ACK Ranges can be repeated. The
number of Gap and ACK Range values is determined by the ACK Range number of Gap and ACK Range values is determined by the ACK Range
Count field; one of each value is present for each value in the ACK Count field; one of each value is present for each value in the ACK
Range Count field. Range Count field.
ACK Ranges are structured as shown in Figure 23. ACK Ranges are structured as shown in Figure 25.
ACK Range { ACK Range {
Gap (i), Gap (i),
ACK Range Length (i), ACK Range Length (i),
} }
Figure 23: ACK Ranges Figure 25: ACK Ranges
The fields that form each ACK Range are: The fields that form each ACK Range are:
Gap: A variable-length integer indicating the number of contiguous Gap: A variable-length integer indicating the number of contiguous
unacknowledged packets preceding the packet number one lower than unacknowledged packets preceding the packet number one lower than
the smallest in the preceding ACK Range. the smallest in the preceding ACK Range.
ACK Range Length: A variable-length integer indicating the number of ACK Range Length: A variable-length integer indicating the number of
contiguous acknowledged packets preceding the largest packet contiguous acknowledged packets preceding the largest packet
number, as determined by the preceding Gap. number, as determined by the preceding Gap.
skipping to change at page 121, line 42 skipping to change at page 125, line 42
a connection error of type FRAME_ENCODING_ERROR. a connection error of type FRAME_ENCODING_ERROR.
19.3.2. ECN Counts 19.3.2. ECN Counts
The ACK frame uses the least significant bit (that is, type 0x03) to The ACK frame uses the least significant bit (that is, type 0x03) to
indicate ECN feedback and report receipt of QUIC packets with indicate ECN feedback and report receipt of QUIC packets with
associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP associated ECN codepoints of ECT(0), ECT(1), or CE in the packet's IP
header. ECN Counts are only present when the ACK frame type is 0x03. header. ECN Counts are only present when the ACK frame type is 0x03.
ECN Counts are only parsed when the ACK frame type is 0x03. There ECN Counts are only parsed when the ACK frame type is 0x03. There
are 3 ECN counts, as shown in Figure 24. are 3 ECN counts, as shown in Figure 26.
ECN Counts { ECN Counts {
ECT0 Count (i), ECT0 Count (i),
ECT1 Count (i), ECT1 Count (i),
ECN-CE Count (i), ECN-CE Count (i),
} }
Figure 24: ECN Count Format Figure 26: ECN Count Format
The three ECN Counts are: The three ECN Counts are:
ECT0 Count: A variable-length integer representing the total number ECT0 Count: A variable-length integer representing the total number
of packets received with the ECT(0) codepoint in the packet number of packets received with the ECT(0) codepoint in the packet number
space of the ACK frame. space of the ACK frame.
ECT1 Count: A variable-length integer representing the total number ECT1 Count: A variable-length integer representing the total number
of packets received with the ECT(1) codepoint in the packet number of packets received with the ECT(1) codepoint in the packet number
space of the ACK frame. space of the ACK frame.
skipping to change at page 122, line 32 skipping to change at page 126, line 32
terminate the sending part of a stream. terminate the sending part of a stream.
After sending a RESET_STREAM, an endpoint ceases transmission and After sending a RESET_STREAM, an endpoint ceases transmission and
retransmission of STREAM frames on the identified stream. A receiver retransmission of STREAM frames on the identified stream. A receiver
of RESET_STREAM can discard any data that it already received on that of RESET_STREAM can discard any data that it already received on that
stream. stream.
An endpoint that receives a RESET_STREAM frame for a send-only stream An endpoint that receives a RESET_STREAM frame for a send-only stream
MUST terminate the connection with error STREAM_STATE_ERROR. MUST terminate the connection with error STREAM_STATE_ERROR.
The RESET_STREAM frame is shown in Figure 25. The RESET_STREAM frame is shown in Figure 27.
RESET_STREAM Frame { RESET_STREAM Frame {
Type (i) = 0x04, Type (i) = 0x04,
Stream ID (i), Stream ID (i),
Application Protocol Error Code (i), Application Protocol Error Code (i),
Final Size (i), Final Size (i),
} }
Figure 25: RESET_STREAM Frame Format Figure 27: RESET_STREAM Frame Format
RESET_STREAM frames contain the following fields: RESET_STREAM frames contain the following fields:
Stream ID: A variable-length integer encoding of the Stream ID of Stream ID: A variable-length integer encoding of the Stream ID of
the stream being terminated. the stream being terminated.
Application Protocol Error Code: A variable-length integer Application Protocol Error Code: A variable-length integer
containing the application protocol error code (see Section 20.1) containing the application protocol error code (see Section 20.1)
which indicates why the stream is being closed. which indicates why the stream is being closed.
skipping to change at page 123, line 21 skipping to change at page 127, line 19
incoming data is being discarded on receipt at application request. incoming data is being discarded on receipt at application request.
STOP_SENDING requests that a peer cease transmission on a stream. STOP_SENDING requests that a peer cease transmission on a stream.
A STOP_SENDING frame can be sent for streams in the Recv or Size A STOP_SENDING frame can be sent for streams in the Recv or Size
Known states; see Section 3.1. Receiving a STOP_SENDING frame for a Known states; see Section 3.1. Receiving a STOP_SENDING frame for a
locally-initiated stream that has not yet been created MUST be locally-initiated stream that has not yet been created MUST be
treated as a connection error of type STREAM_STATE_ERROR. An treated as a connection error of type STREAM_STATE_ERROR. An
endpoint that receives a STOP_SENDING frame for a receive-only stream endpoint that receives a STOP_SENDING frame for a receive-only stream
MUST terminate the connection with error STREAM_STATE_ERROR. MUST terminate the connection with error STREAM_STATE_ERROR.
The STOP_SENDING frame is shown in Figure 26. The STOP_SENDING frame is shown in Figure 28.
STOP_SENDING Frame { STOP_SENDING Frame {
Type (i) = 0x05, Type (i) = 0x05,
Stream ID (i), Stream ID (i),
Application Protocol Error Code (i), Application Protocol Error Code (i),
} }
Figure 26: STOP_SENDING Frame Format Figure 28: STOP_SENDING Frame Format
STOP_SENDING frames contain the following fields: STOP_SENDING frames contain the following fields:
Stream ID: A variable-length integer carrying the Stream ID of the Stream ID: A variable-length integer carrying the Stream ID of the
stream being ignored. stream being ignored.
Application Protocol Error Code: A variable-length integer Application Protocol Error Code: A variable-length integer
containing the application-specified reason the sender is ignoring containing the application-specified reason the sender is ignoring
the stream; see Section 20.1. the stream; see Section 20.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 except 0-RTT. handshake messages. It can be sent in all packet types except 0-RTT.
The CRYPTO frame offers the cryptographic protocol an in-order stream The CRYPTO frame offers the cryptographic protocol an in-order stream
of bytes. CRYPTO frames are functionally identical to STREAM frames, of bytes. CRYPTO frames are functionally identical to STREAM frames,
except that they do not bear a stream identifier; they are not flow except that they do not bear a stream identifier; they are not flow
controlled; and they do not carry markers for optional offset, controlled; and they do not carry markers for optional offset,
optional length, and the end of the stream. optional length, and the end of the stream.
The CRYPTO frame is shown in Figure 27. The CRYPTO frame is shown in Figure 29.
CRYPTO Frame { CRYPTO Frame {
Type (i) = 0x06, Type (i) = 0x06,
Offset (i), Offset (i),
Length (i), Length (i),
Crypto Data (..), Crypto Data (..),
} }
Figure 27: CRYPTO Frame Format Figure 29: CRYPTO Frame Format
CRYPTO frames contain the following fields: CRYPTO frames contain the following fields:
Offset: A variable-length integer specifying the byte offset in the Offset: A variable-length integer specifying the byte offset in the
stream for the data in this CRYPTO frame. stream for the data in this CRYPTO frame.
Length: A variable-length integer specifying the length of the Length: A variable-length integer specifying the length of the
Crypto Data field in this CRYPTO frame. Crypto Data field in this CRYPTO frame.
Crypto Data: The cryptographic message data. Crypto Data: The cryptographic message data.
skipping to change at page 124, line 45 skipping to change at page 128, line 45
stream the data belongs, the CRYPTO frame carries data for a single stream the data belongs, the CRYPTO frame carries data for a single
stream per encryption level. The stream does not have an explicit stream per encryption level. The stream does not have an explicit
end, so CRYPTO frames do not have a FIN bit. end, so CRYPTO frames do not have a FIN bit.
19.7. NEW_TOKEN Frame 19.7. NEW_TOKEN Frame
A server sends a NEW_TOKEN frame (type=0x07) to provide the client A server sends a NEW_TOKEN frame (type=0x07) to provide the client
with a token to send in the header of an Initial packet for a future with a token to send in the header of an Initial packet for a future
connection. connection.
The NEW_TOKEN frame is shown in Figure 28. The NEW_TOKEN frame is shown in Figure 30.
NEW_TOKEN Frame { NEW_TOKEN Frame {
Type (i) = 0x07, Type (i) = 0x07,
Token Length (i), Token Length (i),
Token (..), Token (..),
} }
Figure 28: NEW_TOKEN Frame Format Figure 30: NEW_TOKEN Frame Format
NEW_TOKEN frames contain the following fields: NEW_TOKEN frames contain the following fields:
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
token in bytes. token in bytes.
Token: An opaque blob that the client may use with a future Initial Token: An opaque blob that the client may use with a future Initial
packet. The token MUST NOT be empty. An endpoint MUST treat packet. The token MUST NOT be empty. An endpoint MUST treat
receipt of a NEW_TOKEN frame with an empty Token field as a receipt of a NEW_TOKEN frame with an empty Token field as a
connection error of type FRAME_ENCODING_ERROR. connection error of type FRAME_ENCODING_ERROR.
skipping to change at page 126, line 10 skipping to change at page 130, line 10
* The FIN bit (0x01) of the frame type is set only on frames that * The FIN bit (0x01) of the frame type is set only on frames that
contain the final size of the stream. Setting this bit indicates contain the final size of the stream. Setting this bit indicates
that the frame marks the end of the stream. that the frame marks the end of the stream.
An endpoint MUST terminate the connection with error An endpoint MUST terminate the connection with error
STREAM_STATE_ERROR if it receives a STREAM frame for a locally- STREAM_STATE_ERROR if it receives a STREAM frame for a locally-
initiated stream that has not yet been created, or for a send-only initiated stream that has not yet been created, or for a send-only
stream. stream.
The STREAM frames are shown in Figure 29. The STREAM frames are shown in Figure 31.
STREAM Frame { STREAM Frame {
Type (i) = 0x08..0x0f, Type (i) = 0x08..0x0f,
Stream ID (i), Stream ID (i),
[Offset (i)], [Offset (i)],
[Length (i)], [Length (i)],
Stream Data (..), Stream Data (..),
} }
Figure 29: STREAM Frame Format Figure 31: STREAM Frame Format
STREAM frames contain the following fields: STREAM frames contain the following fields:
Stream ID: A variable-length integer indicating the stream ID of the Stream ID: A variable-length integer indicating the stream ID of the
stream; see Section 2.1. stream; see Section 2.1.
Offset: A variable-length integer specifying the byte offset in the Offset: A variable-length integer specifying the byte offset in the
stream for the data in this STREAM frame. This field is present stream for the data in this STREAM frame. This field is present
when the OFF bit is set to 1. When the Offset field is absent, when the OFF bit is set to 1. When the Offset field is absent,
the offset is 0. the offset is 0.
skipping to change at page 127, line 11 skipping to change at page 131, line 11
credit for that data. Receipt of a frame that exceeds this limit credit for that data. Receipt of a frame that exceeds this limit
MUST be treated as a connection error of type FRAME_ENCODING_ERROR or MUST be treated as a connection error of type FRAME_ENCODING_ERROR or
FLOW_CONTROL_ERROR. FLOW_CONTROL_ERROR.
19.9. MAX_DATA Frame 19.9. MAX_DATA Frame
The MAX_DATA frame (type=0x10) is used in flow control to inform the The MAX_DATA frame (type=0x10) is used in flow control to inform the
peer of the maximum amount of data that can be sent on the connection peer of the maximum amount of data that can be sent on the connection
as a whole. as a whole.
The MAX_DATA frame is shown in Figure 30. The MAX_DATA frame is shown in Figure 32.
MAX_DATA Frame { MAX_DATA Frame {
Type (i) = 0x10, Type (i) = 0x10,
Maximum Data (i), Maximum Data (i),
} }
Figure 30: MAX_DATA Frame Format Figure 32: MAX_DATA Frame Format
MAX_DATA frames contain the following fields: MAX_DATA frames contain the following fields:
Maximum Data: A variable-length integer indicating the maximum Maximum Data: A variable-length integer indicating the maximum
amount of data that can be sent on the entire connection, in units amount of data that can be sent on the entire connection, in units
of bytes. of bytes.
All data sent in STREAM frames counts toward this limit. The sum of All data sent in STREAM frames counts toward this limit. The sum of
the largest received offsets on all streams - including streams in the largest received offsets on all streams - including streams in
terminal states - MUST NOT exceed the value advertised by a receiver. terminal states - MUST NOT exceed the value advertised by a receiver.
skipping to change at page 127, line 47 skipping to change at page 131, line 47
inform a peer of the maximum amount of data that can be sent on a inform a peer of the maximum amount of data that can be sent on a
stream. stream.
A MAX_STREAM_DATA frame can be sent for streams in the Recv state; A MAX_STREAM_DATA frame can be sent for streams in the Recv state;
see Section 3.1. Receiving a MAX_STREAM_DATA frame for a locally- see Section 3.1. Receiving a MAX_STREAM_DATA frame for a locally-
initiated stream that has not yet been created MUST be treated as a initiated stream that has not yet been created MUST be treated as a
connection error of type STREAM_STATE_ERROR. An endpoint that connection error of type STREAM_STATE_ERROR. An endpoint that
receives a MAX_STREAM_DATA frame for a receive-only stream MUST receives a MAX_STREAM_DATA frame for a receive-only stream MUST
terminate the connection with error STREAM_STATE_ERROR. terminate the connection with error STREAM_STATE_ERROR.
The MAX_STREAM_DATA frame is shown in Figure 31. The MAX_STREAM_DATA frame is shown in Figure 33.
MAX_STREAM_DATA Frame { MAX_STREAM_DATA Frame {
Type (i) = 0x11, Type (i) = 0x11,
Stream ID (i), Stream ID (i),
Maximum Stream Data (i), Maximum Stream Data (i),
} }
Figure 31: MAX_STREAM_DATA Frame Format Figure 33: MAX_STREAM_DATA Frame Format
MAX_STREAM_DATA frames contain the following fields: MAX_STREAM_DATA frames contain the following fields:
Stream ID: The stream ID of the stream that is affected encoded as a Stream ID: The stream ID of the stream that is affected encoded as a
variable-length integer. variable-length integer.
Maximum Stream Data: A variable-length integer indicating the Maximum Stream Data: A variable-length integer indicating the
maximum amount of data that can be sent on the identified stream, maximum amount of data that can be sent on the identified stream,
in units of bytes. in units of bytes.
skipping to change at page 128, line 44 skipping to change at page 132, line 44
limits; see Section 7.4.1. limits; see Section 7.4.1.
19.11. MAX_STREAMS Frames 19.11. MAX_STREAMS Frames
The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the The MAX_STREAMS frames (type=0x12 and 0x13) inform the peer of the
cumulative number of streams of a given type it is permitted to open. cumulative number of streams of a given type it is permitted to open.
A MAX_STREAMS frame with a type of 0x12 applies to bidirectional A MAX_STREAMS frame with a type of 0x12 applies to bidirectional
streams, and a MAX_STREAMS frame with a type of 0x13 applies to streams, and a MAX_STREAMS frame with a type of 0x13 applies to
unidirectional streams. unidirectional streams.
The MAX_STREAMS frames are shown in Figure 32; The MAX_STREAMS frames are shown in Figure 34;
MAX_STREAMS Frame { MAX_STREAMS Frame {
Type (i) = 0x12..0x13, Type (i) = 0x12..0x13,
Maximum Streams (i), Maximum Streams (i),
} }
Figure 32: MAX_STREAMS Frame Format Figure 34: MAX_STREAMS Frame Format
MAX_STREAMS frames contain the following fields: MAX_STREAMS frames contain the following fields:
Maximum Streams: A count of the cumulative number of streams of the Maximum Streams: A count of the cumulative number of streams of the
corresponding type that can be opened over the lifetime of the corresponding type that can be opened over the lifetime of the
connection. This value cannot exceed 2^60, as it is not possible connection. This value cannot exceed 2^60, as it is not possible
to encode stream IDs larger than 2^62-1. Receipt of a frame that to encode stream IDs larger than 2^62-1. Receipt of a frame that
permits opening of a stream larger than this limit MUST be treated permits opening of a stream larger than this limit MUST be treated
as a FRAME_ENCODING_ERROR. as a FRAME_ENCODING_ERROR.
skipping to change at page 129, line 38 skipping to change at page 133, line 38
concurrently. The limit includes streams that have been closed as concurrently. The limit includes streams that have been closed as
well as those that are open. well as those that are open.
19.12. DATA_BLOCKED Frame 19.12. DATA_BLOCKED Frame
A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes
to send data, but is unable to due to connection-level flow control; to send data, but is unable to due to connection-level flow control;
see Section 4. DATA_BLOCKED frames can be used as input to tuning of see Section 4. DATA_BLOCKED frames can be used as input to tuning of
flow control algorithms; see Section 4.2. flow control algorithms; see Section 4.2.
The DATA_BLOCKED frame is shown in Figure 33. The DATA_BLOCKED frame is shown in Figure 35.
DATA_BLOCKED Frame { DATA_BLOCKED Frame {
Type (i) = 0x14, Type (i) = 0x14,
Maximum Data (i), Maximum Data (i),
} }
Figure 33: DATA_BLOCKED Frame Format Figure 35: DATA_BLOCKED Frame Format
DATA_BLOCKED frames contain the following fields: DATA_BLOCKED frames contain the following fields:
Maximum Data: A variable-length integer indicating the connection- Maximum Data: A variable-length integer indicating the connection-
level limit at which blocking occurred. level limit at which blocking occurred.
19.13. STREAM_DATA_BLOCKED Frame 19.13. STREAM_DATA_BLOCKED Frame
A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
wishes to send data, but is unable to due to stream-level flow wishes to send data, but is unable to due to stream-level flow
control. This frame is analogous to DATA_BLOCKED (Section 19.12). control. This frame is analogous to DATA_BLOCKED (Section 19.12).
An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only An endpoint that receives a STREAM_DATA_BLOCKED frame for a send-only
stream MUST terminate the connection with error STREAM_STATE_ERROR. stream MUST terminate the connection with error STREAM_STATE_ERROR.
The STREAM_DATA_BLOCKED frame is shown in Figure 34. The STREAM_DATA_BLOCKED frame is shown in Figure 36.
STREAM_DATA_BLOCKED Frame { STREAM_DATA_BLOCKED Frame {
Type (i) = 0x15, Type (i) = 0x15,
Stream ID (i), Stream ID (i),
Maximum Stream Data (i), Maximum Stream Data (i),
} }
Figure 34: STREAM_DATA_BLOCKED Frame Format Figure 36: STREAM_DATA_BLOCKED Frame Format
STREAM_DATA_BLOCKED frames contain the following fields: STREAM_DATA_BLOCKED frames contain the following fields:
Stream ID: A variable-length integer indicating the stream which is Stream ID: A variable-length integer indicating the stream which is
flow control blocked. flow control blocked.
Maximum Stream Data: A variable-length integer indicating the offset Maximum Stream Data: A variable-length integer indicating the offset
of the stream at which the blocking occurred. of the stream at which the blocking occurred.
19.14. STREAMS_BLOCKED Frames 19.14. STREAMS_BLOCKED Frames
skipping to change at page 130, line 45 skipping to change at page 134, line 45
it wishes to open a stream, but is unable to due to the maximum it wishes to open a stream, but is unable to due to the maximum
stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED
frame of type 0x16 is used to indicate reaching the bidirectional frame of type 0x16 is used to indicate reaching the bidirectional
stream limit, and a STREAMS_BLOCKED frame of type 0x17 indicates stream limit, and a STREAMS_BLOCKED frame of type 0x17 indicates
reaching the unidirectional stream limit. reaching the unidirectional stream limit.
A STREAMS_BLOCKED frame does not open the stream, but informs the A STREAMS_BLOCKED frame does not open the stream, but informs the
peer that a new stream was needed and the stream limit prevented the peer that a new stream was needed and the stream limit prevented the
creation of the stream. creation of the stream.
The STREAMS_BLOCKED frames are shown in Figure 35. The STREAMS_BLOCKED frames are shown in Figure 37.
STREAMS_BLOCKED Frame { STREAMS_BLOCKED Frame {
Type (i) = 0x16..0x17, Type (i) = 0x16..0x17,
Maximum Streams (i), Maximum Streams (i),
} }
Figure 35: STREAMS_BLOCKED Frame Format Figure 37: STREAMS_BLOCKED Frame Format
STREAMS_BLOCKED frames contain the following fields: STREAMS_BLOCKED frames contain the following fields:
Maximum Streams: A variable-length integer indicating the maximum Maximum Streams: A variable-length integer indicating the maximum
number of streams allowed at the time the frame was sent. This number of streams allowed at the time the frame was sent. This
value cannot exceed 2^60, as it is not possible to encode stream value cannot exceed 2^60, as it is not possible to encode stream
IDs larger than 2^62-1. Receipt of a frame that encodes a larger IDs larger than 2^62-1. Receipt of a frame that encodes a larger
stream ID MUST be treated as a STREAM_LIMIT_ERROR or a stream ID MUST be treated as a STREAM_LIMIT_ERROR or a
FRAME_ENCODING_ERROR. FRAME_ENCODING_ERROR.
19.15. NEW_CONNECTION_ID Frame 19.15. NEW_CONNECTION_ID Frame
An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide An endpoint sends a NEW_CONNECTION_ID frame (type=0x18) to provide
its peer with alternative connection IDs that can be used to break its peer with alternative connection IDs that can be used to break
linkability when migrating connections; see Section 9.5. linkability when migrating connections; see Section 9.5.
The NEW_CONNECTION_ID frame is shown in Figure 36. The NEW_CONNECTION_ID frame is shown in Figure 38.
NEW_CONNECTION_ID Frame { NEW_CONNECTION_ID Frame {
Type (i) = 0x18, Type (i) = 0x18,
Sequence Number (i), Sequence Number (i),
Retire Prior To (i), Retire Prior To (i),
Length (8), Length (8),
Connection ID (8..160), Connection ID (8..160),
Stateless Reset Token (128), Stateless Reset Token (128),
} }
Figure 36: NEW_CONNECTION_ID Frame Format Figure 38: NEW_CONNECTION_ID Frame Format
NEW_CONNECTION_ID frames contain the following fields: NEW_CONNECTION_ID frames contain the following fields:
Sequence Number: The sequence number assigned to the connection ID Sequence Number: The sequence number assigned to the connection ID
by the sender. See Section 5.1.1. by the sender. See Section 5.1.1.
Retire Prior To: A variable-length integer indicating which Retire Prior To: A variable-length integer indicating which
connection IDs should be retired; see Section 5.1.2. connection IDs should be retired; see Section 5.1.2.
Length: An 8-bit unsigned integer containing the length of the Length: An 8-bit unsigned integer containing the length of the
skipping to change at page 133, line 8 skipping to change at page 137, line 8
indicate that it will no longer use a connection ID that was issued indicate that it will no longer use a connection ID that was issued
by its peer. This may include the connection ID provided during the by its peer. This may include the connection ID provided during the
handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a
request to the peer to send additional connection IDs for future use; request to the peer to send additional connection IDs for future use;
see Section 5.1. New connection IDs can be delivered to a peer using see Section 5.1. New connection IDs can be delivered to a peer using
the NEW_CONNECTION_ID frame (Section 19.15). the NEW_CONNECTION_ID frame (Section 19.15).
Retiring a connection ID invalidates the stateless reset token Retiring a connection ID invalidates the stateless reset token
associated with that connection ID. associated with that connection ID.
The RETIRE_CONNECTION_ID frame is shown in Figure 37. The RETIRE_CONNECTION_ID frame is shown in Figure 39.
RETIRE_CONNECTION_ID Frame { RETIRE_CONNECTION_ID Frame {
Type (i) = 0x19, Type (i) = 0x19,
Sequence Number (i), Sequence Number (i),
} }
Figure 37: RETIRE_CONNECTION_ID Frame Format Figure 39: RETIRE_CONNECTION_ID Frame Format
RETIRE_CONNECTION_ID frames contain the following fields: RETIRE_CONNECTION_ID frames contain the following fields:
Sequence Number: The sequence number of the connection ID being Sequence Number: The sequence number of the connection ID being
retired; see Section 5.1.2. retired; see Section 5.1.2.
Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number
greater than any previously sent to the peer MUST be treated as a greater than any previously sent to the peer MUST be treated as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
skipping to change at page 133, line 42 skipping to change at page 137, line 42
length connection ID by its peer. An endpoint that provides a zero- length connection ID by its peer. An endpoint that provides a zero-
length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID
frame as a connection error of type PROTOCOL_VIOLATION. frame as a connection error of type PROTOCOL_VIOLATION.
19.17. PATH_CHALLENGE Frame 19.17. PATH_CHALLENGE Frame
Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check
reachability to the peer and for path validation during connection reachability to the peer and for path validation during connection
migration. migration.
The PATH_CHALLENGE frame is shown in Figure 38. The PATH_CHALLENGE frame is shown in Figure 40.
PATH_CHALLENGE Frame { PATH_CHALLENGE Frame {
Type (i) = 0x1a, Type (i) = 0x1a,
Data (64), Data (64),
} }
Figure 38: PATH_CHALLENGE Frame Format Figure 40: PATH_CHALLENGE Frame Format
PATH_CHALLENGE frames contain the following fields: PATH_CHALLENGE frames contain the following fields:
Data: This 8-byte field contains arbitrary data. Data: This 8-byte field contains arbitrary data.
A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is A PATH_CHALLENGE frame containing 8 bytes that are hard to guess is
sufficient to ensure that it is easier to receive the packet than it sufficient to ensure that it is easier to receive the packet than it
is to guess the value correctly. is to guess the value correctly.
The recipient of this frame MUST generate a PATH_RESPONSE frame The recipient of this frame MUST generate a PATH_RESPONSE frame
(Section 19.18) containing the same Data. (Section 19.18) containing the same Data.
19.18. PATH_RESPONSE Frame 19.18. PATH_RESPONSE Frame
The PATH_RESPONSE frame (type=0x1b) is sent in response to a The PATH_RESPONSE frame (type=0x1b) is sent in response to a
PATH_CHALLENGE frame. Its format, shown in Figure 39 is identical to PATH_CHALLENGE frame. Its format, shown in Figure 41 is identical to
the PATH_CHALLENGE frame (Section 19.17). the PATH_CHALLENGE frame (Section 19.17).
PATH_RESPONSE Frame { PATH_RESPONSE Frame {
Type (i) = 0x1b, Type (i) = 0x1b,
Data (64), Data (64),
} }
Figure 39: PATH_RESPONSE Frame Format Figure 41: PATH_RESPONSE Frame Format
If the content of a PATH_RESPONSE frame does not match the content of If the content of a PATH_RESPONSE frame does not match the content of
a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint
MAY generate a connection error of type PROTOCOL_VIOLATION. MAY generate a connection error of type PROTOCOL_VIOLATION.
19.19. CONNECTION_CLOSE Frames 19.19. CONNECTION_CLOSE Frames
An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to An endpoint sends a CONNECTION_CLOSE frame (type=0x1c or 0x1d) to
notify its peer that the connection is being closed. The notify its peer that the connection is being closed. The
CONNECTION_CLOSE with a frame type of 0x1c is used to signal errors CONNECTION_CLOSE with a frame type of 0x1c is used to signal errors
at only the QUIC layer, or the absence of errors (with the NO_ERROR at only the QUIC layer, or the absence of errors (with the NO_ERROR
code). The CONNECTION_CLOSE frame with a type of 0x1d is used to code). The CONNECTION_CLOSE frame with a type of 0x1d is used to
signal an error with the application that uses QUIC. signal an error with the application that uses QUIC.
If there are open streams that haven't been explicitly closed, they If there are open streams that 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 shown in Figure 40. The CONNECTION_CLOSE frames are shown in Figure 42.
CONNECTION_CLOSE Frame { CONNECTION_CLOSE Frame {
Type (i) = 0x1c..0x1d, Type (i) = 0x1c..0x1d,
Error Code (i), Error Code (i),
[Frame Type (i)], [Frame Type (i)],
Reason Phrase Length (i), Reason Phrase Length (i),
Reason Phrase (..), Reason Phrase (..),
} }
Figure 40: CONNECTION_CLOSE Frame Format Figure 42: CONNECTION_CLOSE Frame Format
CONNECTION_CLOSE frames contain the following fields: CONNECTION_CLOSE frames contain the following fields:
Error Code: A variable length integer error code which indicates the Error Code: A variable length integer error code which indicates the
reason for closing this connection. A CONNECTION_CLOSE frame of reason for closing this connection. A CONNECTION_CLOSE frame of
type 0x1c uses codes from the space defined in Section 20. A type 0x1c uses codes from the space defined in Section 20. 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
will also limit the space available for a reason phrase. will also limit the space available for a reason phrase.
Reason Phrase: A human-readable explanation for why the connection Reason Phrase: A human-readable explanation for why the connection
was closed. This can be zero length if the sender chooses to not was closed. This can be zero length if the sender chooses to not
give details beyond the Error Code. This SHOULD be a UTF-8 give details beyond the Error Code. This SHOULD be a UTF-8
encoded string [RFC3629]. encoded string [RFC3629].
The application-specific variant of CONNECTION_CLOSE (type 0x1d) can The application-specific variant of CONNECTION_CLOSE (type 0x1d) can
only be sent using 0-RTT or 1-RTT packets ([QUIC-TLS], Section 4). only be sent using 0-RTT or 1-RTT packets; see Section 4 of
When an application wishes to abandon a connection during the [QUIC-TLS]. When an application wishes to abandon a connection
handshake, an endpoint can send a CONNECTION_CLOSE frame (type 0x1c) during the handshake, an endpoint can send a CONNECTION_CLOSE frame
with an error code of APPLICATION_ERROR in an Initial or a Handshake (type 0x1c) with an error code of APPLICATION_ERROR in an Initial or
packet. a Handshake packet.
19.20. HANDSHAKE_DONE frame 19.20. HANDSHAKE_DONE frame
The server uses the HANDSHAKE_DONE frame (type=0x1e) to signal The server uses the HANDSHAKE_DONE frame (type=0x1e) to signal
confirmation of the handshake to the client. The HANDSHAKE_DONE confirmation of the handshake to the client. As shown in Figure 43,
frame contains no additional fields. a HANDSHAKE_DONE frame has no content.
This frame can only be sent by the server. Servers MUST NOT send a HANDSHAKE_DONE Frame {
HANDSHAKE_DONE frame before completing the handshake. A server MUST Type (i) = 0x1e,
treat receipt of a HANDSHAKE_DONE frame as a connection error of type }
PROTOCOL_VIOLATION.
Figure 43: HANDSHAKE_DONE Frame Format
A HANDSHAKE_DONE frame can only be sent by the server. Servers MUST
NOT send a HANDSHAKE_DONE frame before completing the handshake. A
server MUST treat receipt of a HANDSHAKE_DONE frame as a connection
error of type PROTOCOL_VIOLATION.
19.21. Extension Frames 19.21. Extension Frames
QUIC frames do not use a self-describing encoding. An endpoint QUIC frames do not use a self-describing encoding. An endpoint
therefore needs to understand the syntax of all frames before it can therefore needs to understand the syntax of all frames before it can
successfully process a packet. This allows for efficient encoding of successfully process a packet. This allows for efficient encoding of
frames, but it means that an endpoint cannot send a frame of a type frames, but it means that an endpoint cannot send a frame of a type
that is unknown to its peer. that is unknown to its peer.
An extension to QUIC that wishes to use a new type of frame MUST An extension to QUIC that wishes to use a new type of frame MUST
skipping to change at page 136, line 49 skipping to change at page 141, line 5
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
cannot continue with the connection. cannot continue with the connection.
SERVER_BUSY (0x2): The server is currently busy and does not accept CONNECTION_REFUSED (0x2): The server refused to accept a new
any new connections. connection.
FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it FLOW_CONTROL_ERROR (0x3): An endpoint received more data than it
permitted in its advertised data limits; see Section 4. permitted in its advertised data limits; see Section 4.
STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream STREAM_LIMIT_ERROR (0x4): An endpoint received a frame for a stream
identifier that exceeded its advertised stream limit for the identifier that exceeded its advertised stream limit for the
corresponding stream type. corresponding stream type.
STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream STREAM_STATE_ERROR (0x5): An endpoint received a frame for a stream
that was not in a state that permitted that frame; see Section 3. that was not in a state that permitted that frame; see Section 3.
skipping to change at page 138, line 42 skipping to change at page 142, line 42
21.1. Handshake Denial of Service 21.1. Handshake Denial of Service
As an encrypted and authenticated transport QUIC provides a range of As an encrypted and authenticated transport QUIC provides a range of
protections against denial of service. Once the cryptographic protections against denial of service. Once the cryptographic
handshake is complete, QUIC endpoints discard most packets that are handshake is complete, QUIC endpoints discard most packets that are
not authenticated, greatly limiting the ability of an attacker to not authenticated, greatly limiting the ability of an attacker to
interfere with existing connections. interfere with existing connections.
Once a connection is established QUIC endpoints might accept some Once a connection is established QUIC endpoints might accept some
unauthenticated ICMP packets (see Section 14.2), but the use of these unauthenticated ICMP packets (see Section 14.2.1), but the use of
packets is extremely limited. The only other type of packet that an these packets is extremely limited. The only other type of packet
endpoint might accept is a stateless reset (Section 10.4) which that an endpoint might accept is a stateless reset (Section 10.4)
relies on the token being kept secret until it is used. which relies on the token being kept secret until it is used.
During the creation of a connection, QUIC only provides protection During the creation of a connection, QUIC only provides protection
against attack from off the network path. All QUIC packets contain against attack from off the network path. All QUIC packets contain
proof that the recipient saw a preceding packet from its peer. proof that the recipient saw a preceding packet from its peer.
Addresses cannot change during the handshake, so endpoints can Addresses cannot change during the handshake, so endpoints can
discard packets that are received on a different network path. discard packets that are received on a different network path.
The Source and Destination Connection ID fields are the primary means The Source and Destination Connection ID fields are the primary means
of protection against off-path attack during the handshake. These of protection against off-path attack during the handshake. These
skipping to change at page 141, line 36 skipping to change at page 145, line 36
The number of active streams is limited by the The number of active streams is limited by the
initial_max_streams_bidi and initial_max_streams_uni transport initial_max_streams_bidi and initial_max_streams_uni transport
parameters, as explained in Section 4.5. If chosen judiciously, parameters, as explained in Section 4.5. If chosen judiciously,
these limits mitigate the effect of the stream commitment attack. these limits mitigate the effect of the stream commitment attack.
However, setting the limit too low could affect performance when However, setting the limit too low could affect performance when
applications expect to open large number of streams. applications expect to open large number of streams.
21.7. Peer Denial of Service 21.7. Peer Denial of Service
QUIC and TLS both contain messages that have legitimate uses in some QUIC and TLS both contain frames or messages that have legitimate
contexts, but that can be abused to cause a peer to expend processing uses in some contexts, but that can be abused to cause a peer to
resources without having any observable impact on the state of the expend processing resources without having any observable impact on
connection. the state of the connection.
Messages can also be used to change and revert state in small or Messages can also be used to change and revert state in small or
inconsequential ways, such as by sending small increments to flow inconsequential ways, such as by sending small increments to flow
control limits. control limits.
If processing costs are disproportionately large in comparison to If processing costs are disproportionately large in comparison to
bandwidth consumption or effect on state, then this could allow a bandwidth consumption or effect on state, then this could allow a
malicious peer to exhaust processing capacity. malicious peer to exhaust processing capacity.
While there are legitimate uses for all messages, implementations While there are legitimate uses for all messages, implementations
skipping to change at page 156, line 13 skipping to change at page 160, line 13
The initial contents of this registry are shown in Table 7. The initial contents of this registry are shown in Table 7.
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
|Value | Error | Description | Specification | |Value | Error | Description | Specification |
+======+===========================+================+===============+ +======+===========================+================+===============+
| 0x0 | NO_ERROR | No error | Section 20 | | 0x0 | NO_ERROR | No error | Section 20 |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x1 | INTERNAL_ERROR | Implementation | Section 20 | | 0x1 | INTERNAL_ERROR | Implementation | Section 20 |
| | | error | | | | | error | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x2 | SERVER_BUSY |Server currently| Section 20 | | 0x2 | CONNECTION_REFUSED_ERROR |Server refuses a| Section 20 |
| | | busy | | | | | connection | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | | 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 |
| | | error | | | | | error | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x4 | STREAM_LIMIT_ERROR |Too many streams| Section 20 | | 0x4 | STREAM_LIMIT_ERROR |Too many streams| Section 20 |
| | | opened | | | | | opened | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | | 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 |
| | | in invalid | | | | | in invalid | |
| | | stream state | | | | | stream state | |
skipping to change at page 157, line 24 skipping to change at page 161, line 24
<http://www.ietf.org/internet-drafts/draft-ietf-tsvwg- <http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-
datagram-plpmtud-21.txt>. datagram-plpmtud-21.txt>.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", Work in Progress, Internet-Draft, and Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-28, 20 May 2020, draft-ietf-quic-recovery-29, 10 June 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-28>. <https://tools.ietf.org/html/draft-ietf-quic-recovery-29>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", Work in Progress, Layer Security (TLS) to Secure QUIC", Work in Progress,
Internet-Draft, draft-ietf-quic-tls-28, 20 May 2020, Internet-Draft, draft-ietf-quic-tls-29, 10 June 2020,
<https://tools.ietf.org/html/draft-ietf-quic-tls-28>. <https://tools.ietf.org/html/draft-ietf-quic-tls-29>.
[RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", [RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery",
RFC 1191, DOI 10.17487/RFC1191, November 1990, RFC 1191, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 159, line 17 skipping to change at page 163, line 17
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",
Work in Progress, Internet-Draft, draft-ietf-quic- Work in Progress, Internet-Draft, draft-ietf-quic-
invariants-08, 20 May 2020, <https://tools.ietf.org/html/ invariants-09, 10 June 2020, <https://tools.ietf.org/html/
draft-ietf-quic-invariants-08>. draft-ietf-quic-invariants-09>.
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-06, 6 January 2020, draft-ietf-quic-manageability-06, 6 January 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
manageability-06.txt>. manageability-06.txt>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
skipping to change at page 159, line 41 skipping to change at page 163, line 41
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
RFC 4303, DOI 10.17487/RFC4303, December 2005, Sooriyabandara, "TCP Performance Implications of Network
<https://www.rfc-editor.org/info/rfc4303>. Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
December 2002, <https://www.rfc-editor.org/info/rfc3449>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
skipping to change at page 160, line 45 skipping to change at page 164, line 45
RSnake Hansen, R., "Welcome to Slowloris...", June 2009, RSnake Hansen, R., "Welcome to Slowloris...", June 2009,
<https://web.archive.org/web/20150315054838/ <https://web.archive.org/web/20150315054838/
http://ha.ckers.org/slowloris/>. http://ha.ckers.org/slowloris/>.
[STD] Bradner, S., "The Internet Standards Process -- Revision [STD] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>. <https://www.rfc-editor.org/info/rfc2026>.
Appendix A. Sample Packet Number Decoding Algorithm Appendix A. Sample Packet Number Decoding Algorithm
The pseudo-code in Figure 41 shows how an implementation can decode The pseudo-code in Figure 44 shows how an implementation can decode
packet numbers after header protection has been removed. packet numbers after header protection has been removed.
DecodePacketNumber(largest_pn, truncated_pn, pn_nbits): DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
expected_pn = largest_pn + 1 expected_pn = largest_pn + 1
pn_win = 1 << pn_nbits pn_win = 1 << pn_nbits
pn_hwin = pn_win / 2 pn_hwin = pn_win / 2
pn_mask = pn_win - 1 pn_mask = pn_win - 1
// The incoming packet number should be greater than // The incoming packet number should be greater than
// expected_pn - pn_hwin and less than or equal to // expected_pn - pn_hwin and less than or equal to
// expected_pn + pn_hwin // expected_pn + pn_hwin
skipping to change at page 161, line 30 skipping to change at page 165, line 30
// Note the extra checks to prevent overflow and underflow. // Note the extra checks to prevent overflow and underflow.
candidate_pn = (expected_pn & ~pn_mask) | truncated_pn candidate_pn = (expected_pn & ~pn_mask) | truncated_pn
if candidate_pn <= expected_pn - pn_hwin and if candidate_pn <= expected_pn - pn_hwin and
candidate_pn < (1 << 62) - pn_win: candidate_pn < (1 << 62) - pn_win:
return candidate_pn + pn_win return candidate_pn + pn_win
if candidate_pn > expected_pn + pn_hwin and if candidate_pn > expected_pn + pn_hwin and
candidate_pn >= pn_win: candidate_pn >= pn_win:
return candidate_pn - pn_win return candidate_pn - pn_win
return candidate_pn return candidate_pn
Figure 41: Sample Packet Number Decoding Algorithm Figure 44: Sample Packet Number Decoding Algorithm
Appendix B. Sample ECN Validation Algorithm Appendix B. Sample ECN Validation Algorithm
Each time an endpoint commences sending on a new network path, it Each time an endpoint commences sending on a new network path, it
determines whether the path supports ECN; see Section 13.4. If the determines whether the path supports ECN; see Section 13.4. If the
path supports ECN, the goal is to use ECN. Endpoints might also path supports ECN, the goal is to use ECN. Endpoints might also
periodically reassess a path that was determined to not support ECN. periodically reassess a path that was determined to not support ECN.
This section describes one method for testing new paths. This This section describes one method for testing new paths. This
algorithm is intended to show how a path might be tested for ECN algorithm is intended to show how a path might be tested for ECN
skipping to change at page 162, line 36 skipping to change at page 166, line 36
marked packets are discarded by the path, the short duration of the marked packets are discarded by the path, the short duration of the
testing period limits the number of losses incurred. testing period limits the number of losses incurred.
Appendix C. Change Log Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-transport-27 C.1. Since draft-ietf-quic-transport-28
* Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED
(#3709, #3690, #3694)
* Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs
(#3703, #3691)
* Integrate QUIC-specific language from draft-ietf-tsvwg-datagram-
plpmtud (#3695, #3702)
* disable_active_migration does not apply to the addresses offered
in server_preferred_address (#3608, #3670)
C.2. Since draft-ietf-quic-transport-27
* Allowed CONNECTION_CLOSE in any packet number space, with a * Allowed CONNECTION_CLOSE in any packet number space, with a
requirement to use a new transport-level error for application- requirement to use a new transport-level error for application-
specific errors in Initial and Handshake packets (#3430, #3435, specific errors in Initial and Handshake packets (#3430, #3435,
#3440) #3440)
* Clearer requirements for address validation (#2125, #3327) * Clearer requirements for address validation (#2125, #3327)
* Security analysis of handshake and migration (#2143, #2387, #2925) * Security analysis of handshake and migration (#2143, #2387, #2925)
* The entire payload of a datagram is used when counting bytes for * The entire payload of a datagram is used when counting bytes for
skipping to change at page 163, line 33 skipping to change at page 167, line 47
* Restored text on dropping bogus Version Negotiation packets * Restored text on dropping bogus Version Negotiation packets
(#3532, #3533) (#3532, #3533)
* Clarified that largest acknowledged needs to be saved, but not * Clarified that largest acknowledged needs to be saved, but not
necessarily signaled in all cases (#3541, #3581) necessarily signaled in all cases (#3541, #3581)
* Addressed linkability risk with the use of preferred_address * Addressed linkability risk with the use of preferred_address
(#3559, #3563) (#3559, #3563)
C.2. Since draft-ietf-quic-transport-26 * Added authentication of handshake connection IDs (#3439, #3499)
* Opening a stream in the wrong direction is an error (#3527)
C.3. Since draft-ietf-quic-transport-26
* Change format of transport parameters to use varints (#3294, * Change format of transport parameters to use varints (#3294,
#3169) #3169)
C.3. Since draft-ietf-quic-transport-25 C.4. Since draft-ietf-quic-transport-25
* Define the use of CONNECTION_CLOSE prior to establishing * Define the use of CONNECTION_CLOSE prior to establishing
connection state (#3269, #3297, #3292) connection state (#3269, #3297, #3292)
* Allow use of address validation tokens after client address * Allow use of address validation tokens after client address
changes (#3307, #3308) changes (#3307, #3308)
* Define the timer for address validation (#2910, #3339) * Define the timer for address validation (#2910, #3339)
C.4. Since draft-ietf-quic-transport-24 C.5. Since draft-ietf-quic-transport-24
* Added HANDSHAKE_DONE to signal handshake confirmation (#2863, * Added HANDSHAKE_DONE to signal handshake confirmation (#2863,
#3142, #3145) #3142, #3145)
* Add integrity check to Retry packets (#3014, #3274, #3120) * Add integrity check to Retry packets (#3014, #3274, #3120)
* Specify handling of reordered NEW_CONNECTION_ID frames (#3194, * Specify handling of reordered NEW_CONNECTION_ID frames (#3194,
#3202) #3202)
* Require checking of sequence numbers in RETIRE_CONNECTION_ID * Require checking of sequence numbers in RETIRE_CONNECTION_ID
skipping to change at page 165, line 5 skipping to change at page 169, line 25
* Idle timeout is symmetric (#2602, #3099) * Idle timeout is symmetric (#2602, #3099)
* Prohibit IP fragmentation (#3243, #3280) * Prohibit IP fragmentation (#3243, #3280)
* Define the use of provisional registration for all registries * Define the use of provisional registration for all registries
(#3109, #3020, #3102, #3170) (#3109, #3020, #3102, #3170)
* Packets on one path must not adjust values for a different path * Packets on one path must not adjust values for a different path
(#2909, #3139) (#2909, #3139)
C.5. Since draft-ietf-quic-transport-23 C.6. Since draft-ietf-quic-transport-23
* Allow ClientHello to span multiple packets (#2928, #3045) * Allow ClientHello to span multiple packets (#2928, #3045)
* Client Initial size constraints apply to UDP datagram payload * Client Initial size constraints apply to UDP datagram payload
(#3053, #3051) (#3053, #3051)
* Stateless reset changes (#2152, #2993) * Stateless reset changes (#2152, #2993)
- tokens need to be compared in constant time - tokens need to be compared in constant time
skipping to change at page 165, line 33 skipping to change at page 170, line 4
* A new connection ID is necessary when responding to migration * A new connection ID is necessary when responding to migration
(#2778, #2969) (#2778, #2969)
* Stronger requirements for connection ID retirement (#3046, #3096) * Stronger requirements for connection ID retirement (#3046, #3096)
* NEW_TOKEN cannot be empty (#2978, #2977) * NEW_TOKEN cannot be empty (#2978, #2977)
* PING can be sent at any encryption level (#3034, #3035) * PING can be sent at any encryption level (#3034, #3035)
* CONNECTION_CLOSE is not ack-eliciting (#3097, #3098) * CONNECTION_CLOSE is not ack-eliciting (#3097, #3098)
* Frame encoding error conditions updated (#3027, #3042) * Frame encoding error conditions updated (#3027, #3042)
* Non-ack-eliciting packets cannot be sent in response to non-ack- * Non-ack-eliciting packets cannot be sent in response to non-ack-
eliciting packets (#3100, #3104) eliciting packets (#3100, #3104)
* Servers have to change connection IDs in Retry (#2837, #3147) * Servers have to change connection IDs in Retry (#2837, #3147)
C.6. Since draft-ietf-quic-transport-22 C.7. Since draft-ietf-quic-transport-22
* Rules for preventing correlation by connection ID tightened * Rules for preventing correlation by connection ID tightened
(#2084, #2929) (#2084, #2929)
* Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, * Clarified use of CONNECTION_CLOSE in Handshake packets (#2151,
#2541, #2688) #2541, #2688)
* Discourage regressions of largest acknowledged in ACK (#2205, * Discourage regressions of largest acknowledged in ACK (#2205,
#2752) #2752)
skipping to change at page 166, line 48 skipping to change at page 171, line 19
#2840, #2841) #2840, #2841)
* Explanation of the effect of Retry on 0-RTT packets (#2842, #2852) * Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)
* Cryptographic handshake needs to provide server transport * Cryptographic handshake needs to provide server transport
parameter encryption (#2920, #2921) parameter encryption (#2920, #2921)
* Moved ACK generation guidance from recovery draft to transport * Moved ACK generation guidance from recovery draft to transport
draft (#1860, #2916). draft (#1860, #2916).
C.7. Since draft-ietf-quic-transport-21 C.8. Since draft-ietf-quic-transport-21
* Connection ID lengths are now one octet, but limited in version 1 * Connection ID lengths are now one octet, but limited in version 1
to 20 octets of length (#2736, #2749) to 20 octets of length (#2736, #2749)
C.8. Since draft-ietf-quic-transport-20 C.9. Since draft-ietf-quic-transport-20
* Error codes are encoded as variable-length integers (#2672, #2680) * Error codes are encoded as variable-length integers (#2672, #2680)
* NEW_CONNECTION_ID includes a request to retire old connection IDs * NEW_CONNECTION_ID includes a request to retire old connection IDs
(#2645, #2769) (#2645, #2769)
* Tighter rules for generating and explicitly eliciting ACK frames * Tighter rules for generating and explicitly eliciting ACK frames
(#2546, #2794) (#2546, #2794)
* Recommend having only one packet per encryption level in a * Recommend having only one packet per encryption level in a
skipping to change at page 167, line 49 skipping to change at page 172, line 20
* PATH_RESPONSE no longer needs to be received on the validated path * PATH_RESPONSE no longer needs to be received on the validated path
(#2582, #2580, #2579, #2637) (#2582, #2580, #2579, #2637)
* PATH_RESPONSE frames are not stored and retransmitted (#2724, * PATH_RESPONSE frames are not stored and retransmitted (#2724,
#2729) #2729)
* Document hack for enabling routing of ICMP when doing PMTU probing * Document hack for enabling routing of ICMP when doing PMTU probing
(#1243, #2402) (#1243, #2402)
C.9. Since draft-ietf-quic-transport-19 C.10. Since draft-ietf-quic-transport-19
* Refine discussion of 0-RTT transport parameters (#2467, #2464) * Refine discussion of 0-RTT transport parameters (#2467, #2464)
* Fewer transport parameters need to be remembered for 0-RTT (#2624, * Fewer transport parameters need to be remembered for 0-RTT (#2624,
#2467) #2467)
* Spin bit text incorporated (#2564) * Spin bit text incorporated (#2564)
* Close the connection when maximum stream ID in MAX_STREAMS exceeds * Close the connection when maximum stream ID in MAX_STREAMS exceeds
2^62 - 1 (#2499, #2487) 2^62 - 1 (#2499, #2487)
* New connection ID required for intentional migration (#2414, * New connection ID required for intentional migration (#2414,
#2413) #2413)
skipping to change at page 168, line 27 skipping to change at page 172, line 47
* The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) * The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
* Initial packets from clients need to be padded to 1200 unless a * Initial packets from clients need to be padded to 1200 unless a
Handshake packet is sent as well (#2522, #2523) Handshake packet is sent as well (#2522, #2523)
* CRYPTO frames can be discarded if too much data is buffered * CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524) (#1834, #2524)
* Stateless reset uses a short header packet (#2599, #2600) * Stateless reset uses a short header packet (#2599, #2600)
C.10. Since draft-ietf-quic-transport-18 C.11. Since draft-ietf-quic-transport-18
* Removed version negotiation; version negotiation, including * Removed version negotiation; version negotiation, including
authentication of the result, will be addressed in the next authentication of the result, will be addressed in the next
version of QUIC (#1773, #2313) version of QUIC (#1773, #2313)
* Added discussion of the use of IPv6 flow labels (#2348, #2399) * Added discussion of the use of IPv6 flow labels (#2348, #2399)
* A connection ID can't be retired in a packet that uses that * A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420) connection ID (#2101, #2420)
* Idle timeout transport parameter is in milliseconds (from seconds) * Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454) (#2453, #2454)
* Endpoints are required to use new connection IDs when they use new * Endpoints are required to use new connection IDs when they use new
network paths (#2413, #2414) network paths (#2413, #2414)
* Increased the set of permissible frames in 0-RTT (#2344, #2355) * Increased the set of permissible frames in 0-RTT (#2344, #2355)
C.11. Since draft-ietf-quic-transport-17 C.12. Since draft-ietf-quic-transport-17
* Stream-related errors now use STREAM_STATE_ERROR (#2305) * Stream-related errors now use STREAM_STATE_ERROR (#2305)
* Endpoints discard initial keys as soon as handshake keys are * Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
* Expanded conditions for ignoring ICMP packet too big messages * Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161) (#2108, #2161)
* Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, * Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
skipping to change at page 169, line 37 skipping to change at page 174, line 10
#2301) #2301)
* Allow server preferred address for both IPv4 and IPv6 (#2122, * Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296) #2296)
* Corrected requirements for migration to a preferred address * Corrected requirements for migration to a preferred address
(#2146, #2349) (#2146, #2349)
* ACK of non-existent packet is illegal (#2298, #2302) * ACK of non-existent packet is illegal (#2298, #2302)
C.12. Since draft-ietf-quic-transport-16 C.13. Since draft-ietf-quic-transport-16
* Stream limits are defined as counts, not maximums (#1850, #1906) * Stream limits are defined as counts, not maximums (#1850, #1906)
* Require amplification attack defense after closing (#1905, #1911) * Require amplification attack defense after closing (#1905, #1911)
* Remove reservation of application error code 0 for STOPPING * Remove reservation of application error code 0 for STOPPING
(#1804, #1922) (#1804, #1922)
* Renumbered frames (#1945) * Renumbered frames (#1945)
skipping to change at page 170, line 32 skipping to change at page 175, line 4
* Allow STOP_SENDING to open a remote bidirectional stream (#1797, * Allow STOP_SENDING to open a remote bidirectional stream (#1797,
#2013) #2013)
* Added mitigation for off-path migration attacks (#1278, #1749, * Added mitigation for off-path migration attacks (#1278, #1749,
#2033) #2033)
* Don't let the PMTU to drop below 1280 (#2063, #2069) * Don't let the PMTU to drop below 1280 (#2063, #2069)
* Require peers to replace retired connection IDs (#2085) * Require peers to replace retired connection IDs (#2085)
* Servers are required to ignore Version Negotiation packets (#2088) * Servers are required to ignore Version Negotiation packets (#2088)
* Tokens are repeated in all Initial packets (#2089) * Tokens are repeated in all Initial packets (#2089)
* Clarified how PING frames are sent after loss (#2094) * Clarified how PING frames are sent after loss (#2094)
* Initial keys are discarded once Handshake are available (#1951, * Initial keys are discarded once Handshake are available (#1951,
#2045) #2045)
* ICMP PTB validation clarifications (#2161, #2109, #2108) * ICMP PTB validation clarifications (#2161, #2109, #2108)
C.13. Since draft-ietf-quic-transport-15 C.14. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
C.14. Since draft-ietf-quic-transport-14 C.15. Since draft-ietf-quic-transport-14
* Merge ACK and ACK_ECN (#1778, #1801) * Merge ACK and ACK_ECN (#1778, #1801)
* Explicitly communicate max_ack_delay (#981, #1781) * Explicitly communicate max_ack_delay (#981, #1781)
* Validate original connection ID after Retry packets (#1710, #1486, * Validate original connection ID after Retry packets (#1710, #1486,
#1793) #1793)
* Idle timeout is optional and has no specified maximum (#1765) * Idle timeout is optional and has no specified maximum (#1765)
* Update connection ID handling; add RETIRE_CONNECTION_ID type * Update connection ID handling; add RETIRE_CONNECTION_ID type
(#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799,
#1821) #1821)
* Include a Token in all Initial packets (#1649, #1794) * Include a Token in all Initial packets (#1649, #1794)
* Prevent handshake deadlock (#1764, #1824) * Prevent handshake deadlock (#1764, #1824)
C.15. Since draft-ietf-quic-transport-13 C.16. Since draft-ietf-quic-transport-13
* Streams open when higher-numbered streams of the same type open * Streams open when higher-numbered streams of the same type open
(#1342, #1549) (#1342, #1549)
* Split initial stream flow control limit into 3 transport * Split initial stream flow control limit into 3 transport
parameters (#1016, #1542) parameters (#1016, #1542)
* All flow control transport parameters are optional (#1610) * All flow control transport parameters are optional (#1610)
* Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) * Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
skipping to change at page 172, line 7 skipping to change at page 176, line 28
* Permit 0-RTT after receiving Version Negotiation or Retry (#1507, * Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621) #1514, #1621)
* Permit Retry in response to 0-RTT (#1547, #1552) * Permit Retry in response to 0-RTT (#1547, #1552)
* Looser verification of ECN counters to account for ACK loss * Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565) (#1555, #1481, #1565)
* Remove frame type field from APPLICATION_CLOSE (#1508, #1528) * Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
C.16. Since draft-ietf-quic-transport-12 C.17. Since draft-ietf-quic-transport-12
* Changes to integration of the TLS handshake (#829, #1018, #1094, * Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450, #1458) #1165, #1190, #1233, #1242, #1252, #1450, #1458)
- The cryptographic handshake uses CRYPTO frames, not stream 0 - The cryptographic handshake uses CRYPTO frames, not stream 0
- QUIC packet protection is used in place of TLS record - QUIC packet protection is used in place of TLS record
protection protection
- Separate QUIC packet number spaces are used for the handshake - Separate QUIC packet number spaces are used for the handshake
skipping to change at page 172, line 50 skipping to change at page 177, line 23
* Fixed sampling method for packet number encryption; the length * Fixed sampling method for packet number encryption; the length
field in long headers includes the packet number field in addition field in long headers includes the packet number field in addition
to the packet payload (#1387, #1389) to the packet payload (#1387, #1389)
* Stateless Reset is now symmetric and subject to size constraints * Stateless Reset is now symmetric and subject to size constraints
(#466, #1346) (#466, #1346)
* Added frame type extension mechanism (#58, #1473) * Added frame type extension mechanism (#58, #1473)
C.17. Since draft-ietf-quic-transport-11 C.18. Since draft-ietf-quic-transport-11
* Enable server to transition connections to a preferred address * Enable server to transition connections to a preferred address
(#560, #1251) (#560, #1251)
* Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, * Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
#990, #734, #1317, #1267, #1079) #990, #734, #1317, #1267, #1079)
* Packet numbers use a variable-length encoding (#989, #1334) * Packet numbers use a variable-length encoding (#989, #1334)
* STREAM frames can now be empty (#1350) * STREAM frames can now be empty (#1350)
C.18. Since draft-ietf-quic-transport-10 C.19. Since draft-ietf-quic-transport-10
* Swap payload length and packed number fields in long header * Swap payload length and packed number fields in long header
(#1294) (#1294)
* Clarified that CONNECTION_CLOSE is allowed in Handshake packet * Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
* Spin bit reserved (#1283) * Spin bit reserved (#1283)
* Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) * Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
skipping to change at page 173, line 31 skipping to change at page 178, line 4
* Spin bit reserved (#1283) * Spin bit reserved (#1283)
* Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) * Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
* A more complete connection migration (#1249) * A more complete connection migration (#1249)
* Refine opportunistic ACK defense text (#305, #1030, #1185) * Refine opportunistic ACK defense text (#305, #1030, #1185)
* A Stateless Reset Token isn't mandatory (#818, #1191) * A Stateless Reset Token isn't mandatory (#818, #1191)
* Removed implicit stream opening (#896, #1193) * Removed implicit stream opening (#896, #1193)
* An empty STREAM frame can be used to open a stream without sending * An empty STREAM frame can be used to open a stream without sending
data (#901, #1194) data (#901, #1194)
* Define stream counts in transport parameters rather than a maximum * Define stream counts in transport parameters rather than a maximum
stream ID (#1023, #1065) stream ID (#1023, #1065)
* STOP_SENDING is now prohibited before streams are used (#1050) * STOP_SENDING is now prohibited before streams are used (#1050)
* Recommend including ACK in Retry packets and allow PADDING (#1067, * Recommend including ACK in Retry packets and allow PADDING (#1067,
#882) #882)
* Endpoints now become closing after an idle timeout (#1178, #1179) * Endpoints now become closing after an idle timeout (#1178, #1179)
* Remove implication that Version Negotiation is sent when a packet * Remove implication that Version Negotiation is sent when a packet
of the wrong version is received (#1197) of the wrong version is received (#1197)
C.19. Since draft-ietf-quic-transport-09 C.20. Since draft-ietf-quic-transport-09
* Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with * Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with
Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d.
(#1091, #725, #1086) (#1091, #725, #1086)
* A server can now only send 3 packets without validating the client * A server can now only send 3 packets without validating the client
address (#38, #1090) address (#38, #1090)
* Delivery order of stream data is no longer strongly specified * Delivery order of stream data is no longer strongly specified
(#252, #1070) (#252, #1070)
skipping to change at page 174, line 29 skipping to change at page 179, line 5
* Improved retransmission rules for all frame types: information is * Improved retransmission rules for all frame types: information is
retransmitted, not packets or frames (#463, #765, #1095, #1053) retransmitted, not packets or frames (#463, #765, #1095, #1053)
* Added an error code for server busy signals (#1137) * Added an error code for server busy signals (#1137)
* Endpoints now set the connection ID that their peer uses. * Endpoints now set the connection ID that their peer uses.
Connection IDs are variable length. Removed the Connection IDs are variable length. Removed the
omit_connection_id transport parameter and the corresponding short omit_connection_id transport parameter and the corresponding short
header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
C.20. Since draft-ietf-quic-transport-08 C.21. Since draft-ietf-quic-transport-08
* Clarified requirements for BLOCKED usage (#65, #924) * Clarified requirements for BLOCKED usage (#65, #924)
* BLOCKED frame now includes reason for blocking (#452, #924, #927, * BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
* GAP limitation in ACK Frame (#613) * GAP limitation in ACK Frame (#613)
* Improved PMTUD description (#614, #1036) * Improved PMTUD description (#614, #1036)
skipping to change at page 175, line 10 skipping to change at page 179, line 33
* Stateless reset clarified as version-specific (#930, #986) * Stateless reset clarified as version-specific (#930, #986)
* initial_max_stream_id_x transport parameters are optional (#970, * initial_max_stream_id_x transport parameters are optional (#970,
#971) #971)
* Ack Delay assumes a default value during the handshake (#1007, * Ack Delay assumes a default value during the handshake (#1007,
#1009) #1009)
* Removed transport parameters from NewSessionTicket (#1015) * Removed transport parameters from NewSessionTicket (#1015)
C.21. Since draft-ietf-quic-transport-07 C.22. Since draft-ietf-quic-transport-07
* The long header now has version before packet number (#926, #939) * The long header now has version before packet number (#926, #939)
* Rename and consolidate packet types (#846, #822, #847) * Rename and consolidate packet types (#846, #822, #847)
* Packet types are assigned new codepoints and the Connection ID * Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956) Flag is inverted (#426, #956)
* Removed type for Version Negotiation and use Version 0 (#963, * Removed type for Version Negotiation and use Version 0 (#963,
#968) #968)
skipping to change at page 176, line 5 skipping to change at page 180, line 28
* Address validation for connection migration (#161, #732, #878) * Address validation for connection migration (#161, #732, #878)
* Clearly defined retransmission rules for BLOCKED (#452, #65, #924) * Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
* negotiated_version is sent in server transport parameters (#710, * negotiated_version is sent in server transport parameters (#710,
#959) #959)
* Increased the range over which packet numbers are randomized * Increased the range over which packet numbers are randomized
(#864, #850, #964) (#864, #850, #964)
C.22. Since draft-ietf-quic-transport-06 C.23. Since draft-ietf-quic-transport-06
* Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) * Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
* Split error code space between application and transport (#485) * Split error code space between application and transport (#485)
* Stateless reset token moved to end (#820) * Stateless reset token moved to end (#820)
* 1-RTT-protected long header types removed (#848) * 1-RTT-protected long header types removed (#848)
* No acknowledgments during draining period (#852) * No acknowledgments during draining period (#852)
* Remove "application close" as a separate close type (#854) * Remove "application close" as a separate close type (#854)
* Remove timestamps from the ACK frame (#841) * Remove timestamps from the ACK frame (#841)
* Require transport parameters to only appear once (#792) * Require transport parameters to only appear once (#792)
C.23. Since draft-ietf-quic-transport-05 C.24. Since draft-ietf-quic-transport-05
* Stateless token is server-only (#726) * Stateless token is server-only (#726)
* Refactor section on connection termination (#733, #748, #328, * Refactor section on connection termination (#733, #748, #328,
#177) #177)
* Limit size of Version Negotiation packet (#585) * Limit size of Version Negotiation packet (#585)
* Clarify when and what to ack (#736) * Clarify when and what to ack (#736)
* Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED * Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
* Clarify Keep-alive requirements (#729) * Clarify Keep-alive requirements (#729)
C.24. Since draft-ietf-quic-transport-04 C.25. Since draft-ietf-quic-transport-04
* Introduce STOP_SENDING frame, RESET_STREAM only resets in one * Introduce STOP_SENDING frame, RESET_STREAM only resets in one
direction (#165) direction (#165)
* Removed GOAWAY; application protocols are responsible for graceful * Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696) shutdown (#696)
* Reduced the number of error codes (#96, #177, #184, #211) * Reduced the number of error codes (#96, #177, #184, #211)
* Version validation fields can't move or change (#121) * Version validation fields can't move or change (#121)
skipping to change at page 177, line 24 skipping to change at page 181, line 47
* Increased the maximum length of the Largest Acknowledged field in * Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
* truncate_connection_id is renamed to omit_connection_id (#659) * truncate_connection_id is renamed to omit_connection_id (#659)
* CONNECTION_CLOSE terminates the connection like TCP RST (#330, * CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
* Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) * Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
C.25. Since draft-ietf-quic-transport-03 C.26. Since draft-ietf-quic-transport-03
* Change STREAM and RESET_STREAM layout * Change STREAM and RESET_STREAM layout
* Add MAX_STREAM_ID settings * Add MAX_STREAM_ID settings
C.26. Since draft-ietf-quic-transport-02 C.27. Since draft-ietf-quic-transport-02
* The size of the initial packet payload has a fixed minimum (#267, * The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
* Define when Version Negotiation packets are ignored (#284, #294, * Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
* The 64-bit FNV-1a algorithm is used for integrity protection of * The 64-bit FNV-1a algorithm is used for integrity protection of
unprotected packets (#167, #480, #481, #517) unprotected packets (#167, #480, #481, #517)
skipping to change at page 178, line 27 skipping to change at page 182, line 51
linkability (#232, #491, #496) linkability (#232, #491, #496)
* Transport parameters for 0-RTT are retained from a previous * Transport parameters for 0-RTT are retained from a previous
connection (#405, #513, #512) connection (#405, #513, #512)
- A client in 0-RTT no longer required to reset excess streams - A client in 0-RTT no longer required to reset excess streams
(#425, #479) (#425, #479)
* Expanded security considerations (#440, #444, #445, #448) * Expanded security considerations (#440, #444, #445, #448)
C.27. Since draft-ietf-quic-transport-01 C.28. Since draft-ietf-quic-transport-01
* Defined short and long packet headers (#40, #148, #361) * Defined short and long packet headers (#40, #148, #361)
* Defined a versioning scheme and stable fields (#51, #361) * Defined a versioning scheme and stable fields (#51, #361)
* Define reserved version values for "greasing" negotiation (#112, * Define reserved version values for "greasing" negotiation (#112,
#278) #278)
* The initial packet number is randomized (#35, #283) * The initial packet number is randomized (#35, #283)
* Narrow the packet number encoding range requirement (#67, #286, * Narrow the packet number encoding range requirement (#67, #286,
skipping to change at page 180, line 25 skipping to change at page 184, line 49
* Remove error code and reason phrase from GOAWAY (#352, #355) * Remove error code and reason phrase from GOAWAY (#352, #355)
* GOAWAY includes a final stream number for both directions (#347) * GOAWAY includes a final stream number for both directions (#347)
* Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a * Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
* Defined priority as the responsibility of the application protocol * Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
C.28. Since draft-ietf-quic-transport-00 C.29. Since draft-ietf-quic-transport-00
* Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag * Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
* Defined versioning * Defined versioning
* Reworked description of packet and frame layout * Reworked description of packet and frame layout
* Error code space is divided into regions for each component * Error code space is divided into regions for each component
* Use big endian for all numeric values * Use big endian for all numeric values
C.29. Since draft-hamilton-quic-transport-protocol-01 C.30. Since draft-hamilton-quic-transport-protocol-01
* Adopted as base for draft-ietf-quic-tls * Adopted as base for draft-ietf-quic-tls
* Updated authors/editors list * Updated authors/editors list
* Added IANA Considerations section * Added IANA Considerations section
* Moved Contributors and Acknowledgments to appendices * Moved Contributors and Acknowledgments to appendices
Contributors Contributors
 End of changes. 226 change blocks. 
619 lines changed or deleted 787 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/