draft-ietf-quic-transport-27.txt   draft-ietf-quic-transport-28.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: 24 August 2020 Mozilla Expires: 21 November 2020 Mozilla
21 February 2020 20 May 2020
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-27 draft-ietf-quic-transport-28
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
mailing list (quic@ietf.org), which is archived at mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
<https://mailarchive.ietf.org/arch/search/?email_list=quic>. archived at https://mailarchive.ietf.org/arch/search/?email_list=quic
Working Group information can be found at <https://github.com/ Working Group information can be found at https://github.com/quicwg;
quicwg>; source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-transport>. https://github.com/quicwg/base-drafts/labels/-transport.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 24 August 2020. This Internet-Draft will expire on 21 November 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 20 skipping to change at page 2, line 20
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 10 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 11
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 11 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 12
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 12
2.4. Required Operations on Streams . . . . . . . . . . . . . 12 2.4. Required Operations on Streams . . . . . . . . . . . . . 13
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 13 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 14
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 15 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 17
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 18 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 19
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 18 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 20
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 19 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 21
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 21 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 21 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 23
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 22 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 24
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 23 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 25
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 24 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 26
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 24 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 26
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 25 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 27
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 26 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 29
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 27 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 30
5.2. Matching Packets to Connections . . . . . . . . . . . . . 28 5.2. Matching Packets to Connections . . . . . . . . . . . . . 31
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 29 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 32
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 29 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 32
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 30 5.2.3. Considerations for Simple Load Balancers . . . . . . 33
5.4. Required Operations on Connections . . . . . . . . . . . 31 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 33
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 32 5.4. Required Operations on Connections . . . . . . . . . . . 34
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 32 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 35
6.2. Handling Version Negotiation Packets . . . . . . . . . . 33 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 35
6.2.1. Version Negotiation Between Draft Versions . . . . . 33 6.2. Handling Version Negotiation Packets . . . . . . . . . . 36
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 33 6.2.1. Version Negotiation Between Draft Versions . . . . . 36
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 34 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 37
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 35 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 37
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 36 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 38
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 37 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 39
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 38 7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 41
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 39 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 43
7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 40 7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 43
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 40 7.4.2. New Transport Parameters . . . . . . . . . . . . . . 45
8.1. Address Validation During Connection Establishment . . . 41 7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 45
8.1.1. Token Construction . . . . . . . . . . . . . . . . . 42 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 46
8.1.2. Address Validation using Retry Packets . . . . . . . 42 8.1. Address Validation During Connection Establishment . . . 46
8.1.3. Address Validation for Future Connections . . . . . . 43 8.1.1. Token Construction . . . . . . . . . . . . . . . . . 47
8.1.4. Address Validation Token Integrity . . . . . . . . . 45 8.1.2. Address Validation using Retry Packets . . . . . . . 47
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 46 8.1.3. Address Validation for Future Connections . . . . . . 48
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 46 8.1.4. Address Validation Token Integrity . . . . . . . . . 51
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 47 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 51
8.5. Successful Path Validation . . . . . . . . . . . . . . . 47 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 52
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 47 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 52
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 48 8.5. Successful Path Validation . . . . . . . . . . . . . . . 53
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 49 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 53
9.2. Initiating Connection Migration . . . . . . . . . . . . . 49 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 54
9.3. Responding to Connection Migration . . . . . . . . . . . 50 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 55
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 50 9.2. Initiating Connection Migration . . . . . . . . . . . . . 55
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 51 9.3. Responding to Connection Migration . . . . . . . . . . . 56
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 52 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 56
9.4. Loss Detection and Congestion Control . . . . . . . . . . 53 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 57
9.5. Privacy Implications of Connection Migration . . . . . . 54 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 58
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 55 9.4. Loss Detection and Congestion Control . . . . . . . . . . 59
9.6.1. Communicating a Preferred Address . . . . . . . . . . 55 9.5. Privacy Implications of Connection Migration . . . . . . 60
9.6.2. Responding to Connection Migration . . . . . . . . . 56 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 61
9.6.1. Communicating a Preferred Address . . . . . . . . . . 61
9.6.2. Responding to Connection Migration . . . . . . . . . 62
9.6.3. Interaction of Client Migration and Preferred 9.6.3. Interaction of Client Migration and Preferred
Address . . . . . . . . . . . . . . . . . . . . . . . 56 Address . . . . . . . . . . . . . . . . . . . . . . . 62
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 57 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 63
10. Connection Termination . . . . . . . . . . . . . . . . . . . 57 10. Connection Termination . . . . . . . . . . . . . . . . . . . 63
10.1. Closing and Draining Connection States . . . . . . . . . 57 10.1. Closing and Draining Connection States . . . . . . . . . 64
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 59 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 65
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 59 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 66
10.3.1. Immediate Close During the Handshake . . . . . . . . 60 10.3.1. Immediate Close During the Handshake . . . . . . . . 67
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 61 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 69
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 64 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 71
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 65 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 72
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 66 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 73
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 67 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 74
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 67 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 74
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 68 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 75
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 68 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 75
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 69 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 76
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 69 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 76
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 70 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 77
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 71 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 78
13. Packetization and Reliability . . . . . . . . . . . . . . . . 81
13. Packetization and Reliability . . . . . . . . . . . . . . . . 74 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 82
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 75 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 82
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 75 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 83
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 76 13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 84
13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 77 13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 85
13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 78 13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 85
13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 78 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 86
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 78 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 86
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 79 13.3. Retransmission of Information . . . . . . . . . . . . . 87
13.3. Retransmission of Information . . . . . . . . . . . . . 79 13.4. Explicit Congestion Notification . . . . . . . . . . . . 89
13.4. Explicit Congestion Notification . . . . . . . . . . . . 82 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 90
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 82 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 90
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 83 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 92
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 84 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 93
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 85 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 94
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 86 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 95
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 87 14.3.1. PMTU Probes Containing Source Connection ID . . . . 95
14.3.1. PMTU Probes Containing Source Connection ID . . . . 87 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 96
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 88 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 97
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 89 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 97
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 89 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 98
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 90 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 99
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 91 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 101
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 93 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 103
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 95 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 105
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 97 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 106
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 99 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 107
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 100 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 109
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 102 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 111
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 104 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 112
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 105 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 113
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 106 18.2. Transport Parameter Definitions . . . . . . . . . . . . 113
18.2. Transport Parameter Definitions . . . . . . . . . . . . 106 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 117
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 111 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 117
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 111 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 118
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 111 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 118
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 112 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 120
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 113 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 121
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 115 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 122
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 116 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 123
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 117 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 123
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 117 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 124
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 118 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 125
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 119 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 127
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 121 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 127
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 121 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 128
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 122 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 129
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 123 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 130
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 124 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 130
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 124 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 131
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 125 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 132
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 127 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 133
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 128 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 134
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 128 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 134
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 128 19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 135
19.20. HANDSHAKE_DONE frame . . . . . . . . . . . . . . . . . . 130 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 136
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 130 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 136
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 130 20.1. Application Protocol Error Codes . . . . . . . . . . . . 138
20.1. Application Protocol Error Codes . . . . . . . . . . . . 132 21. Security Considerations . . . . . . . . . . . . . . . . . . . 138
21. Security Considerations . . . . . . . . . . . . . . . . . . . 132 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 138
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 132 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 139
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 134 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 140
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 134 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 140
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 134 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 140
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 134 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 141
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 135 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 141
21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 135 21.8. Explicit Congestion Notification Attacks . . . . . . . . 142
21.8. Explicit Congestion Notification Attacks . . . . . . . . 136 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 142
21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 136 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 143
21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 137 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 143
21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 137 21.12. Overview of Security Properties . . . . . . . . . . . . 143
21.12. Overview of Security Properties . . . . . . . . . . . . 137 21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 144
21.12.1. Handshake . . . . . . . . . . . . . . . . . . . . . 138 21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 145
21.12.2. Protected Packets . . . . . . . . . . . . . . . . . 139 21.12.3. Connection Migration . . . . . . . . . . . . . . . 146
21.12.3. Connection Migration . . . . . . . . . . . . . . . 140 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 150
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 144 22.1. Registration Policies for QUIC Registries . . . . . . . 150
22.1. Registration Policies for QUIC Registries . . . . . . . 144 22.1.1. Provisional Registrations . . . . . . . . . . . . . 150
22.1.1. Provisional Registrations . . . . . . . . . . . . . 144 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 151
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 145 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 152
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 146 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 153
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 146 22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 153
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 147 22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 154
22.3. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 148 22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 155
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 149 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 157
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 151 23.1. Normative References . . . . . . . . . . . . . . . . . . 157
23.1. Normative References . . . . . . . . . . . . . . . . . . 151 23.2. Informative References . . . . . . . . . . . . . . . . . 158
23.2. Informative References . . . . . . . . . . . . . . . . . 152 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 160
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 154 Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 161
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 155 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 162
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 156 C.1. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 162
C.1. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 156 C.2. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 163
C.2. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 156 C.3. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 163
C.3. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 156 C.4. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 163
C.4. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 158 C.5. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 165
C.5. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 158 C.6. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 165
C.6. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 159 C.7. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 166
C.7. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 160 C.8. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 167
C.8. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 160 C.9. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 167
C.9. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 161 C.10. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 168
C.10. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 161 C.11. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 168
C.11. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 162 C.12. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 169
C.12. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 163 C.13. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 170
C.13. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 163 C.14. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 170
C.14. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 164 C.15. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 171
C.15. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 165 C.16. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 172
C.16. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 165 C.17. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 172
C.17. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 166 C.18. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 173
C.18. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 166 C.19. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 173
C.19. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 167 C.20. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 174
C.20. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 168 C.21. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 175
C.21. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 169 C.22. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 176
C.22. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 169 C.23. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 176
C.23. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 169 C.24. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 176
C.24. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 170 C.25. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 177
C.25. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 170 C.26. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 177
C.26. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 171 C.27. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 178
C.27. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 173 C.28. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 180
C.28. Since draft-hamilton-quic-transport-protocol-01 . . . . . 173 C.29. Since draft-hamilton-quic-transport-protocol-01 . . . . . 180
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 182
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 21 skipping to change at page 8, line 21
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].
1.2. Terms and Definitions 1.2. Terms and Definitions
The keywords "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 BCP "OPTIONAL" in this document are to be interpreted as described in
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.
QUIC: The transport protocol described by this document. QUIC is a QUIC: The transport protocol described by this document. QUIC is a
name, not an acronym. name, not an acronym.
QUIC packet: A complete processable unit of QUIC that can be QUIC packet: A complete processable unit of QUIC that can be
encapsulated in a UDP datagram. Multiple QUIC packets can be encapsulated in a UDP datagram. Multiple QUIC packets can be
encapsulated in a single UDP datagram. encapsulated in a single UDP datagram.
Ack-eliciting Packet: A QUIC packet that contains frames other than Ack-eliciting Packet: A QUIC packet that contains frames other than
ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to ACK, PADDING, and CONNECTION_CLOSE. These cause a recipient to
send an acknowledgment (see Section 13.2.1). send an acknowledgment; see Section 13.2.1.
Out-of-order packet: A packet that does not increase the largest Out-of-order packet: A packet that does not increase the largest
received packet number for its packet number space (Section 12.3) received packet number for its packet number space (Section 12.3)
by exactly one. A packet can arrive out of order if it is delayed by exactly one. A packet can arrive out of order if it is
or if earlier packets are lost or delayed. delayed, if earlier packets are lost or delayed, or if the sender
intentionally skips a packet number.
Endpoint: An entity that can participate in a QUIC connection by Endpoint: An entity that can participate in a QUIC connection by
generating, receiving, and processing QUIC packets. There are generating, receiving, and processing QUIC packets. There are
only two types of endpoint in QUIC: client and server. only two types of endpoint in QUIC: client and server.
Client: The endpoint initiating a QUIC connection. Client: The endpoint initiating a QUIC connection.
Server: The endpoint accepting incoming QUIC connections. Server: The endpoint accepting incoming QUIC connections.
Address: When used without qualification, the tuple of IP version, Address: When used without qualification, the tuple of IP version,
skipping to change at page 9, line 21 skipping to change at page 9, line 23
peer to include in packets sent towards the endpoint. peer to include in packets sent towards the endpoint.
Stream: A unidirectional or bidirectional channel of ordered bytes Stream: A unidirectional or bidirectional channel of ordered bytes
within a QUIC connection. A QUIC connection can carry multiple within a QUIC connection. A QUIC connection can carry multiple
simultaneous streams. simultaneous streams.
Application: An entity that uses QUIC to send and receive data. Application: An entity that uses QUIC to send and receive data.
1.3. Notational Conventions 1.3. Notational Conventions
Packet and frame diagrams in this document use the format described Packet and frame diagrams in this document use a bespoke format. The
in Section 3.1 of [RFC2360], with the following additional purpose of this format is to summarize, not define, protocol
conventions: elements. Prose defines the complete semantics and details of
structures.
[x]: Indicates that x is optional Complex fields are named and then followed by a list of fields
surrounded by a pair of matching braces. Each field in this list is
separated by commas.
x (A): Indicates that x is A bits long Individual fields include length information, plus indications about
fixed value, optionality, or repetitions. Individual fields use the
following notational conventions, with all lengths in bits:
x (A/B/C) ...: Indicates that x is one of A, B, or C bits long x (A): Indicates that x is A bits long
x (i) ...: Indicates that x uses the variable-length encoding in x (i): Indicates that x uses the variable-length encoding in
Section 16 Section 16
x (*) ...: Indicates that x is variable-length x (A..B): Indicates that x can be any length from A to B; A can be
omitted to indicate a minimum of zero bits and B can be omitted to
indicate no set upper limit; values in this format always end on
an octet boundary
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,
inclusive
[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
each instance is length E)
By convention, individual fields reference a complex field by using
the name of the complex field.
For example:
Example Structure {
One-bit Field (1),
7-bit Field with Fixed Value (7) = 61,
Arbitrary-Length Field (..),
Variable-Length Field (8..24),
Field With Minimum Length (16..),
Field With Maximum Length (..128),
[Optional Field (64)],
Repeated Field (8) ...,
}
Figure 1: Example Format
2. Streams 2. Streams
Streams in QUIC provide a lightweight, ordered byte-stream Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application. Streams can be unidirectional or abstraction to an application. Streams can be unidirectional or
bidirectional. An alternative view of QUIC unidirectional streams is bidirectional. An alternative view of QUIC unidirectional streams is
a "message" abstraction of practically unlimited length. a "message" abstraction of practically unlimited length.
Streams can be created by sending data. Other processes associated Streams can be created by sending data. Other processes associated
with stream management - ending, cancelling, and managing flow with stream management - ending, cancelling, and managing flow
skipping to change at page 10, line 9 skipping to change at page 10, line 46
for, and close a stream. Streams can also be long-lived and can last for, and close a stream. Streams can also be long-lived and can last
the entire duration of a connection. the entire duration of a connection.
Streams can be created by either endpoint, can concurrently send data Streams can be created by either endpoint, can concurrently send data
interleaved with other streams, and can be cancelled. QUIC does not interleaved with other streams, and can be cancelled. QUIC does not
provide any means of ensuring ordering between bytes on different provide any means of ensuring ordering between bytes on different
streams. streams.
QUIC allows for an arbitrary number of streams to operate QUIC allows for an arbitrary number of streams to operate
concurrently and for an arbitrary amount of data to be sent on any concurrently and for an arbitrary amount of data to be sent on any
stream, subject to flow control constraints (see Section 4) and stream, subject to flow control constraints and stream limits; see
stream limits. Section 4.
2.1. Stream Types and Identifiers 2.1. Stream Types and Identifiers
Streams can be unidirectional or bidirectional. Unidirectional Streams can be unidirectional or bidirectional. Unidirectional
streams carry data in one direction: from the initiator of the stream streams carry data in one direction: from the initiator of the stream
to its peer. Bidirectional streams allow for data to be sent in both to its peer. Bidirectional streams allow for data to be sent in both
directions. directions.
Streams are identified within a connection by a numeric value, Streams are identified within a connection by a numeric value,
referred to as the stream ID. A stream ID is a 62-bit integer (0 to referred to as the stream ID. A stream ID is a 62-bit integer (0 to
2^62-1) that is unique for all streams on a connection. Stream IDs 2^62-1) that is unique for all streams on a connection. Stream IDs
are encoded as variable-length integers (see Section 16). A QUIC are encoded as variable-length integers; see Section 16. A QUIC
endpoint MUST NOT reuse a stream ID within a connection. endpoint MUST NOT reuse a stream ID within a connection.
The least significant bit (0x1) of the stream ID identifies the The least significant bit (0x1) of the stream ID identifies the
initiator of the stream. Client-initiated streams have even-numbered initiator of the stream. Client-initiated streams have even-numbered
stream IDs (with the bit set to 0), and server-initiated streams have stream IDs (with the bit set to 0), and server-initiated streams have
odd-numbered stream IDs (with the bit set to 1). odd-numbered stream IDs (with the bit set to 1).
The second least significant bit (0x2) of the stream ID distinguishes The second least significant bit (0x2) of the stream ID distinguishes
between bidirectional streams (with the bit set to 0) and between bidirectional streams (with the bit set to 0) and
unidirectional streams (with the bit set to 1). unidirectional streams (with the bit set to 1).
skipping to change at page 13, line 28 skipping to change at page 14, line 28
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
implementation can define a different state machine as long as its implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements behavior is consistent with an implementation that implements
these states. these states.
3.1. Sending Stream States 3.1. Sending Stream States
Figure 1 shows the states for the part of a stream that sends data to Figure 2 shows the states for the part of a stream that sends data to
a peer. a peer.
o o
| Create Stream (Sending) | Create Stream (Sending)
| Peer Creates Bidirectional Stream | Peer Creates Bidirectional Stream
v v
+-------+ +-------+
| Ready | Send RESET_STREAM | Ready | Send RESET_STREAM
| |-----------------------. | |-----------------------.
+-------+ | +-------+ |
skipping to change at page 14, line 39 skipping to change at page 15, line 39
| Sent |------------------>| Sent | | Sent |------------------>| Sent |
+-------+ +-------+ +-------+ +-------+
| | | |
| Recv All ACKs | Recv ACK | Recv All ACKs | Recv ACK
v v v v
+-------+ +-------+ +-------+ +-------+
| Data | | Reset | | Data | | Reset |
| Recvd | | Recvd | | Recvd | | Recvd |
+-------+ +-------+ +-------+ +-------+
Figure 1: 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 stream that the endpoint initiates (types 0 and 2
for clients, 1 and 3 for servers) is opened by the application. The for clients, 1 and 3 for servers) is opened by the application. The
"Ready" state represents a newly created stream that is able to "Ready" state represents a newly created stream that is able to
accept data from the application. Stream data might be buffered in accept data from the application. Stream data might be buffered in
this state in preparation for sending. this state in preparation for sending.
Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a
sending part of a stream to enter the "Send" state. An sending part of a stream to enter the "Send" state. An
implementation might choose to defer allocating a stream ID to a implementation might choose to defer allocating a stream ID to a
skipping to change at page 15, line 48 skipping to change at page 17, line 7
An endpoint MAY send a RESET_STREAM as the first frame that mentions An endpoint MAY send a RESET_STREAM as the first frame that mentions
a stream; this causes the sending part of that stream to open and a stream; this causes the sending part of that stream to open and
then immediately transition to the "Reset Sent" state. then immediately transition to the "Reset Sent" state.
Once a packet containing a RESET_STREAM has been acknowledged, the Once a packet containing a RESET_STREAM has been acknowledged, the
sending part of the stream enters the "Reset Recvd" state, which is a sending part of the stream enters the "Reset Recvd" state, which is a
terminal state. terminal state.
3.2. Receiving Stream States 3.2. Receiving Stream States
Figure 2 shows the states for the part of a stream that receives data Figure 3 shows the states for the part of a stream that receives data
from a peer. The states for a receiving part of a stream mirror only from a peer. The states for a receiving part of a stream mirror only
some of the states of the sending part of the stream at the peer. some of the states of the sending part of the stream at the peer.
The receiving part of a stream does not track states on the sending The receiving part of a stream does not track states on the sending
part that cannot be observed, such as the "Ready" state. Instead, part that cannot be observed, such as the "Ready" state. Instead,
the receiving part of a stream tracks the delivery of data to the the receiving part of a stream tracks the delivery of data to the
application, some of which cannot be observed by the sender. application, some of which cannot be observed by the sender.
o o
| Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM | Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM
| Create Bidirectional Stream (Sending) | Create Bidirectional Stream (Sending)
skipping to change at page 16, line 39 skipping to change at page 17, line 47
| Recvd | Recv All Data | Recvd | | Recvd | Recv All Data | Recvd |
+-------+<-- (optional) ----+-------+ +-------+<-- (optional) ----+-------+
| | | |
| App Read All Data | App Read RST | App Read All Data | App Read RST
v v v v
+-------+ +-------+ +-------+ +-------+
| Data | | Reset | | Data | | Reset |
| Read | | Read | | Read | | Read |
+-------+ +-------+ +-------+ +-------+
Figure 2: 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 is received for that stream.
For bidirectional streams initiated by a peer, receipt of a 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
skipping to change at page 17, line 26 skipping to change at page 18, line 33
order for streams is consistent on both endpoints. order for streams is consistent on both endpoints.
In the "Recv" state, the endpoint receives STREAM and In the "Recv" state, the endpoint receives STREAM and
STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be
reassembled into the correct order for delivery to the application. reassembled into the correct order for delivery to the application.
As data is consumed by the application and buffer space becomes As data is consumed by the application and buffer space becomes
available, the endpoint sends MAX_STREAM_DATA frames to allow the available, the endpoint sends MAX_STREAM_DATA frames to allow the
peer to send more data. peer to send more data.
When a STREAM frame with a FIN bit is received, the final size of the When a STREAM frame with a FIN bit is received, the final size of the
stream is known (see Section 4.4). The receiving part of the stream stream is known; see Section 4.4. The receiving part of the stream
then enters the "Size Known" state. In this state, the endpoint no then enters the "Size Known" state. In this state, the endpoint no
longer needs to send MAX_STREAM_DATA frames, it only receives any longer needs to send MAX_STREAM_DATA frames, it only receives any
retransmissions of stream data. retransmissions of stream data.
Once all data for the stream has been received, the receiving part Once all data for the stream has been received, the receiving part
enters the "Data Recvd" state. This might happen as a result of enters the "Data Recvd" state. This might happen as a result of
receiving the same STREAM frame that causes the transition to "Size receiving the same STREAM frame that causes the transition to "Size
Known". After all data has been received, any STREAM or Known". After all data has been received, any STREAM or
STREAM_DATA_BLOCKED frames for the stream can be discarded. STREAM_DATA_BLOCKED frames for the stream can be discarded.
skipping to change at page 21, line 43 skipping to change at page 23, line 43
* Stream flow control, which prevents a single stream from consuming * Stream flow control, which prevents a single stream from consuming
the entire receive buffer for a connection by limiting the amount the entire receive buffer for a connection by limiting the amount
of data that can be sent on any stream. of data that can be sent on any stream.
* Connection flow control, which prevents senders from exceeding a * Connection flow control, which prevents senders from exceeding a
receiver's buffer capacity for the connection, by limiting the receiver's buffer capacity for the connection, by limiting the
total bytes of stream data sent in STREAM frames on all streams. total bytes of stream data sent in STREAM frames on all streams.
A receiver sets initial credits for all streams by sending transport A receiver sets initial credits for all streams by sending transport
parameters during the handshake (Section 7.3). A receiver sends parameters during the handshake (Section 7.4). A receiver sends
MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to
the sender to advertise additional credit. the sender to advertise additional credit.
A receiver advertises credit for a stream by sending a A receiver advertises credit for a stream by sending a
MAX_STREAM_DATA frame with the Stream ID field set appropriately. A MAX_STREAM_DATA frame with the Stream ID field set appropriately. A
MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a
stream. A receiver could use the current offset of data consumed to stream. A receiver could use the current offset of data consumed to
determine the flow control offset to be advertised. A receiver MAY determine the flow control offset to be advertised. A receiver MAY
send MAX_STREAM_DATA frames in multiple packets in order to make sure send MAX_STREAM_DATA frames in multiple packets in order to make sure
that the sender receives an update before running out of flow control that the sender receives an update before running out of flow control
skipping to change at page 24, line 28 skipping to change at page 26, line 35
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
final size for the stream, an endpoint SHOULD respond with a final size for the stream, an endpoint SHOULD respond with a
FINAL_SIZE_ERROR error (see Section 11). A receiver SHOULD treat FINAL_SIZE_ERROR error; see Section 11. A receiver SHOULD treat
receipt of data at or beyond the final size as a FINAL_SIZE_ERROR receipt of data at or beyond the final size as a FINAL_SIZE_ERROR
error, even after a stream is closed. Generating these errors is not error, even after a stream is closed. Generating these errors is not
mandatory, but only because requiring that an endpoint generate these mandatory, but only because requiring that an endpoint generate these
errors also means that the endpoint needs to maintain the final size errors also means that the endpoint needs to maintain the final size
state for closed streams, which could mean a significant state state for closed streams, which could mean a significant state
commitment. commitment.
4.5. Controlling Concurrency 4.5. Controlling Concurrency
An endpoint limits the cumulative number of incoming streams a peer An endpoint limits the cumulative number of incoming streams a peer
can open. Only streams with a stream ID less than (max_stream * 4 + can open. Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened (see Table 5). Initial initial_stream_id_for_type) can be opened; see Table 5. Initial
limits are set in the transport parameters (see Section 18.2) and limits are set in the transport parameters (see Section 18.2) and
subsequently limits are advertised using MAX_STREAMS frames subsequently limits are advertised using MAX_STREAMS frames
(Section 19.11). Separate limits apply to unidirectional and (Section 19.11). Separate limits apply to unidirectional and
bidirectional streams. bidirectional streams.
If a max_streams transport parameter or MAX_STREAMS frame is received If a max_streams transport parameter or MAX_STREAMS frame is received
with a value greater than 2^60, this would allow a maximum stream ID with a value greater than 2^60, this would allow a maximum stream ID
that cannot be expressed as a variable-length integer (see that cannot be expressed as a variable-length integer; see
Section 16). If either is received, the connection MUST be closed Section 16. If either is received, the connection MUST be closed
immediately with a connection error of type STREAM_LIMIT_ERROR (see immediately with a connection error of type STREAM_LIMIT_ERROR; see
Section 10.3). Section 10.3.
Endpoints MUST NOT exceed the limit set by their peer. An endpoint Endpoints MUST NOT exceed the limit set by their peer. An endpoint
that receives a frame with a stream ID exceeding the limit it has that receives a frame with a stream ID exceeding the limit it has
sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR
(Section 11). (Section 11).
Once a receiver advertises a stream limit using the MAX_STREAMS Once a receiver advertises a stream limit using the MAX_STREAMS
frame, advertising a smaller limit has no effect. A receiver MUST frame, advertising a smaller limit has no effect. A receiver MUST
ignore any MAX_STREAMS frame that does not increase the stream limit. ignore any MAX_STREAMS frame that does not increase the stream limit.
skipping to change at page 27, line 18 skipping to change at page 29, line 28
ID randomly selected by the client in the Initial packet and any ID randomly selected by the client in the Initial packet and any
connection ID provided by a Retry packet are not assigned sequence connection ID provided by a Retry packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection numbers unless a server opts to retain them as its initial connection
ID. ID.
When an endpoint issues a connection ID, it MUST accept packets that When an endpoint issues a connection ID, it MUST accept packets that
carry this connection ID for the duration of the connection or until carry this connection ID for the duration of the connection or until
its peer invalidates the connection ID via a RETIRE_CONNECTION_ID its peer invalidates the connection ID via a RETIRE_CONNECTION_ID
frame (Section 19.16). Connection IDs that are issued and not frame (Section 19.16). Connection IDs that are issued and not
retired are considered active; any active connection ID is valid for retired are considered active; any active connection ID is valid for
use at any time, in any packet type. This includes the connection ID use with the current connection at any time, in any packet type.
issued by the server via the preferred_address transport parameter. This includes the connection ID issued by the server via the
preferred_address transport parameter.
An endpoint SHOULD ensure that its peer has a sufficient number of An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs. Endpoints store received available and unused connection IDs. Endpoints advertise the number
connection IDs for future use and advertise the number of connection of active connection IDs they are willing to maintain using the
IDs they are willing to store with the active_connection_id_limit active_connection_id_limit transport parameter. An endpoint MUST NOT
transport parameter. An endpoint MUST NOT provide more connection provide more connection IDs than the peer's limit. An endpoint MAY
IDs than the peer's limit. An endpoint that receives more connection send connection IDs that temporarily exceed a peer's limit if the
IDs than its advertised active_connection_id_limit MUST close the NEW_CONNECTION_ID frame also requires the retirement of any excess,
connection with an error of type CONNECTION_ID_LIMIT_ERROR. by including a sufficiently large value in the Retire Prior To field.
A NEW_CONNECTION_ID frame might cause an endpoint to add some active
connection IDs and retire others based on the value of the Retire
Prior To field. After processing a NEW_CONNECTION_ID frame and
adding and retiring active connection IDs, if the number of active
connection IDs exceeds the value advertised in its
active_connection_id_limit transport parameter, an endpoint MUST
close the connection with an error of type CONNECTION_ID_LIMIT_ERROR.
An endpoint SHOULD supply a new connection ID when the peer retires a An endpoint SHOULD supply a new connection ID when the peer retires a
connection ID. If an endpoint provided fewer connection IDs than the connection ID. If an endpoint provided fewer connection IDs than the
peer's active_connection_id_limit, it MAY supply a new connection ID peer's active_connection_id_limit, it MAY supply a new connection ID
when it receives a packet with a previously unused connection ID. An when it receives a packet with a previously unused connection ID. An
endpoint MAY limit the frequency or the total number of connection endpoint MAY limit the frequency or the total number of connection
IDs issued for each connection to avoid the risk of running out of IDs issued for each connection to avoid the risk of running out of
connection IDs; see Section 10.4.2. connection IDs; see Section 10.4.2. An endpoint MAY also limit the
issuance of connection IDs to reduce the amount of per-path state it
maintains, such as path validation status, as its peer might interact
with it over as many paths as there are issued connection IDs.
An endpoint that initiates migration and requires non-zero-length An endpoint that initiates migration and requires non-zero-length
connection IDs SHOULD ensure that the pool of connection IDs connection IDs SHOULD ensure that the pool of connection IDs
available to its peer allows the peer to use a new connection ID on available to its peer allows the peer to use a new connection ID on
migration, as the peer will close the connection if the pool is migration, as the peer will close the connection if the pool is
exhausted. exhausted.
5.1.2. Consuming and Retiring Connection IDs 5.1.2. Consuming and Retiring Connection IDs
An endpoint can change the connection ID it uses for a peer to An endpoint can change the connection ID it uses for a peer to
skipping to change at page 28, line 10 skipping to change at page 30, line 32
Section 9.5 for more. Section 9.5 for more.
An endpoint maintains a set of connection IDs received from its peer, An endpoint maintains a set of connection IDs received from its peer,
any of which it can use when sending packets. When the endpoint any of which it can use when sending packets. When the endpoint
wishes to remove a connection ID from use, it sends a wishes to remove a connection ID from use, it sends a
RETIRE_CONNECTION_ID frame to its peer. Sending a RETIRE_CONNECTION_ID frame to its peer. Sending a
RETIRE_CONNECTION_ID frame indicates that the connection ID will not RETIRE_CONNECTION_ID frame indicates that the connection ID will not
be used again and requests that the peer replace it with a new be used again and requests that the peer replace it with a new
connection ID using a NEW_CONNECTION_ID frame. connection ID using a NEW_CONNECTION_ID frame.
As discussed in Section 9.5, each connection ID MUST be used on As discussed in Section 9.5, endpoints limit the use of a connection
packets sent from only one local address. An endpoint that migrates ID to packets sent from a single local address to a single
away from a local address SHOULD retire all connection IDs used on destination address. Endpoints SHOULD retire connection IDs when
that address once it no longer plans to use that address. they are no longer actively using either the local or destination
address for which the connection ID was used.
An endpoint can cause its peer to retire connection IDs by sending a An endpoint might need to stop accepting previously issued connection
NEW_CONNECTION_ID frame with an increased Retire Prior To field. IDs in certain circumstances. Such an endpoint can cause its peer to
Upon receipt, the peer MUST first retire the corresponding connection retire connection IDs by sending a NEW_CONNECTION_ID frame with an
IDs using RETIRE_CONNECTION_ID frames and then add the newly provided increased Retire Prior To field. The endpoint SHOULD continue to
connection ID to the set of active connection IDs. Failure to retire accept the previously issued connection IDs until they are retired by
the connection IDs within approximately one PTO can cause packets to the peer. If the endpoint can no longer process the indicated
be delayed, lost, or cause the original endpoint to send a stateless connection IDs, it MAY close the connection.
reset in response to a connection ID it can no longer route
correctly.
An endpoint MAY discard a connection ID for which retirement has been Upon receipt of an increased Retire Prior To field, the peer MUST
requested once an interval of no less than 3 PTO has elapsed since an stop using the corresponding connection IDs and retire them with
acknowledgement is received for the NEW_CONNECTION_ID frame RETIRE_CONNECTION_ID frames before adding the newly provided
requesting that retirement. Until then, the endpoint SHOULD be connection ID to the set of active connection IDs. This ordering
prepared to receive packets that contain the connection ID that it allows an endpoint to replace all active connection IDs without the
has requested be retired. Subsequent incoming packets using that possibility of a peer having no available connection IDs and without
connection ID could elicit a response with the corresponding exceeding the limit the peer sets in the active_connection_id_limit
stateless reset token. transport parameter; see Section 18.2. Failure to cease using the
connection IDs when requested can result in connection failures, as
the issuing endpoint might be unable to continue using the connection
IDs with the active connection.
An endpoint SHOULD limit the number of connection IDs it has retired
locally and have not yet been acknowledged. An endpoint SHOULD allow
for sending and tracking a number of RETIRE_CONNECTION_ID frames of
at least twice the active_connection_id limit. An endpoint MUST NOT
forget a connection ID without retiring it, though it MAY choose to
treat having connection IDs in need of retirement that exceed this
limit as a connection error of type CONNECTION_ID_LIMIT_ERROR.
Endpoints SHOULD NOT issue updates of the Retire Prior To field
before receiving RETIRE_CONNECTION_ID frames that retire all
connection IDs indicated by the previous Retire Prior To value.
5.2. Matching Packets to Connections 5.2. Matching Packets to Connections
Incoming packets are classified on receipt. Packets can either be Incoming packets are classified on receipt. Packets can either be
associated with an existing connection, or - for servers - associated with an existing connection, or - for servers -
potentially create a new connection. potentially create a new connection.
Endpoints try to associate a packet with an existing connection. If Endpoints try to associate a packet with an existing connection. If
the packet has a non-zero-length Destination Connection ID the packet has a non-zero-length Destination Connection ID
corresponding to an existing connection, QUIC processes that packet corresponding to an existing connection, QUIC processes that packet
skipping to change at page 30, line 30 skipping to change at page 33, line 17
code SERVER_BUSY. code SERVER_BUSY.
If the packet is a 0-RTT packet, the server MAY buffer a limited If the packet is a 0-RTT packet, the server MAY buffer a limited
number of these packets in anticipation of a late-arriving Initial number of these packets in anticipation of a late-arriving Initial
packet. Clients are 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
A server deployment could load balance among servers using only
source and destination IP addresses and ports. Changes to the
client's IP address or port could result in packets being forwarded
to the wrong server. Such a server deployment could use one of the
following methods for connection continuity when a client's address
changes.
* Servers could use an out-of-band mechanism to forward packets to
the correct server based on Connection ID.
* If servers can use a dedicated server IP address or port, other
than the one that the client initially connects to, they could use
the preferred_address transport parameter to request that clients
move connections to that dedicated address. Note that clients
could choose not to use the preferred address.
A server in a deployment that does not implement a solution to
maintain connection continuity during connection migration SHOULD
disallow migration using the disable_active_migration transport
parameter.
Server deployments that use this simple form of load balancing MUST
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.
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.
skipping to change at page 30, line 40 skipping to change at page 34, line 4
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.3). 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 messages to be sent by
a client before receiving any messages from the server. However, a client before receiving any messages from the server. However,
0-RTT lacks certain key security guarantees. In particular, there is 0-RTT lacks certain key security guarantees. In particular, there is
no protection against replay attacks in 0-RTT; see [QUIC-TLS]. no 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
skipping to change at page 31, line 50 skipping to change at page 35, line 16
the TLS resumption ticket sent to the client; and the TLS resumption ticket sent to the client; and
* if Early Data is supported, retrieve application-controlled data * if Early Data is supported, retrieve application-controlled data
from the client's resumption ticket and enable rejecting Early from the client's resumption ticket and enable rejecting Early
Data based on that information. Data based on that information.
In either role, applications need to be able to: In either role, applications need to be able to:
* configure minimum values for the initial number of permitted * configure minimum values for the initial number of permitted
streams of each type, as communicated in the transport parameters streams of each type, as communicated in the transport parameters
(Section 7.3); (Section 7.4);
* control resource allocation of various types, including flow * control resource allocation of various types, including flow
control and the number of permitted streams of each type; control and the number of permitted streams of each type;
* identify whether the handshake has completed successfully or is * identify whether the handshake has completed successfully or is
still ongoing still ongoing;
* keep a connection from silently closing, either by generating PING * keep a connection from silently closing, either by generating PING
frames (Section 19.2) or by requesting that the transport send frames (Section 19.2) or by requesting that the transport send
additional frames before the idle timeout expires (Section 10.2); additional frames before the idle timeout expires (Section 10.2);
and and
* immediately close (Section 10.3) the connection. * immediately close (Section 10.3) the connection.
6. Version Negotiation 6. Version Negotiation
skipping to change at page 32, line 35 skipping to change at page 35, line 48
The size of the first packet sent by a client will determine whether The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet. Clients that support a server sends a Version Negotiation packet. Clients that support
multiple QUIC versions SHOULD pad the first packet they send to the multiple QUIC versions SHOULD pad the first packet they send to the
largest of the minimum packet sizes across all versions they support. largest of the minimum packet sizes across all versions they support.
This ensures that the server responds if there is a mutually This ensures that the server responds if there is a mutually
supported version. supported version.
6.1. Sending Version Negotiation Packets 6.1. Sending Version Negotiation Packets
If the version selected by the client is not acceptable to the If the version selected by the client is not acceptable to the
server, the server responds with a Version Negotiation packet (see server, the server responds with a Version Negotiation packet; see
Section 17.2.1). This includes a list of versions that the server Section 17.2.1. This includes a list of versions that the server
will accept. An endpoint MUST NOT send a Version Negotiation packet will accept. An endpoint MUST NOT send a Version Negotiation packet
in response to receiving a Version Negotiation packet. in response to receiving a Version Negotiation packet.
This system allows a server to process packets with unsupported This system allows a server to process packets with unsupported
versions without retaining state. Though either the Initial packet versions without retaining state. Though either the Initial packet
or the Version Negotiation packet that is sent in response could be or the Version Negotiation packet that is sent in response could be
lost, the client will send new packets until it successfully receives lost, the client will send new packets until it successfully receives
a response or it abandons the connection attempt. As a result, the a response or it abandons the connection attempt. As a result, the
client discards all state for the connection and does not send any client discards all state for the connection and does not send any
more packets on the connection. more packets on the connection.
A server MAY limit the number of Version Negotiation packets it A server MAY limit the number of Version Negotiation packets it
sends. For instance, a server that is able to recognize packets as sends. For instance, a server that is able to recognize packets as
0-RTT might choose not to send Version Negotiation packets in 0-RTT might choose not to send Version Negotiation packets in
response to 0-RTT packets with the expectation that it will response to 0-RTT packets with the expectation that it will
eventually receive an Initial packet. eventually receive an Initial packet.
6.2. Handling Version Negotiation Packets 6.2. Handling Version Negotiation Packets
When a client receives a Version Negotiation packet, it MUST abandon Version Negotiation packets are designed to allow future versions of
the current connection attempt. Version Negotiation packets are QUIC to negotiate the version in use between endpoints. Future
designed to allow future versions of QUIC to negotiate the version in versions of QUIC might change how implementations that support
use between endpoints. Future versions of QUIC might change how multiple versions of QUIC react to Version Negotiation packets when
implementations that support multiple versions of QUIC react to attempting to establish a connection using this version.
Version Negotiation packets when attempting to establish a connection
using this version. How to perform version negotiation is left as A client that supports only this version of QUIC MUST abandon the
future work defined by future versions of QUIC. In particular, that current connection attempt if it receives a Version Negotiation
future work will need to ensure robustness against version downgrade packet, with the following two exceptions. A client MUST discard any
attacks; see Section 21.10. Version Negotiation packet if it has received and successfully
processed any other packet, including an earlier Version Negotiation
packet. A client MUST discard a Version Negotiation packet that
lists the QUIC version selected by the client.
How to perform version negotiation is left as future work defined by
future versions of QUIC. In particular, that future work will ensure
robustness against version downgrade attacks; see Section 21.10.
6.2.1. Version Negotiation Between Draft Versions 6.2.1. Version Negotiation Between Draft Versions
[[RFC editor: please remove this section before publication.]] [[RFC editor: please remove this section before publication.]]
When a draft implementation receives a Version Negotiation packet, it When a draft implementation receives a Version Negotiation packet, it
MAY use it to attempt a new connection with one of the versions MAY use it to attempt a new connection with one of the versions
listed in the packet, instead of abandoning the current connection listed in the packet, instead of abandoning the current connection
attempt; see Section 6.2. attempt; see Section 6.2.
skipping to change at page 33, line 45 skipping to change at page 37, line 18
connection using that version. The new connection MUST use a new connection using that version. The new connection MUST use a new
random Destination Connection ID different from the one it had random Destination Connection ID different from the one it had
previously sent. previously sent.
Note that this mechanism does not protect against downgrade attacks Note that this mechanism does not protect against downgrade attacks
and MUST NOT be used outside of draft implementations. and MUST NOT be used outside of draft implementations.
6.3. Using Reserved Versions 6.3. Using Reserved Versions
For a server to use a new version in the future, clients need to For a server to use a new version in the future, clients need to
correctly handle unsupported versions. To help ensure this, a server correctly handle unsupported versions. Some version numbers
SHOULD include a version that is reserved for forcing version (0x?a?a?a?a as defined in Section 15) are reserved for inclusion in
negotiation (0x?a?a?a?a as defined in Section 15) when generating a fields that contain version numbers.
Version Negotiation packet.
The design of version negotiation permits a server to avoid
maintaining state for packets that it rejects in this fashion.
A client MAY send a packet using a version that is reserved for Endpoints MAY add reserved versions to any field where unknown or
forcing version negotiation. This can be used to solicit a list of unsupported versions are ignored to test that a peer correctly
supported versions from a server. ignores the value. For instance, an endpoint could include a
reserved version in a Version Negotiation packet; see Section 17.2.1.
Endpoints MAY send packets with a reserved version to test that a
peer correctly discards the packet.
7. Cryptographic and Transport Handshake 7. Cryptographic and Transport Handshake
QUIC relies on a combined cryptographic and transport handshake to QUIC relies on a combined cryptographic and transport handshake to
minimize connection establishment latency. QUIC uses the CRYPTO minimize connection establishment latency. QUIC uses the CRYPTO
frame Section 19.6 to transmit the cryptographic handshake. Version frame Section 19.6 to transmit the cryptographic handshake. Version
0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different
QUIC version number could indicate that a different cryptographic QUIC version number could indicate that a different cryptographic
handshake protocol is in use. handshake protocol is in use.
skipping to change at page 34, line 38 skipping to change at page 38, line 9
- every connection produces distinct and unrelated keys, - every connection produces distinct and unrelated keys,
- keying material is usable for packet protection for both 0-RTT - keying material is usable for packet protection for both 0-RTT
and 1-RTT packets, and and 1-RTT packets, and
- 1-RTT keys have forward secrecy - 1-RTT keys have forward secrecy
* authenticated values for transport parameters of both endpoints, * authenticated values for transport parameters of both endpoints,
and confidentiality protection for server transport parameters and confidentiality protection for server transport parameters
(see Section 7.3) (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 sequence numbers used by CRYPTO frames to ensure
ordered delivery of cryptographic handshake data start from zero in ordered delivery of cryptographic handshake data start from zero in
skipping to change at page 35, line 19 skipping to change at page 38, line 38
Details of how TLS is integrated with QUIC are provided in Details of how TLS is integrated with QUIC are provided in
[QUIC-TLS], but some examples are provided here. An extension of [QUIC-TLS], but some examples are provided here. An extension of
this exchange to support client address validation is shown in this exchange to support client address validation is shown in
Section 8.1.2. Section 8.1.2.
Once any address validation exchanges are complete, the cryptographic Once any address validation exchanges are complete, the cryptographic
handshake is used to agree on cryptographic keys. The cryptographic handshake is used to agree on cryptographic keys. The cryptographic
handshake is carried in Initial (Section 17.2.2) and Handshake handshake is carried in Initial (Section 17.2.2) and Handshake
(Section 17.2.4) packets. (Section 17.2.4) packets.
Figure 3 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 encryption levels Note that multiple QUIC packets - even of different packet types -
- may be coalesced into a single UDP datagram (see Section 12.2), and can be coalesced into a single UDP datagram; see Section 12.2). As a
so this handshake may consist of as few as 4 UDP datagrams, or any result, this handshake may consist of as few as 4 UDP datagrams, or
number more. For instance, the server's first flight contains any number more. For instance, the server's first flight contains
packets from the Initial encryption level (obfuscation), the Initial packets, Handshake packets, and "0.5-RTT data" in 1-RTT
Handshake level, and "0.5-RTT data" from the server at the 1-RTT packets with a short header.
encryption level.
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]
Handshake[0]: CRYPTO[FIN], ACK[0] Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1-RTT[0]: STREAM[0, "..."], ACK[0] ->
1-RTT[1]: STREAM[3, "..."], ACK[0] Handshake[1]: ACK[0]
<- Handshake[1]: ACK[0] <- 1-RTT[1]: STREAM[3, "..."], ACK[0]
Figure 3: Example 1-RTT Handshake Figure 4: Example 1-RTT Handshake
Figure 4 shows an example of a connection with a 0-RTT handshake and Figure 5 shows an example of a connection with a 0-RTT handshake and
a single packet of 0-RTT data. Note that as described in a single packet of 0-RTT data. Note that as described in
Section 12.3, the server acknowledges 0-RTT data at the 1-RTT Section 12.3, the server acknowledges 0-RTT data in 1-RTT packets,
encryption level, and the client sends 1-RTT packets in the same and the client sends 1-RTT packets in the same packet number space.
packet number space.
Client Server Client Server
Initial[0]: CRYPTO[CH] Initial[0]: CRYPTO[CH]
0-RTT[0]: STREAM[0, "..."] -> 0-RTT[0]: STREAM[0, "..."] ->
Initial[0]: CRYPTO[SH] ACK[0] Initial[0]: CRYPTO[SH] ACK[0]
Handshake[0] CRYPTO[EE, FIN] Handshake[0] CRYPTO[EE, FIN]
<- 1-RTT[0]: STREAM[1, "..."] ACK[0] <- 1-RTT[0]: STREAM[1, "..."] ACK[0]
Initial[1]: ACK[0] Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0] Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[1]: STREAM[0, "..."] ACK[0] -> 1-RTT[1]: STREAM[0, "..."] ACK[0] ->
1-RTT[1]: STREAM[3, "..."], ACK[1] Handshake[1]: ACK[0]
<- Handshake[1]: ACK[0] <- 1-RTT[1]: STREAM[3, "..."], ACK[1]
Figure 4: Example 0-RTT Handshake Figure 5: Example 0-RTT Handshake
7.2. Negotiating Connection IDs 7.2. Negotiating Connection IDs
A connection ID is used to ensure consistent routing of packets, as A connection ID is used to ensure consistent routing of packets, as
described in Section 5.1. The long header contains two connection described in Section 5.1. The long header contains two connection
IDs: the Destination Connection ID is chosen by the recipient of the IDs: the Destination Connection ID is chosen by the recipient of the
packet and is used to provide consistent routing; the Source packet and is used to provide consistent routing; the Source
Connection ID is used to set the Destination Connection ID used by Connection ID is used to set the Destination Connection ID used by
the peer. the peer.
During the handshake, packets with the long header (Section 17.2) are During the handshake, packets with the long header (Section 17.2) are
used to establish the connection ID that each endpoint uses. Each used to establish the connection IDs in each direction. Each
endpoint uses the Source Connection ID field to specify the endpoint uses the Source Connection ID field to specify the
connection ID that is used in the Destination Connection ID field of connection ID that is used in the Destination Connection ID field of
packets being sent to them. Upon receiving a packet, each endpoint packets being sent to them. Upon receiving a packet, each endpoint
sets the Destination Connection ID it sends to match the value of the sets the Destination Connection ID it sends to match the value of the
Source Connection ID that they receive. Source Connection ID that it receives.
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, it populates the received an Initial or Retry packet from the server, the client
Destination Connection ID field with an unpredictable value. This populates the Destination Connection ID field with an unpredictable
MUST be at least 8 bytes in length. Until a packet is received from value. This Destination Connection ID MUST be at least 8 bytes in
the server, the client MUST use the same value unless it abandons the length. Until a packet is received from the server, the client MUST
connection attempt and starts a new one. The initial Destination use the same Destination Connection ID value on all packets in this
Connection ID is used to determine packet protection keys for Initial connection. This Destination Connection ID is used to determine
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 Len field to indicate the length. its choosing and sets the SCID Length field to indicate the length.
The first flight of 0-RTT packets use the same Destination and Source The first flight of 0-RTT packets use the same Destination Connection
Connection ID values as the client's first Initial. ID and Source Connection ID values as the client's first Initial
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 Destination Connection ID for subsequent packets, including any 0-RTT
subsequent 0-RTT packets. That means that a client might change the packets. This means that a client might have to change the
Destination Connection ID twice during connection establishment, once connection ID it sets in the Destination Connection ID field twice
in response to a Retry and once in response to the first Initial during connection establishment: once in response to a Retry, and
packet from the server. Once a client has received an Initial packet once in response to an Initial packet from the server. Once a client
from the server, it MUST discard any packet it receives with a has received a valid Initial packet from the server, it MUST discard
different Source Connection ID. any subsequent packet it receives with a different Source Connection
ID.
A client MUST only change the value it sends in the Destination A client MUST change the Destination Connection ID it uses for
Connection ID in response to the first packet of each type it sending packets in response to only the first received Initial or
receives from the server (Retry or Initial); a server MUST set its Retry packet. A server MUST set the Destination Connection ID it
value based on the Initial packet. Any additional changes are not uses for sending packets based on the first received Initial packet.
permitted; if subsequent packets of those types include a different Any further changes to the Destination Connection ID are only
Source Connection ID, they MUST be discarded. This avoids problems permitted if the values are taken from any received NEW_CONNECTION_ID
that might arise from stateless processing of multiple Initial frames; if subsequent Initial packets include a different Source
packets producing different connection IDs. Connection ID, they MUST be discarded. This avoids unpredictable
outcomes that might otherwise result from stateless processing of
multiple Initial packets with different Source Connection IDs.
The connection ID can change over the lifetime of a connection, The Destination Connection ID that an endpoint sends can change over
especially in response to connection migration (Section 9); see the lifetime of a connection, especially in response to connection
Section 5.1.1 for details. migration (Section 9); see Section 5.1.1 for details.
7.3. Transport Parameters 7.3. Authenticating Connection IDs
The choice each endpoint makes about connection IDs during the
handshake is authenticated by including all values in transport
parameters; see Section 7.4. This ensures that all connection IDs
used for the handshake are also authenticated by the cryptographic
handshake.
Each endpoint includes the value of the Source Connection ID field
from the first Initial packet it sent in the
initial_source_connection_id transport parameter; see Section 18.2.
A server includes the Destination Connection ID field from the first
Initial packet it received from the client in the
original_destination_connection_id transport parameter; if the server
sent a Retry packet this refers to the first Initial packet received
before sending the Retry packet. If it sends a Retry packet, a
server also includes the Source Connection ID field from the Retry
packet in the retry_source_connection_id transport parameter.
The values provided by a peer for these transport parameters MUST
match the values that an endpoint used in the Destination and Source
Connection ID fields of Initial packets that it sent. Including
connection ID values in transport parameters and verifying them
ensures that that an attacker cannot influence the choice of
connection ID for a successful connection by injecting packets
carrying attacker-chosen connection IDs during the handshake. An
endpoint MUST treat any of the following as a connection error of
type PROTOCOL_VIOLATION:
* absence of the initial_source_connection_id transport parameter
from either endpoint,
* absence of the original_destination_connection_id transport
parameter from the server,
* absence of the retry_source_connection_id transport parameter from
the server after receiving a Retry packet,
* presence of the retry_source_connection_id transport parameter
when no Retry packet was received, or
* a mismatch between values received from a peer in these transport
parameters and the value sent in the corresponding Destination or
Source Connection ID fields of Initial packets.
If a zero-length connection ID is selected, the corresponding
transport parameter is included with a zero-length value.
Figure 6 shows the connection IDs that are used in a complete
handshake. The exchange of Initial packets is shown, plus the later
exchange of 1-RTT packets that includes the connection ID established
during the handshake.
Client Server
Initial: DCID=S1, SCID=C1 ->
<- Initial: DCID=C1, SCID=S3
...
1-RTT: DCID=S3 ->
<- 1-RTT: DCID=C1
Figure 6: Use of Connection IDs in a Handshake
Figure 7 shows a similar handshake that includes a Retry packet.
Client Server
Initial: DCID=S1, SCID=C1 ->
<- Retry: DCID=C1, SCID=S2
Initial: DCID=S2, SCID=C1 ->
<- Initial: DCID=C1, SCID=S3
...
1-RTT: DCID=S3 ->
<- 1-RTT: DCID=C1
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
of the initial_source_connection_id transport parameter to "C1". In
Figure 7, the server sets original_destination_connection_id to "S1",
retry_source_connection_id to "S2", and initial_source_connection_id
to "S3". In Figure 6, the server sets
original_destination_connection_id to "S1",
initial_source_connection_id to "S3", and does not include
retry_source_connection_id. Each endpoint validates the transport
parameters set by their peer, including the client confirming that
retry_source_connection_id is absent if no Retry packet was
processed.
7.4. Transport Parameters
During connection establishment, both endpoints make authenticated During connection establishment, both endpoints make authenticated
declarations of their transport parameters. These declarations are declarations of their transport parameters. Endpoints are required
made unilaterally by each endpoint. Endpoints are required to comply to comply with the restrictions implied by these parameters; the
with the restrictions implied by these parameters; the description of description of each parameter includes rules for its handling.
each parameter includes rules for its handling.
Transport parameters are declarations that are made unilaterally by
each endpoint. Each endpoint can choose values for transport
parameters independent of the values chosen by its peer.
The encoding of the transport parameters is detailed in Section 18. The encoding of the transport parameters is detailed in Section 18.
QUIC includes the encoded transport parameters in the cryptographic QUIC includes the encoded transport parameters in the cryptographic
handshake. Once the handshake completes, the transport parameters handshake. Once the handshake completes, the transport parameters
declared by the peer are available. Each endpoint validates the declared by the peer are available. Each endpoint validates the
value provided by its peer. value provided by its peer.
Definitions for each of the defined transport parameters are included Definitions for each of the defined transport parameters are included
in Section 18.2. in Section 18.2.
An endpoint MUST treat receipt of a transport parameter with an An endpoint MUST treat receipt of a transport parameter with an
invalid value as a connection error of type invalid value as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
An endpoint MUST NOT send a parameter more than once in a given An endpoint MUST NOT send a parameter more than once in a given
transport parameters extension. An endpoint SHOULD treat receipt of transport parameters extension. An endpoint SHOULD treat receipt of
duplicate transport parameters as a connection error of type duplicate transport parameters as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
A server MUST include the original_connection_id transport parameter Endpoints use transport parameters to authenticate the negotiation of
(Section 18.2) if it sent a Retry packet to enable validation of the connection IDs during the handshake; see Section 7.3.
Retry, as described in Section 17.2.5.
7.3.1. Values of Transport Parameters for 0-RTT 7.4.1. Values of Transport Parameters for 0-RTT
Both endpoints store the value of the server transport parameters Both endpoints store the value of the server transport parameters
from a connection and apply them to any 0-RTT packets that are sent from a connection and apply them to any 0-RTT packets that are sent
in subsequent connections to that peer, except for transport in subsequent connections to that peer, except for transport
parameters that are explicitly excluded. Remembered transport parameters that are explicitly excluded. Remembered transport
parameters apply to the new connection until the handshake completes parameters apply to the new connection until the handshake completes
and the client starts sending 1-RTT packets. Once the handshake and the client starts sending 1-RTT packets. Once the handshake
completes, the client uses the transport parameters established in completes, the client uses the transport parameters established in
the handshake. the handshake.
The definition of new transport parameters (Section 7.3.2) MUST The definition of new transport parameters (Section 7.4.2) MUST
specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A
client need not store a transport parameter it cannot process. client need not store a transport parameter it cannot process.
A client MUST NOT use remembered values for the following parameters: A client MUST NOT use remembered values for the following parameters:
original_connection_id, preferred_address, stateless_reset_token, ack_delay_exponent, max_ack_delay, initial_source_connection_id,
ack_delay_exponent and active_connection_id_limit. The client MUST original_destination_connection_id, preferred_address,
use the server's new values in the handshake instead, and absent new retry_source_connection_id, and stateless_reset_token. The client
values from the server, the default value. MUST use the server's new values in the handshake instead, and absent
new values from the server, the default value.
A client that attempts to send 0-RTT data MUST remember all other A client that attempts to send 0-RTT data MUST remember all other
transport parameters used by the server. The server can remember transport parameters used by the server. The server can remember
these transport parameters, or store an integrity-protected copy of these transport parameters, or store an integrity-protected copy of
the values in the ticket and recover the information when accepting the values in the ticket and recover the information when accepting
0-RTT data. A server uses the transport parameters in determining 0-RTT data. A server uses the transport parameters in determining
whether to accept 0-RTT data. whether to accept 0-RTT data.
If 0-RTT data is accepted by the server, the server MUST NOT reduce If 0-RTT data is accepted by the server, the server MUST NOT reduce
any limits or alter any values that might be violated by the client any limits or alter any values that might be violated by the client
with its 0-RTT data. In particular, a server that accepts 0-RTT data with its 0-RTT data. In particular, a server that accepts 0-RTT data
MUST NOT set values for the following parameters (Section 18.2) that MUST NOT set values for the following parameters (Section 18.2) that
are smaller than the remembered value of the parameters. are smaller than the remembered value of the parameters.
* active_connection_id_limit
* initial_max_data * initial_max_data
* initial_max_stream_data_bidi_local * initial_max_stream_data_bidi_local
* initial_max_stream_data_bidi_remote * initial_max_stream_data_bidi_remote
* initial_max_stream_data_uni * initial_max_stream_data_uni
* initial_max_streams_bidi * initial_max_streams_bidi
skipping to change at page 39, line 41 skipping to change at page 45, line 12
remembered transport parameters; importantly, it MUST NOT use updated remembered transport parameters; importantly, it MUST NOT use updated
values that it learns from the server's updated transport parameters values that it learns from the server's updated transport parameters
or from frames received in 1-RTT packets. Updated values of or from frames received in 1-RTT packets. Updated values of
transport parameters from the handshake apply only to 1-RTT packets. transport parameters from the handshake apply only to 1-RTT packets.
For instance, flow control limits from remembered transport For instance, flow control limits from remembered transport
parameters apply to all 0-RTT packets even if those values are parameters apply to all 0-RTT packets even if those values are
increased by the handshake or by frames sent in 1-RTT packets. A increased by the handshake or by frames sent in 1-RTT packets. A
server MAY treat use of updated transport parameters in 0-RTT as a server MAY treat use of updated transport parameters in 0-RTT as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
7.3.2. New Transport Parameters 7.4.2. New Transport Parameters
New transport parameters can be used to negotiate new protocol New transport parameters can be used to negotiate new protocol
behavior. An endpoint MUST ignore transport parameters that it does behavior. An endpoint MUST ignore transport parameters that it does
not support. Absence of a transport parameter therefore disables any not support. Absence of a transport parameter therefore disables any
optional protocol feature that is negotiated using the parameter. As optional protocol feature that is negotiated using the parameter. As
described in Section 18.1, some identifiers are reserved in order to described in Section 18.1, some identifiers are reserved in order to
exercise this requirement. exercise this requirement.
New transport parameters can be registered according to the rules in New transport parameters can be registered according to the rules in
Section 22.2. Section 22.2.
7.4. 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 CRYPTO frames out of order. 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
skipping to change at page 41, line 17 skipping to change at page 46, line 32
Connection establishment implicitly provides address validation for Connection establishment implicitly provides address validation for
both endpoints. In particular, receipt of a packet protected with both endpoints. In particular, receipt of a packet protected with
Handshake keys confirms that the client received the Initial packet Handshake keys confirms that the client received the Initial packet
from the server. Once the server has successfully processed a from the server. Once the server has successfully processed a
Handshake packet from the client, it can consider the client address Handshake packet from the client, it can consider the client address
to have been validated. to have been validated.
Prior to validating the client address, servers MUST NOT send more Prior to validating the client address, servers MUST NOT send more
than three times as many bytes as the number of bytes they have than three times as many bytes as the number of bytes they have
received. This limits the magnitude of any amplification attack that received. This limits the magnitude of any amplification attack that
can be mounted using spoofed source addresses. In determining this can be mounted using spoofed source addresses. For the purposes of
limit, servers only count the size of successfully processed packets. avoiding amplification prior to address validation, servers MUST
count all of the payload bytes received in datagrams that are
uniquely attributed to a single connection. This includes datagrams
that contain packets that are successfully processed and datagrams
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. Sending padded datagrams ensures that
the server is not overly constrained by the amplification the server is not overly constrained by the amplification
restriction. restriction.
Packet loss, in particular loss of a Handshake packet from the Loss of an Initial or Handshake packet from the server can cause a
server, can cause a situation in which the server cannot send when deadlock if the client does not send additional Initial or Handshake
the client has no data to send and the anti-amplification limit is packets. A deadlock could occur when the server reaches its anti-
reached. In order to avoid this causing a handshake deadlock, amplification limit and the client has received acknowledgements for
clients MUST send a packet upon a probe timeout, as described in all the data it has sent. In this case, when the client has no
[QUIC-RECOVERY]. If the client has no data to retransmit and does reason to send additional packets, the server will be unable to send
not have Handshake keys, it MUST send an Initial packet in a UDP more data because it has not validated the client's address. To
datagram of at least 1200 bytes. If the client has Handshake keys, prevent this deadlock, clients MUST send a packet on a probe timeout
it SHOULD send a Handshake packet. (PTO, see Section 5.3 of [QUIC-RECOVERY]). Specifically, the client
MUST send an Initial packet in a UDP datagram of at least 1200 bytes
if it does not have Handshake keys, and otherwise send a 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
by the congestion controller. Clients are only constrained by the by the congestion controller. Clients are only constrained by the
congestion controller. congestion controller.
8.1.1. Token Construction 8.1.1. Token Construction
A token sent in a NEW_TOKEN frames or a Retry packet MUST be A token sent in a NEW_TOKEN frames or a Retry packet MUST be
constructed in a way that allows the server to identity how it was constructed in a way that allows the server to identify how it was
provided to a client. These tokens are carried in the same field, provided to a client. These tokens are carried in the same field,
but require different handling from servers. but require different handling from servers.
8.1.2. Address Validation using Retry Packets 8.1.2. Address Validation using Retry Packets
Upon receiving the client's Initial packet, the server can request Upon receiving the client's Initial packet, the server can request
address validation by sending a Retry packet (Section 17.2.5) address validation by sending a Retry packet (Section 17.2.5)
containing a token. This token MUST be repeated by the client in all containing a token. This token MUST be repeated by the client in all
Initial packets it sends for that connection after it receives the Initial packets it sends for that connection after it receives the
Retry packet. In response to processing an Initial containing a Retry packet. In response to processing an Initial containing a
skipping to change at page 42, line 30 skipping to change at page 47, line 46
proceed. proceed.
As long as it is not possible for an attacker to generate a valid As long as it is not possible for an attacker to generate a valid
token for its own address (see Section 8.1.4) and the client is able token for its own address (see Section 8.1.4) and the client is able
to return that token, it proves to the server that it received the to return that token, it proves to the server that it received the
token. token.
A server can also use a Retry packet to defer the state and A server can also use a Retry packet to defer the state and
processing costs of connection establishment. Requiring the server processing costs of connection establishment. Requiring the server
to provide a different connection ID, along with the to provide a different connection ID, along with the
original_connection_id transport parameter defined in Section 18.2, original_destination_connection_id transport parameter defined in
forces the server to demonstrate that it, or an entity it cooperates Section 18.2, forces the server to demonstrate that it, or an entity
with, received the original Initial packet from the client. it cooperates with, received the original Initial packet from the
Providing a different connection ID also grants a server some control client. Providing a different connection ID also grants a server
over how subsequent packets are routed. This can be used to direct some control over how subsequent packets are routed. This can be
connections to a different server instance. used to direct connections to a different server instance.
If a server receives a client Initial that can be unprotected but If a server receives a client Initial that can be unprotected but
contains an invalid Retry token, it knows the client will not accept contains an invalid Retry token, it knows the client will not accept
another Retry token. The server can discard such a packet and allow another Retry token. The server can discard such a packet and allow
the client to time out to detect handshake failure, but that could the client to time out to detect handshake failure, but that could
impose a significant latency penalty on the client. A server MAY impose a significant latency penalty on the client. Instead, the
proceed with the connection without verifying the token, though the server SHOULD immediately close (Section 10.3) the connection with an
server MUST NOT consider the client address validated. If a server INVALID_TOKEN error. Note that a server has not established any
chooses not to proceed with the handshake, it SHOULD immediately state for the connection at this point and so does not enter the
close (Section 10.3) the connection with an INVALID_TOKEN error. closing period.
Note that a server has not established any state for the connection
at this point and so does not enter the closing period.
A flow showing the use of a Retry packet is shown in Figure 5. A flow showing the use of a Retry packet is shown in Figure 8.
Client Server Client Server
Initial[0]: CRYPTO[CH] -> Initial[0]: CRYPTO[CH] ->
<- Retry+Token <- Retry+Token
Initial+Token[1]: CRYPTO[CH] -> Initial+Token[1]: CRYPTO[CH] ->
Initial[0]: CRYPTO[SH] ACK[1] Initial[0]: CRYPTO[SH] ACK[1]
Handshake[0]: CRYPTO[EE, CERT, CV, FIN] Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
<- 1-RTT[0]: STREAM[1, "..."] <- 1-RTT[0]: STREAM[1, "..."]
Figure 5: Example Handshake with Retry Figure 8: Example Handshake with Retry
8.1.3. Address Validation for Future Connections 8.1.3. Address Validation for Future Connections
A server MAY provide clients with an address validation token during A server MAY provide clients with an address validation token during
one connection that can be used on a subsequent connection. Address one connection that can be used on a subsequent connection. Address
validation is especially important with 0-RTT because a server validation is especially important with 0-RTT because a server
potentially sends a significant amount of data to a client in potentially sends a significant amount of data to a client in
response to 0-RTT data. response to 0-RTT data.
The server uses the NEW_TOKEN frame Section 19.7 to provide the The server uses the NEW_TOKEN frame Section 19.7 to provide the
skipping to change at page 43, line 45 skipping to change at page 49, line 14
Unlike the token that is created for a Retry packet, which is used Unlike the token that is created for a Retry packet, which is used
immediately, the token sent in the NEW_TOKEN frame might be used immediately, the token sent in the NEW_TOKEN frame might be used
after some period of time has passed. Thus, a token SHOULD have an after some period of time has passed. Thus, a token SHOULD have an
expiration time, which could be either an explicit expiration time or expiration time, which could be either an explicit expiration time or
an issued timestamp that can be used to dynamically calculate the an issued timestamp that can be used to dynamically calculate the
expiration time. A server can store the expiration time or include expiration time. A server can store the expiration time or include
it in an encrypted form in the token. it in an encrypted form in the token.
A token issued with NEW_TOKEN MUST NOT include information that would A token issued with NEW_TOKEN MUST NOT include information that would
allow values to be linked by an on-path observer to the connection on allow values to be linked by an observer to the connection on which
which it was issued, unless the values are encrypted. For example, it was issued, unless the values are encrypted. For example, it
it cannot include the previous connection ID or addressing cannot include the previous connection ID or addressing information.
information. A server MUST ensure that every NEW_TOKEN frame it A server MUST ensure that every NEW_TOKEN frame it sends is unique
sends is unique across all clients, with the exception of those sent across all clients, with the exception of those sent to repair losses
to repair losses of previously sent NEW_TOKEN frames. Information of previously sent NEW_TOKEN frames. Information that allows the
that allows the server to distinguish between tokens from Retry and server to distinguish between tokens from Retry and NEW_TOKEN MAY be
NEW_TOKEN MAY be accessible to entities other than the server. accessible to entities other than the server.
It is unlikely that the client port number is the same on two It is unlikely that the client port number is the same on two
different connections; validating the port is therefore unlikely to different connections; validating the port is therefore unlikely to
be successful. be successful.
A token received in a NEW_TOKEN frame is applicable to any server A token received in a NEW_TOKEN frame is applicable to any server
that the connection is considered authoritative for (e.g., server that the connection is considered authoritative for (e.g., server
names included in the certificate). When connecting to a server for names included in the certificate). When connecting to a server for
which the client retains an applicable and unused token, it SHOULD which the client retains an applicable and unused token, it SHOULD
include that token in the Token field of its Initial packet. include that token in the Token field of its Initial packet.
skipping to change at page 45, line 29 skipping to change at page 50, line 49
Clients MAY use tokens obtained on one connection for any connection Clients MAY use tokens obtained on one connection for any connection
attempt using the same version. When selecting a token to use, attempt using the same version. When selecting a token to use,
clients do not need to consider other properties of the connection clients do not need to consider other properties of the connection
that is being attempted, including the choice of possible application that is being attempted, including the choice of possible application
protocols, session tickets, or other connection properties. protocols, session tickets, or other connection properties.
Attackers could replay tokens to use servers as amplifiers in DDoS Attackers could replay tokens to use servers as amplifiers in DDoS
attacks. To protect against such attacks, servers SHOULD ensure that attacks. To protect against such attacks, servers SHOULD ensure that
tokens sent in Retry packets are only accepted for a short time. tokens sent in Retry packets are only accepted for a short time.
Tokens that are provided in NEW_TOKEN frames (see Section 19.7) need Tokens that are provided in NEW_TOKEN frames (Section 19.7) need to
to be valid for longer, but SHOULD NOT be accepted multiple times in be valid for longer, but SHOULD NOT be accepted multiple times in a
a short period. Servers are encouraged to allow tokens to be used short period. Servers are encouraged to allow tokens to be used only
only once, if possible. once, if possible.
8.1.4. Address Validation Token Integrity 8.1.4. Address Validation Token Integrity
An address validation token MUST be difficult to guess. Including a An address validation token MUST be difficult to guess. Including a
large enough random value in the token would be sufficient, but this large enough random value in the token would be sufficient, but this
depends on the server remembering the value it sends to clients. depends on the server remembering the value it sends to clients.
A token-based scheme allows the server to offload any state A token-based scheme allows the server to offload any state
associated with validation to the client. For this design to work, associated with validation to the client. For this design to work,
the token MUST be covered by integrity protection against the token MUST be covered by integrity protection against
modification or falsification by clients. Without integrity modification or falsification by clients. Without integrity
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. A because the server that generates the token also consumes it. Tokens
token could include information about the claimed client address (IP sent in Retry packets SHOULD include information that allows the
and port), a timestamp, and any other supplementary information the server to verify that the source IP address and port in client
server will need to validate the token in the future. packets remains constant.
Tokens sent in NEW_TOKEN frames MUST include information that allows
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
deciding not to send a Retry packet, even if the client address has
changed. If the client IP address has changed, the server MUST
adhere to the anti-amplification limits found in Section 8.1. Note
that in the presence of NAT, this requirement might be insufficient
to protect other hosts that share the NAT from amplification attack.
Servers MUST ensure that replay of tokens is prevented or limited.
For instance, servers might limit the time over which a token is
accepted. Tokens provided in NEW_TOKEN frames might need to allow
longer validity periods. Tokens MAY include additional information
about clients to further narrow applicability or reuse.
8.2. Path Validation 8.2. Path Validation
Path validation is used during connection migration (see Section 9 Path validation is used during connection migration (see Section 9
and Section 9.6) by the migrating endpoint to verify reachability of and Section 9.6) by the migrating endpoint to verify reachability of
a peer from a new local address. In path validation, endpoints test a peer from a new local address. In path validation, endpoints test
reachability between a specific local address and a specific peer reachability between a specific local address and a specific peer
address, where an address is the two-tuple of IP address and port. address, where an address is the two-tuple of IP address and port.
Path validation tests that packets (PATH_CHALLENGE) can be both sent Path validation tests that packets (PATH_CHALLENGE) can be both sent
skipping to change at page 47, line 18 skipping to change at page 53, line 6
frame so that it can associate the peer's response with the frame so that it can associate the peer's response with the
corresponding PATH_CHALLENGE. corresponding PATH_CHALLENGE.
8.4. Path Validation Responses 8.4. Path Validation Responses
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond On receiving a PATH_CHALLENGE frame, an endpoint MUST respond
immediately by echoing the data contained in the PATH_CHALLENGE frame immediately by echoing the data contained in the PATH_CHALLENGE frame
in a PATH_RESPONSE frame. in a PATH_RESPONSE frame.
An endpoint MUST NOT send more than one PATH_RESPONSE frame in An endpoint MUST NOT send more than one PATH_RESPONSE frame in
response to one PATH_CHALLENGE frame (see Section 13.3). The peer is response to one PATH_CHALLENGE frame; see Section 13.3. The peer is
expected to send more PATH_CHALLENGE frames as necessary to evoke expected to send more PATH_CHALLENGE frames as necessary to evoke
additional PATH_RESPONSE frames. additional PATH_RESPONSE frames.
8.5. Successful Path Validation 8.5. Successful Path Validation
A new address is considered valid when a PATH_RESPONSE frame is A new address is considered valid when a PATH_RESPONSE frame is
received that contains the data that was sent in a previous received that contains the data that was sent in a previous
PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing
a PATH_CHALLENGE frame is not adequate validation, since the a PATH_CHALLENGE frame is not adequate validation, since the
acknowledgment can be spoofed by a malicious peer. acknowledgment can be spoofed by a malicious peer.
skipping to change at page 48, line 30 skipping to change at page 54, line 19
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 An endpoint also MUST NOT send packets from a different local
address, actively initiating migration, if the peer sent the address, actively initiating migration, if the peer sent the
"disable_active_migration" transport parameter during the handshake. disable_active_migration transport parameter during the handshake.
An endpoint which has sent this transport parameter, but detects that An endpoint which has sent this transport parameter, but detects that
a peer has nonetheless migrated to a different network MUST either a peer has nonetheless migrated to a different network MUST either
drop the incoming packets on that path without generating a stateless drop the incoming packets on that path without generating a stateless
reset or proceed with path validation and allow the peer to migrate. reset or proceed with path validation and allow the peer to migrate.
Generating a stateless reset or closing the connection would allow Generating a stateless reset or closing the connection would allow
third parties in the network to cause connections to close by third parties in the network to cause connections to close by
spoofing or otherwise manipulating observed traffic. 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
skipping to change at page 50, line 10 skipping to change at page 56, line 10
controller, as described in Section 9.4. controller, as described in Section 9.4.
The new path might not have the same ECN capability. Therefore, the The new path might not have the same ECN capability. Therefore, the
endpoint verifies ECN capability as described in Section 13.4. endpoint verifies ECN capability as described in Section 13.4.
Receiving acknowledgments for data sent on the new path serves as Receiving acknowledgments for data sent on the new path serves as
proof of the peer's reachability from the new address. Note that proof of the peer's reachability from the new address. Note that
since acknowledgments may be received on any path, return since acknowledgments may be received on any path, return
reachability on the new path is not established. To establish return reachability on the new path is not established. To establish return
reachability on the new path, an endpoint MAY concurrently initiate reachability on the new path, an endpoint MAY concurrently initiate
path validation Section 8.2 on the new path. path validation Section 8.2 on the new path or it MAY choose to wait
for the peer to send the next non-probing frame to its new address.
9.3. Responding to Connection Migration 9.3. Responding to Connection Migration
Receiving a packet from a new peer address containing a non-probing Receiving a packet from a new peer address containing a non-probing
frame indicates that the peer has migrated to that address. frame indicates that the peer has migrated to that address.
In response to such a packet, an endpoint MUST start sending In response to such a packet, an endpoint MUST start sending
subsequent packets to the new peer address and MUST initiate path subsequent packets to the new peer address and MUST initiate path
validation (Section 8.2) to verify the peer's ownership of the validation (Section 8.2) to verify the peer's ownership of the
unvalidated address. unvalidated address.
skipping to change at page 51, line 15 skipping to change at page 57, line 15
As described in Section 9.3, an endpoint is required to validate a As described in Section 9.3, an endpoint is required to validate a
peer's new address to confirm the peer's possession of the new peer's new address to confirm the peer's possession of the new
address. Until a peer's address is deemed valid, an endpoint MUST address. Until a peer's address is deemed valid, an endpoint MUST
limit the rate at which it sends data to this address. The endpoint limit the rate at which it sends data to this address. The endpoint
MUST NOT send more than a minimum congestion window's worth of data MUST NOT send more than a minimum congestion window's worth of data
per estimated round-trip time (kMinimumWindow, as defined in per estimated round-trip time (kMinimumWindow, as defined in
[QUIC-RECOVERY]). In the absence of this limit, an endpoint risks [QUIC-RECOVERY]). In the absence of this limit, an endpoint risks
being used for a denial of service attack against an unsuspecting being used for a denial of service attack against an unsuspecting
victim. Note that since the endpoint will not have any round-trip victim. Note that since the endpoint will not have any round-trip
time measurements to this address, the estimate SHOULD be the default time measurements to this address, the estimate SHOULD be the default
initial value (see [QUIC-RECOVERY]). initial value; see [QUIC-RECOVERY].
If an endpoint skips validation of a peer address as described in If an endpoint skips validation of a peer address as described in
Section 9.3, it does not need to limit its sending rate. Section 9.3, it does not need to limit its sending rate.
9.3.2. On-Path Address Spoofing 9.3.2. On-Path Address Spoofing
An on-path attacker could cause a spurious connection migration by An on-path attacker could cause a spurious connection migration by
copying and forwarding a packet with a spoofed address such that it copying and forwarding a packet with a spoofed address such that it
arrives before the original packet. The packet with the spoofed arrives before the original packet. The packet with the spoofed
address will be seen to come from a migrating connection, and the address will be seen to come from a migrating connection, and the
skipping to change at page 54, line 19 skipping to change at page 60, line 19
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
to ensure that connection IDs they provide cannot be linked by any to ensure that connection IDs they provide cannot be linked by any
other entity. other entity.
At any time, endpoints MAY change the Destination Connection ID they At any time, endpoints MAY change the Destination Connection ID they
send to a value that has not been used on another path. send to a value that has not been used on another path.
An endpoint MUST use a new connection ID if it initiates connection An endpoint MUST NOT reuse a connection ID when sending from more
migration as described in Section 9.2 or probes a new network path as than one local address, for example when initiating connection
described in Section 9.1. An endpoint MUST use a new connection ID migration as described in Section 9.2 or when probing a new network
in response to a change in the address of a peer if the packet with path as described in Section 9.1.
the new peer address uses an active connection ID that has not been
previously used by the peer. Similarly, an endpoint MUST NOT reuse a connection ID when sending to
more than one destination address. Due to network changes outside
the control of its peer, an endpoint might receive packets from a new
source address with the same destination connection ID, in which case
it MAY continue to use the current connection ID with the new remote
address while still sending from the same local address.
These requirements regarding connection ID reuse apply only to the
sending of packets, as unintentional changes in path without a change
in connection ID are possible. For example, after a period of
network inactivity, NAT rebinding might cause packets to be sent on a
new path when the client resumes sending. An endpoint responds to
such an event as described in Section 9.3.
Using different connection IDs for packets sent in both directions on Using different connection IDs for packets sent in both directions on
each new network path eliminates the use of the connection ID for each new network path eliminates the use of the connection ID for
linking packets from the same connection across different network linking packets from the same connection across different network
paths. Header protection ensures that packet numbers cannot be used paths. Header protection ensures that packet numbers cannot be used
to correlate activity. This does not prevent other properties of to correlate activity. This does not prevent other properties of
packets, such as timing and size, from being used to correlate packets, such as timing and size, from being used to correlate
activity. activity.
Unintentional changes in path without a change in connection ID are An endpoint SHOULD NOT initiate migration with a peer that has
possible. For example, after a period of network inactivity, NAT requested a zero-length connection ID, because traffic over the new
rebinding might cause packets to be sent on a new path when the path might be trivially linkable to traffic over the old one. If the
client resumes sending. server is able to route packets with a zero-length connection ID to
the right connection, it means that the server is using other
information to demultiplex packets. For example, a server might
provide a unique address to every client, for instance using HTTP
alternative services [ALTSVC]. Information that might allow correct
routing of packets across multiple network paths will also allow
activity on those paths to be linked by entities other than the peer.
A client might wish to reduce linkability by employing a new A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period connection ID and source UDP port when sending traffic after a period
of inactivity. Changing the UDP port from which it sends packets at of inactivity. Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection the same time might cause the packet to appear as a connection
migration. This ensures that the mechanisms that support migration migration. This ensures that the mechanisms that support migration
are exercised even for clients that don't experience NAT rebindings are exercised even for clients that don't experience NAT rebindings
or genuine migrations. Changing port number can cause a peer to or genuine migrations. Changing port number can cause a peer to
reset its congestion state (see Section 9.4), so the port SHOULD only reset its congestion state (see Section 9.4), so the port SHOULD only
be changed infrequently. be changed infrequently.
skipping to change at page 55, line 33 skipping to change at page 62, line 5
9.6.1. Communicating a Preferred Address 9.6.1. Communicating a Preferred Address
A server conveys a preferred address by including the A server conveys a preferred address by including the
preferred_address transport parameter in the TLS handshake. preferred_address transport parameter in the TLS handshake.
Servers MAY communicate a preferred address of each address family Servers MAY communicate a preferred address of each address family
(IPv4 and IPv6) to allow clients to pick the one most suited to their (IPv4 and IPv6) to allow clients to pick the one most suited to their
network attachment. network attachment.
Once the handshake is finished, the client SHOULD select one of the Once the handshake is confirmed, the client SHOULD select one of the
two server's preferred addresses and initiate path validation (see two server's preferred addresses and initiate path validation (see
Section 8.2) of that address using the connection ID provided in the Section 8.2) of that address using any previously unused active
preferred_address transport parameter. connection ID, taken from either the preferred_address transport
parameter or a NEW_CONNECTION_ID frame.
If path validation succeeds, the client SHOULD immediately begin If path validation succeeds, the client SHOULD immediately begin
sending all future packets to the new server address using the new sending all future packets to the new server address using the new
connection ID and discontinue use of the old server address. If path connection ID and discontinue use of the old server address. If path
validation fails, the client MUST continue sending all future packets validation fails, the client MUST continue sending all future packets
to the server's original IP address. to the server's original IP address.
9.6.2. Responding to Connection Migration 9.6.2. Responding to Connection Migration
A server might receive a packet addressed to its preferred IP address A server might receive a packet addressed to its preferred IP address
skipping to change at page 56, line 26 skipping to change at page 62, line 38
preferred address. This helps to guard against spurious migration preferred address. This helps to guard against spurious migration
initiated by an attacker. initiated by an attacker.
Once the server has completed its path validation and has received a Once the server has completed its path validation and has received a
non-probing packet with a new largest packet number on its preferred non-probing packet with a new largest packet number on its preferred
address, the server begins sending non-probing packets to the client address, the server begins sending non-probing packets to the client
exclusively from its preferred IP address. It SHOULD drop packets exclusively from its preferred IP address. It SHOULD drop packets
for this connection received on the old IP address, but MAY continue for this connection received on the old IP address, but MAY continue
to process delayed packets. to process delayed packets.
The addresses that a server provides in the preferred_address
transport parameter are only valid for the connection in which they
are provided. A client MUST NOT use these for other connections,
including connections that are resumed from the current connection.
9.6.3. Interaction of Client Migration and Preferred Address 9.6.3. Interaction of Client Migration and Preferred Address
A client might need to perform a connection migration before it has A client might need to perform a connection migration before it has
migrated to the server's preferred address. In this case, the client migrated to the server's preferred address. In this case, the client
SHOULD perform path validation to both the original and preferred SHOULD perform path validation to both the original and preferred
server address from the client's new address concurrently. server address from the client's new address concurrently.
If path validation of the server's preferred address succeeds, the If path validation of the server's preferred address succeeds, the
client MUST abandon validation of the original address and migrate to client MUST abandon validation of the original address and migrate to
using the server's preferred address. If path validation of the using the server's preferred address. If path validation of the
skipping to change at page 57, line 8 skipping to change at page 63, line 23
server's preferred address. server's preferred address.
Servers SHOULD initiate path validation to the client's new address Servers SHOULD initiate path validation to the client's new address
upon receiving a probe packet from a different address. Servers MUST upon receiving a probe packet from a different address. Servers MUST
NOT send more than a minimum congestion window's worth of non-probing NOT send more than a minimum congestion window's worth of non-probing
packets to the new address before path validation is complete. packets to the new address before path validation is complete.
A client that migrates to a new address SHOULD use a preferred A client that migrates to a new address SHOULD use a preferred
address from the same address family for the server. address from the same address family for the server.
The connection ID provided in the preferred_address transport
parameter is not specific to the addresses that are provided. This
connection ID is provided to ensure that the client has a connection
ID available for migration, but the client MAY use this connection ID
on any path.
9.7. Use of IPv6 Flow-Label and Migration 9.7. Use of IPv6 Flow-Label and Migration
Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label
in compliance with [RFC6437], unless the local API does not allow in compliance with [RFC6437], unless the local API does not allow
setting IPv6 flow labels. setting IPv6 flow labels.
The IPv6 flow label SHOULD be a pseudo-random function of the source The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the and destination addresses, source and destination UDP ports, and the
destination CID. The flow label generation MUST be designed to destination CID. The flow label generation MUST be designed to
minimize the chances of linkability with a previously used flow minimize the chances of linkability with a previously used flow
label, as this would enable correlating activity on multiple paths label, as this would enable correlating activity on multiple paths;
(see Section 9.5). see Section 9.5.
A possible implementation is to compute the flow label as a A possible implementation is to compute the flow label as a
cryptographic hash function of the source and destination addresses, cryptographic hash function of the source and destination addresses,
source and destination UDP ports, destination CID, and a local source and destination UDP ports, destination CID, and a local
secret. secret.
10. Connection Termination 10. Connection Termination
An established QUIC connection can be terminated in one of three An established QUIC connection can be terminated in one of three
ways: ways:
* idle timeout (Section 10.2) * idle timeout (Section 10.2)
* immediate close (Section 10.3) * immediate close (Section 10.3)
* stateless reset (Section 10.4) * stateless reset (Section 10.4)
An endpoint MAY discard connection state if it does not have a An endpoint MAY discard connection state if it does not have a
validated path on which it can send packets (see Section 8.2). validated path on which it can send packets; see Section 8.2.
10.1. Closing and Draining Connection States 10.1. Closing and Draining Connection States
The closing and draining connection states exist to ensure that The closing and draining connection states exist to ensure that
connections close cleanly and that delayed or reordered packets are connections close cleanly and that delayed or reordered packets are
properly discarded. These states SHOULD persist for at least three properly discarded. These states SHOULD persist for at least three
times the current Probe Timeout (PTO) interval as defined in times the current Probe Timeout (PTO) interval as defined in
[QUIC-RECOVERY]. [QUIC-RECOVERY].
An endpoint enters a closing period after initiating an immediate An endpoint enters a closing period after initiating an immediate
close (Section 10.3). While closing, an endpoint MUST NOT send close; Section 10.3. While closing, an endpoint MUST NOT send
packets unless they contain a CONNECTION_CLOSE frame (see packets unless they contain a CONNECTION_CLOSE frame; see
Section 10.3 for details). An endpoint retains only enough Section 10.3 for details. An endpoint retains only enough
information to generate a packet containing a CONNECTION_CLOSE frame information to generate a packet containing a CONNECTION_CLOSE frame
and to identify packets as belonging to the connection. The and to identify packets as belonging to the connection. The
endpoint's selected connection ID and the QUIC version are sufficient endpoint's selected connection ID and the QUIC version are sufficient
information to identify packets for a closing connection; an endpoint information to identify packets for a closing connection; an endpoint
can discard all other connection state. An endpoint MAY retain can discard all other connection state. An endpoint MAY retain
packet protection keys for incoming packets to allow it to read and packet protection keys for incoming packets to allow it to read and
process a CONNECTION_CLOSE frame. process a CONNECTION_CLOSE frame.
The draining state is entered once an endpoint receives a signal that The draining state is entered once an endpoint receives a signal that
its peer is closing or draining. While otherwise identical to the its peer is closing or draining. While otherwise identical to the
skipping to change at page 58, line 47 skipping to change at page 65, line 21
send a stateless reset in response to any further incoming packets. send a stateless reset in response to any further incoming packets.
The draining and closing periods do not apply when a stateless reset The draining and closing periods do not apply when a stateless reset
(Section 10.4) is sent. (Section 10.4) is sent.
An endpoint is not expected to handle key updates when it is closing An endpoint is not expected to handle key updates when it is closing
or draining. A key update might prevent the endpoint from moving or draining. A key update might prevent the endpoint from moving
from the closing state to draining, but it otherwise has no impact. from the closing state to draining, but it otherwise has no impact.
While in the closing period, an endpoint could receive packets from a While in the closing period, an endpoint could receive packets from a
new source address, indicating a connection migration (Section 9). new source address, indicating a connection migration; Section 9. An
An endpoint in the closing state MUST strictly limit the number of endpoint in the closing state MUST strictly limit the number of
packets it sends to this new address until the address is validated packets it sends to this new address until the address is validated;
(see Section 8.2). A server in the closing state MAY instead choose see Section 8.2. A server in the closing state MAY instead choose to
to discard packets received from a new source address. discard packets received from a new source address.
10.2. Idle Timeout 10.2. Idle Timeout
If the idle timeout is enabled by either peer, a connection is If a max_idle_timeout is specified by either peer in its transport
silently closed and its state is discarded when it remains idle for parameters (Section 18.2), the connection is silently closed and its
longer than the minimum of the max_idle_timeouts (see Section 18.2) state is discarded when it remains idle for longer than the minimum
and three times the current Probe Timeout (PTO). of both peers max_idle_timeout values and three times the current
Probe Timeout (PTO).
Each endpoint advertises a max_idle_timeout, but the effective value Each endpoint advertises a max_idle_timeout, but the effective value
at an endpoint is computed as the minimum of the two advertised at an endpoint is computed as the minimum of the two advertised
values. By announcing a max_idle_timeout, an endpoint commits to values. By announcing a max_idle_timeout, an endpoint commits to
initiating an immediate close (Section 10.3) if it abandons the initiating an immediate close (Section 10.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. The idle timer is also received and processed successfully. An endpoint also restarts its
restarted when sending an ack-eliciting packet (see [QUIC-RECOVERY]), idle timer when sending an ack-eliciting packet if no other ack-
but only if no other ack-eliciting packets have been sent since last eliciting packets have been sent since last receiving and processing
receiving a packet. Restarting when sending packets ensures that a packet. Restarting this timer when sending a packet ensures that
connections do not prematurely time out when initiating new activity. connections are not closed after new activity is initiated.
An endpoint might need to send packets to avoid an idle timeout if it
is unable to send application data due to being blocked on flow
control limits; see Section 4.
An endpoint that sends packets near the end of the idle timeout An endpoint might need to send ack-eliciting packets to avoid an idle
period risks having those packets discarded if its peer enters the timeout if it is expecting response data, but does not have or is
draining state before the packets arrive. If a peer could time out unable to send application data.
within a Probe Timeout (PTO; see Section 6.6 of [QUIC-RECOVERY]), it
is advisable to test for liveness before sending any data that cannot An endpoint that sends packets close to the effective timeout risks
be retried safely. Note that it is likely that only applications or having them be discarded at the peer, since the peer might enter its
application protocols will know what information can be retried. 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.6 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.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 60, line 23 skipping to change at page 67, line 6
closing connection, endpoints MAY send the exact same packet. closing connection, endpoints MAY send the exact same packet.
Note: Allowing retransmission of a closing packet contradicts other Note: Allowing retransmission of a closing packet contradicts other
advice in this document that recommends the creation of new packet advice in this document that recommends the creation of new packet
numbers for every packet. Sending new packet numbers is primarily numbers for every packet. Sending new packet numbers is primarily
of advantage to loss recovery and congestion control, which are of advantage to loss recovery and congestion control, which are
not expected to be relevant for a closed connection. not expected to be relevant for a closed connection.
Retransmitting the final packet requires less state. Retransmitting the final packet requires less state.
New packets from unverified addresses could be used to create an New packets from unverified addresses could be used to create an
amplification attack (see Section 8). To avoid this, endpoints MUST amplification attack; see Section 8. To avoid this, endpoints MUST
either limit transmission of CONNECTION_CLOSE frames to validated either limit transmission of CONNECTION_CLOSE frames to validated
addresses or drop packets without response if the response would be addresses or drop packets without response if the response would be
more than three times larger than the received packet. more than three times larger than the received packet.
After receiving a CONNECTION_CLOSE frame, endpoints enter the After receiving a CONNECTION_CLOSE frame, endpoints enter the
draining state. An endpoint that receives a CONNECTION_CLOSE frame draining state. An endpoint that receives a CONNECTION_CLOSE frame
MAY send a single packet containing a CONNECTION_CLOSE frame before MAY send a single packet containing a CONNECTION_CLOSE frame before
entering the draining state, using a CONNECTION_CLOSE frame and a entering the draining state, using a CONNECTION_CLOSE frame and a
NO_ERROR code if appropriate. An endpoint MUST NOT send further NO_ERROR code if appropriate. An endpoint MUST NOT send further
packets, which could result in a constant exchange of packets, which could result in a constant exchange of
skipping to change at page 61, line 6 skipping to change at page 67, line 38
10.3.1. Immediate Close During the Handshake 10.3.1. Immediate Close During the Handshake
When sending CONNECTION_CLOSE, the goal is to ensure that the peer When sending CONNECTION_CLOSE, the goal is to ensure that the peer
will process the frame. Generally, this means sending the frame in a will process the frame. Generally, this means sending the frame in a
packet with the highest level of packet protection to avoid the packet with the highest level of packet protection to avoid the
packet being discarded. After the handshake is confirmed (see packet being discarded. After the handshake is confirmed (see
Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any Section 4.1.2 of [QUIC-TLS]), an endpoint MUST send any
CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to CONNECTION_CLOSE frames in a 1-RTT packet. However, prior to
confirming the handshake, it is possible that more advanced packet confirming the handshake, it is possible that more advanced packet
protection keys are not available to the peer, so the frame MAY be protection keys are not available to the peer, so another
replicated in a packet that uses a lower packet protection level. CONNECTION_CLOSE frame MAY be sent in a packet that uses a lower
packet protection level. More specifically:
A client will always know whether the server has Handshake keys (see * A client will always know whether the server has Handshake keys
Section 17.2.2.1), but it is possible that a server does not know (see Section 17.2.2.1), but it is possible that a server does not
whether the client has Handshake keys. Under these circumstances, a know whether the client has Handshake keys. Under these
server SHOULD send a CONNECTION_CLOSE frame in both Handshake and circumstances, a server SHOULD send a CONNECTION_CLOSE frame in
Initial packets to ensure that at least one of them is processable by both Handshake and Initial packets to ensure that at least one of
the client. Similarly, a peer might be unable to read 1-RTT packets, them is processable by the client.
so an endpoint SHOULD send CONNECTION_CLOSE in Handshake and 1-RTT
packets prior to confirming the handshake. These packets can be * A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be
assured of the server has accepted 0-RTT and so sending a
CONNECTION_CLOSE frame in an Initial packet makes it more likely
that the server can receive the close signal, even if the
application error code might not be received.
* Prior to confirming the handshake, a peer might be unable to
process 1-RTT packets, so an endpoint SHOULD send CONNECTION_CLOSE
in both Handshake and 1-RTT packets. A server SHOULD also send
CONNECTION_CLOSE in an Initial packet.
Sending a CONNECTION_CLOSE of type 0x1d in an Initial or Handshake
packet could expose application state or be used to alter application
state. A CONNECTION_CLOSE of type 0x1d MUST be replaced by a
CONNECTION_CLOSE of type 0x1c when sending the frame in Initial or
Handshake packets. Otherwise, information about the application
state might be revealed. Endpoints MUST clear the value of the
Reason Phrase field and SHOULD use the APPLICATION_ERROR code when
converting to a CONNECTION_CLOSE of type 0x1c.
CONNECTION_CLOSE frames sent in multiple packet types can be
coalesced into a single UDP datagram; see Section 12.2. coalesced into a single UDP datagram; see Section 12.2.
An endpoint might send a CONNECTION_CLOSE frame in an Initial packet An endpoint might send a CONNECTION_CLOSE frame in an Initial packet
or in response to unauthenticated information received in Initial or or in response to unauthenticated information received in Initial or
Handshake packets. Such an immediate close might expose legitimate Handshake packets. Such an immediate close might expose legitimate
connections to a denial of service. QUIC does not include defensive connections to a denial of service. QUIC does not include defensive
measures for on-path attacks during the handshake; see Section 21.1. measures for on-path attacks during the handshake; see Section 21.1.
However, at the cost of reducing feedback about errors for legitimate However, at the cost of reducing feedback about errors for legitimate
peers, some forms of denial of service can be made more difficult for peers, some forms of denial of service can be made more difficult for
an attacker if endpoints discard illegal packets rather than an attacker if endpoints discard illegal packets rather than
skipping to change at page 62, line 16 skipping to change at page 69, line 32
it selected during the handshake; clients cannot use this transport it selected during the handshake; clients cannot use this transport
parameter because their transport parameters don't have parameter because their transport parameters don't have
confidentiality protection. These tokens are protected by confidentiality protection. These tokens are protected by
encryption, so only client and server know their value. Tokens are encryption, so only client and server know their value. Tokens are
invalidated when their associated connection ID is retired via a invalidated when their associated connection ID is retired via a
RETIRE_CONNECTION_ID frame (Section 19.16). RETIRE_CONNECTION_ID frame (Section 19.16).
An endpoint that receives packets that it cannot process sends a An endpoint that receives packets that it cannot process sends a
packet in the following layout: packet in the following layout:
0 1 2 3 Stateless Reset {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Fixed Bits (2) = 1,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unpredictable Bits (38..),
|0|1| Unpredictable Bits (38 ..) ... Stateless Reset Token (128),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| |
+ +
| |
+ Stateless Reset Token (128) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Stateless Reset Packet Figure 9: Stateless Reset Packet
This design ensures that a stateless reset packet is - to the extent This design ensures that a stateless reset packet is - to the extent
possible - indistinguishable from a regular packet with a short possible - indistinguishable from a regular packet with a short
header. header.
A stateless reset uses an entire UDP datagram, starting with the A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header. The remainder of the first byte first two bits of the packet header. The remainder of the first byte
and an arbitrary number of bytes following it that are set to and an arbitrary number of bytes following it that are set to
unpredictable values. The last 16 bytes of the datagram contain a unpredictable values. The last 16 bytes of the datagram contain a
Stateless Reset Token. Stateless Reset Token.
skipping to change at page 67, line 9 skipping to change at page 74, line 12
depending upon the length of the peer's connection IDs. Conversely, depending upon the length of the peer's connection IDs. Conversely,
refusing to send a Stateless Reset in response to a small packet refusing to send a Stateless Reset in response to a small packet
might result in Stateless Reset not being useful in detecting cases might result in Stateless Reset not being useful in detecting cases
of broken connections where only very small packets are sent; such of broken connections where only very small packets are sent; such
failures might only be detected by other means, such as timers. failures might only be detected by other means, such as timers.
11. Error Handling 11. Error Handling
An endpoint that detects an error SHOULD signal the existence of that An endpoint that detects an error SHOULD signal the existence of that
error to its peer. Both transport-level and application-level errors error to its peer. Both transport-level and application-level errors
can affect an entire connection (see Section 11.1), while only can affect an entire connection; see Section 11.1. Only application-
application-level errors can be isolated to a single stream (see level errors can be isolated to a single stream; see Section 11.2.
Section 11.2).
The most appropriate error code (Section 20) SHOULD be included in The most appropriate error code (Section 20) SHOULD be included in
the frame that signals the error. Where this specification the frame that signals the error. Where this specification
identifies error conditions, it also identifies the error code that identifies error conditions, it also identifies the error code that
is used; though these are worded as requirements, different is used; though these are worded as requirements, different
implementation strategies might lead to different errors being implementation strategies might lead to different errors being
reported. In particular, an endpoint MAY use any applicable error reported. In particular, an endpoint MAY use any applicable error
code when it detects an error condition; a generic error code (such code when it detects an error condition; a generic error code (such
as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place
of specific error codes. of specific error codes.
skipping to change at page 68, line 32 skipping to change at page 75, line 36
instance of the application protocol uses a direct API call and a instance of the application protocol uses a direct API call and a
remote instance uses the STOP_SENDING frame, which triggers an remote instance uses the STOP_SENDING frame, which triggers an
automatic RESET_STREAM. automatic RESET_STREAM.
Application protocols SHOULD define rules for handling streams that Application protocols SHOULD define rules for handling streams that
are prematurely cancelled by either endpoint. are prematurely cancelled by either endpoint.
12. Packets and Frames 12. Packets and Frames
QUIC endpoints communicate by exchanging packets. Packets have QUIC endpoints communicate by exchanging packets. Packets have
confidentiality and integrity protection (see Section 12.1) and are confidentiality and integrity protection; see Section 12.1. Packets
carried in UDP datagrams (see Section 12.2). are carried in UDP datagrams; see Section 12.2.
This version of QUIC uses the long packet header (see Section 17.2) This version of QUIC uses the long packet header during connection
during connection establishment. Packets with the long header are establishment; see Section 17.2. Packets with the long header are
Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake
(Section 17.2.4), and Retry (Section 17.2.5). Version negotiation (Section 17.2.4), and Retry (Section 17.2.5). Version negotiation
uses a version-independent packet with a long header (see uses a version-independent packet with a long header; see
Section 17.2.1). Section 17.2.1.
Packets with the short header (Section 17.3) are designed for minimal Packets with the short header are designed for minimal overhead and
overhead and are used after a connection is established and 1-RTT are used after a connection is established and 1-RTT keys are
keys are available. available; see Section 17.3.
12.1. Protected Packets 12.1. Protected Packets
All QUIC packets except Version Negotiation packets use authenticated All QUIC packets except Version Negotiation packets use authenticated
encryption with additional data (AEAD) [RFC5116] to provide encryption with additional data (AEAD) [RFC5116] to provide
confidentiality and integrity protection. Retry packets use AEAD to confidentiality and integrity protection. Retry packets use AEAD to
provide integrity protection. Details of packet protection are found provide integrity protection. Details of packet protection are found
in [QUIC-TLS]; this section includes an overview of the process. in [QUIC-TLS]; this section includes an overview of the process.
Initial packets are protected using keys that are statically derived. Initial packets are protected using keys that are statically derived.
This packet protection is not effective confidentiality protection. This packet protection is not effective confidentiality protection.
Initial protection only exists to ensure that the sender of the Initial protection only exists to ensure that the sender of the
packet is on the network path. Any entity that receives the Initial packet is on the network path. Any entity that receives the Initial
packet from a client can recover the keys necessary to remove packet packet from a client can recover the keys necessary to remove packet
protection or to generate packets that will be successfully protection or to generate packets that will be successfully
authenticated. authenticated.
All other packets are protected with keys derived from the All other packets are protected with keys derived from the
cryptographic handshake. The type of the packet from the long header cryptographic handshake. The type of the packet from the long header
or key phase from the short header are used to identify which or key phase from the short header are used to identify which
encryption level - and therefore the keys - that are used. Packets encryption keys are used. Packets protected with 0-RTT and 1-RTT
protected with 0-RTT and 1-RTT keys are expected to have keys are expected to have confidentiality and data origin
confidentiality and data origin authentication; the cryptographic authentication; the cryptographic handshake ensures that only the
handshake ensures that only the communicating endpoints receive the communicating endpoints receive the corresponding keys.
corresponding keys.
The packet number field contains a packet number, which has The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet additional confidentiality protection that is applied after packet
protection is applied (see [QUIC-TLS] for details). The underlying protection is applied; see [QUIC-TLS] for details. The underlying
packet number increases with each packet sent in a given packet packet number increases with each packet sent in a given packet
number space; see Section 12.3 for details. number space; see Section 12.3 for details.
12.2. Coalescing Packets 12.2. Coalescing Packets
Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake
(Section 17.2.4) packets contain a Length field, which determines the (Section 17.2.4) packets contain a Length field, which determines the
end of the packet. The length includes both the Packet Number and end of the packet. The length includes both the Packet Number and
Payload fields, both of which are confidentiality protected and Payload fields, both of which are confidentiality protected and
initially of unknown length. The length of the Payload field is initially of unknown length. The length of the Payload field is
learned once header protection is removed. learned once header protection is removed.
Using the Length field, a sender can coalesce multiple QUIC packets Using the Length field, a sender can coalesce multiple QUIC packets
into one UDP datagram. This can reduce the number of UDP datagrams into one UDP datagram. This can reduce the number of UDP datagrams
needed to complete the cryptographic handshake and 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 Section 14.3.1. Receivers MUST be able to process coalesced packets.
packets.
Coalescing packets in order of increasing encryption levels (Initial, Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 0-RTT, Handshake, 1-RTT; see Section 4.1.4 of [QUIC-TLS]) makes it
able to process all the packets in a single pass. A packet with a more likely the receiver will be able to process all the packets in a
short header does not include a length, so it can only be the last single pass. A packet with a short header does not include a length,
packet included in a UDP datagram. An endpoint SHOULD NOT coalesce so it can only be the last packet included in a UDP datagram. An
multiple packets at the same encryption level. endpoint SHOULD NOT coalesce multiple packets at the same encryption
level.
Senders MUST NOT coalesce QUIC packets for different connections into Senders MUST NOT coalesce QUIC packets for different connections into
a single UDP datagram. Receivers SHOULD ignore any subsequent a single UDP datagram. Receivers SHOULD ignore any subsequent
packets with a different Destination Connection ID than the first packets with a different Destination Connection ID than the first
packet in the datagram. packet in the datagram.
Every QUIC packet that is coalesced into a single UDP datagram is Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete. The receiver of coalesced QUIC packets MUST separate and complete. The receiver of coalesced QUIC packets MUST
individually process each QUIC packet and separately acknowledge individually process each QUIC packet and separately acknowledge
them, as if they were received as the payload of different UDP them, as if they were received as the payload of different UDP
skipping to change at page 70, line 43 skipping to change at page 77, line 40
12.3. Packet Numbers 12.3. Packet Numbers
The packet number is an integer in the range 0 to 2^62-1. This The packet number is an integer in the range 0 to 2^62-1. This
number is used in determining the cryptographic nonce for packet number is used in determining the cryptographic nonce for packet
protection. Each endpoint maintains a separate packet number for protection. Each endpoint maintains a separate packet number for
sending and receiving. sending and receiving.
Packet numbers are limited to this range because they need to be Packet numbers are limited to this range because they need to be
representable in whole in the Largest Acknowledged field of an ACK representable in whole in the Largest Acknowledged field of an ACK
frame (Section 19.3). When present in a long or short header frame (Section 19.3). When present in a long or short header
however, packet numbers are reduced and encoded in 1 to 4 bytes (see however, packet numbers are reduced and encoded in 1 to 4 bytes; see
Section 17.1). Section 17.1.
Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5) Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5)
packets do not include a packet number. packets do not include a packet number.
Packet numbers are divided into 3 spaces in QUIC: Packet numbers are divided into 3 spaces in QUIC:
* Initial space: All Initial packets (Section 17.2.2) are in this * Initial space: All Initial packets (Section 17.2.2) are in this
space. space.
* Handshake space: All Handshake packets (Section 17.2.4) are in * Handshake space: All Handshake packets (Section 17.2.4) are in
skipping to change at page 71, line 50 skipping to change at page 78, line 50
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]. An efficient algorithm for duplicate
suppression can be found in Section 3.4.3 of [RFC4303]. suppression can be found in Section 3.4.3 of [RFC4303].
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 7. 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.
0 1 2 3 Packet Payload {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Frame (..) ...,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Frame 1 (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame 2 (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame N (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: QUIC Payload Figure 10: QUIC Payload
The payload of a packet that contains frames MUST contain at least The payload of a packet that contains frames MUST contain at least
one frame, and MAY contain multiple frames and multiple frame types. one frame, and MAY contain multiple frames and multiple frame types.
Frames always fit within a single QUIC packet and cannot span Frames always fit within a single QUIC packet and cannot span
multiple packets. multiple packets.
Each frame begins with a Frame Type, indicating its type, followed by Each frame begins with a Frame Type, indicating its type, followed by
additional type-dependent fields: additional type-dependent fields:
0 1 2 3 Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Frame Type (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type-Dependent Fields (..),
| Frame Type (i) ... }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-Dependent Fields (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Generic Frame Layout Figure 11: Generic Frame Layout
The frame types defined in this specification are listed in Table 3. The frame types defined in this specification are listed in Table 3.
The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and
CONNECTION_CLOSE frames is used to carry other frame-specific flags. CONNECTION_CLOSE frames is used to carry other frame-specific flags.
For all other frames, the Frame Type field simply identifies the For all other frames, the Frame Type field simply identifies the
frame. These frames are explained in more detail in Section 19. frame. These frames are explained in more detail in Section 19.
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
| Type Value | Frame Type Name | Definition | Packets | | Type Value | Frame Type Name | Definition | Packets |
+=============+======================+===============+=========+ +=============+======================+===============+=========+
skipping to change at page 73, line 44 skipping to change at page 80, line 44
| 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 | | 0x16 - 0x17 | STREAMS_BLOCKED | Section 19.14 | __01 |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
| 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 | | 0x18 | NEW_CONNECTION_ID | Section 19.15 | __01 |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
| 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
| 0x1a | PATH_CHALLENGE | Section 19.17 | __01 | | 0x1a | PATH_CHALLENGE | Section 19.17 | __01 |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
| 0x1b | PATH_RESPONSE | Section 19.18 | __01 | | 0x1b | PATH_RESPONSE | Section 19.18 | __01 |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
| 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | IH_1* | | 0x1c - 0x1d | CONNECTION_CLOSE | Section 19.19 | ih01 |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
| 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 | | 0x1e | HANDSHAKE_DONE | Section 19.20 | ___1 |
+-------------+----------------------+---------------+---------+ +-------------+----------------------+---------------+---------+
Table 3: Frame Types Table 3: Frame Types
The "Packets" column in Table 3 does not form part of the IANA The "Packets" column in Table 3 does not form part of the IANA
registry (see Section 22.3). This column lists the types of packets registry; see Section 22.3. This column lists the types of packets
that each frame type can appear in, indicated by the following that each frame type could appear in, indicated by the following
characters: characters:
I: Initial (Section 17.2.2) I: Initial (Section 17.2.2)
H: Handshake (Section 17.2.4) H: Handshake (Section 17.2.4)
0: 0-RTT (Section 17.2.3) 0: 0-RTT (Section 17.2.3)
1: 1-RTT (Section 17.3) 1: 1-RTT (Section 17.3)
*: A CONNECTION_CLOSE frame of type 0x1c can appear in Initial, ih: A CONNECTION_CLOSE frame of type 0x1d cannot appear in Initial
Handshake, and 1-RTT packets, whereas a CONNECTION_CLOSE of type or Handshake packets.
0x1d can only appear in a 1-RTT packet.
Section 4 of [QUIC-TLS] provides more detail about these Section 4 of [QUIC-TLS] provides more detail about these
restrictions. Note that all frames can appear in 1-RTT packets. restrictions. Note that all frames can appear in 1-RTT packets.
An endpoint MUST treat the receipt of a frame of unknown type as a An endpoint MUST treat the receipt of a frame of unknown type as a
connection error of type FRAME_ENCODING_ERROR. connection error of type FRAME_ENCODING_ERROR.
All QUIC frames are idempotent in this version of QUIC. That is, a All QUIC frames are idempotent in this version of QUIC. That is, a
valid frame does not cause undesirable side effects or errors when valid frame does not cause undesirable side effects or errors when
received more than once. received more than once.
skipping to change at page 74, line 44 skipping to change at page 81, line 46
these values as a two-, four- or eight-byte variable length integer. these values as a two-, four- or eight-byte variable length integer.
For instance, though 0x4001 is a legitimate two-byte encoding for a For instance, though 0x4001 is a legitimate two-byte encoding for a
variable-length integer with a value of 1, PING frames are always variable-length integer with a value of 1, PING frames are always
encoded as a single byte with the value 0x01. This rule applies to encoded as a single byte with the value 0x01. This rule applies to
all current and future QUIC frame types. An endpoint MAY treat the all current and future QUIC frame types. An endpoint MAY treat the
receipt of a frame type that uses a longer encoding than necessary as receipt of a frame type that uses a longer encoding than necessary as
a connection error of type PROTOCOL_VIOLATION. a connection error of type PROTOCOL_VIOLATION.
13. Packetization and Reliability 13. Packetization and Reliability
A sender bundles one or more frames in a QUIC packet (see A sender 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 bundling as many frames as possible within a 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 bundle multiple frames before
sending a packet that is not maximally packed, to avoid sending out sending a packet that is not maximally packed, to avoid sending out
large numbers of small packets. An implementation MAY use knowledge large numbers of small packets. An implementation MAY use knowledge
about application sending behavior or heuristics to determine whether about application sending behavior or heuristics to determine whether
and for how long to wait. This waiting period is an implementation and for how long to wait. This waiting period is an implementation
decision, and an implementation should be careful to delay decision, and an implementation should be careful to delay
conservatively, since any delay is likely to increase application- conservatively, since any delay is likely to increase application-
skipping to change at page 75, line 43 skipping to change at page 82, line 44
receipt by sending one or more ACK frames containing the packet receipt by sending one or more ACK frames containing the packet
number of the received packet. number of the received packet.
13.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.
In general, frequent feedback from a receiver improves loss and In general, frequent feedback from a receiver improves loss and
congestion response, but this has to be balanced against excessive congestion response, but this has to be balanced against excessive
load generated by a receiver that sends an ACK frame in response to load generated by a receiver that sends an ACK frame in response to
every ack-eliciting packet. The guidance offered below seeks to every ack-eliciting packet. The guidance offered below seeks to
strike this balance. strike this balance.
13.2.1. Sending ACK Frames 13.2.1. Sending ACK Frames
Every packet SHOULD be acknowledged at least once, and ack-eliciting Every packet SHOULD be acknowledged at least once, and ack-eliciting
packets MUST be acknowledged at least once within the maximum ack packets MUST be acknowledged at least once within the maximum 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 5.2.1 of [QUIC-RECOVERY].
An ACK frame SHOULD be generated for at least every second ack- An ACK frame SHOULD be generated for at least every second ack-
eliciting packet. This recommendation is in keeping with standard eliciting packet. This recommendation is in keeping with standard
practice for TCP [RFC5681]. practice for TCP [RFC5681]. A receiver could decide to send an ACK
frame less frequently if it has information about how frequently the
sender's congestion controller needs feedback, or if the receiver is
CPU or bandwidth constrained.
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 MAY continue sending ACK frames that is out of order. The endpoint SHOULD NOT continue sending ACK
immediately on each subsequently received packet, but the endpoint frames immediately unless more ack-eliciting packets are received out
SHOULD return to acknowledging every other packet within a period of of order. If every subsequent ack-eliciting packet arrives out of
1/8 x RTT, unless more ack-eliciting packets are received out 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 As an optimization, a receiver MAY process multiple packets before
sending any ACK frames in response. In this case the receiver can sending any ACK frames in response. In this case the receiver can
determine whether an immediate or delayed acknowledgement should be determine whether an immediate or delayed acknowledgement should be
skipping to change at page 77, line 46 skipping to change at page 85, line 6
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.3 and Section 13.2.4 describe an exemplary approach for
determining what packets to acknowledge in each ACK frame. determining what packets to acknowledge in each ACK frame. Though
the goal of these algorithms is to generate an acknowledgment for
every packet that is processed, it is still possible for
acknowledgments to be lost. A sender cannot expect to receive an
acknowledgment for every packet that the receiver processes.
13.2.3. Receiver Tracking of ACK Frames 13.2.3. 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.4. Limiting ACK Ranges
To limit ACK Ranges (see Section 19.3.1) to those that have not yet A receiver limits the number of ACK Ranges (Section 19.3.1) it
been received by the sender, the receiver SHOULD track which ACK remembers and sends in ACK frames, both to limit the size of ACK
frames have been acknowledged by its peer. The receiver SHOULD frames and to avoid resource exhaustion. After receiving
exclude already acknowledged packets from future ACK frames whenever acknowledgments for an ACK frame, the receiver SHOULD stop tracking
these packets would unnecessarily contribute to the ACK frame size. those acknowledged ACK Ranges.
When the receiver is only sending non-ack-eliciting packets, it can
bundle a PING or other small ack-eliciting frame with a fraction of
them, such as once per round trip, to enable dropping unnecessary ACK
ranges and any state for previously sent packets. The receiver MUST
NOT bundle an ack-eliciting frame, such as a PING, with all packets
that would otherwise be non-ack-eliciting, in order to avoid an
infinite feedback loop of acknowledgements.
To limit receiver state or the size of ACK frames, a receiver MAY It is possible that retaining many ACK Ranges could cause an ACK
limit the number of ACK Ranges it sends. A receiver can do this even frame to become too large. A receiver can discard unacknowledged ACK
without receiving acknowledgment of its ACK frames, with the Ranges to limit ACK frame size, at the cost of increased
knowledge this could cause the sender to unnecessarily retransmit retransmissions from the sender. This is necessary if an ACK frame
some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare would be too large to fit in a packet, however receivers MAY also
packets lost after sufficiently newer packets are acknowledged. limit ACK frame size further to preserve space for other frames.
Therefore, the receiver SHOULD repeatedly acknowledge newly received
packets in preference to packets received in the past. A receiver MUST retain an ACK Range unless it can ensure that it will
not subsequently accept packets with numbers in that range.
Maintaining a minimum packet number that increases as ranges are
discarded is one way to achieve this with minimal state.
Receivers can discard all ACK Ranges, but they MUST retain the
largest packet number that has been successfully processed as that is
used to recover packet numbers from subsequent packets; see
Section 17.1.
A receiver SHOULD include an ACK Range containing the largest
received packet number in every ACK frame. The Largest Acknowledged
field is used in ECN validation at a sender and including a lower
value than what was included in a previous ACK frame could cause ECN
to be unnecessarily disabled; see Section 13.4.2.
A receiver that sends only non-ack-eliciting packets, such as ACK
frames, might not receive an acknowledgement for a long period of
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
sends could be unnecessarily large. In such a case, a receiver could
bundle a PING or other small ack-eliciting frame occasionally, such
as once per round trip, to elicit an ACK from the peer.
A receiver MUST NOT bundle an ack-eliciting frame with all packets
that would otherwise be non-ack-eliciting, to avoid an infinite
feedback loop of acknowledgements.
13.2.5. Measuring and Reporting Host Delay 13.2.5. Measuring and Reporting Host Delay
An endpoint measures the delays intentionally introduced between the An endpoint measures the delays intentionally introduced between the
time the packet with the largest packet number is received and the time the packet with the largest packet number is received and the
time an acknowledgment is sent. The endpoint encodes this delay in time an acknowledgment is sent. The endpoint encodes this 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.6. ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed (see Section 12.1). For number space as the packet being 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.
skipping to change at page 79, line 40 skipping to change at page 87, line 21
New frames and packets are used to carry information that is New frames and packets are used to carry information that is
determined to have been lost. In general, information is sent again determined to have been lost. In general, information is sent again
when a packet containing that information is determined to be lost when a packet containing that information is determined to be lost
and sending ceases when a packet containing that information is and sending ceases when a packet containing that information is
acknowledged. acknowledged.
* Data sent in CRYPTO frames is retransmitted according to the rules * Data sent in CRYPTO frames is retransmitted according to the rules
in [QUIC-RECOVERY], until all data has been acknowledged. Data in in [QUIC-RECOVERY], until all data has been acknowledged. Data in
CRYPTO frames for Initial and Handshake packets is discarded when CRYPTO frames for Initial and Handshake packets is discarded when
keys for the corresponding encryption level are discarded. keys for the corresponding packet number space are discarded.
* Application data sent in STREAM frames is retransmitted in new * Application data sent in STREAM frames is retransmitted in new
STREAM frames unless the endpoint has sent a RESET_STREAM for that STREAM frames unless the endpoint has sent a RESET_STREAM for that
stream. Once an endpoint sends a RESET_STREAM frame, no further stream. Once an endpoint sends a RESET_STREAM frame, no further
STREAM frames are needed. STREAM frames are needed.
* ACK frames carry the most recent set of acknowledgements and the * ACK frames carry the most recent set of acknowledgements and the
Ack Delay from the largest acknowledged packet, as described in Ack Delay from the largest acknowledged packet, as described in
Section 13.2.1. Delaying the transmission of packets containing Section 13.2.1. Delaying the transmission of packets containing
ACK frames or sending old ACK frames can cause the peer to ACK frames or sending old ACK frames can cause the peer to
skipping to change at page 81, line 35 skipping to change at page 89, line 18
frame contents. frame contents.
* PING and PADDING frames contain no information, so lost PING or * PING and PADDING frames contain no information, so lost PING or
PADDING frames do not require repair. PADDING frames do not require repair.
* The HANDSHAKE_DONE frame MUST be retransmitted until it is * The HANDSHAKE_DONE frame MUST be retransmitted until it is
acknowledged. acknowledged.
Endpoints SHOULD prioritize retransmission of data over sending new Endpoints SHOULD prioritize retransmission of data over sending new
data, unless priorities specified by the application indicate data, unless priorities specified by the application indicate
otherwise (see Section 2.3). otherwise; see Section 2.3.
Even though a sender is encouraged to assemble frames containing up- Even though a sender is encouraged to assemble frames containing up-
to-date information every time it sends a packet, it is not forbidden to-date information every time it sends a packet, it is not forbidden
to retransmit copies of frames from lost packets. A sender that to retransmit copies of frames from lost packets. A sender that
retransmits copies of frames needs to handle decreases in available retransmits copies of frames needs to handle decreases in available
payload size due to change in packet number length, connection ID payload size due to change in packet number length, connection ID
length, and path MTU. A receiver MUST accept packets containing an length, and path MTU. A receiver MUST accept packets containing an
outdated frame, such as a MAX_DATA frame carrying a smaller maximum outdated frame, such as a MAX_DATA frame carrying a smaller maximum
data than one found in an older packet. data than one found in an older packet.
skipping to change at page 82, line 26 skipping to change at page 90, line 10
IP header. A network path does not support ECN if ECN marked packets IP header. A network path does not support ECN if ECN marked packets
get dropped or ECN markings are rewritten on the path. An endpoint get dropped or ECN markings are rewritten on the path. An endpoint
validates the use of ECN on the path, both during connection validates the use of ECN on the path, both during connection
establishment and when migrating to a new path (Section 9). establishment and when migrating to a new path (Section 9).
13.4.1. ECN Counts 13.4.1. ECN Counts
On receiving a QUIC packet with an ECT or CE codepoint, an ECN- On receiving a QUIC packet with an ECT or CE codepoint, an ECN-
enabled endpoint that can access the ECN codepoints from the enabled endpoint that can access the ECN codepoints from the
enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE
count, and includes these counts in subsequent ACK frames (see count, and includes these counts in subsequent ACK frames; see
Section 13.2 and Section 19.3). Note that this requires being able Section 13.2 and Section 19.3. Note that this requires being able to
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 A packet detected by a receiver as a duplicate does not affect the
receiver's local ECN codepoint counts; see (Section 21.8) for receiver's local ECN codepoint counts; see (Section 21.8) for
relevant security concerns. 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
skipping to change at page 85, line 7 skipping to change at page 92, line 45
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 header.
A client MUST expand the payload of all UDP datagrams carrying A client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least 1200 bytes, by adding PADDING frames to Initial packets to at least 1200 bytes, by adding PADDING frames to
the Initial packet or by coalescing the Initial packet (see the Initial packet or by coalescing the Initial packet; see
Section 12.2). Sending a UDP datagram of this size ensures that the Section 12.2. Sending a UDP datagram of this size ensures that the
network path from the client to the server supports a reasonable network path from the client to the server supports a reasonable
Maximum Transmission Unit (MTU). Padding datagrams also helps reduce Maximum Transmission Unit (MTU). Padding datagrams also helps reduce
the amplitude of amplification attacks caused by server responses the amplitude of amplification attacks caused by server responses
toward an unverified client address; see Section 8. toward an unverified client address; see Section 8.
Enforcement of the max_udp_payload_size transport parameter
(Section 18.2) might act as an additional limit on packet size.
Exceeding this limit can be avoided once the value is known.
However, prior to learning the value of the transport parameter,
endpoints risk datagrams being lost if they send packets larger than
1200 bytes.
Datagrams containing Initial packets MAY exceed 1200 bytes if the Datagrams containing Initial packets MAY exceed 1200 bytes if the
client believes that the Path Maximum Transmission Unit (PMTU) client believes that the network path and peer both support the size
supports the size that it chooses. that it chooses.
UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4
[IPv4], the DF bit MUST be set to prevent fragmentation on the path. [IPv4], the DF bit MUST be set to prevent fragmentation on the path.
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 that is smaller than 1200 bytes. A server MAY also datagram with a payload that is less than 1200 bytes. A server MAY
immediately close the connection by sending a CONNECTION_CLOSE frame also immediately close the connection by sending a CONNECTION_CLOSE
with an error code of PROTOCOL_VIOLATION; see Section 10.3.1. 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.1. Path Maximum Transmission Unit (PMTU)
The PMTU is the maximum size of the entire IP packet including the IP The Path Maximum Transmission Unit (PMTU) is the maximum size of the
header, UDP header, and UDP payload. The UDP payload includes the entire IP packet including the IP header, UDP header, and UDP
QUIC packet header, protected payload, and any authentication fields. payload. The UDP payload includes the QUIC packet header, protected
The PMTU can depend upon the current path characteristics. payload, and any authentication fields. The PMTU can depend on path
Therefore, the current largest UDP payload an implementation will characteristics, and can therefore change over time. The largest UDP
send is referred to as the QUIC maximum packet size. payload an endpoint sends at any given time is referred to as the
endpoint's maximum packet size.
QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6 QUIC depends on a PMTU of at least 1280 bytes. This is the IPv6
minimum size [RFC8200] and is also supported by most modern IPv4 minimum size [RFC8200] and is also supported by most modern IPv4
networks. All QUIC packets (except for PMTU probe packets) SHOULD be networks. All QUIC packets (except for PMTU probe packets) SHOULD be
sized to fit within the maximum packet size to avoid the packet being sized to fit within the maximum packet size to avoid the packet being
fragmented or dropped [RFC8085]. fragmented or dropped [RFC8085].
An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery
([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191] ([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191]
[RFC8201] to determine whether the path to a destination will support [RFC8201] to determine whether the path to a destination will support
skipping to change at page 86, line 49 skipping to change at page 95, line 5
QUIC endpoints SHOULD validate ICMP messages to protect from off-path QUIC endpoints SHOULD validate ICMP messages to protect from off-path
injection as specified in [RFC8201] and Section 5.2 of [RFC8085]. injection as specified in [RFC8201] and Section 5.2 of [RFC8085].
This validation SHOULD use the quoted packet supplied in the payload This validation SHOULD use the quoted packet supplied in the payload
of an ICMP message to associate the message with a corresponding of an ICMP message to associate the message with a corresponding
transport connection [DPLPMTUD]. transport connection [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.
Further validation can also be provided:
* An IPv4 endpoint could set the Don't Fragment (DF) bit on a small
proportion of packets, so that most invalid ICMP messages arrive
when there are no DF packets outstanding, and can therefore be
identified as spurious.
* An endpoint could store additional information from the IP or UDP
headers to use for validation (for example, the IP ID or UDP
checksum).
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. Any An endpoint MUST NOT increase PMTU based on ICMP messages; see
reduction in the QUIC maximum packet size MAY be provisional until Section 3, clause 6 of [DPLPMTUD]. Any reduction in the QUIC maximum
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 Section 6.3 of [DPLPMTUD] provides considerations for implementing
Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC. Datagram Packetization Layer PMTUD (DPLPMTUD) with QUIC.
When implementing the algorithm in Section 5 of [DPLPMTUD], the When implementing the algorithm in Section 5 of [DPLPMTUD], the
initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC
skipping to change at page 87, line 43 skipping to change at page 95, line 35
which could delay the transmission of subsequent application data. which could delay the transmission of subsequent application data.
A PING frame can be included in a PMTU probe to ensure that a valid A PING frame can be included in a PMTU probe to ensure that a valid
probe is acknowledged. probe is acknowledged.
The considerations for processing ICMP messages in the previous The considerations for processing ICMP messages in the previous
section also apply if these messages are used by DPLPMTUD. section also apply if these messages are used by DPLPMTUD.
14.3.1. PMTU Probes Containing Source Connection ID 14.3.1. PMTU Probes Containing Source Connection ID
Endpoints that rely on the destination connection ID for routing QUIC Endpoints that rely on the destination connection ID for routing
packets are likely to require that the connection ID be included in incoming QUIC packets are likely to require that the connection ID be
PMTU probe packets to route any resulting ICMP messages included in PMTU probe packets to route any resulting ICMP messages
(Section 14.2) back to the correct endpoint. However, only long (Section 14.2) 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 source connection IDs, and long
header packets are not decrypted or acknowledged by the peer once the header packets are not decrypted or acknowledged by the peer once the
handshake is complete. One way to construct a PMTU probe is to handshake is complete.
coalesce (see Section 12.2) a Handshake packet (Section 17.2.4) with
a short header packet in a single UDP datagram. If the UDP datagram One way to construct a probe for the path MTU is to coalesce (see
reaches the endpoint, the Handshake packet will be ignored, but the Section 12.2) a Handshake packet (Section 17.2.4) with a short header
short header packet will be acknowledged. If the UDP datagram packet in a single UDP datagram. If the UDP datagram reaches the
elicits an ICMP message, that message will likely contain the source endpoint, the Handshake packet will be ignored, but the short header
connection ID within the quoted portion of the UDP datagram. packet will be acknowledged. If the UDP datagram causes an ICMP
message to be sent, the first part of the datagram will be quoted in
that message. If the source connection ID is within the quoted
portion of the UDP datagram, that could be used for routing.
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 89, line 5 skipping to change at page 96, line 49
The version number for the final version of this specification The version number for the final version of this specification
(0x00000001), is reserved for the version of the protocol that is (0x00000001), is reserved for the version of the protocol that is
published as an RFC. published as an RFC.
Version numbers used to identify IETF drafts are created by adding Version numbers used to identify IETF drafts are created by adding
the draft number to 0xff000000. For example, draft-ietf-quic- the draft number to 0xff000000. For example, draft-ietf-quic-
transport-13 would be identified as 0xff00000D. transport-13 would be identified as 0xff00000D.
Implementors are encouraged to register version numbers of QUIC that Implementors are encouraged to register version numbers of QUIC that
they are using for private experimentation on the GitHub wiki at they are using for private experimentation on the GitHub wiki at
<https://github.com/quicwg/base-drafts/wiki/QUIC-Versions>. https://github.com/quicwg/base-drafts/wiki/QUIC-Versions.
16. Variable-Length Integer Encoding 16. Variable-Length Integer Encoding
QUIC packets and frames commonly use a variable-length encoding for QUIC packets and frames commonly use a variable-length encoding for
non-negative integer values. This encoding ensures that smaller non-negative integer values. This encoding ensures that smaller
integer values need fewer bytes to encode. integer values need fewer bytes to encode.
The QUIC variable-length integer encoding reserves the two most The QUIC variable-length integer encoding reserves the two most
significant bits of the first byte to encode the base 2 logarithm of significant bits of the first byte to encode the base 2 logarithm of
the integer encoding length in bytes. The integer value is encoded the integer encoding length in bytes. The integer value is encoded
skipping to change at page 91, line 7 skipping to change at page 99, line 7
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
0 1 2 3 Long Header Packet {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Header Form (1) = 1,
+-+-+-+-+-+-+-+-+ Fixed Bit (1) = 1,
|1|1|T T|X X X X| Long Packet Type (2),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type-Specific Bits (4),
| Version (32) | Version (32),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DCID Length (8),
| DCID Len (8) | Destination Connection ID (0..160),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SCID Length (8),
| Destination Connection ID (0..160) ... Source Connection ID (0..160),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| SCID Len (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: 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
packet format. Packets that use the long header contain the packet format. Packets that use the long header contain the
following fields: following fields:
Header Form: The most significant bit (0x80) of byte 0 (the first Header Form: The most significant bit (0x80) of byte 0 (the first
byte) is set to 1 for long headers. byte) is set to 1 for long headers.
Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets
containing a zero value for this bit are not valid packets in this containing a zero value for this bit are not valid packets in this
version and MUST be discarded. version and MUST be discarded.
Long Packet Type (T): The next two bits (those with a mask of 0x30) Long Packet Type: The next two bits (those with a mask of 0x30) of
of byte 0 contain a packet type. Packet types are listed in byte 0 contain a packet type. Packet types are listed in Table 5.
Table 5.
Type-Specific Bits (X): The lower four bits (those with a mask of Type-Specific Bits: The lower four bits (those with a mask of 0x0f)
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 Len: The byte following the version contains the length in DCID Length: The byte following the version contains the length in
bytes of the Destination Connection ID field that follows it. bytes of the Destination Connection ID field that follows it.
This length is encoded as an 8-bit unsigned integer. In QUIC This length is encoded as an 8-bit unsigned integer. In QUIC
version 1, this value MUST NOT exceed 20. Endpoints that receive version 1, this value MUST NOT exceed 20. Endpoints that receive
a version 1 long header with a value larger than 20 MUST drop the a version 1 long header with a value larger than 20 MUST drop the
packet. Servers SHOULD be able to read longer connection IDs from packet. Servers SHOULD be able to read longer connection IDs from
other QUIC versions in order to properly form a version other QUIC versions in order to properly form a version
negotiation packet. negotiation packet.
Destination Connection ID: The Destination Connection ID field Destination Connection ID: The Destination Connection ID field
follows the DCID Len and is between 0 and 20 bytes in length. follows the DCID 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.
SCID Len: The byte following the Destination Connection ID contains SCID Length: The byte following the Destination Connection ID
the length in bytes of the Source Connection ID field that follows contains the length in bytes of the Source Connection ID field
it. This length is encoded as a 8-bit unsigned integer. In QUIC that follows it. This length is encoded as a 8-bit unsigned
version 1, this value MUST NOT exceed 20 bytes. Endpoints that integer. In QUIC version 1, this value MUST NOT exceed 20 bytes.
receive a version 1 long header with a value larger than 20 MUST Endpoints that receive a version 1 long header with a value larger
drop the packet. Servers SHOULD be able to read longer connection than 20 MUST drop the packet. Servers SHOULD be able to read
IDs from other QUIC versions in order to properly form a version longer connection IDs from other QUIC versions in order to
negotiation packet. 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 Len and is between 0 and 20 bytes in length. Section 7.2 SCID Length field and is between 0 and 20 bytes in length.
describes the use of this field in more detail. 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 93, line 10 skipping to change at page 101, line 16
Source Connection ID fields, and Version fields of a long header Source Connection ID fields, and Version fields of a long header
packet are version-independent. The other fields in the first byte packet are version-independent. The other fields in the first byte
are version-specific. See [QUIC-INVARIANTS] for details on how are version-specific. See [QUIC-INVARIANTS] for details on how
packets from different versions of QUIC are interpreted. packets from different versions of QUIC are interpreted.
The interpretation of the fields and the payload are specific to a The interpretation of the fields and the payload are specific to a
version and packet type. While type-specific semantics for this version and packet type. While type-specific semantics for this
version are described in the following sections, several long-header version are described in the following sections, several long-header
packets in this version of QUIC contain these additional fields: packets in this version of QUIC contain these additional fields:
Reserved Bits (R): Two bits (those with a mask of 0x0c) of byte 0 Reserved Bits: Two bits (those with a mask of 0x0c) of byte 0 are
are reserved across multiple packet types. These bits are reserved across multiple packet types. These bits are protected
protected using header protection (see Section 5.4 of [QUIC-TLS]). using header protection; see Section 5.4 of [QUIC-TLS]. The value
The value included prior to protection MUST be set to 0. An included prior to protection MUST be set to 0. An endpoint MUST
endpoint MUST treat receipt of a packet that has a non-zero value treat receipt of a packet that has a non-zero value for these
for these bits, after removing both packet and header protection, bits, after removing both packet and header protection, as a
as a connection error of type PROTOCOL_VIOLATION. Discarding such connection error of type PROTOCOL_VIOLATION. Discarding such a
a packet after only removing header protection can expose the packet after only removing header protection can expose the
endpoint to attacks (see Section 9.3 of [QUIC-TLS]). endpoint to attacks; see Section 9.3 of [QUIC-TLS].
Packet Number Length (P): In packet types which contain a Packet Packet Number Length: In packet types which contain a Packet Number
Number field, the least significant two bits (those with a mask of field, the least significant two bits (those with a mask of 0x03)
0x03) of byte 0 contain the length of the packet number, encoded of byte 0 contain the length of the packet number, encoded as an
as an unsigned, two-bit integer that is one less than the length unsigned, two-bit integer that is one less than the length of the
of the packet number field in bytes. That is, the length of the packet number field in bytes. That is, the length of the packet
packet number field is the value of this field, plus one. These number field is the value of this field, plus one. These bits are
bits are protected using header protection (see Section 5.4 of protected using header protection; see Section 5.4 of [QUIC-TLS].
[QUIC-TLS]).
Length: The length of the remainder of the packet (that is, the Length: The length of the remainder of the packet (that is, the
Packet Number and Payload fields) in bytes, encoded as a variable- Packet Number and Payload fields) in bytes, encoded as a variable-
length integer (Section 16). length integer (Section 16).
Packet Number: The packet number field is 1 to 4 bytes long. The Packet Number: The packet number field is 1 to 4 bytes long. The
packet number has confidentiality protection separate from packet packet number has confidentiality protection separate from packet
protection, as described in Section 5.4 of [QUIC-TLS]. The length protection, as described in Section 5.4 of [QUIC-TLS]. The length
of the packet number field is encoded in the Packet Number Length of the packet number field is encoded in the Packet Number Length
bits of byte 0 (see above). bits of byte 0; see above.
17.2.1. Version Negotiation Packet 17.2.1. Version Negotiation Packet
A Version Negotiation packet is inherently not version-specific. A Version Negotiation packet is inherently not version-specific.
Upon receipt by a client, it will be identified as a Version Upon receipt by a client, it will be identified as a Version
Negotiation packet based on the Version field having a value of 0. Negotiation packet based on the Version field having a value of 0.
The Version Negotiation packet is a response to a client packet that The Version Negotiation packet is a response to a client packet that
contains a version that is not supported by the server, and is only contains a version that is not supported by the server, and is only
sent by servers. sent by servers.
The layout of a Version Negotiation packet is: The layout of a Version Negotiation packet is:
0 1 2 3 Version Negotiation Packet {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Header Form (1) = 1,
+-+-+-+-+-+-+-+-+ Unused (7),
|1| Unused (7) | Version (32) = 0,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DCID Length (8),
| Version (32) | Destination Connection ID (0..2040),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SCID Length (8),
| DCID Len (8) | Source Connection ID (0..2040),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Supported Version (32) ...,
| Destination Connection ID (0..2040) ... }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCID Len (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0..2040) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version 1 (32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Supported Version 2 (32)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Supported Version N (32)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Version Negotiation Packet Figure 13: Version Negotiation Packet
The value in the Unused field is selected randomly by the server. The value in the Unused field is selected randomly by the server.
Clients MUST ignore the value of this field. Servers SHOULD set the Clients MUST ignore the value of this field. Servers SHOULD set the
most significant bit of this field (0x40) to 1 so that Version most significant bit of this field (0x40) to 1 so that Version
Negotiation packets appear to have the Fixed Bit field. Negotiation packets appear to have the Fixed Bit field.
The Version field of a Version Negotiation packet MUST be set to The Version field of a Version Negotiation packet MUST be set to
0x00000000. 0x00000000.
The server MUST include the value from the Source Connection ID field The server MUST include the value from the Source Connection ID field
skipping to change at page 95, line 28 skipping to change at page 103, line 16
response to a single UDP datagram. response to a single UDP datagram.
See Section 6 for a description of the version negotiation process. See Section 6 for a description of the version negotiation process.
17.2.2. Initial Packet 17.2.2. Initial Packet
An Initial packet uses long headers with a type value of 0x0. It An Initial packet uses long headers with a type value of 0x0. It
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 {
|1|1| 0 |R R|P P| Header Form (1) = 1,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fixed Bit (1) = 1,
| Version (32) | Long Packet Type (2) = 0,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Bits (2),
| DCID Len (8) | Packet Number Length (2),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (32),
| Destination Connection ID (0..160) ... DCID Length (8),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Connection ID (0..160),
| SCID Len (8) | SCID Length (8),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Connection ID (0..160),
| Source Connection ID (0..160) ... Token Length (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Token (..),
| Token Length (i) ... Length (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Number (8..32),
| Token (*) ... Packet Payload (..),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: 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 SCID and Length fields, there
are two additional field specific to the Initial packet. 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.
Payload: The payload of the packet. Packet Payload: The payload of the packet.
In order to prevent tampering by version-unaware middleboxes, Initial In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys packets are protected with connection- and version-specific keys
(Initial keys) as described in [QUIC-TLS]. This protection does not (Initial keys) as described in [QUIC-TLS]. This protection does not
provide confidentiality or integrity against on-path attackers, but provide confidentiality or integrity against on-path attackers, but
provides some level of protection against off-path attackers. provides some level of protection against off-path attackers.
The client and server use the Initial packet type for any packet that The client and server use the Initial packet type for any packet that
contains an initial cryptographic handshake message. This includes contains an initial cryptographic handshake message. This includes
all cases where a new packet containing the initial cryptographic all cases where a new packet containing the initial cryptographic
skipping to change at page 96, line 48 skipping to change at page 104, line 31
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 are also permitted. An
endpoint that receives an Initial packet containing other frames can endpoint that receives an Initial packet containing other frames can
either discard the packet as spurious or treat it as a connection either discard the packet as spurious or treat it as a connection
error. 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 0 message. The first CRYPTO frame sent always begins at an offset of
(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.10.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.5 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
to handshake completion. As part of the TLS handshake, the server to handshake completion. As part of the TLS handshake, the server
can accept or reject this early data. can accept or reject this early data.
See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its See Section 2.3 of [TLS13] for a discussion of 0-RTT data and its
limitations. limitations.
+-+-+-+-+-+-+-+-+ 0-RTT Packet {
|1|1| 1 |R R|P P| Header Form (1) = 1,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fixed Bit (1) = 1,
| Version (32) | Long Packet Type (2) = 1,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Bits (2),
| DCID Len (8) | Packet Number Length (2),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (32),
| Destination Connection ID (0..160) ... DCID Length (8),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Connection ID (0..160),
| SCID Len (8) | SCID Length (8),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Connection ID (0..160),
| Source Connection ID (0..160) ... Length (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Number (8..32),
| Length (i) ... Packet Payload (..),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: 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.
After a client receives a Retry packet, 0-RTT packets are likely to After a client receives a Retry packet, 0-RTT packets are likely to
have been lost or discarded by the server. A client SHOULD attempt have been lost or discarded by the server. A client SHOULD attempt
to resend data in 0-RTT packets after it sends a new Initial packet. to resend data in 0-RTT packets after it sends a new Initial packet.
A client MUST NOT reset the packet number it uses for 0-RTT packets, A client MUST NOT reset the packet number it uses for 0-RTT packets,
since the keys used to protect 0-RTT packets will not change as a since the keys used to protect 0-RTT packets will not change as a
skipping to change at page 99, line 20 skipping to change at page 106, line 28
FLOW_CONTROL_ERROR for exceeding stream data limits). FLOW_CONTROL_ERROR for exceeding stream data limits).
17.2.4. Handshake Packet 17.2.4. Handshake Packet
A Handshake packet uses long headers with a type value of 0x2, A Handshake packet uses long headers with a type value of 0x2,
followed by the Length and Packet Number fields. The first byte followed by the Length and Packet Number fields. The first byte
contains the Reserved and Packet Number Length bits. It is used to contains the Reserved and Packet Number Length bits. It is used to
carry acknowledgments and cryptographic handshake messages from the carry acknowledgments and cryptographic handshake messages from the
server and client. server and client.
+-+-+-+-+-+-+-+-+ Handshake Packet {
|1|1| 2 |R R|P P| Header Form (1) = 1,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fixed Bit (1) = 1,
| Version (32) | Long Packet Type (2) = 2,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Bits (2),
| DCID Len (8) | Packet Number Length (2),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (32),
| Destination Connection ID (0..160) ... DCID Length (8),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination Connection ID (0..160),
| SCID Len (8) | SCID Length (8),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Connection ID (0..160),
| Source Connection ID (0..160) ... Length (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Number (8..32),
| Length (i) ... Packet Payload (..),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: 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
and acknowledgments to the server. and acknowledgments to the server.
The Destination Connection ID field in a Handshake packet contains a The Destination Connection ID field in a Handshake packet contains a
connection ID that is chosen by the recipient of the packet; the connection ID that is chosen by the recipient of the packet; the
Source Connection ID includes the connection ID that the sender of Source Connection ID includes the connection ID that the sender of
the packet wishes to use (see Section 7.2). the packet wishes to use; see Section 7.2.
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. Endpoints MUST treat receipt of Handshake
packets with other frames as a connection error. packets with other frames as a connection error.
Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames
the Handshake encryption level is discarded - and no longer for Handshake packets is discarded - and no longer retransmitted -
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.
0 1 2 3 Retry Packet {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Header Form (1) = 1,
+-+-+-+-+-+-+-+-+ Fixed Bit (1) = 1,
|1|1| 3 | Unused| Long Packet Type (2) = 3,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unused (4),
| Version (32) | Version (32),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DCID Length (8),
| DCID Len (8) | Destination Connection ID (0..160),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SCID Length (8),
| Destination Connection ID (0..160) ... Source Connection ID (0..160),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Retry Token (..),
| SCID Len (8) | Retry Integrity Tag (128),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Source Connection ID (0..160) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Retry Integrity Tag (128) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Retry Packet Figure 17: Retry Packet
A Retry packet (shown in Figure 14) 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 long header, it contains these additional server. In addition to the fields from the long header, it contains
fields: these additional fields:
Retry Token: An opaque token that the server can use to validate the Retry Token: An opaque token that the server can use to validate the
client's address. client's address.
Retry Integrity Tag: See the Retry Packet Integrity section of Retry Integrity Tag: See the Retry Packet Integrity section of
[QUIC-TLS]. [QUIC-TLS].
17.2.5.1. Sending a Retry Packet
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
Initial or 0-RTT packets. A server MUST NOT send more than one Retry Initial or 0-RTT packets. A server MUST NOT send more than one Retry
packet in response to a single UDP datagram. packet in response to a single UDP datagram.
17.2.5.2. Handling a Retry Packet
A client MUST accept and process at most one Retry packet for each A client MUST accept and process at most one Retry packet for each
connection attempt. After the client has received and processed an connection attempt. After the client has received and processed an
Initial or Retry packet from the server, it MUST discard any Initial or Retry packet from the server, it MUST discard any
subsequent Retry packets that it receives. subsequent Retry packets that it receives.
Clients MUST discard Retry packets that have a Retry Integrity Tag Clients MUST discard Retry packets that have a Retry Integrity Tag
that cannot be validated, see the Retry Packet Integrity section of that cannot be validated, see the Retry Packet Integrity section of
[QUIC-TLS]. This diminishes an off-path attacker's ability to inject [QUIC-TLS]. This diminishes an off-path attacker's ability to inject
a Retry packet and protects against accidental corruption of Retry a Retry packet and protects against accidental corruption of Retry
packets. A client MUST discard a Retry packet with a zero-length packets. A client MUST discard a Retry packet with a zero-length
skipping to change at page 102, line 8 skipping to change at page 109, line 11
The client responds to a Retry packet with an Initial packet that The client responds to a Retry packet with an Initial packet that
includes the provided Retry Token to continue connection includes the provided Retry Token to continue connection
establishment. establishment.
A client sets the Destination Connection ID field of this Initial A client sets the Destination Connection ID field of this Initial
packet to the value from the Source Connection ID in the Retry packet to the value from the Source Connection ID in the Retry
packet. Changing Destination Connection ID also results in a change packet. Changing Destination Connection ID also results in a change
to the keys used to protect the Initial packet. It also sets the to the keys used to protect the Initial packet. It also sets the
Token field to the token provided in the Retry. The client MUST NOT Token field to the token provided in the Retry. The client MUST NOT
change the Source Connection ID because the server could include the change the Source Connection ID because the server could include the
connection ID as part of its token validation logic (see connection ID as part of its token validation logic; see
Section 8.1.4). Section 8.1.4.
A Retry packet does not include a packet number and cannot be
explicitly acknowledged by a client.
17.2.5.3. Continuing a Handshake After Retry
The next Initial packet from the client uses the connection ID and The next Initial packet from the client uses the connection ID and
token values from the Retry packet (see Section 7.2). Aside from token values from the Retry packet; see Section 7.2. Aside from
this, the Initial packet sent by the client is subject to the same this, the Initial packet sent by the client is subject to the same
restrictions as the first Initial packet. A client MUST use the same restrictions as the first Initial packet. A client MUST use the same
cryptographic handshake message it includes in this packet. A server cryptographic handshake message it includes in this packet. A server
MAY treat a packet that contains a different cryptographic handshake MAY treat a packet that contains a different cryptographic handshake
message as a connection error or discard it. message as a connection error or discard it.
A client MAY attempt 0-RTT after receiving a Retry packet by sending A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server. A client 0-RTT packets to the connection ID provided by the server. A client
MUST NOT change the cryptographic handshake message it sends in MUST NOT change the cryptographic handshake message it sends in
response to receiving a Retry. response to receiving a Retry.
A client MUST NOT reset the packet number for any packet number space A client MUST NOT reset the packet number for any packet number space
after processing a Retry packet; Section 17.2.3 contains more after processing a Retry packet; Section 17.2.3 contains more
information on this. information on this.
A server acknowledges the use of a Retry packet for a connection A server acknowledges the use of a Retry packet for a connection
using the original_connection_id transport parameter (see using the retry_source_connection_id transport parameter; see
Section 18.2). If the server sends a Retry packet, it MUST include Section 18.2. If the server sends a Retry packet, it also
the Destination Connection ID field from the client's first Initial subsequently includes the value of the Source Connection ID field
packet in the transport parameter. from the Retry packet in its retry_source_connection_id transport
parameter.
If the client received and processed a Retry packet, it MUST validate If the client received and processed a Retry packet, it MUST validate
that the original_connection_id transport parameter is present and that the retry_source_connection_id transport parameter is present
correct; otherwise, it MUST validate that the transport parameter is and correct; otherwise, it MUST validate that the transport parameter
absent. A client MUST treat a failed validation as a connection is absent. A client MUST treat a failed validation as a connection
error of type TRANSPORT_PARAMETER_ERROR. error of type PROTOCOL_VIOLATION.
A Retry packet does not include a packet number and cannot be
explicitly acknowledged by a client.
17.3. Short Header Packets 17.3. Short Header Packets
This version of QUIC defines a single packet type which uses the This version of QUIC defines a single packet type which uses the
short packet header. short packet header.
0 1 2 3 Short Header Packet {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Header Form (1) = 0,
+-+-+-+-+-+-+-+-+ Fixed Bit (1) = 1,
|0|1|S|R|R|K|P P| Spin Bit (1),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved Bits (2),
| Destination Connection ID (0..160) ... Key Phase (1),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Number Length (2),
| Packet Number (8/16/24/32) ... Destination Connection ID (0..160),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Number (8..32),
| Protected Payload (*) ... Packet Payload (..),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
Figure 15: Short Header Packet Format Figure 18: Short Header Packet Format
The short header can be used after the version and 1-RTT keys are The short header can be used after the version and 1-RTT keys are
negotiated. Packets that use the short header contain the following negotiated. Packets that use the short header contain the following
fields: fields:
Header Form: The most significant bit (0x80) of byte 0 is set to 0 Header Form: The most significant bit (0x80) of byte 0 is set to 0
for the short header. for the short header.
Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets
containing a zero value for this bit are not valid packets in this containing a zero value for this bit are not valid packets in this
version and MUST be discarded. version and MUST be discarded.
Spin Bit (S): The third most significant bit (0x20) of byte 0 is the Spin Bit: The third most significant bit (0x20) of byte 0 is the
latency spin bit, set as described in Section 17.3.1. latency spin bit, set as described in Section 17.3.1.
Reserved Bits (R): The next two bits (those with a mask of 0x18) of Reserved Bits: The next two bits (those with a mask of 0x18) of byte
byte 0 are reserved. These bits are protected using header 0 are reserved. These bits are protected using header protection;
protection (see Section 5.4 of [QUIC-TLS]). The value included see Section 5.4 of [QUIC-TLS]. The value included prior to
prior to protection MUST be set to 0. An endpoint MUST treat protection MUST be set to 0. An endpoint MUST treat receipt of a
receipt of a packet that has a non-zero value for these bits, packet that has a non-zero value for these bits, after removing
after removing both packet and header protection, as a connection both packet and header protection, as a connection error of type
error of type PROTOCOL_VIOLATION. Discarding such a packet after PROTOCOL_VIOLATION. Discarding such a packet after only removing
only removing header protection can expose the endpoint to attacks header protection can expose the endpoint to attacks; see
(see Section 9.3 of [QUIC-TLS]). Section 9.3 of [QUIC-TLS].
Key Phase (K): The next bit (0x04) of byte 0 indicates the key Key Phase: The next bit (0x04) of byte 0 indicates the key phase,
phase, which allows a recipient of a packet to identify the packet which allows a recipient of a packet to identify the packet
protection keys that are used to protect the packet. See protection keys that are used to protect the packet. See
[QUIC-TLS] for details. This bit is protected using header [QUIC-TLS] for details. This bit is protected using header
protection (see Section 5.4 of [QUIC-TLS]). protection; see Section 5.4 of [QUIC-TLS].
Packet Number Length (P): The least significant two bits (those with Packet Number Length: The least significant two bits (those with a
a mask of 0x03) of byte 0 contain the length of the packet number, mask of 0x03) of byte 0 contain the length of the packet number,
encoded as an unsigned, two-bit integer that is one less than the encoded as an unsigned, two-bit integer that is one less than the
length of the packet number field in bytes. That is, the length length of the packet number field in bytes. That is, the length
of the packet number field is the value of this field, plus one. of the packet number field is the value of this field, plus one.
These bits are protected using header protection (see Section 5.4 These bits are protected using header protection; see Section 5.4
of [QUIC-TLS]). of [QUIC-TLS].
Destination Connection ID: The Destination Connection ID is a Destination Connection ID: The Destination Connection ID is a
connection ID that is chosen by the intended recipient of the connection ID that is chosen by the intended recipient of the
packet. See Section 5.1 for more details. packet. See Section 5.1 for more details.
Packet Number: The packet number field is 1 to 4 bytes long. The Packet Number: The packet number field is 1 to 4 bytes long. The
packet number has confidentiality protection separate from packet packet number has confidentiality protection separate from packet
protection, as described in Section 5.4 of [QUIC-TLS]. The length protection, as described in Section 5.4 of [QUIC-TLS]. The length
of the packet number field is encoded in Packet Number Length of the packet number field is encoded in Packet Number Length
field. See Section 17.1 for details. field. See Section 17.1 for details.
Protected Payload: Packets with a short header always include a Packet Payload: Packets with a short header always include a 1-RTT
1-RTT protected payload. protected payload.
The header form bit and the connection ID field of a short header The header form bit and the connection ID field of a short header
packet are version-independent. The remaining fields are specific to packet are version-independent. The remaining fields are specific to
the selected QUIC version. See [QUIC-INVARIANTS] for details on how the selected QUIC version. See [QUIC-INVARIANTS] for details on how
packets from different versions of QUIC are interpreted. packets from different versions of QUIC are interpreted.
17.3.1. Latency Spin Bit 17.3.1. Latency Spin Bit
The latency spin bit enables passive latency monitoring from The latency spin bit enables passive latency monitoring from
observation points on the network path throughout the duration of a observation points on the network path throughout the duration of a
skipping to change at page 105, line 38 skipping to change at page 112, line 38
the risk that transient spin bit state can be used to link flows the risk that transient spin bit state can be used to link flows
across connection migration or ID change. across connection migration or ID change.
With this mechanism, the server reflects the spin value received, With this mechanism, the server reflects the spin value received,
while the client 'spins' it after one RTT. On-path observers can while the client 'spins' it after one RTT. On-path observers can
measure the time between two spin bit toggle events to estimate the measure the time between two spin bit toggle events to estimate the
end-to-end RTT of a connection. end-to-end RTT of a connection.
18. Transport Parameter Encoding 18. Transport Parameter Encoding
The "extension_data" field of the quic_transport_parameters extension The extension_data field of the quic_transport_parameters extension
defined in [QUIC-TLS] contains the QUIC transport parameters. They defined in [QUIC-TLS] contains the QUIC transport parameters. They
are encoded as a sequence of transport parameters, as shown in are encoded as a sequence of transport parameters, as shown in
Figure 16: Figure 19:
0 1 2 3 Transport Parameters {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Transport Parameter (..) ...,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Transport Parameter 1 (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Parameter 2 (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Parameter N (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Sequence of Transport Parameters Figure 19: Sequence of Transport Parameters
Each transport parameter is encoded as an (identifier, length, value) Each transport parameter is encoded as an (identifier, length, value)
tuple, as shown in Figure 17: tuple, as shown in Figure 20:
0 1 2 3 Transport Parameter {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Transport Parameter ID (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transport Parameter Length (i),
| Transport Parameter ID (i) ... Transport Parameter Value (..),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Transport Parameter Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Parameter Value (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Transport Parameter Encoding Figure 20: Transport Parameter Encoding
The Transport Param Length field contains the length of the Transport The Transport Parameter Length field contains the length of the
Parameter Value field. Transport Parameter Value field.
QUIC encodes transport parameters into a sequence of bytes, which are QUIC encodes transport parameters into a sequence of bytes, which are
then included in the cryptographic handshake. then included in the cryptographic handshake.
18.1. Reserved Transport Parameters 18.1. Reserved Transport Parameters
Transport parameters with an identifier of the form "31 * N + 27" for Transport parameters with an identifier of the form "31 * N + 27" for
integer values of N are reserved to exercise the requirement that integer values of N are reserved to exercise the requirement that
unknown transport parameters be ignored. These transport parameters unknown transport parameters be ignored. These transport parameters
have no semantics, and may carry arbitrary values. have no semantics, and may carry arbitrary values.
18.2. Transport Parameter Definitions 18.2. Transport Parameter Definitions
This section details the transport parameters defined in this This section details the transport parameters defined in this
document. document.
Many transport parameters listed here have integer values. Those Many transport parameters listed here have integer values. Those
transport parameters that are identified as integers use a variable- transport parameters that are identified as integers use a variable-
length integer encoding (see Section 16) and have a default value of length integer encoding; see Section 16. Transport parameters have a
0 if the transport parameter is absent, unless otherwise stated. default value of 0 if the transport parameter is absent unless
otherwise stated.
The following transport parameters are defined: The following transport parameters are defined:
original_connection_id (0x00): The value of the Destination original_destination_connection_id (0x00): The value of the
Connection ID field from the first Initial packet sent by the Destination Connection ID field from the first Initial packet sent
client. This transport parameter is only sent by a server. This by the client; see Section 7.3. This transport parameter is only
is the same value sent in the "Original Destination Connection ID" sent by a server.
field of a Retry packet (see Section 17.2.5). A server MUST
include the original_connection_id transport parameter if it sent
a Retry packet.
max_idle_timeout (0x01): The max idle timeout is a value in max_idle_timeout (0x01): The max idle timeout is a value in
milliseconds that is encoded as an integer; see (Section 10.2). milliseconds that is encoded as an integer; see (Section 10.2).
Idle timeout is disabled when both endpoints omit this transport Idle timeout is disabled when both endpoints omit this transport
parameter or specify a value of 0. parameter or specify a value of 0.
stateless_reset_token (0x02): A stateless reset token is used in stateless_reset_token (0x02): A stateless reset token is used in
verifying a stateless reset; see Section 10.4. This parameter is verifying a stateless reset; see Section 10.4. This parameter is
a sequence of 16 bytes. This transport parameter MUST NOT be sent a sequence of 16 bytes. This transport parameter MUST NOT be sent
by a client, but MAY be sent by a server. A server that does not by a client, but MAY be sent by a server. A server that does not
send this transport parameter cannot use stateless reset send this transport parameter cannot use stateless reset
(Section 10.4) for the connection ID negotiated during the (Section 10.4) for the connection ID negotiated during the
handshake. handshake.
max_packet_size (0x03): The maximum packet size parameter is an max_udp_payload_size (0x03): The maximum UDP payload size parameter
integer value that limits the size of packets that the endpoint is is an integer value that limits the size of UDP payloads that the
willing to receive. This indicates that packets larger than this endpoint is willing to receive. UDP packets with payloads larger
limit will be dropped. The default for this parameter is the than this limit are not likely to be processed by the receiver.
maximum permitted UDP payload of 65527. Values below 1200 are
invalid. This limit only applies to protected packets The default for this parameter is the maximum permitted UDP
(Section 12.1). payload of 65527. Values below 1200 are invalid.
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
endpoint and not the path. It is expected that 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 109, line 20 skipping to change at page 116, line 8
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). Peers of an endpoint
that sets this transport parameter MUST NOT send any packets, that sets this transport parameter MUST NOT send any packets,
including probing packets (Section 9.1), from a local address or including probing packets (Section 9.1), from a local address or
port other than that used to perform the handshake. This port other than that used to perform the handshake. 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 18. 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. The CID Length field contains the encoded in network byte order.
length of the Connection ID field.
0 1 2 3 The Connection ID field and the Stateless Reset Token field
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 contain an alternative connection ID that has a sequence number of
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1; see Section 5.1.1. Having these values bundled with the
| IPv4 Address (32) | preferred address ensures that there will be at least one unused
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ active connection ID when the client initiates migration to the
| IPv4 Port (16) | preferred address.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address (128) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Port (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID Length (8)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection ID (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Stateless Reset Token (128) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Preferred Address format The Connection ID and Stateless Reset Token fields of a preferred
address are identical in syntax and semantics to the corresponding
fields of a NEW_CONNECTION_ID frame (Section 19.15). A server
that chooses a zero-length connection ID MUST NOT provide a
preferred address. Similarly, a server MUST NOT include a zero-
length connection ID in this transport parameter. A client MUST
treat violation of these requirements as a connection error of
type TRANSPORT_PARAMETER_ERROR.
Preferred Address {
IPv4 Address (32),
IPv4 Port (16),
IPv6 Address (128),
IPv6 Port (16),
CID Length (8),
Connection ID (..),
Stateless Reset Token (128),
}
Figure 21: Preferred Address format
active_connection_id_limit (0x0e): The active connection ID limit is active_connection_id_limit (0x0e): The active connection ID limit is
an integer value specifying the maximum number of connection IDs an integer value specifying the maximum number of connection IDs
from the peer that an endpoint is willing to store. This value from the peer that an endpoint is willing to store. This value
includes the connection ID received during the handshake, that includes the connection ID received during the handshake, that
received in the preferred_address transport parameter, and those received in the preferred_address transport parameter, and those
received in NEW_CONNECTION_ID frames. Unless a zero-length received in NEW_CONNECTION_ID frames. The value of the
connection ID is being used, the value of the active_connection_id_limit parameter MUST be at least 2. An
active_connection_id_limit parameter MUST be no less than 2. If endpoint that receives a value less than 2 MUST close the
this transport parameter is absent, a default of 2 is assumed. connection with an error of type TRANSPORT_PARAMETER_ERROR. If
When a zero-length connection ID is being used, the this transport parameter is absent, a default of 2 is assumed. If
active_connection_id_limit parameter MUST NOT be sent. an endpoint issues a zero-length connection ID, it will never send
a NEW_CONNECTION_ID frame and therefore ignores the
active_connection_id_limit value received from its peer.
initial_source_connection_id (0x0f): The value that the endpoint
included in the Source Connection ID field of the first Initial
packet it sends for the connection; see Section 7.3.
retry_source_connection_id (0x10): The value that the the server
included in the Source Connection ID field of a Retry packet; see
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.
A client MUST NOT include server-only transport parameters A client MUST NOT include any server-only transport parameter:
(original_connection_id, stateless_reset_token, or original_destination_connection_id, preferred_address,
preferred_address). A server MUST treat receipt of any of these retry_source_connection_id, or stateless_reset_token. A server MUST
transport parameters as a connection error of type treat receipt of any of these transport parameters as a connection
TRANSPORT_PARAMETER_ERROR. error of type TRANSPORT_PARAMETER_ERROR.
19. Frame Types and Formats 19. Frame Types and Formats
As described in Section 12.4, packets contain one or more frames. As described in Section 12.4, packets contain one or more frames.
This section describes the format and semantics of the core QUIC This section describes the format and semantics of the core QUIC
frame types. frame types.
19.1. PADDING Frame 19.1. PADDING Frame
The PADDING frame (type=0x00) has no semantic value. PADDING frames The PADDING frame (type=0x00) has no semantic value. PADDING frames
skipping to change at page 111, line 50 skipping to change at page 118, line 28
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. An application protocol SHOULD provide guidance
about the conditions under which generating a PING is recommended. about the conditions under which generating a PING is recommended.
This guidance SHOULD indicate whether it is the client or the server This guidance SHOULD indicate whether it is the client or the server
that is expected to send the PING. Having both endpoints send PING that is expected to send the PING. Having both endpoints send PING
frames without coordination can produce an excessive number of frames without coordination can produce an excessive number of
packets and poor performance. packets and poor performance.
A connection will time out if no packets are sent or received for a A connection will time out if no packets are sent or received for a
period longer than the time negotiated using the max_idle_timeout period longer than the time negotiated using the max_idle_timeout
transport parameter (see Section 10). However, state in middleboxes transport parameter; see Section 10. However, state in middleboxes
might time out earlier than that. Though REQ-5 in [RFC4787] might time out earlier than that. Though REQ-5 in [RFC4787]
recommends a 2 minute timeout interval, experience shows that sending recommends a 2 minute timeout interval, experience shows that sending
packets every 15 to 30 seconds is necessary to prevent the majority packets every 15 to 30 seconds is necessary to prevent the majority
of middleboxes from losing state for UDP flows. 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
skipping to change at page 112, line 34 skipping to change at page 119, 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 19. An ACK frame is shown in Figure 22.
0 1 2 3 ACK Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x02..0x03,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Largest Acknowledged (i),
| Largest Acknowledged (i) ... ACK Delay (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACK Range Count (i),
| ACK Delay (i) ... First ACK Range (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACK Range (..) ...,
| ACK Range Count (i) ... [ECN Counts (..)],
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| First ACK Range (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 22: ACK Frame Format
| ACK Ranges (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ECN Counts] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: 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
microseconds between when this ACK was sent and when the largest microseconds between when this ACK was sent and when the largest
acknowledged packet, as indicated in the Largest Acknowledged acknowledged packet, as indicated in the Largest Acknowledged
field, was received by this peer. The value of the ACK Delay field, was received by this peer. The value of the ACK Delay
field is scaled by multiplying the encoded value by 2 to the power field is scaled by multiplying the encoded value by 2 to the power
of the value of the "ack_delay_exponent" transport parameter set of the value of the ack_delay_exponent transport parameter set by
by the sender of the ACK frame (see Section 18.2). Scaling in the sender of the ACK frame; see Section 18.2. Scaling in this
this fashion allows for a larger range of values with a shorter fashion allows for a larger range of values with a shorter
encoding at the cost of lower resolution. Because the receiver encoding at the cost of lower resolution. Because the receiver
doesn't use the ACK Delay for Initial and Handshake packets, a doesn't use the ACK Delay for Initial and Handshake packets, a
sender SHOULD send a value of 0. sender SHOULD send a value of 0.
ACK Range Count: A variable-length integer specifying the number of ACK Range Count: A variable-length integer specifying the number of
Gap and ACK Range fields in the frame. Gap and ACK Range fields in the frame.
First ACK Range: A variable-length integer indicating the number of First ACK Range: A variable-length integer indicating the number of
contiguous packets preceding the Largest Acknowledged that are contiguous packets preceding the Largest Acknowledged that are
being acknowledged. The First ACK Range is encoded as an ACK being acknowledged. The First ACK Range is encoded as an ACK
Range (see Section 19.3.1) starting from the Largest Acknowledged. Range; see Section 19.3.1 starting from the Largest Acknowledged.
That is, the smallest packet acknowledged in the range is That is, the smallest packet acknowledged in the range is
determined by subtracting the First ACK Range value from the determined by subtracting the First ACK Range value from the
Largest Acknowledged. Largest Acknowledged.
ACK Ranges: Contains additional ranges of packets which are ACK Ranges: Contains additional ranges of packets which are
alternately not acknowledged (Gap) and acknowledged (ACK Range); alternately not acknowledged (Gap) and acknowledged (ACK Range);
see Section 19.3.1. see Section 19.3.1.
ECN Counts: The three ECN Counts; see Section 19.3.2. ECN Counts: The three ECN Counts; see Section 19.3.2.
19.3.1. ACK Ranges 19.3.1. ACK Ranges
The ACK Ranges field consists of alternating Gap and ACK Range values Each ACK Range consists of alternating Gap and ACK Range values in
in descending packet number order. The number of Gap and ACK Range descending packet number order. ACK Ranges can be repeated. The
values is determined by the ACK Range Count field; one of each value number of Gap and ACK Range values is determined by the ACK Range
is present for each value in the ACK Range Count field. Count field; one of each value is present for each value in the ACK
Range Count field.
ACK Ranges are structured as shown in Figure 20. ACK Ranges are structured as shown in Figure 23.
0 1 2 3 ACK Range {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Gap (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACK Range Length (i),
| [Gap (i)] ... }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ACK Range (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Gap (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ACK Range (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Gap (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ACK Range (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: ACK Ranges Figure 23: ACK Ranges
The fields that form the ACK Ranges are: The fields that form each ACK Range are:
Gap (repeated): A variable-length integer indicating the number of Gap: A variable-length integer indicating the number of contiguous
contiguous unacknowledged packets preceding the packet number one unacknowledged packets preceding the packet number one lower than
lower than the smallest in the preceding ACK Range. the smallest in the preceding ACK Range.
ACK Range (repeated): A variable-length integer indicating the ACK Range Length: A variable-length integer indicating the number of
number of contiguous acknowledged packets preceding the largest contiguous acknowledged packets preceding the largest packet
packet number, as determined by the preceding Gap. number, as determined by the preceding Gap.
Gap and ACK Range value use a relative integer encoding for Gap and ACK Range value use a relative integer encoding for
efficiency. Though each encoded value is positive, the values are efficiency. Though each encoded value is positive, the values are
subtracted, so that each ACK Range describes progressively lower- subtracted, so that each ACK Range describes progressively lower-
numbered packets. numbered packets.
Each ACK Range acknowledges a contiguous range of packets by Each ACK Range acknowledges a contiguous range of packets by
indicating the number of acknowledged packets that precede the indicating the number of acknowledged packets that precede the
largest packet number in that range. A value of zero indicates that largest packet number in that range. A value of zero indicates that
only the largest packet number is acknowledged. Larger ACK Range only the largest packet number is acknowledged. Larger ACK Range
skipping to change at page 115, line 28 skipping to change at page 121, 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 21. are 3 ECN counts, as shown in Figure 24.
0 1 2 3 ECN Counts {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ECT0 Count (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ECT1 Count (i),
| ECT(0) Count (i) ... ECN-CE Count (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| ECT(1) Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: ECN Count Format Figure 24: ECN Count Format
The three ECN Counts are: The three ECN Counts are:
ECT(0) Count: A variable-length integer representing the total ECT0 Count: A variable-length integer representing the total number
number of packets received with the ECT(0) codepoint in the packet of packets received with the ECT(0) codepoint in the packet number
number space of the ACK frame. space of the ACK frame.
ECT(1) Count: A variable-length integer representing the total ECT1 Count: A variable-length integer representing the total number
number of packets received with the ECT(1) codepoint in the packet of packets received with the ECT(1) codepoint in the packet number
number space of the ACK frame. space of the ACK frame.
CE Count: A variable-length integer representing the total number of CE Count: A variable-length integer representing the total number of
packets received with the CE codepoint in the packet number space packets received with the CE codepoint in the packet number space
of the ACK frame. of the ACK frame.
ECN counts are maintained separately for each packet number space. ECN counts are maintained separately for each packet number space.
19.4. RESET_STREAM Frame 19.4. RESET_STREAM Frame
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly
terminate the sending part of a stream. terminate the sending part of a stream.
After sending a RESET_STREAM, an endpoint ceases transmission and After sending a RESET_STREAM, an endpoint ceases transmission and
retransmission of STREAM frames on the identified stream. A receiver retransmission of STREAM frames on the identified stream. A receiver
of RESET_STREAM can discard any data that it already received on that of RESET_STREAM can discard any data that it already received on that
stream. stream.
An endpoint that receives a RESET_STREAM frame for a send-only stream An endpoint that receives a RESET_STREAM frame for a send-only stream
MUST terminate the connection with error STREAM_STATE_ERROR. MUST terminate the connection with error STREAM_STATE_ERROR.
The RESET_STREAM frame is shown in Figure 22. The RESET_STREAM frame is shown in Figure 25.
0 1 2 3 RESET_STREAM Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x04,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream ID (i),
| Stream ID (i) ... Application Protocol Error Code (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Final Size (i),
| Application Error Code (i) ... }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Final Size (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: RESET_STREAM Frame Format Figure 25: 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.
Final Size: A variable-length integer indicating the final size of Final Size: A variable-length integer indicating the final size of
the stream by the RESET_STREAM sender, in unit of bytes. the stream by the RESET_STREAM sender, in unit of bytes.
19.5. STOP_SENDING Frame 19.5. STOP_SENDING Frame
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that
incoming data is being discarded on receipt at application request. incoming data is being discarded on receipt at application request.
STOP_SENDING requests that a peer cease transmission on a stream. STOP_SENDING requests that a peer cease transmission on a stream.
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 23. The STOP_SENDING frame is shown in Figure 26.
0 1 2 3 STOP_SENDING Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x05,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream ID (i),
| Stream ID (i) ... Application Protocol Error Code (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Application Error Code (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: STOP_SENDING Frame Format Figure 26: 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 Error Code: A variable-length integer containing the Application Protocol Error Code: A variable-length integer
application-specified reason the sender is ignoring the stream containing the application-specified reason the sender is ignoring
(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 24. The CRYPTO frame is shown in Figure 27.
0 1 2 3 CRYPTO Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x06,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Offset (i),
| Offset (i) ... Length (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Crypto Data (..),
| Length (i) ... }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: CRYPTO Frame Format Figure 27: 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 118, line 48 skipping to change at page 124, 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 25. The NEW_TOKEN frame is shown in Figure 28.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: NEW_TOKEN Frame Format NEW_TOKEN Frame {
Type (i) = 0x07,
Token Length (i),
Token (..),
}
Figure 28: 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 120, line 9 skipping to change at page 126, line 5
* The LEN bit (0x02) in the frame type is set to indicate that there * The LEN bit (0x02) in the frame type is set to indicate that there
is a Length field present. If this bit is set to 0, the Length is a Length field present. If this bit is set to 0, the Length
field is absent and the Stream Data field extends to the end of field is absent and the Stream Data field extends to the end of
the packet. If this bit is set to 1, the Length field is present. the packet. If this bit is set to 1, the Length field is present.
* 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 that receives a STREAM frame for a send-only stream MUST An endpoint MUST terminate the connection with error
terminate the connection with error STREAM_STATE_ERROR. 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
stream.
The STREAM frames are shown in Figure 26. The STREAM frames are shown in Figure 29.
0 1 2 3 STREAM Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x08..0x0f,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream ID (i),
| Stream ID (i) ... [Offset (i)],
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Length (i)],
| [Offset (i)] ... Stream Data (..),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| [Length (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: STREAM Frame Format Figure 29: 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.
Length: A variable-length integer specifying the length of the Length: A variable-length integer specifying the length of the
Stream Data field in this STREAM frame. This field is present Stream Data field in this STREAM frame. This field is present
when the LEN bit is set to 1. When the LEN bit is set to 0, the when the LEN bit is set to 1. When the LEN bit is set to 0, the
Stream Data field consumes all the remaining bytes in the packet. Stream Data field consumes all the remaining bytes in the packet.
skipping to change at page 121, line 13 skipping to change at page 127, 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 27. The MAX_DATA frame is shown in Figure 30.
0 1 2 3 MAX_DATA Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x10,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Data (i),
| Maximum Data (i) ... }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: MAX_DATA Frame Format Figure 30: 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.
An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR
error if it receives more data than the maximum data value that it error if it receives more data than the maximum data value that it
has sent, unless this is a result of a change in the initial limits has sent, unless this is a result of a change in the initial limits;
(see Section 7.3.1). see Section 7.4.1.
19.10. MAX_STREAM_DATA Frame 19.10. MAX_STREAM_DATA Frame
The MAX_STREAM_DATA frame (type=0x11) is used in flow control to The MAX_STREAM_DATA frame (type=0x11) is used in flow control to
inform a peer of the maximum amount of data that can be sent on a 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 28. The MAX_STREAM_DATA frame is shown in Figure 31.
0 1 2 3 MAX_STREAM_DATA Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x11,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream ID (i),
| Stream ID (i) ... Maximum Stream Data (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Maximum Stream Data (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: MAX_STREAM_DATA Frame Format Figure 31: 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 122, line 36 skipping to change at page 128, line 34
stream. Loss or reordering can mean that the largest received offset stream. Loss or reordering can mean that the largest received offset
on a stream can be greater than the total size of data received on on a stream can be greater than the total size of data received on
that stream. Receiving STREAM frames might not increase the largest that stream. Receiving STREAM frames might not increase the largest
received offset. received offset.
The data sent on a stream MUST NOT exceed the largest maximum stream The data sent on a stream MUST NOT exceed the largest maximum stream
data value advertised by the receiver. An endpoint MUST terminate a data value advertised by the receiver. An endpoint MUST terminate a
connection with a FLOW_CONTROL_ERROR error if it receives more data connection with a FLOW_CONTROL_ERROR error if it receives more data
than the largest maximum stream data that it has sent for the than the largest maximum stream data that it has sent for the
affected stream, unless this is a result of a change in the initial affected stream, unless this is a result of a change in the initial
limits (see Section 7.3.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 29; The MAX_STREAMS frames are shown in Figure 32;
0 1 2 3 MAX_STREAMS Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x12..0x13,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Streams (i),
| Maximum Streams (i) ... }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: MAX_STREAMS Frame Format Figure 32: 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. Stream IDs cannot exceed 2^62-1, as it is not connection. This value cannot exceed 2^60, as it is not possible
possible to encode stream IDs larger than this value. Receipt of to encode stream IDs larger than 2^62-1. Receipt of a frame that
a frame that permits opening of a stream larger than this limit permits opening of a stream larger than this limit MUST be treated
MUST be treated as a FRAME_ENCODING_ERROR. as a FRAME_ENCODING_ERROR.
Loss or reordering can cause a MAX_STREAMS frame to be received which Loss or reordering can cause a MAX_STREAMS frame to be received which
states a lower stream limit than an endpoint has previously received. states a lower stream limit than an endpoint has previously received.
MAX_STREAMS frames which do not increase the stream limit MUST be MAX_STREAMS frames which do not increase the stream limit MUST be
ignored. ignored.
An endpoint MUST NOT open more streams than permitted by the current An endpoint MUST NOT open more streams than permitted by the current
stream limit set by its peer. For instance, a server that receives a stream limit set by its peer. For instance, a server that receives a
unidirectional stream limit of 3 is permitted to open stream 3, 7, unidirectional stream limit of 3 is permitted to open stream 3, 7,
and 11, but not stream 15. An endpoint MUST terminate a connection and 11, but not stream 15. An endpoint MUST terminate a connection
skipping to change at page 123, line 35 skipping to change at page 129, line 34
permitted. permitted.
Note that these frames (and the corresponding transport parameters) Note that these frames (and the corresponding transport parameters)
do not describe the number of streams that can be opened do not describe the number of streams that can be opened
concurrently. The limit includes streams that have been closed as concurrently. The limit includes streams that have been closed as
well as those that are open. well as those that are open.
19.12. DATA_BLOCKED Frame 19.12. DATA_BLOCKED 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 see Section 4. DATA_BLOCKED frames can be used as input to tuning of
of flow control algorithms (see Section 4.2). flow control algorithms; see Section 4.2.
The DATA_BLOCKED frame is shown in Figure 30. The DATA_BLOCKED frame is shown in Figure 33.
0 1 2 3 DATA_BLOCKED Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x14,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Data (i),
| Data Limit (i) ... }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: DATA_BLOCKED Frame Format Figure 33: DATA_BLOCKED Frame Format
DATA_BLOCKED frames contain the following fields: DATA_BLOCKED frames contain the following fields:
Data Limit: 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 31. The STREAM_DATA_BLOCKED frame is shown in Figure 34.
0 1 2 3 STREAM_DATA_BLOCKED Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x15,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream ID (i),
| Stream ID (i) ... Maximum Stream Data (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }
| Stream Data Limit (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: STREAM_DATA_BLOCKED Frame Format Figure 34: 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.
Stream Data Limit: A variable-length integer indicating the offset Maximum Stream Data: A variable-length integer indicating the offset
of the stream at which the blocking occurred. of the stream at which the blocking occurred.
19.14. STREAMS_BLOCKED Frames 19.14. STREAMS_BLOCKED Frames
A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when
it wishes to open a stream, but is unable to due to the maximum it wishes to open a stream, but is unable to due to the maximum
stream limit set by its peer (see Section 19.11). A STREAMS_BLOCKED stream limit set by its peer; see Section 19.11. A STREAMS_BLOCKED
frame of type 0x16 is used to indicate reaching the bidirectional frame of type 0x16 is used to indicate reaching the bidirectional
stream limit, and a STREAMS_BLOCKED frame of type 0x17 indicates stream limit, and a STREAMS_BLOCKED frame of type 0x17 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 32. The STREAMS_BLOCKED frames are shown in Figure 35.
0 1 2 3 STREAMS_BLOCKED Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x16..0x17,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Streams (i),
| Stream Limit (i) ... }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: STREAMS_BLOCKED Frame Format Figure 35: STREAMS_BLOCKED Frame Format
STREAMS_BLOCKED frames contain the following fields: STREAMS_BLOCKED frames contain the following fields:
Stream Limit: A variable-length integer indicating the stream limit Maximum Streams: A variable-length integer indicating the maximum
at the time the frame was sent. Stream IDs cannot exceed 2^62-1, number of streams allowed at the time the frame was sent. This
as it is not possible to encode stream IDs larger than this value. value cannot exceed 2^60, as it is not possible to encode stream
Receipt of a frame that encodes a larger stream ID MUST be treated IDs larger than 2^62-1. Receipt of a frame that encodes a larger
as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR. stream ID MUST be treated as a STREAM_LIMIT_ERROR or a
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 33. The NEW_CONNECTION_ID frame is shown in Figure 36.
0 1 2 3 NEW_CONNECTION_ID Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x18,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number (i),
| Sequence Number (i) ... Retire Prior To (i),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length (8),
| Retire Prior To (i) ... Connection ID (8..160),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stateless Reset Token (128),
| Length (8) | | }
+-+-+-+-+-+-+-+-+ Connection ID (8..160) +
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Stateless Reset Token (128) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: NEW_CONNECTION_ID Frame Format Figure 36: 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
connection ID. Values less than 1 and greater than 20 are invalid connection ID. Values less than 1 and greater than 20 are invalid
and MUST be treated as a connection error of type and MUST be treated as a connection error of type
FRAME_ENCODING_ERROR. FRAME_ENCODING_ERROR.
Connection ID: A connection ID of the specified length. Connection ID: A connection ID of the specified length.
Stateless Reset Token: A 128-bit value that will be used for a Stateless Reset Token: A 128-bit value that will be used for a
stateless reset when the associated connection ID is used (see stateless reset when the associated connection ID is used; see
Section 10.4). Section 10.4.
An endpoint MUST NOT send this frame if it currently requires that An endpoint MUST NOT send this frame if it currently requires that
its peer send packets with a zero-length Destination Connection ID. its peer send packets with a zero-length Destination Connection ID.
Changing the length of a connection ID to or from zero-length makes Changing the length of a connection ID to or from zero-length makes
it difficult to identify when the value of the connection ID changed. it difficult to identify when the value of the connection ID changed.
An endpoint that is sending packets with a zero-length Destination An endpoint that is sending packets with a zero-length Destination
Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
Transmission errors, timeouts and retransmissions might cause the Transmission errors, timeouts and retransmissions might cause the
skipping to change at page 126, line 43 skipping to change at page 132, line 26
error. A receiver can use the sequence number supplied in the error. A receiver can use the sequence number supplied in the
NEW_CONNECTION_ID frame to identify new connection IDs from old ones. NEW_CONNECTION_ID frame to identify new connection IDs from old ones.
If an endpoint receives a NEW_CONNECTION_ID frame that repeats a If an endpoint receives a NEW_CONNECTION_ID frame that repeats a
previously issued connection ID with a different Stateless Reset previously issued connection ID with a different Stateless Reset
Token or a different sequence number, or if a sequence number is used Token or a different sequence number, or if a sequence number is used
for different connection IDs, the endpoint MAY treat that receipt as for different connection IDs, the endpoint MAY treat that receipt as
a connection error of type PROTOCOL_VIOLATION. a connection error of type PROTOCOL_VIOLATION.
The Retire Prior To field counts connection IDs established during The Retire Prior To field counts connection IDs established during
connection setup and the preferred_address transport parameter (see connection setup and the preferred_address transport parameter; see
Section 5.1.2). The Retire Prior To field MUST be less than or equal Section 5.1.2. The Retire Prior To field MUST be less than or equal
to the Sequence Number field. Receiving a value greater than the to the Sequence Number field. Receiving a value greater than the
Sequence Number MUST be treated as a connection error of type Sequence Number MUST be treated as a connection error of type
FRAME_ENCODING_ERROR. FRAME_ENCODING_ERROR.
Once a sender indicates a Retire Prior To value, smaller values sent Once a sender indicates a Retire Prior To value, smaller values sent
in subsequent NEW_CONNECTION_ID frames have no effect. A receiver in subsequent NEW_CONNECTION_ID frames have no effect. A receiver
MUST ignore any Retire Prior To fields that do not increase the MUST ignore any Retire Prior To fields that do not increase the
largest received Retire Prior To value. largest received Retire Prior To value.
An endpoint that receives a NEW_CONNECTION_ID frame with a sequence An endpoint that receives a NEW_CONNECTION_ID frame with a sequence
number smaller than the Retire Prior To field of a previously number smaller than the Retire Prior To field of a previously
received NEW_CONNECTION_ID frame MUST immediately send a received NEW_CONNECTION_ID frame MUST send a corresponding
corresponding RETIRE_CONNECTION_ID frame that retires the newly RETIRE_CONNECTION_ID frame that retires the newly received connection
received connection ID. ID, unless it has already done so for that sequence number.
19.16. RETIRE_CONNECTION_ID Frame 19.16. RETIRE_CONNECTION_ID Frame
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to
indicate that it will no longer use a connection ID that was issued indicate that it will no longer use a connection ID that was issued
by its peer. This may include the connection ID provided during the by its peer. This may include the connection ID provided during the
handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a
request to the peer to send additional connection IDs for future use request to the peer to send additional connection IDs for future use;
(see Section 5.1). New connection IDs can be delivered to a peer see Section 5.1. New connection IDs can be delivered to a peer using
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 34. The RETIRE_CONNECTION_ID frame is shown in Figure 37.
0 1 2 3 RETIRE_CONNECTION_ID Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x19,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number (i),
| Sequence Number (i) ... }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: RETIRE_CONNECTION_ID Frame Format Figure 37: 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.
The sequence number specified in a RETIRE_CONNECTION_ID frame MUST The sequence number specified in a RETIRE_CONNECTION_ID frame MUST
NOT refer to the Destination Connection ID field of the packet in NOT refer to the Destination Connection ID field of the packet in
which the frame is contained. The peer MAY treat this as a which the frame is contained. The peer MAY treat this as a
connection error of type FRAME_ENCODING_ERROR. connection error of type FRAME_ENCODING_ERROR.
skipping to change at page 128, line 11 skipping to change at page 133, 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 35. The PATH_CHALLENGE frame is shown in Figure 38.
0 1 2 3 PATH_CHALLENGE Frame {
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type (i) = 0x1a,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data (64),
| | }
+ Data (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: PATH_CHALLENGE Frame Format Figure 38: 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 is identical to the PATH_CHALLENGE PATH_CHALLENGE frame. Its format, shown in Figure 39 is identical to
frame (Section 19.17). the PATH_CHALLENGE frame (Section 19.17).
PATH_RESPONSE Frame {
Type (i) = 0x1b,
Data (64),
}
Figure 39: 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 36. The CONNECTION_CLOSE frames are shown in Figure 40.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Frame Type (i) ] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36: CONNECTION_CLOSE Frame Format CONNECTION_CLOSE Frame {
Type (i) = 0x1c..0x1d,
Error Code (i),
[Frame Type (i)],
Reason Phrase Length (i),
Reason Phrase (..),
}
Figure 40: 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
skipping to change at page 129, line 49 skipping to change at page 135, line 31
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 an 1-RTT packet ([QUIC-TLS], Section 4). When an only be sent using 0-RTT or 1-RTT packets ([QUIC-TLS], Section 4).
application wishes to abandon a connection during the handshake, an When an application wishes to abandon a connection during the
endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error handshake, an endpoint can send a CONNECTION_CLOSE frame (type 0x1c)
code of 0x15a ("user_canceled" alert; see [TLS13]) in an Initial or a with an error code of APPLICATION_ERROR in an Initial or a Handshake
Handshake packet. 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. The HANDSHAKE_DONE
frame contains no additional fields. frame contains no additional fields.
This frame can only be sent by the server. Servers MUST NOT send a This frame can only be sent by the server. Servers MUST NOT send a
HANDSHAKE_DONE frame before completing the handshake. A server MUST HANDSHAKE_DONE frame before completing the handshake. A server MUST
treat receipt of a HANDSHAKE_DONE frame as a connection error of type treat receipt of a HANDSHAKE_DONE frame as a connection error of type
skipping to change at page 131, line 20 skipping to change at page 137, line 6
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 SERVER_BUSY (0x2): The server is currently busy and does not accept
any new connections. any new connections.
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.
FINAL_SIZE_ERROR (0x6): An endpoint received a STREAM frame FINAL_SIZE_ERROR (0x6): An endpoint received a STREAM frame
containing data that exceeded the previously established final containing data that exceeded the previously established final
size. Or an endpoint received a STREAM frame or a RESET_STREAM size. Or an endpoint received a STREAM frame or a RESET_STREAM
frame containing a final size that was lower than the size of frame containing a final size that was lower than the size of
stream data that was already received. Or an endpoint received a stream data that was already received. Or an endpoint received a
STREAM frame or a RESET_STREAM frame containing a different final STREAM frame or a RESET_STREAM frame containing a different final
size to the one already established. size to the one already established.
FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was
skipping to change at page 132, line 10 skipping to change at page 137, line 44
provided by the peer exceeds the advertised provided by the peer exceeds the advertised
active_connection_id_limit. active_connection_id_limit.
PROTOCOL_VIOLATION (0xA): An endpoint detected an error with PROTOCOL_VIOLATION (0xA): An endpoint detected an error with
protocol compliance that was not covered by more specific error protocol compliance that was not covered by more specific error
codes. codes.
INVALID_TOKEN (0xB): A server received a Retry Token in a client INVALID_TOKEN (0xB): A server received a Retry Token in a client
Initial that is invalid. Initial that is invalid.
APPLICATION_ERROR (0xC): The application or application protocol
caused the connection to be closed.
CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in
CRYPTO frames than it can buffer. CRYPTO frames than it can buffer.
CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range
of 256 values is reserved for carrying error codes specific to the of 256 values is reserved for carrying error codes specific to the
cryptographic handshake that is used. Codes for errors occurring cryptographic handshake that is used. Codes for errors occurring
when TLS is used for the crypto handshake are described in when TLS is used for the crypto handshake are described in
Section 4.8 of [QUIC-TLS]. Section 4.8 of [QUIC-TLS].
See Section 22.4 for details of registering new error codes. See Section 22.4 for details of registering new error codes.
skipping to change at page 134, line 16 skipping to change at page 139, line 49
An attacker might be able to receive an address validation token An attacker might be able to receive an address validation token
(Section 8) from a server and then release the IP address it used to (Section 8) from a server and then release the IP address it used to
acquire that token. At a later time, the attacker may initiate a acquire that token. At a later time, the attacker may initiate a
0-RTT connection with a server by spoofing this same address, which 0-RTT connection with a server by spoofing this same address, which
might now address a different (victim) endpoint. The attacker can might now address a different (victim) endpoint. The attacker can
thus potentially cause the server to send an initial congestion thus potentially cause the server to send an initial congestion
window's worth of data towards the victim. window's worth of data towards the victim.
Servers SHOULD provide mitigations for this attack by limiting the Servers SHOULD provide mitigations for this attack by limiting the
usage and lifetime of address validation tokens (see Section 8.1.3). usage and lifetime of address validation tokens; see Section 8.1.3.
21.3. Optimistic ACK Attack 21.3. Optimistic ACK Attack
An endpoint that acknowledges packets it has not received might cause An endpoint that acknowledges packets it has not received might cause
a congestion controller to permit sending at rates beyond what the a congestion controller to permit sending at rates beyond what the
network supports. An endpoint MAY skip packet numbers when sending network supports. An endpoint MAY skip packet numbers when sending
packets to detect this behavior. An endpoint can then immediately packets to detect this behavior. An endpoint can then immediately
close the connection with a connection error of type close the connection with a connection error of type
PROTOCOL_VIOLATION (see Section 10.3). PROTOCOL_VIOLATION; see Section 10.3.
21.4. Slowloris Attacks 21.4. Slowloris Attacks
The attacks commonly known as Slowloris [SLOWLORIS] try to keep many The attacks commonly known as Slowloris [SLOWLORIS] try to keep many
connections to the target endpoint open and hold them open as long as connections to the target endpoint open and hold them open as long as
possible. These attacks can be executed against a QUIC endpoint by possible. These attacks can be executed against a QUIC endpoint by
generating the minimum amount of activity necessary to avoid being generating the minimum amount of activity necessary to avoid being
closed for inactivity. This might involve sending small amounts of closed for inactivity. This might involve sending small amounts of
data, gradually opening flow control windows in order to control the data, gradually opening flow control windows in order to control the
sender rate, or manufacturing ACK frames that simulate a high loss sender rate, or manufacturing ACK frames that simulate a high loss
skipping to change at page 135, line 32 skipping to change at page 141, line 23
An adversarial endpoint can open lots of streams, exhausting state on An adversarial endpoint can open lots of streams, exhausting state on
an endpoint. The adversarial endpoint could repeat the process on a an endpoint. The adversarial endpoint could repeat the process on a
large number of connections, in a manner similar to SYN flooding large number of connections, in a manner similar to SYN flooding
attacks in TCP. attacks in TCP.
Normally, clients will open streams sequentially, as explained in Normally, clients will open streams sequentially, as explained in
Section 2.1. However, when several streams are initiated at short Section 2.1. However, when several streams are initiated at short
intervals, loss or reordering may cause STREAM frames that open intervals, loss or reordering may cause STREAM frames that open
streams to be received out of sequence. On receiving a higher- streams to be received out of sequence. On receiving a higher-
numbered stream ID, a receiver is required to open all intervening numbered stream ID, a receiver is required to open all intervening
streams of the same type (see Section 3.2). Thus, on a new streams of the same type; see Section 3.2. Thus, on a new
connection, opening stream 4000000 opens 1 million and 1 client- connection, opening stream 4000000 opens 1 million and 1 client-
initiated bidirectional streams. initiated bidirectional streams.
The number of active streams is limited by the The number of active streams is limited by the
initial_max_streams_bidi and initial_max_streams_uni transport initial_max_streams_bidi and initial_max_streams_uni transport
parameters, as explained in Section 4.5. If chosen judiciously, parameters, as explained in Section 4.5. If chosen judiciously,
these limits mitigate the effect of the stream commitment attack. these limits mitigate the effect of the stream commitment attack.
However, setting the limit too low could affect performance when However, setting the limit too low could affect performance when
applications expect to open large number of streams. applications expect to open large number of streams.
skipping to change at page 138, line 13 skipping to change at page 144, line 7
it no longer reaches its destination, while an off-path attacker it no longer reaches its destination, while an off-path attacker
observes the packets, but cannot prevent the original packet from observes the packets, but cannot prevent the original packet from
reaching its intended destination. An off-path attacker can also reaching its intended destination. An off-path attacker can also
transmit arbitrary packets. transmit arbitrary packets.
Properties of the handshake, protected packets, and connection Properties of the handshake, protected packets, and connection
migration are considered separately. migration are considered separately.
21.12.1. Handshake 21.12.1. Handshake
The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the The QUIC handshake incorporates the TLS 1.3 handshake and inherits
cryptographic properties described in Appendix E.1 of [TLS13]. the cryptographic properties described in Appendix E.1 of [TLS13].
Many of the security properties of QUIC depend on the TLS handshake
providing these properties. Any attack on the TLS handshake could
affect QUIC.
In addition to those properties, the handshake is intended to provide Any attack on the TLS handshake that compromises the secrecy or
some defense against DoS attacks on the handshake, as described uniqueness of session keys affects other security guarantees provided
below. by QUIC that depends on these keys. For instance, migration
(Section 9) depends on the efficacy of confidentiality protections,
both for the negotiation of keys using the TLS handshake and for QUIC
packet protection, to avoid linkability across network paths.
An attack on the integrity of the TLS handshake might allow an
attacker to affect the selection of application protocol or QUIC
version.
In addition to the properties provided by TLS, the QUIC handshake
provides some defense against DoS attacks on the handshake.
21.12.1.1. Anti-Amplification 21.12.1.1. Anti-Amplification
Address validation (Section 8) is used to verify that an entity that Address validation (Section 8) is used to verify that an entity that
claims a given address is able to receive packets at that address. claims a given address is able to receive packets at that address.
Address validation limits amplification attack targets to addresses Address validation limits amplification attack targets to addresses
for which an attacker is either on-path or off-path. for which an attacker is either on-path or off-path.
Prior to validation, endpoints are limited in what they are able to Prior to validation, endpoints are limited in what they are able to
send. During the handshake, a server cannot send more than three send. During the handshake, a server cannot send more than three
skipping to change at page 139, line 16 skipping to change at page 145, line 25
either side and therefore cause the client or server to have an either side and therefore cause the client or server to have an
incorrect view of the remote addresses. Such an attack is incorrect view of the remote addresses. Such an attack is
indistinguishable from the functions performed by a NAT. indistinguishable from the functions performed by a NAT.
21.12.1.4. Parameter Negotiation 21.12.1.4. Parameter Negotiation
The entire handshake is cryptographically protected, with the Initial The entire handshake is cryptographically protected, with the Initial
packets being encrypted with per-version keys and the Handshake and packets being encrypted with per-version keys and the Handshake and
later packets being encrypted with keys derived from the TLS key later packets being encrypted with keys derived from the TLS key
exchange. Further, parameter negotiation is folded into the TLS exchange. Further, parameter negotiation is folded into the TLS
transcript and thus provides the same security guarantees as ordinary transcript and thus provides the same integrity guarantees as
TLS negotiation. Thus, an attacker can observe the client's ordinary TLS negotiation. An attacker can observe the client's
transport parameters (as long as it knows the version-specific salt) transport parameters (as long as it knows the version-specific keys)
but cannot observe the server's transport parameters and cannot but cannot observe the server's transport parameters and cannot
influence parameter negotiation. influence parameter negotiation.
Connection IDs are unencrypted but integrity protected in all Connection IDs are unencrypted but integrity protected in all
packets. packets.
This version of QUIC does not incorporate a version negotiation This version of QUIC does not incorporate a version negotiation
mechanism; implementations of incompatible versions will simply fail mechanism; implementations of incompatible versions will simply fail
to establish a connection. to establish a connection.
skipping to change at page 147, line 15 skipping to change at page 153, line 31
Any stricter requirements for permanent registrations do not prevent Any stricter requirements for permanent registrations do not prevent
provisional registrations for affected codepoints. For instance, a provisional registrations for affected codepoints. For instance, a
provisional registration for a frame type Section 22.3 of 61 could be provisional registration for a frame type Section 22.3 of 61 could be
requested. requested.
All registrations made by Standards Track publications MUST be All registrations made by Standards Track publications MUST be
permanent. permanent.
All registrations in this document are assigned a permanent status All registrations in this document are assigned a permanent status
and list as contact both the IESG (ietf@ietf.org) and the QUIC and list as contact both the IESG (ietf@ietf.org) and the QUIC
working group (quic@ietf.org). working group (quic@ietf.org (mailto:quic@ietf.org)).
22.2. QUIC Transport Parameter Registry 22.2. QUIC Transport Parameter Registry
IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" IANA [SHALL add/has added] a registry for "QUIC Transport Parameters"
under a "QUIC" heading. under a "QUIC" heading.
The "QUIC Transport Parameters" registry governs a 62-bit space. The "QUIC Transport Parameters" registry governs a 62-bit space.
This registry follows the registration policy from Section 22.1. This registry follows the registration policy from Section 22.1.
Permanent registrations in this registry are assigned using the Permanent registrations in this registry are assigned using the
Specification Required policy [RFC8126]. Specification Required policy [RFC8126].
skipping to change at page 148, line 8 skipping to change at page 154, line 8
In addition to the fields in Section 22.1.1, permanent registrations In addition to the fields in Section 22.1.1, permanent registrations
in this registry MUST include the following fields: in this registry MUST include the following fields:
Parameter Name: A short mnemonic for the parameter. Parameter Name: A short mnemonic for the parameter.
The initial contents of this registry are shown in Table 6. The initial contents of this registry are shown in Table 6.
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| Value | Parameter Name | Specification | | Value | Parameter Name | Specification |
+=======+=====================================+===============+ +=======+=====================================+===============+
| 0x00 | original_connection_id | Section 18.2 | | 0x00 | original_destination_connection_id | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x01 | max_idle_timeout | Section 18.2 | | 0x01 | max_idle_timeout | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x02 | stateless_reset_token | Section 18.2 | | 0x02 | stateless_reset_token | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x03 | max_packet_size | Section 18.2 | | 0x03 | max_udp_payload_size | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x04 | initial_max_data | Section 18.2 | | 0x04 | initial_max_data | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x05 | initial_max_stream_data_bidi_local | Section 18.2 | | 0x05 | initial_max_stream_data_bidi_local | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 | | 0x06 | initial_max_stream_data_bidi_remote | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x07 | initial_max_stream_data_uni | Section 18.2 | | 0x07 | initial_max_stream_data_uni | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x08 | initial_max_streams_bidi | Section 18.2 | | 0x08 | initial_max_streams_bidi | Section 18.2 |
skipping to change at page 148, line 38 skipping to change at page 154, line 38
| 0x0a | ack_delay_exponent | Section 18.2 | | 0x0a | ack_delay_exponent | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x0b | max_ack_delay | Section 18.2 | | 0x0b | max_ack_delay | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x0c | disable_active_migration | Section 18.2 | | 0x0c | disable_active_migration | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x0d | preferred_address | Section 18.2 | | 0x0d | preferred_address | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x0e | active_connection_id_limit | Section 18.2 | | 0x0e | active_connection_id_limit | Section 18.2 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
| 0x0f | initial_source_connection_id | Section 18.2 |
+-------+-------------------------------------+---------------+
| 0x10 | retry_source_connection_id | Section 18.2 |
+-------+-------------------------------------+---------------+
Table 6: Initial QUIC Transport Parameters Entries Table 6: Initial QUIC Transport Parameters Entries
Additionally, each value of the format "31 * N + 27" for integer Additionally, each value of the format "31 * N + 27" for integer
values of N (that is, "27", "58", "89", ...) are reserved and MUST values of N (that is, 27, 58, 89, ...) are reserved and MUST NOT be
NOT be assigned by IANA. assigned by IANA.
22.3. QUIC Frame Type Registry 22.3. QUIC Frame Type Registry
IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
"QUIC" heading. "QUIC" heading.
The "QUIC Frame Types" registry governs a 62-bit space. This The "QUIC Frame Types" registry governs a 62-bit space. This
registry follows the registration policy from Section 22.1. registry follows the registration policy from Section 22.1.
Permanent registrations in this registry are assigned using the Permanent registrations in this registry are assigned using the
Specification Required policy [RFC8126], except for values between Specification Required policy [RFC8126], except for values between
skipping to change at page 149, line 17 skipping to change at page 155, line 21
of [RFC8126]. of [RFC8126].
In addition to the fields in Section 22.1.1, permanent registrations In addition to the fields in Section 22.1.1, permanent registrations
in this registry MUST include the following fields: in this registry MUST include the following fields:
Frame Name: A short mnemonic for the frame type. Frame Name: A short mnemonic for the frame type.
In addition to the advice in Section 22.1, specifications for new In addition to the advice in Section 22.1, specifications for new
permanent registrations SHOULD describe the means by which an permanent registrations SHOULD describe the means by which an
endpoint might determine that it can send the identified type of endpoint might determine that it can send the identified type of
frame. An accompanying transport parameter registration (see frame. An accompanying transport parameter registration is expected
Section 22.2) is expected for most registrations. Specifications for for most registrations; see Section 22.2. Specifications for
permanent registrations also needs to describe the format and permanent registrations also needs to describe the format and
assigned semantics of any fields in the frame. assigned semantics of any fields in the frame.
The initial contents of this registry are tabulated in Table 3. The initial contents of this registry are tabulated in Table 3.
22.4. QUIC Transport Error Codes Registry 22.4. QUIC Transport Error Codes Registry
IANA [SHALL add/has added] a registry for "QUIC Transport Error IANA [SHALL add/has added] a registry for "QUIC Transport Error
Codes" under a "QUIC" heading. Codes" under a "QUIC" heading.
skipping to change at page 150, line 46 skipping to change at page 156, line 46
| 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many | Section 20 | | 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many | Section 20 |
| | | connection IDs | | | | | connection IDs | |
| | | received | | | | | received | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xA | PROTOCOL_VIOLATION |Generic protocol| Section 20 | | 0xA | PROTOCOL_VIOLATION |Generic protocol| Section 20 |
| | | violation | | | | | violation | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xB | INVALID_TOKEN | Invalid Token | Section 20 | | 0xB | INVALID_TOKEN | Invalid Token | Section 20 |
| | | Received | | | | | Received | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xC | APPLICATION_ERROR | Application | Section 20 |
| | | error | |
+------+---------------------------+----------------+---------------+
| 0xD | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 | | 0xD | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 |
| | | buffer | | | | | buffer | |
| | | overflowed | | | | | overflowed | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
Table 7: Initial QUIC Transport Error Codes Entries Table 7: Initial QUIC Transport Error Codes Entries
23. References 23. References
23.1. Normative References 23.1. Normative References
[DPLPMTUD] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and [DPLPMTUD] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", Work in Progress, Internet-Draft, Datagram Transports", Work in Progress, Internet-Draft,
draft-ietf-tsvwg-datagram-plpmtud-08, 5 June 2019, draft-ietf-tsvwg-datagram-plpmtud-21, 12 May 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-tsvwg- <http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-
datagram-plpmtud-08.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-27, 21 February 2020, draft-ietf-quic-recovery-28, 20 May 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-27>. <https://tools.ietf.org/html/draft-ietf-quic-recovery-28>.
[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-27, 21 February 2020, Internet-Draft, draft-ietf-quic-tls-28, 20 May 2020,
<https://tools.ietf.org/html/draft-ietf-quic-tls-27>. <https://tools.ietf.org/html/draft-ietf-quic-tls-28>.
[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 152, line 43 skipping to change at page 158, line 48
Notification (ECN) Experimentation", RFC 8311, Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018, DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>. <https://www.rfc-editor.org/info/rfc8311>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
23.2. Informative References 23.2. Informative References
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[EARLY-DESIGN] [EARLY-DESIGN]
Roskind, J., "QUIC: Multiplexed Transport Over UDP", 2 Roskind, J., "QUIC: Multiplexed Transport Over UDP", 2
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-07, 21 February 2020, invariants-08, 20 May 2020, <https://tools.ietf.org/html/
<https://tools.ietf.org/html/draft-ietf-quic-invariants- draft-ietf-quic-invariants-08>.
07>.
[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-05, 5 July 2019, 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-05.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,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
[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>.
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22,
RFC 2360, DOI 10.17487/RFC2360, June 1998,
<https://www.rfc-editor.org/info/rfc2360>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[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>.
skipping to change at page 154, line 40 skipping to change at page 160, 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 37 shows how an implementation can decode The pseudo-code in Figure 41 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 155, line 30 skipping to change at page 161, 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 37: Sample Packet Number Decoding Algorithm Figure 41: 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 156, line 33 skipping to change at page 162, 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-26 C.1. Since draft-ietf-quic-transport-27
* Change format of transport paramters to use varints (#3294, #3169) * Allowed CONNECTION_CLOSE in any packet number space, with a
requirement to use a new transport-level error for application-
specific errors in Initial and Handshake packets (#3430, #3435,
#3440)
C.2. Since draft-ietf-quic-transport-25 * Clearer requirements for address validation (#2125, #3327)
* Security analysis of handshake and migration (#2143, #2387, #2925)
* The entire payload of a datagram is used when counting bytes for
mitigating amplification attacks (#3333, #3470)
* Connection IDs can be used at any time, including in the handshake
(#3348, #3560, #3438, #3565)
* Only one ACK should be sent for each instance of reordering
(#3357, #3361)
* Remove text allowing a server to proceed with a bad Retry token
(#3396, #3398)
* Ignore active_connection_id_limit with a zero-length connection ID
(#3427, #3426)
* Require active_connection_id_limit be remembered for 0-RTT (#3423,
#3425)
* Require ack_delay not be remembered for 0-RTT (#3433, #3545)
* Redefined max_packet_size to max_udp_datagram_size (#3471, #3473)
* Guidance on limiting outstanding attempts to retire connection IDs
(#3489, #3509, #3557, #3547)
* Restored text on dropping bogus Version Negotiation packets
(#3532, #3533)
* Clarified that largest acknowledged needs to be saved, but not
necessarily signaled in all cases (#3541, #3581)
* Addressed linkability risk with the use of preferred_address
(#3559, #3563)
C.2. Since draft-ietf-quic-transport-26
* Change format of transport parameters to use varints (#3294,
#3169)
C.3. 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.3. Since draft-ietf-quic-transport-24 C.4. 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 158, line 5 skipping to change at page 165, line 5
* Idle timeout is symmetric (#2602, #3099) * Idle timeout is symmetric (#2602, #3099)
* Prohibit IP fragmentation (#3243, #3280) * Prohibit IP fragmentation (#3243, #3280)
* Define the use of provisional registration for all registries * Define the use of provisional registration for all registries
(#3109, #3020, #3102, #3170) (#3109, #3020, #3102, #3170)
* Packets on one path must not adjust values for a different path * Packets on one path must not adjust values for a different path
(#2909, #3139) (#2909, #3139)
C.4. Since draft-ietf-quic-transport-23 C.5. 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 158, line 41 skipping to change at page 165, line 41
* 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.5. Since draft-ietf-quic-transport-22 C.6. 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 159, line 48 skipping to change at page 166, line 48
#2840, #2841) #2840, #2841)
* Explanation of the effect of Retry on 0-RTT packets (#2842, #2852) * Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)
* Cryptographic handshake needs to provide server transport * Cryptographic handshake needs to provide server transport
parameter encryption (#2920, #2921) parameter encryption (#2920, #2921)
* Moved ACK generation guidance from recovery draft to transport * Moved ACK generation guidance from recovery draft to transport
draft (#1860, #2916). draft (#1860, #2916).
C.6. Since draft-ietf-quic-transport-21 C.7. 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.7. Since draft-ietf-quic-transport-20 C.8. 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 160, line 49 skipping to change at page 167, line 49
* PATH_RESPONSE no longer needs to be received on the validated path * PATH_RESPONSE no longer needs to be received on the validated path
(#2582, #2580, #2579, #2637) (#2582, #2580, #2579, #2637)
* PATH_RESPONSE frames are not stored and retransmitted (#2724, * PATH_RESPONSE frames are not stored and retransmitted (#2724,
#2729) #2729)
* Document hack for enabling routing of ICMP when doing PMTU probing * Document hack for enabling routing of ICMP when doing PMTU probing
(#1243, #2402) (#1243, #2402)
C.8. Since draft-ietf-quic-transport-19 C.9. 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)
skipping to change at page 161, line 27 skipping to change at page 168, line 27
* The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) * The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
* Initial packets from clients need to be padded to 1200 unless a * Initial packets from clients need to be padded to 1200 unless a
Handshake packet is sent as well (#2522, #2523) Handshake packet is sent as well (#2522, #2523)
* CRYPTO frames can be discarded if too much data is buffered * CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524) (#1834, #2524)
* Stateless reset uses a short header packet (#2599, #2600) * Stateless reset uses a short header packet (#2599, #2600)
C.9. Since draft-ietf-quic-transport-18 C.10. 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.10. Since draft-ietf-quic-transport-17 C.11. 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 162, line 37 skipping to change at page 169, line 37
#2301) #2301)
* Allow server preferred address for both IPv4 and IPv6 (#2122, * Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296) #2296)
* Corrected requirements for migration to a preferred address * Corrected requirements for migration to a preferred address
(#2146, #2349) (#2146, #2349)
* ACK of non-existent packet is illegal (#2298, #2302) * ACK of non-existent packet is illegal (#2298, #2302)
C.11. Since draft-ietf-quic-transport-16 C.12. 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 163, line 44 skipping to change at page 170, line 44
* 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.12. Since draft-ietf-quic-transport-15 C.13. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
C.13. Since draft-ietf-quic-transport-14 C.14. 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.14. Since draft-ietf-quic-transport-13 C.15. 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 165, line 7 skipping to change at page 172, line 7
* Permit 0-RTT after receiving Version Negotiation or Retry (#1507, * Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621) #1514, #1621)
* Permit Retry in response to 0-RTT (#1547, #1552) * Permit Retry in response to 0-RTT (#1547, #1552)
* Looser verification of ECN counters to account for ACK loss * Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565) (#1555, #1481, #1565)
* Remove frame type field from APPLICATION_CLOSE (#1508, #1528) * Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
C.15. Since draft-ietf-quic-transport-12 C.16. 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 165, line 50 skipping to change at page 172, line 50
* Fixed sampling method for packet number encryption; the length * Fixed sampling method for packet number encryption; the length
field in long headers includes the packet number field in addition field in long headers includes the packet number field in addition
to the packet payload (#1387, #1389) to the packet payload (#1387, #1389)
* Stateless Reset is now symmetric and subject to size constraints * Stateless Reset is now symmetric and subject to size constraints
(#466, #1346) (#466, #1346)
* Added frame type extension mechanism (#58, #1473) * Added frame type extension mechanism (#58, #1473)
C.16. Since draft-ietf-quic-transport-11 C.17. 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.17. Since draft-ietf-quic-transport-10 C.18. 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 166, line 50 skipping to change at page 173, line 50
* 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.18. Since draft-ietf-quic-transport-09 C.19. 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 167, line 29 skipping to change at page 174, line 29
* Improved retransmission rules for all frame types: information is * Improved retransmission rules for all frame types: information is
retransmitted, not packets or frames (#463, #765, #1095, #1053) retransmitted, not packets or frames (#463, #765, #1095, #1053)
* Added an error code for server busy signals (#1137) * Added an error code for server busy signals (#1137)
* Endpoints now set the connection ID that their peer uses. * Endpoints now set the connection ID that their peer uses.
Connection IDs are variable length. Removed the Connection IDs are variable length. Removed the
omit_connection_id transport parameter and the corresponding short omit_connection_id transport parameter and the corresponding short
header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
C.19. Since draft-ietf-quic-transport-08 C.20. 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 168, line 10 skipping to change at page 175, line 10
* 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.20. Since draft-ietf-quic-transport-07 C.21. 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 169, line 5 skipping to change at page 176, line 5
* Address validation for connection migration (#161, #732, #878) * Address validation for connection migration (#161, #732, #878)
* Clearly defined retransmission rules for BLOCKED (#452, #65, #924) * Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
* negotiated_version is sent in server transport parameters (#710, * negotiated_version is sent in server transport parameters (#710,
#959) #959)
* Increased the range over which packet numbers are randomized * Increased the range over which packet numbers are randomized
(#864, #850, #964) (#864, #850, #964)
C.21. Since draft-ietf-quic-transport-06 C.22. 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.22. Since draft-ietf-quic-transport-05 C.23. 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.23. Since draft-ietf-quic-transport-04 C.24. 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 170, line 24 skipping to change at page 177, line 24
* Increased the maximum length of the Largest Acknowledged field in * Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
* truncate_connection_id is renamed to omit_connection_id (#659) * truncate_connection_id is renamed to omit_connection_id (#659)
* CONNECTION_CLOSE terminates the connection like TCP RST (#330, * CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
* Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) * Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
C.24. Since draft-ietf-quic-transport-03 C.25. 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.25. Since draft-ietf-quic-transport-02 C.26. 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 171, line 27 skipping to change at page 178, line 27
linkability (#232, #491, #496) linkability (#232, #491, #496)
* Transport parameters for 0-RTT are retained from a previous * Transport parameters for 0-RTT are retained from a previous
connection (#405, #513, #512) connection (#405, #513, #512)
- A client in 0-RTT no longer required to reset excess streams - A client in 0-RTT no longer required to reset excess streams
(#425, #479) (#425, #479)
* Expanded security considerations (#440, #444, #445, #448) * Expanded security considerations (#440, #444, #445, #448)
C.26. Since draft-ietf-quic-transport-01 C.27. 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)
skipping to change at page 173, line 25 skipping to change at page 180, line 25
* Remove error code and reason phrase from GOAWAY (#352, #355) * Remove error code and reason phrase from GOAWAY (#352, #355)
* GOAWAY includes a final stream number for both directions (#347) * GOAWAY includes a final stream number for both directions (#347)
* Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a * Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
* Defined priority as the responsibility of the application protocol * Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
C.27. Since draft-ietf-quic-transport-00 C.28. 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.28. Since draft-hamilton-quic-transport-protocol-01 C.29. 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
The original design and rationale behind this protocol draw The original design and rationale behind this protocol draw
significantly from work by Jim Roskind [EARLY-DESIGN]. significantly from work by Jim Roskind [EARLY-DESIGN].
The IETF QUIC Working Group received an enormous amount of support The IETF QUIC Working Group received an enormous amount of support
from many people. The following people provided substantive from many people. The following people provided substantive
contributions to this document: Alessandro Ghedini, Alyssa Wilk, contributions to this document:
Antoine Delignat-Lavaud, Brian Trammell, Christian Huitema, Colin
Perkins, David Schinazi, Dmitri Tikhonov, Eric Kinnear, Eric * Alessandro Ghedini
Rescorla, Gorry Fairhurst, Ian Swett, Igor Lubashev, 奥 一穂 (Kazuho
Oku), Lucas Pardue, Magnus Westerlund, Marten Seemann, Martin Duke, * Alyssa Wilk
Mike Bishop, Mikkel Fahnøe Jørgensen, Mirja Kühlewind, Nick Banks,
Nick Harper, Patrick McManus, Roberto Peon, Ryan Hamilton, Subodh * Antoine Delignat-Lavaud
Iyengar, Tatsuhiro Tsujikawa, Ted Hardie, Tom Jones, and Victor
Vasiliev. * Brian Trammell
* Christian Huitema
* Colin Perkins
* David Schinazi
* Dmitri Tikhonov
* Eric Kinnear
* Eric Rescorla
* Gorry Fairhurst
* Ian Swett
* Igor Lubashev
* 奥 一穂 (Kazuho Oku)
* Lucas Pardue
* Magnus Westerlund
* Marten Seemann
* Martin Duke
* Mike Bishop
* Mikkel Fahnøe Jørgensen
* Mirja Kühlewind
* Nick Banks
* Nick Harper
* Patrick McManus
* Roberto Peon
* Ryan Hamilton
* Subodh Iyengar
* Tatsuhiro Tsujikawa
* Ted Hardie
* Tom Jones
* Victor Vasiliev
Authors' Addresses Authors' Addresses
Jana Iyengar (editor) Jana Iyengar (editor)
Fastly Fastly
Email: jri.ietf@gmail.com Email: jri.ietf@gmail.com
Martin Thomson (editor) Martin Thomson (editor)
Mozilla Mozilla
 End of changes. 344 change blocks. 
1260 lines changed or deleted 1556 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/