draft-ietf-quic-transport-22.txt   draft-ietf-quic-transport-23.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: January 10, 2020 Mozilla Expires: March 15, 2020 Mozilla
July 09, 2019 September 12, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-22 draft-ietf-quic-transport-23
Abstract Abstract
This document defines the core of the QUIC transport protocol. This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation. control and the use of TLS for key negotiation.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2020. This Internet-Draft will expire on March 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 8
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Required Operations on Streams . . . . . . . . . . . . . 11
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 12 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 12
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 14 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 14
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 17
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 17 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 17
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 19
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 20 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 20
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 21 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 21
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 22 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 22
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 23
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 23 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 23
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 25 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 25
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 26 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 26
5.2. Matching Packets to Connections . . . . . . . . . . . . . 27 5.2. Matching Packets to Connections . . . . . . . . . . . . . 27
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 27 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 28
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 28 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 28
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 29 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 29
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 29 5.4. Required Operations on Connections . . . . . . . . . . . 29
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 29 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 30
6.2. Handling Version Negotiation Packets . . . . . . . . . . 29 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 30
6.2.1. Version Negotiation Between Draft Versions . . . . . 30 6.2. Handling Version Negotiation Packets . . . . . . . . . . 31
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 30 6.2.1. Version Negotiation Between Draft Versions . . . . . 31
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 31 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 31
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 32 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 32
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 33 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 33
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 35 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 34
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 35 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 36
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 37 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 36
7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 37 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 38
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 38
8.1. Address Validation During Connection Establishment . . . 38 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 38
8.1.1. Address Validation using Retry Packets . . . . . . . 39 8.1. Address Validation During Connection Establishment . . . 39
8.1.2. Address Validation for Future Connections . . . . . . 39 8.1.1. Address Validation using Retry Packets . . . . . . . 40
8.1.3. Address Validation Token Integrity . . . . . . . . . 41 8.1.2. Address Validation for Future Connections . . . . . . 40
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 42 8.1.3. Address Validation Token Integrity . . . . . . . . . 43
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 43 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 43
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 43 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 44
8.5. Successful Path Validation . . . . . . . . . . . . . . . 43 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 44
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43 8.5. Successful Path Validation . . . . . . . . . . . . . . . 44
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 44 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 45
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 45 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 45
9.2. Initiating Connection Migration . . . . . . . . . . . . . 45 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 46
9.3. Responding to Connection Migration . . . . . . . . . . . 46 9.2. Initiating Connection Migration . . . . . . . . . . . . . 47
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 47 9.3. Responding to Connection Migration . . . . . . . . . . . 47
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 47 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 48
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 48 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 48
9.4. Loss Detection and Congestion Control . . . . . . . . . . 49 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 49
9.5. Privacy Implications of Connection Migration . . . . . . 50 9.4. Loss Detection and Congestion Control . . . . . . . . . . 50
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 50 9.5. Privacy Implications of Connection Migration . . . . . . 51
9.6.1. Communicating a Preferred Address . . . . . . . . . . 51 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 52
9.6.2. Responding to Connection Migration . . . . . . . . . 51 9.6.1. Communicating a Preferred Address . . . . . . . . . . 52
9.6.3. Interaction of Client Migration and Preferred Address 52 9.6.2. Responding to Connection Migration . . . . . . . . . 52
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 52 9.6.3. Interaction of Client Migration and Preferred Address 53
10. Connection Termination . . . . . . . . . . . . . . . . . . . 53 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 53
10.1. Closing and Draining Connection States . . . . . . . . . 53 10. Connection Termination . . . . . . . . . . . . . . . . . . . 54
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 54 10.1. Closing and Draining Connection States . . . . . . . . . 54
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 55 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 55
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 56 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 56
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 59 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 57
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 59 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 60
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 60 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 61
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 61 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 62
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 61 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 62
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 62 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 63
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 62 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 64
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 63 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 64
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 63 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 64
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 64 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 65
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 66 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 66
13. Packetization and Reliability . . . . . . . . . . . . . . . . 68 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 67
13.1. Packet Processing and Acknowledgment . . . . . . . . . . 69 13. Packetization and Reliability . . . . . . . . . . . . . . . . 70
13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 69 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 71
13.1.2. Limiting ACK Ranges . . . . . . . . . . . . . . . . 70 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 71
13.1.3. ACK Frames and Packet Protection . . . . . . . . . . 70 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 71
13.2. Retransmission of Information . . . . . . . . . . . . . 71 13.2.2. Managing ACK Ranges . . . . . . . . . . . . . . . . 73
13.3. Explicit Congestion Notification . . . . . . . . . . . . 73 13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 73
13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 73 13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 73
13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 74 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 74
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 75 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 74
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 76 13.3. Retransmission of Information . . . . . . . . . . . . . 75
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 77 13.4. Explicit Congestion Notification . . . . . . . . . . . . 77
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 78 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 77
14.3.1. PMTU Probes Containing Source Connection ID . . . . 78 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 78
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 79 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 80
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 80 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 81
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 80 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 82
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 81 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 83
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 82 14.3.1. PMTU Probes Containing Source Connection ID . . . . 83
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 84 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 83
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 86 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 84
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 88 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 85
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 90 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 85
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 91 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 86
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 93 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 89
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 95 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 91
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 96 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 93
18.1. Transport Parameter Definitions . . . . . . . . . . . . 97 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 95
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 100 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 96
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 101 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 98
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 101 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 100
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 101 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 101
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 103 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 102
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 105 18.2. Transport Parameter Definitions . . . . . . . . . . . . 102
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 106 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 106
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 106 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 106
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 107 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 106
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 108 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 106
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 108 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 108
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 110 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 110
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 110 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 111
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 111 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 111
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 112 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 112
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 113 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 113
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 113 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 114
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 114 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 115
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 116 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 116
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 116 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 117
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 117 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 118
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 117 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 118
19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 118 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 119
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 119 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 119
20.1. Application Protocol Error Codes . . . . . . . . . . . . 120 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 121
21. Security Considerations . . . . . . . . . . . . . . . . . . . 120 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 122
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 120 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 123
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 121 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 123
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 122 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 124
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 122 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 124
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 122 20.1. Application Protocol Error Codes . . . . . . . . . . . . 126
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 123 21. Security Considerations . . . . . . . . . . . . . . . . . . . 126
21.7. Explicit Congestion Notification Attacks . . . . . . . . 123 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 126
21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 124 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 127
21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 124 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 127
21.10. Targeted Attacks by Routing . . . . . . . . . . . . . . 124 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 128
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 128
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 125 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 128
22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 126 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 129
22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 127 21.8. Explicit Congestion Notification Attacks . . . . . . . . 129
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 129 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 130
23.1. Normative References . . . . . . . . . . . . . . . . . . 130 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 130
23.2. Informative References . . . . . . . . . . . . . . . . . 131 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 130
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 133 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 133 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 131
B.1. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 134 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 132
B.2. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 134 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 133
B.3. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 135 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.4. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 135 23.1. Normative References . . . . . . . . . . . . . . . . . . 136
B.5. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 136 23.2. Informative References . . . . . . . . . . . . . . . . . 137
B.6. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 136 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 139
B.7. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 138 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 140
B.8. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 138 B.1. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 140
B.9. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 138 B.2. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 141
B.10. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 139 B.3. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 141
B.11. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 140 B.4. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 142
B.12. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 140 B.5. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 142
B.13. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 141 B.6. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 143
B.14. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 141 B.7. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 144
B.15. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 142 B.8. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 145
B.16. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 143 B.9. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 145
B.17. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 143 B.10. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 145
B.18. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 143 B.11. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 146
B.19. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 144 B.12. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 147
B.20. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 144 B.13. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 147
B.21. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 145 B.14. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 148
B.22. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 147 B.15. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 148
B.23. Since draft-hamilton-quic-transport-protocol-01 . . . . . 147 B.16. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 149
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 148 B.17. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 150
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 148 B.18. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 150
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 148 B.19. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 151
B.20. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 151
B.21. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 152
B.22. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 153
B.23. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 155
B.24. Since draft-hamilton-quic-transport-protocol-01 . . . . . 155
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 155
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 156
1. Introduction 1. Introduction
QUIC is a multiplexed and secure general-purpose transport protocol QUIC is a multiplexed and secure general-purpose transport protocol
that provides: that provides:
o Stream multiplexing o Stream multiplexing
o Stream and connection-level flow control o Stream and connection-level flow control
skipping to change at page 8, line 38 skipping to change at page 9, line 4
Packet and frame diagrams in this document use the format described Packet and frame diagrams in this document use the format described
in Section 3.1 of [RFC2360], with the following additional in Section 3.1 of [RFC2360], with the following additional
conventions: conventions:
[x]: Indicates that x is optional [x]: Indicates that x is optional
x (A): Indicates that x is A bits long x (A): Indicates that x is A bits long
x (A/B/C) ...: Indicates that x is one of A, B, or C bits long x (A/B/C) ...: Indicates that x is one of A, B, or C bits long
x (i) ...: Indicates that x uses the variable-length encoding in x (i) ...: Indicates that x uses the variable-length encoding in
Section 16 Section 16
x (*) ...: Indicates that x is variable-length x (*) ...: Indicates that x is variable-length
2. Streams 2. Streams
Streams in QUIC provide a lightweight, ordered byte-stream Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application. Streams can be unidirectional or abstraction to an application. Streams can be unidirectional or
bidirecational. An alternative view of QUIC unidirectional streams bidirectional. An alternative view of QUIC unidirectional streams is
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
control - are all designed to impose minimal overheads. For control - are all designed to impose minimal overheads. For
instance, a single STREAM frame (Section 19.8) can open, carry data instance, a single STREAM frame (Section 19.8) can open, carry data
for, and close a stream. Streams can also be long-lived and can last for, and close a stream. Streams can also be long-lived and can last
the entire duration of a connection. the entire duration of a connection.
Streams can be created by either endpoint, can concurrently send data Streams can be created by either endpoint, can concurrently send data
interleaved with other streams, and can be cancelled. QUIC does not interleaved with other streams, and can be cancelled. QUIC does not
skipping to change at page 11, line 24 skipping to change at page 11, line 31
QUIC does not provide a mechanism for exchanging prioritization QUIC does not provide a mechanism for exchanging prioritization
information. Instead, it relies on receiving priority information information. Instead, it relies on receiving priority information
from the application that uses QUIC. from the application that uses QUIC.
A QUIC implementation SHOULD provide ways in which an application can A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams. When deciding which indicate the relative priority of streams. When deciding which
streams to dedicate resources to, the implementation SHOULD use the streams to dedicate resources to, the implementation SHOULD use the
information provided by the application. information provided by the application.
2.4. Required Operations on Streams
There are certain operations which an application MUST be able to
perform when interacting with QUIC streams. This document does not
specify an API, but any implementation of this version of QUIC MUST
expose the ability to perform the operations described in this
section on a QUIC stream.
On the sending part of a stream, application protocols need to be
able to:
o write data, understanding when stream flow control credit
(Section 4.1) has successfully been reserved to send the written
data
o end the stream (clean termination), resulting in a STREAM frame
(Section 19.8) with the FIN bit set; and
o reset the stream (abrupt termination), resulting in a RESET_STREAM
frame (Section 19.4), even if the stream was already ended.
On the receiving part of a stream, application protocols need to be
able to:
o read data
o abort reading of the stream and request closure, possibly
resulting in a STOP_SENDING frame (Section 19.5)
Applications also need to be informed of state changes on streams,
including when the peer has opened or reset a stream, when a peer
aborts reading on a stream, when new data is available, and when data
can or cannot be written to the stream due to flow control.
3. Stream States 3. Stream States
This section describes streams in terms of their send or receive This section describes streams in terms of their send or receive
components. Two state machines are described: one for the streams on components. Two state machines are described: one for the streams on
which an endpoint transmits data (Section 3.1), and another for which an endpoint transmits data (Section 3.1), and another for
streams on which an endpoint receives data (Section 3.2). streams on which an endpoint receives data (Section 3.2).
Unidirectional streams use the applicable state machine directly. Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines. For the most part, Bidirectional streams use both state machines. For the most part,
the use of these state machines is the same whether the stream is the use of these state machines is the same whether the stream is
skipping to change at page 18, line 44 skipping to change at page 19, line 7
+-----------------------+---------------------+---------------------+ +-----------------------+---------------------+---------------------+
Table 2: Possible Mapping of Stream States to HTTP/2 Table 2: Possible Mapping of Stream States to HTTP/2
Note (*1): A stream is considered "idle" if it has not yet been Note (*1): A stream is considered "idle" if it has not yet been
created, or if the receiving part of the stream is in the "Recv" created, or if the receiving part of the stream is in the "Recv"
state without yet having received any frames. state without yet having received any frames.
3.5. Solicited State Transitions 3.5. Solicited State Transitions
If an endpoint is no longer interested in the data it is receiving on If an application is no longer interested in the data it is receiving
a stream, it MAY send a STOP_SENDING frame identifying that stream to on a stream, it can abort reading the stream and specify an
prompt closure of the stream in the opposite direction. This application error code.
typically indicates that the receiving application is no longer
reading data it receives from the stream, but it is not a guarantee If the stream is in the "Recv" or "Size Known" states, the transport
that incoming data will be ignored. SHOULD signal this by sending a STOP_SENDING frame to prompt closure
of the stream in the opposite direction. This typically indicates
that the receiving application is no longer reading data it receives
from the stream, but it is not a guarantee that incoming data will be
ignored.
STREAM frames received after sending STOP_SENDING are still counted STREAM frames received after sending STOP_SENDING are still counted
toward connection and stream flow control, even though these frames toward connection and stream flow control, even though these frames
can be discarded upon receipt. can be discarded upon receipt.
A STOP_SENDING frame requests that the receiving endpoint send a A STOP_SENDING frame requests that the receiving endpoint send a
RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame
MUST send a RESET_STREAM frame if the stream is in the Ready or Send MUST send a RESET_STREAM frame if the stream is in the Ready or Send
state. If the stream is in the Data Sent state and any outstanding state. If the stream is in the Data Sent state and any outstanding
data is declared lost, an endpoint SHOULD send a RESET_STREAM frame data is declared lost, an endpoint SHOULD send a RESET_STREAM frame
skipping to change at page 23, line 28 skipping to change at page 23, line 41
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.1) 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).
skipping to change at page 24, line 40 skipping to change at page 25, line 6
The primary function of a connection ID is to ensure that changes in The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP) don't cause packets for addressing at lower protocol layers (UDP, IP) don't cause packets for
a QUIC connection to be delivered to the wrong endpoint. Each a QUIC connection to be delivered to the wrong endpoint. Each
endpoint selects connection IDs using an implementation-specific (and endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method which will allow packets with perhaps deployment-specific) method which will allow packets with
that connection ID to be routed back to the endpoint and identified that connection ID to be routed back to the endpoint and identified
by the endpoint upon receipt. by the endpoint upon receipt.
Connection IDs MUST NOT contain any information that can be used by Connection IDs MUST NOT contain any information that can be used by
an external observer to correlate them with other connection IDs for an external observer (that is, one that does not cooperate with the
the same connection. As a trivial example, this means the same issuer) to correlate them with other connection IDs for the same
connection ID MUST NOT be issued more than once on the same connection. As a trivial example, this means the same connection ID
connection. MUST NOT be issued more than once on the same connection.
Packets with long headers include Source Connection ID and Packets with long headers include Source Connection ID and
Destination Connection ID fields. These fields are used to set the Destination Connection ID fields. These fields are used to set the
connection IDs for new connections; see Section 7.2 for details. connection IDs for new connections; see Section 7.2 for details.
Packets with short headers (Section 17.3) only include the Packets with short headers (Section 17.3) only include the
Destination Connection ID and omit the explicit length. The length Destination Connection ID and omit the explicit length. The length
of the Destination Connection ID field is expected to be known to of the Destination Connection ID field is expected to be known to
endpoints. Endpoints using a load balancer that routes based on endpoints. Endpoints using a load balancer that routes based on
connection ID could agree with the load balancer on a fixed length connection ID could agree with the load balancer on a fixed length
skipping to change at page 29, line 11 skipping to change at page 29, line 25
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.3. Life of a QUIC Connection 5.3. Life of a QUIC Connection
TBD. TBD.
5.4. Required Operations on Connections
There are certain operations which an application MUST be able to
perform when interacting with the QUIC transport. This document does
not specify an API, but any implementation of this version of QUIC
MUST expose the ability to perform the operations described in this
section on a QUIC connection.
When implementing the client role, applications need to be able to:
o open a connection, which begins the exchange described in
Section 7;
o enable 0-RTT; and
o be informed when 0-RTT has been accepted or rejected by a server.
When implementing the server role, applications need to be able to:
o listen for incoming connections, which prepares for the exchange
described in Section 7;
o if Early Data is supported, embed application-controlled data in
the TLS resumption ticket sent to the client; and
o if Early Data is supported, retrieve application-controlled data
from the client's resumption ticket and enable rejecting Early
Data based on that information.
In either role, applications need to be able to:
o configure minimum values for the initial number of permitted
streams of each type, as communicated in the transport parameters
(Section 7.3);
o control resource allocation of various types, including flow
control and the number of permitted streams of each type;
o identify whether the handshake has completed successfully or is
still ongoing
o keep a connection from silently closing, either by generating PING
frames (Section 19.2) or by requesting that the transport send
additional frames before the idle timeout expires (Section 10.2);
and
o immediately close (Section 10.3) the connection.
6. Version Negotiation 6. Version Negotiation
Version negotiation ensures that client and server agree to a QUIC Version negotiation ensures that client and server agree to a QUIC
version that is mutually supported. A server sends a Version version that is mutually supported. A server sends a Version
Negotiation packet in response to each packet that might initiate a Negotiation packet in response to each packet that might initiate a
new connection; see Section 5.2 for details. new connection; see Section 5.2 for details.
The size of the first packet sent by a client will determine whether The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet. Clients that support a server sends a Version Negotiation packet. Clients that support
multiple QUIC versions SHOULD pad the first packet they send to the multiple QUIC versions SHOULD pad the first packet they send to the
skipping to change at page 30, line 9 skipping to change at page 31, line 22
When a client receives a Version Negotiation packet, it MUST abandon When a client receives a Version Negotiation packet, it MUST abandon
the current connection attempt. Version Negotiation packets are the current connection attempt. Version Negotiation packets are
designed to allow future versions of QUIC to negotiate the version in designed to allow future versions of QUIC to negotiate the version in
use between endpoints. Future versions of QUIC might change how use between endpoints. Future versions of QUIC might change how
implementations that support multiple versions of QUIC react to implementations that support multiple versions of QUIC react to
Version Negotiation packets when attempting to establish a connection Version Negotiation packets when attempting to establish a connection
using this version. How to perform version negotiation is left as using this version. How to perform version negotiation is left as
future work defined by future versions of QUIC. In particular, that future work defined by future versions of QUIC. In particular, that
future work will need to ensure robustness against version downgrade future work will need to ensure robustness against version downgrade
attacks Section 21.9. attacks 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 Section 6.2. attempt Section 6.2.
skipping to change at page 31, line 32 skipping to change at page 32, line 41
* a client is optionally authenticated, * a client is optionally authenticated,
* 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
o authenticated values for the transport parameters of the peer (see o authenticated values for transport parameters of both endpoints,
Section 7.3) and confidentiality protection for server transport parameters
(see Section 7.3)
o authenticated negotiation of an application protocol (TLS uses o authenticated negotiation of an application protocol (TLS uses
ALPN [RFC7301] for this purpose) ALPN [RFC7301] for this purpose)
The first CRYPTO frame from a client MUST be sent in a single packet. The first CRYPTO frame from a client MUST be sent in a single packet.
Any second attempt that is triggered by address validation (see Any second attempt that is triggered by address validation (see
Section 8.1) MUST also be sent within a single packet. This avoids Section 8.1) MUST also be sent within a single packet. This avoids
having to reassemble a message from multiple packets. having to reassemble a message from multiple packets.
The first client packet of the cryptographic handshake protocol MUST The first client packet of the cryptographic handshake protocol MUST
fit within a 1232 byte QUIC packet payload. This includes overheads fit within a 1232 byte QUIC packet payload. This includes overheads
that reduce the space available to the cryptographic handshake that reduce the space available to the cryptographic handshake
protocol. protocol.
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.3.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 The CRYPTO frame can be sent in different packet number spaces. The
sequence numbers used by CRYPTO frames to ensure ordered delivery of sequence numbers used by CRYPTO frames to ensure ordered delivery of
cryptographic handshake data start from zero in each packet number cryptographic handshake data start from zero in each packet number
space. space.
Endpoints MUST explicitly negotiate an application protocol. This Endpoints MUST explicitly negotiate an application protocol. This
avoids situations where there is a disagreement about the protocol avoids situations where there is a disagreement about the protocol
that is in use. that is in use.
skipping to change at page 35, line 21 skipping to change at page 36, line 21
each parameter includes rules for its handling. each parameter includes rules for its handling.
The encoding of the transport parameters is detailed in Section 18. The encoding of the transport parameters is detailed in Section 18.
QUIC includes the encoded transport parameters in the cryptographic QUIC includes the encoded transport parameters in the cryptographic
handshake. Once the handshake completes, the transport parameters handshake. Once the handshake completes, the transport parameters
declared by the peer are available. Each endpoint validates the declared by the peer are available. Each endpoint validates the
value provided by its peer. value provided by its peer.
Definitions for each of the defined transport parameters are included Definitions for each of the defined transport parameters are included
in Section 18.1. 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 A server MUST include the original_connection_id transport parameter
(Section 18.1) if it sent a Retry packet to enable validation of the (Section 18.2) if it sent a Retry packet to enable validation of the
Retry, as described in Section 17.2.5. Retry, as described in Section 17.2.5.
7.3.1. Values of Transport Parameters for 0-RTT 7.3.1. Values of Transport Parameters for 0-RTT
Both endpoints store the value of the server transport parameters Both endpoints store the value of the server transport parameters
from a connection and apply them to any 0-RTT packets that are sent from a connection and apply them to any 0-RTT packets that are sent
in subsequent connections to that peer, except for transport in subsequent connections to that peer, except for transport
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
skipping to change at page 36, line 18 skipping to change at page 37, line 18
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.1) 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.
o initial_max_data o initial_max_data
o initial_max_stream_data_bidi_local o initial_max_stream_data_bidi_local
o initial_max_stream_data_bidi_remote o initial_max_stream_data_bidi_remote
o initial_max_stream_data_uni o initial_max_stream_data_uni
skipping to change at page 37, line 12 skipping to change at page 38, line 12
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.3.2. New Transport Parameters
New transport parameters can be used to negotiate new protocol New transport parameters can be used to negotiate new protocol
behavior. An endpoint MUST ignore transport parameters that it does behavior. An endpoint MUST ignore transport parameters that it does
not support. Absence of a transport parameter therefore disables any not support. Absence of a transport parameter therefore disables any
optional protocol feature that is negotiated using the parameter. optional protocol feature that is negotiated using the parameter. As
described in Section 18.1, some identifiers are reserved in order to
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.1. Section 22.1.
7.4. Cryptographic Message Buffering 7.4. 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.
skipping to change at page 40, line 16 skipping to change at page 41, line 16
The server uses the NEW_TOKEN frame Section 19.7 to provide the The server uses the NEW_TOKEN frame Section 19.7 to provide the
client with an address validation token that can be used to validate client with an address validation token that can be used to validate
future connections. The client includes this token in Initial future connections. The client includes this token in Initial
packets to provide address validation in a future connection. The packets to provide address validation in a future connection. The
client MUST include the token in all Initial packets it sends, unless client MUST include the token in all Initial packets it sends, unless
a Retry replaces the token with a newer one. The client MUST NOT use a Retry replaces the token with a newer one. The client MUST NOT use
the token provided in a Retry for future connections. Servers MAY the token provided in a Retry for future connections. Servers MAY
discard any Initial packet that does not carry the expected token. discard any Initial packet that does not carry the expected token.
A token SHOULD be constructed for the server to easily distinguish it A token SHOULD be constructed in a way that allows the server to
from tokens that are sent in Retry packets as they are carried in the distinguish it from tokens that are sent in Retry packets as they are
same field. carried in the same field.
The token MUST NOT include information that would allow it to be The token MUST NOT include information that would allow it to be
linked by an on-path observer to the connection on which it was linked by an on-path observer to the connection on which it was
issued. For example, it cannot include the connection ID or issued. For example, it cannot include the connection ID or
addressing information unless the values are encrypted. addressing information unless the values are encrypted.
Unlike the token that is created for a Retry packet, there might be Unlike the token that is created for a Retry packet, there might be
some time between when the token is created and when the token is some time between when the token is created and when the token is
subsequently used. Thus, a token SHOULD have an expiration time, subsequently used. Thus, a token SHOULD have an expiration time,
which could be either an explicit expiration time or an issued which could be either an explicit expiration time or an issued
skipping to change at page 41, line 4 skipping to change at page 42, line 4
A token allows a server to correlate activity between the connection A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used. where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server MAY Clients that want to break continuity of identity with a server MAY
discard tokens provided using the NEW_TOKEN frame. A token obtained discard tokens provided using the NEW_TOKEN frame. A token obtained
in a Retry packet MUST be used immediately during the connection in a Retry packet MUST be used immediately during the connection
attempt and cannot be used in subsequent connection attempts. attempt and cannot be used in subsequent connection attempts.
A client SHOULD NOT reuse a token in different connections. Reusing A client SHOULD NOT reuse a token in different connections. Reusing
a token allows connections to be linked by entities on the network a token allows connections to be linked by entities on the network
path (see Section 9.5). A client MUST NOT reuse a token if it path; see Section 9.5. A client MUST NOT reuse a token if it
believes that its point of network attachment has changed since the believes that its point of network attachment has changed since the
token was last used; that is, if there is a change in its local IP token was last used; that is, if there is a change in its local IP
address or network interface. A client needs to start the connection address or network interface. A client needs to start the connection
process over if it migrates prior to completing the handshake. process over if there is any change in its local address prior to
completing the handshake.
Clients might receive multiple tokens on a single connection. Aside
from preventing linkability, any token can be used in any connection
attempt. Servers can send additional tokens to either enable address
validation for multiple connection attempts or to replace older
tokens that might become invalid. For a client, this ambiguity means
that sending the most recent unused token is most likely to be
effective. Though saving and using older tokens has no negative
consequences, clients can regard older tokens as being less likely be
useful to the server for address validation.
When a server receives an Initial packet with an address validation When a server receives an Initial packet with an address validation
token, it MUST attempt to validate the token, unless it has already token, it MUST attempt to validate the token, unless it has already
completed address validation. If the token is invalid then the completed address validation. If the token is invalid then the
server SHOULD proceed as if the client did not have a validated server SHOULD proceed as if the client did not have a validated
address, including potentially sending a Retry. If the validation address, including potentially sending a Retry. If the validation
succeeds, the server SHOULD then allow the handshake to proceed. succeeds, the server SHOULD then allow the handshake to proceed.
Note: The rationale for treating the client as unvalidated rather Note: The rationale for treating the client as unvalidated rather
than discarding the packet is that the client might have received than discarding the packet is that the client might have received
skipping to change at page 43, line 28 skipping to change at page 44, line 40
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.2). 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 44, line 37 skipping to change at page 45, line 51
The use of a connection ID allows connections to survive changes to The use of a connection ID allows connections to survive changes to
endpoint addresses (IP address and port), such as those caused by an endpoint addresses (IP address and port), such as those caused by an
endpoint migrating to a new network. This section describes the endpoint migrating to a new network. This section describes the
process by which an endpoint migrates to a new address. process by which an endpoint migrates to a new address.
The design of QUIC relies on endpoints retaining a stable address for The design of QUIC relies on endpoints retaining a stable address for
the duration of the handshake. An endpoint MUST NOT initiate the duration of the handshake. An endpoint MUST NOT initiate
connection migration before the handshake is confirmed, as defined in connection migration before the handshake is confirmed, as defined in
section 4.1.2 of [QUIC-TLS]. section 4.1.2 of [QUIC-TLS].
An endpoint also MUST NOT initiate connection migration if the peer An endpoint also MUST NOT send packets from a different local
sent the "disable_migration" transport parameter during the address, actively initiating migration, if the peer sent the
handshake. An endpoint which has sent this transport parameter, but "disable_active_migration" transport parameter during the handshake.
detects that a peer has nonetheless migrated to a different network An endpoint which has sent this transport parameter, but detects that
MAY treat this as a connection error of type INVALID_MIGRATION. a peer has nonetheless migrated to a different network MUST either
Similarly, an endpoint MUST NOT initiate migration if its peer drop the incoming packets on that path without generating a stateless
supplies a zero-length connection ID as packets without a Destination reset or proceed with path validation and allow the peer to migrate.
Connection ID cannot be attributed to a connection based on address Generating a stateless reset or closing the connection would allow
tuple. third parties in the network to cause connections to close by
spoofing or otherwise manipulating observed traffic.
Not all changes of peer address are intentional migrations. The peer Not all changes of peer address are intentional, or active,
could experience NAT rebinding: a change of address due to a migrations. The peer could experience NAT rebinding: a change of
middlebox, usually a NAT, allocating a new outgoing port or even a address due to a middlebox, usually a NAT, allocating a new outgoing
new outgoing IP address for a flow. An endpoint MUST perform path port or even a new outgoing IP address for a flow. An endpoint MUST
validation (Section 8.2) if it detects any change to a peer's perform path validation (Section 8.2) if it detects any change to a
address, unless it has previously validated that address. peer's address, unless it has previously validated that address.
When an endpoint has no validated path on which to send packets, it When an endpoint has no validated path on which to send packets, it
MAY discard connection state. An endpoint capable of connection MAY discard connection state. An endpoint capable of connection
migration MAY wait for a new path to become available before migration MAY wait for a new path to become available before
discarding connection state. discarding connection state.
This document limits migration of connections to new client This document limits migration of connections to new client
addresses, except as described in Section 9.6. Clients are addresses, except as described in Section 9.6. Clients are
responsible for initiating all migrations. Servers do not send non- responsible for initiating all migrations. Servers do not send non-
probing packets (see Section 9.1) toward a client address until they probing packets (see Section 9.1) toward a client address until they
skipping to change at page 46, line 12 skipping to change at page 47, line 26
establishment. Therefore, a migrating endpoint can send to its peer establishment. Therefore, a migrating endpoint can send to its peer
knowing that the peer is willing to receive at the peer's current knowing that the peer is willing to receive at the peer's current
address. Thus an endpoint can migrate to a new local address without address. Thus an endpoint can migrate to a new local address without
first validating the peer's address. first validating the peer's address.
When migrating, the new path might not support the endpoint's current When migrating, the new path might not support the endpoint's current
sending rate. Therefore, the endpoint resets its congestion sending rate. Therefore, the endpoint resets its congestion
controller, as described in Section 9.4. controller, 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.3. 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.
9.3. Responding to Connection Migration 9.3. Responding to Connection Migration
skipping to change at page 49, line 15 skipping to change at page 50, line 27
is rare on IPv6 paths. Endpoints can also look for duplicated is rare on IPv6 paths. Endpoints can also look for duplicated
packets. Conversely, a change in connection ID is more likely to packets. Conversely, a change in connection ID is more likely to
indicate an intentional migration rather than an attack. indicate an intentional migration rather than an attack.
9.4. Loss Detection and Congestion Control 9.4. Loss Detection and Congestion Control
The capacity available on the new path might not be the same as the The capacity available on the new path might not be the same as the
old path. Packets sent on the old path SHOULD NOT contribute to old path. Packets sent on the old path SHOULD NOT contribute to
congestion control or RTT estimation for the new path. congestion control or RTT estimation for the new path.
On confirming a peer's ownership of its new address, an endpoint On confirming a peer's ownership of its new address, an endpoint MUST
SHOULD immediately reset the congestion controller and round-trip immediately reset the congestion controller and round-trip time
time estimator for the new path. estimator for the new path to initial values (see Sections A.3 and
B.3 in [QUIC-RECOVERY]) unless it has knowledge that a previous send
An endpoint MUST NOT return to the send rate used for the previous rate or round-trip time estimate is valid for the new path. For
path unless it is reasonably sure that the previous send rate is instance, an endpoint might infer that a change in only the client's
valid for the new path. For instance, a change in the client's port port number is indicative of a NAT rebinding, meaning that the new
number is likely indicative of a rebinding in a middlebox and not a path is likely to have similar bandwidth and round-trip time.
complete change in path. This determination likely depends on However, this determination will be imperfect. If the determination
heuristics, which could be imperfect; if the new path capacity is is incorrect, the congestion controller and the RTT estimator are
significantly reduced, ultimately this relies on the congestion expected to adapt to the new path. Generally, implementations are
controller responding to congestion signals and reducing send rates advised to be cautious when using previous values on a new path.
appropriately.
There may be apparent reordering at the receiver when an endpoint There may be apparent reordering at the receiver when an endpoint
sends data and probes from/to multiple addresses during the migration sends data and probes from/to multiple addresses during the migration
period, since the two resulting paths may have different round-trip period, since the two resulting paths may have different round-trip
times. A receiver of packets on multiple paths will still send ACK times. A receiver of packets on multiple paths will still send ACK
frames covering all received packets. frames covering all received packets.
While multiple paths might be used during connection migration, a While multiple paths might be used during connection migration, a
single congestion control context and a single loss recovery context single congestion control context and a single loss recovery context
(as described in [QUIC-RECOVERY]) may be adequate. For instance, an (as described in [QUIC-RECOVERY]) may be adequate. For instance, an
skipping to change at page 54, line 40 skipping to change at page 55, line 47
new source address, indicating a connection migration (Section 9). new source address, indicating a connection migration (Section 9).
An endpoint in the closing state MUST strictly limit the number of An 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 discard packets received from a new source address. to discard packets received from a new source address.
10.2. Idle Timeout 10.2. Idle Timeout
If the idle timeout is enabled, a connection is silently closed and If the idle timeout is enabled, a connection is silently closed and
the state is discarded when it remains idle for longer than both the the state is discarded when it remains idle for longer than both the
advertised idle timeout (see Section 18.1) and three times the advertised idle timeout (see Section 18.2) and three times the
current Probe Timeout (PTO). current Probe Timeout (PTO).
Each endpoint advertises its own idle timeout to its peer. An Each endpoint advertises its own idle timeout to its peer. An
endpoint restarts any timer it maintains when a packet from its peer endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully. The timer is also restarted is received and processed successfully. The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an when sending a packet containing frames other than ACK or PADDING (an
ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK- ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK-
eliciting packets have been sent since last receiving a packet. eliciting packets have been sent since last receiving a packet.
Restarting when sending packets ensures that connections do not Restarting when sending packets ensures that connections do not
prematurely time out when initiating new activity. prematurely time out when initiating new activity.
skipping to change at page 57, line 20 skipping to change at page 58, line 26
protected by encryption, so only client and server know this value. protected by encryption, so only client and server know this value.
Tokens are invalidated when their associated connection ID is retired Tokens are invalidated when their associated connection ID is retired
via a RETIRE_CONNECTION_ID frame (Section 19.16). via a 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 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Unpredictable Bits (198..) ... |0|1| Unpredictable Bits (38 ..) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Stateless Reset Token (128) + + Stateless Reset Token (128) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 57, line 44 skipping to change at page 58, line 50
possible - indistinguishable from a regular packet with a short possible - indistinguishable from a regular packet with a short
header. header.
A stateless reset uses an entire UDP datagram, starting with the A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header. The remainder of the first byte first two bits of the packet header. The remainder of the first byte
and an arbitrary number of bytes following it that are set to and an arbitrary number of bytes following it that are set to
unpredictable values. The last 16 bytes of the datagram contain a unpredictable values. The last 16 bytes of the datagram contain a
Stateless Reset Token. Stateless Reset Token.
To entities other than its intended recipient, a stateless reset will To entities other than its intended recipient, a stateless reset will
appear to be a packet with a short header. For the packet to appear appear to be a packet with a short header. For the stateless reset
as valid, the Unpredictable Bits field needs to include at least 198 to appear as a valid QUIC packet, the Unpredictable Bits field needs
bits of data (or 25 bytes, less the two fixed bits). This is to include at least 38 bits of data (or 5 bytes, less the two fixed
intended to allow for a Destination Connection ID of the maximum bits).
length permitted, with a minimal packet number, and payload. The
Stateless Reset Token corresponds to the minimum expansion of the
packet protection AEAD. More unpredictable bytes might be necessary
if the endpoint could have negotiated a packet protection scheme with
a larger minimum AEAD expansion.
An endpoint SHOULD NOT send a stateless reset that is significantly A minimum size of 21 bytes does not guarantee that a stateless reset
larger than the packet it receives. Endpoints MUST discard packets is difficult to distinguish from other packets if the recipient
that are too small to be valid QUIC packets. With the set of AEAD requires the use of a connection ID. To prevent a resulting
functions defined in [QUIC-TLS], packets that are smaller than 21 stateless reset from being trivially distinguishable from a valid
bytes are never valid. packet, all packets sent by an endpoint SHOULD be padded to at least
22 bytes longer than the minimum connection ID that the endpoint
might use. An endpoint that sends a stateless reset in response to
packet that is 43 bytes or less in length SHOULD send a stateless
reset that is one byte shorter than the packet it responds to.
These values assume that the Stateless Reset Token is the same as the
minimum expansion of the packet protection AEAD. Additional
unpredictable bytes are necessary if the endpoint could have
negotiated a packet protection scheme with a larger minimum
expansion.
An endpoint MUST NOT send a stateless reset that is three times or
more larger than the packet it receives to avoid being used for
amplification. Section 10.4.3 describes additional limits on
stateless reset size.
Endpoints MUST discard packets that are too small to be valid QUIC
packets. With the set of AEAD functions defined in [QUIC-TLS],
packets that are smaller than 21 bytes are never valid.
Endpoints MUST send stateless reset packets formatted as a packet Endpoints MUST send stateless reset packets formatted as a packet
with a short header. However, endpoints MUST treat any packet ending with a short header. However, endpoints MUST treat any packet ending
in a valid stateless reset token as a stateless reset, as other QUIC in a valid stateless reset token as a stateless reset, as other QUIC
versions might allow the use of a long header. versions might allow the use of a long header.
An endpoint MAY send a stateless reset in response to a packet with a An endpoint MAY send a stateless reset in response to a packet with a
long header. Sending a stateless reset is not effective prior to the long header. Sending a stateless reset is not effective prior to the
stateless reset token being available to a peer. In this QUIC stateless reset token being available to a peer. In this QUIC
version, packets with a long header are only used during connection version, packets with a long header are only used during connection
skipping to change at page 58, line 49 skipping to change at page 60, line 23
Stateless Reset that is not correctly routed is an ineffective Stateless Reset that is not correctly routed is an ineffective
error detection and recovery mechanism. In this case, endpoints error detection and recovery mechanism. In this case, endpoints
will need to rely on other methods - such as timers - to detect will need to rely on other methods - such as timers - to detect
that the connection has failed. that the connection has failed.
o The randomly generated connection ID can be used by entities other o The randomly generated connection ID can be used by entities other
than the peer to identify this as a potential stateless reset. An than the peer to identify this as a potential stateless reset. An
endpoint that occasionally uses different connection IDs might endpoint that occasionally uses different connection IDs might
introduce some uncertainty about this. introduce some uncertainty about this.
Finally, the last 16 bytes of the packet are set to the value of the
Stateless Reset Token.
This stateless reset design is specific to QUIC version 1. An This stateless reset design is specific to QUIC version 1. An
endpoint that supports multiple versions of QUIC needs to generate a endpoint that supports multiple versions of QUIC needs to generate a
stateless reset that will be accepted by peers that support any stateless reset that will be accepted by peers that support any
version that the endpoint might support (or might have supported version that the endpoint might support (or might have supported
prior to losing state). Designers of new versions of QUIC need to be prior to losing state). Designers of new versions of QUIC need to be
aware of this and either reuse this design, or use a portion of the aware of this and either reuse this design, or use a portion of the
packet other than the last 16 bytes for carrying data. packet other than the last 16 bytes for carrying data.
10.4.1. Detecting a Stateless Reset 10.4.1. Detecting a Stateless Reset
skipping to change at page 60, line 24 skipping to change at page 61, line 44
without state. In addition, it cannot provide a zero-length without state. In addition, it cannot provide a zero-length
connection ID. connection ID.
Revealing the Stateless Reset Token allows any entity to terminate Revealing the Stateless Reset Token allows any entity to terminate
the connection, so a value can only be used once. This method for the connection, so a value can only be used once. This method for
choosing the Stateless Reset Token means that the combination of choosing the Stateless Reset Token means that the combination of
connection ID and static key MUST NOT be used for another connection. connection ID and static key MUST NOT be used for another connection.
A denial of service attack is possible if the same connection ID is A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the cause a packet to be routed to an instance that has no state but the
same static key; see Section 21.8. A connection ID from a connection same static key; see Section 21.9. A connection ID from a connection
that is reset by revealing the Stateless Reset Token MUST NOT be that is reset by revealing the Stateless Reset Token MUST NOT be
reused for new connections at nodes that share a static key. reused for new connections at nodes that share a static key.
The same Stateless Reset Token MAY be used for multiple connection The same Stateless Reset Token MAY be used for multiple connection
IDs on the same connection. However, reuse of a Stateless Reset IDs on the same connection. However, reuse of a Stateless Reset
Token might expose an endpoint to denial of service if associated Token might expose an endpoint to denial of service if associated
connection IDs are forgotten while the associated token is still connection IDs are forgotten while the associated token is still
active at a peer. An endpoint MUST ensure that packets with active at a peer. An endpoint MUST ensure that packets with
Destination Connection ID field values that correspond to a reused Destination Connection ID field values that correspond to a reused
Stateless Reset Token are attributed to the same connection as long Stateless Reset Token are attributed to the same connection as long
as the Stateless Reset Token is still usable, even when the as the Stateless Reset Token is still usable, even when the
connection ID has been retired. Otherwise, an attacker might be able connection ID has been retired. Otherwise, an attacker might be able
to send a packet with a retired connection ID and cause the endpoint to send a packet with a retired connection ID and cause the endpoint
to produce a Stateless Reset that it can use to disrupt the to produce a Stateless Reset that it can use to disrupt the
connection, just as with the attacks in Section 21.8. connection, just as with the attacks in Section 21.9.
Note that Stateless Reset packets do not have any cryptographic Note that Stateless Reset packets do not have any cryptographic
protection. protection.
10.4.3. Looping 10.4.3. Looping
The design of a Stateless Reset is such that without knowing the The design of a Stateless Reset is such that without knowing the
stateless reset token it is indistinguishable from a valid packet. stateless reset token it is indistinguishable from a valid packet.
For instance, if a server sends a Stateless Reset to another server For instance, if a server sends a Stateless Reset to another server
it might receive another Stateless Reset in response, which could it might receive another Stateless Reset in response, which could
skipping to change at page 61, line 17 skipping to change at page 62, line 35
sufficient to prevent looping. In the event of a loop, this results sufficient to prevent looping. In the event of a loop, this results
in packets eventually being too small to trigger a response. in packets eventually being too small to trigger a response.
An endpoint can remember the number of Stateless Reset packets that An endpoint can remember the number of Stateless Reset packets that
it has sent and stop generating new Stateless Reset packets once a it has sent and stop generating new Stateless Reset packets once a
limit is reached. Using separate limits for different remote limit is reached. Using separate limits for different remote
addresses will ensure that Stateless Reset packets can be used to addresses will ensure that Stateless Reset packets can be used to
close connections when other peers or connections have exhausted close connections when other peers or connections have exhausted
limits. limits.
Reducing the size of a Stateless Reset below the recommended minimum Reducing the size of a Stateless Reset below 41 bytes means that the
size of 41 bytes could mean that the packet could reveal to an packet could reveal to an observer that it is a Stateless Reset,
observer that it is a Stateless Reset. Conversely, refusing to send depending upon the length of the peer's connection IDs. Conversely,
a Stateless Reset in response to a small packet might result in refusing to send a Stateless Reset in response to a small packet
Stateless Reset not being useful in detecting cases of broken might result in Stateless Reset not being useful in detecting cases
connections where only very small packets are sent; such failures of broken connections where only very small packets are sent; such
might only be detected by other means, such as timers. failures might only be detected by other means, such as timers.
An endpoint can increase the odds that a packet will trigger a
Stateless Reset if it cannot be processed by padding it to at least
42 bytes.
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), while only
application-level errors can be isolated to a single stream (see application-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. is used; though these are worded as requirements, different
implementation strategies might lead to different errors being
reported. In particular, an endpoint MAY use any applicable error
code when it detects an error condition; a generic error code (such
as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place
of specific error codes.
A stateless reset (Section 10.4) is not suitable for any error that A stateless reset (Section 10.4) is not suitable for any error that
can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A
stateless reset MUST NOT be used by an endpoint that has the state stateless reset MUST NOT be used by an endpoint that has the state
necessary to send a frame on the connection. necessary to send a frame on the connection.
11.1. Connection Errors 11.1. Connection Errors
Errors that result in the connection being unusable, such as an Errors that result in the connection being unusable, such as an
obvious violation of protocol semantics or corruption of state that obvious violation of protocol semantics or corruption of state that
skipping to change at page 62, line 36 skipping to change at page 64, line 12
An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT
signal the existence of the error to its peer. signal the existence of the error to its peer.
11.2. Stream Errors 11.2. Stream Errors
If an application-level error affects a single stream, but otherwise If an application-level error affects a single stream, but otherwise
leaves the connection in a recoverable state, the endpoint can send a leaves the connection in a recoverable state, the endpoint can send a
RESET_STREAM frame (Section 19.4) with an appropriate error code to RESET_STREAM frame (Section 19.4) with an appropriate error code to
terminate just the affected stream. terminate just the affected stream.
RESET_STREAM MUST be instigated by the protocol using QUIC, either RESET_STREAM MUST be instigated by the protocol using QUIC.
directly or through the receipt of a STOP_SENDING frame from a peer. RESET_STREAM carries an application error code. Only the application
RESET_STREAM carries an application error code. Resetting a stream protocol is able to cause a stream to be terminated. A local
without knowledge of the application protocol could cause the instance of the application protocol uses a direct API call and a
protocol to enter an unrecoverable state. Application protocols remote instance uses the STOP_SENDING frame, which triggers an
might require certain streams to be reliably delivered in order to automatic RESET_STREAM.
guarantee consistent state between endpoints.
Resetting a stream without knowledge of the application protocol
could cause the protocol to enter an unrecoverable state.
Application protocols might require certain streams to be reliably
delivered in order to guarantee consistent state between endpoints.
Application protocols SHOULD define rules for handling streams that
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) and are
carried in UDP datagrams (see Section 12.2). 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 (see Section 17.2)
during connection establishment. Packets with the long header are during connection establishment. 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
skipping to change at page 64, line 37 skipping to change at page 66, line 18
receiver of coalesced QUIC packets MUST individually process each receiver of coalesced QUIC packets MUST individually process each
QUIC packet and separately acknowledge them, as if they were received QUIC packet and separately acknowledge them, as if they were received
as the payload of different UDP datagrams. For example, if as the payload of different UDP datagrams. For example, if
decryption fails (because the keys are not available or any other decryption fails (because the keys are not available or any other
reason), the receiver MAY either discard or buffer the packet for reason), the receiver MAY either discard or buffer the packet for
later processing and MUST attempt to process the remaining packets. later processing and MUST attempt to process the remaining packets.
Retry packets (Section 17.2.5), Version Negotiation packets Retry packets (Section 17.2.5), Version Negotiation packets
(Section 17.2.1), and packets with a short header (Section 17.3) do (Section 17.2.1), and packets with a short header (Section 17.3) do
not contain a Length field and so cannot be followed by other packets not contain a Length field and so cannot be followed by other packets
in the same UDP datagram. in the same UDP datagram. Note also that there is no situation where
a Retry or Version Negotiation packet is coalesced with another
packet.
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
skipping to change at page 69, line 5 skipping to change at page 71, line 5
One of the benefits of QUIC is avoidance of head-of-line blocking One of the benefits of QUIC is avoidance of head-of-line blocking
across multiple streams. When a packet loss occurs, only streams across multiple streams. When a packet loss occurs, only streams
with data in that packet are blocked waiting for a retransmission to with data in that packet are blocked waiting for a retransmission to
be received, while other streams can continue making progress. Note be received, while other streams can continue making progress. Note
that when data from multiple streams is bundled into a single QUIC that when data from multiple streams is bundled into a single QUIC
packet, loss of that packet blocks all those streams from making packet, loss of that packet blocks all those streams from making
progress. Implementations are advised to bundle as few streams as progress. Implementations are advised to bundle as few streams as
necessary in outgoing packets without losing transmission efficiency necessary in outgoing packets without losing transmission efficiency
to underfilled packets. to underfilled packets.
13.1. Packet Processing and Acknowledgment 13.1. Packet Processing
A packet MUST NOT be acknowledged until packet protection has been A packet MUST NOT be acknowledged until packet protection has been
successfully removed and all frames contained in the packet have been successfully removed and all frames contained in the packet have been
processed. For STREAM frames, this means the data has been enqueued processed. For STREAM frames, this means the data has been enqueued
in preparation to be received by the application protocol, but it in preparation to be received by the application protocol, but it
does not require that data is delivered and consumed. does not require that data is delivered and consumed.
Once the packet has been fully processed, a receiver acknowledges Once the packet has been fully processed, a receiver acknowledges
receipt by sending one or more ACK frames containing the packet receipt by sending one or more ACK frames containing the packet
number of the received packet. number of the received packet.
13.1.1. Sending ACK Frames 13.2. Generating Acknowledgements
An endpoint sends ACK frames to acknowledge packets it has received Endpoints acknowledge all packets they receive and process. However,
and processed. only ack-eliciting packets (see [QUIC-RECOVERY]) trigger the sending
of an ACK frame. Packets that are not ack-eliciting are only
acknowledged when an ACK frame is sent for other reasons.
Packets containing only ACK frames are not congestion controlled, so When sending a packet for any reason, an endpoint should attempt to
there are limits on how frequently they can be sent. An endpoint bundle an ACK frame if one has not been sent recently. Doing so
MUST NOT send more than one ACK-frame-only packet in response to helps with timely loss detection at the peer.
receiving an ACK-eliciting packet (one containing frames other than
ACK and/or PADDING). An endpoint MUST NOT send a packet containing In general, frequent feedback from a receiver improves loss and
only an ACK frame in response to a non-ACK-eliciting packet (one congestion response, but this has to be balanced against excessive
containing only ACK and/or PADDING frames), even if there are packet load generated by a receiver that sends an ACK frame in response to
gaps which precede the received packet. Limiting ACK frames avoids every ack-eliciting packet. The guidance offered below seeks to
an infinite feedback loop of acknowledgements, which could prevent strike this balance.
the connection from ever becoming idle. However, the endpoint
acknowledges non-ACK-eliciting packets when it sends an ACK frame. 13.2.1. Sending ACK Frames
An ACK frame SHOULD be generated for at least every second ack-
eliciting packet. This recommendation is in keeping with standard
practice for TCP [RFC5681].
A receiver's delayed acknowledgment timer SHOULD NOT exceed the
current RTT estimate or the value it indicates in the "max_ack_delay"
transport parameter. This ensures an acknowledgment is sent at least
once per RTT when packets needing acknowledgement are received. The
sender can use the receiver's "max_ack_delay" value in determining
timeouts for timer-based retransmission.
In order to assist loss detection at the sender, an endpoint SHOULD
send an ACK frame immediately on receiving an ack-eliciting packet
that is out of order. The endpoint MAY continue sending ACK frames
immediately on each subsequently received packet, but the endpoint
SHOULD return to acknowledging every other packet after a period 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
received ACK-eliciting packet.
Similarly, packets marked with the ECN Congestion Experienced (CE)
codepoint in the IP header SHOULD be acknowledged immediately, to
reduce the peer's response time to congestion events.
As an optimization, a receiver MAY process multiple packets before
sending any ACK frames in response. In this case the receiver can
determine whether an immediate or delayed acknowledgement should be
generated after processing incoming packets.
Acknowledgements of packets carrying CRYPTO frames SHOULD be
minimally delayed, to complete the handshake with minimal latency.
Delaying them by a small amount, such as the local timer granularity,
allows the endpoint to bundle any data sent in response with the ACK
frame. ACK frames SHOULD be sent immediately when the crypto stack
indicates all data for that packet number space has been received.
Packets containing PADDING frames are considered to be in flight for Packets containing PADDING frames are considered to be in flight for
congestion control purposes [QUIC-RECOVERY]. Sending only PADDING congestion control purposes [QUIC-RECOVERY]. Sending only PADDING
frames might cause the sender to become limited by the congestion frames might cause the sender to become limited by the congestion
controller (as described in [QUIC-RECOVERY]) with no acknowledgments controller (as described in [QUIC-RECOVERY]) with no acknowledgments
forthcoming from the receiver. Therefore, a sender SHOULD ensure forthcoming from the receiver. Therefore, a sender SHOULD ensure
that other frames are sent in addition to PADDING frames to elicit that other frames are sent in addition to PADDING frames to elicit
acknowledgments from the receiver. acknowledgments from the receiver.
An endpoint that is only sending ACK frames will not receive An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are acknowledgments from its peer unless those acknowledgements are
included in packets with ACK-eliciting frames. An endpoint SHOULD included in packets with ACK-eliciting frames. An endpoint SHOULD
bundle ACK frames with other frames when there are new ACK-eliciting bundle ACK frames with other frames when there are new ACK-eliciting
packets to acknowledge. When only non-ACK-eliciting packets need to packets to acknowledge. When only non-ACK-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ACK-eliciting packet be acknowledged, an endpoint MAY wait until an ACK-eliciting packet
has been received to bundle an ACK frame with outgoing frames. has been received to bundle an ACK frame with outgoing frames.
The algorithms in [QUIC-RECOVERY] are resilient to receivers that do
not follow guidance offered above. However, an implementor should
only deviate from these requirements after careful consideration of
the performance implications of doing so.
Packets containing only ACK frames are not congestion controlled, so
there are limits on how frequently they can be sent. An endpoint
MUST NOT send more than one ACK-frame-only packet in response to
receiving an ACK-eliciting packet (one containing frames other than
ACK and/or PADDING). An endpoint MUST NOT send a packet containing
only an ACK frame in response to a non-ACK-eliciting packet (one
containing only ACK and/or PADDING frames), even if there are packet
gaps which precede the received packet. Limiting ACK frames avoids
an infinite feedback loop of acknowledgements, which could prevent
the connection from ever becoming idle. However, the endpoint
acknowledges non-ACK-eliciting packets when it sends an ACK frame.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it An endpoint SHOULD treat receipt of an acknowledgment for a packet it
did not send as a connection error of type PROTOCOL_VIOLATION, if it did not send as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition. is able to detect the condition.
The receiver's delayed acknowledgment timer SHOULD NOT exceed the 13.2.2. Managing ACK Ranges
current RTT estimate or the value it indicates in the "max_ack_delay"
transport parameter. This ensures an acknowledgment is sent at least
once per RTT when packets needing acknowledgement are received. The
sender can use the receiver's "max_ack_delay" value in determining
timeouts for timer-based retransmission.
Strategies and implications of the frequency of generating When an ACK frame is sent, one or more ranges of acknowledged packets
acknowledgments are discussed in more detail in [QUIC-RECOVERY]. are included. Including older packets reduces the chance of spurious
retransmits caused by losing previously sent ACK frames, at the cost
of larger ACK frames.
13.1.2. Limiting ACK Ranges ACK frames SHOULD always acknowledge the most recently received
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
peer from declaring a packet as lost and spuriously retransmitting
the frames it contains.
Section 13.2.3 and Section 13.2.4 describe an exemplary approach for
determining what packets to acknowledge in each ACK frame.
13.2.3. Receiver Tracking of ACK Frames
When a packet containing an ACK frame is sent, the largest
acknowledged in that frame may be saved. When a packet containing an
ACK frame is acknowledged, the receiver can stop acknowledging
packets less than or equal to the largest acknowledged in the sent
ACK frame.
In cases without ACK frame loss, this algorithm allows for a minimum
of 1 RTT of reordering. In cases with ACK frame loss and reordering,
this approach does not guarantee that every acknowledgement is seen
by the sender before it is no longer included in the ACK frame.
Packets could be received out of order and all subsequent ACK frames
containing them could be lost. In this case, the loss recovery
algorithm could cause spurious retransmits, but the sender will
continue making forward progress.
13.2.4. Limiting ACK Ranges
To limit ACK Ranges (see Section 19.3.1) to those that have not yet To limit ACK Ranges (see Section 19.3.1) to those that have not yet
been received by the sender, the receiver SHOULD track which ACK been received by the sender, the receiver SHOULD track which ACK
frames have been acknowledged by its peer. The receiver SHOULD frames have been acknowledged by its peer. The receiver SHOULD
exclude already acknowledged packets from future ACK frames whenever exclude already acknowledged packets from future ACK frames whenever
these packets would unnecessarily contribute to the ACK frame size. these packets would unnecessarily contribute to the ACK frame size.
When the receiver is only sending non-ACK-eliciting packets, it can 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 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 them, such as once per round trip, to enable dropping unnecessary ACK
ranges and any state for previously sent packets. The receiver MUST ranges and any state for previously sent packets. The receiver MUST
NOT bundle an ACK-elicing frame, such as a PING, with all packets 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 that would otherwise be non-ACK-eliciting, in order to avoid an
infinite feedback loop of acknowledgements. infinite feedback loop of acknowledgements.
To limit receiver state or the size of ACK frames, a receiver MAY To limit receiver state or the size of ACK frames, a receiver MAY
limit the number of ACK Ranges it sends. A receiver can do this even limit the number of ACK Ranges it sends. A receiver can do this even
without receiving acknowledgment of its ACK frames, with the without receiving acknowledgment of its ACK frames, with the
knowledge this could cause the sender to unnecessarily retransmit knowledge this could cause the sender to unnecessarily retransmit
some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare
packets lost after sufficiently newer packets are acknowledged. packets lost after sufficiently newer packets are acknowledged.
Therefore, the receiver SHOULD repeatedly acknowledge newly received Therefore, the receiver SHOULD repeatedly acknowledge newly received
packets in preference to packets received in the past. packets in preference to packets received in the past.
13.1.3. ACK Frames and Packet Protection 13.2.5. Measuring and Reporting Host Delay
An endpoint measures the delays intentionally introduced between when
an ACK-eliciting packet is received and the corresponding
acknowledgment is sent. The endpoint encodes this delay for the
largest acknowledged packet in 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 is important for getting a better
estimate of the path RTT when acknowledgments are delayed. A packet
might be held in the OS kernel or elsewhere on the host before being
processed. An endpoint MUST NOT include delays that is does not
control when populating the Ack Delay field in an ACK frame.
An endpoint MUST NOT excessively delay acknowledgements of ack-
eliciting packets. An endpoint commits to a maximum delay using the
max_ack_delay transport parameter; see Section 18.2. max_ack_delay
declares an explicit contract: an endpoint promises to never delay
acknowledgments of an ack-eliciting packet by more than the indicated
value. If it does, any excess accrues to the RTT estimate and could
result in delayed retransmissions from the peer. For Initial and
Handshake packets, a max_ack_delay of 0 is used.
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.
Endpoints SHOULD send acknowledgments for packets containing CRYPTO 13.3. Retransmission of Information
frames with a reduced delay; see Section 6.2 of [QUIC-RECOVERY].
13.2. Retransmission of Information
QUIC packets that are determined to be lost are not retransmitted QUIC packets that are determined to be lost are not retransmitted
whole. The same applies to the frames that are contained within lost whole. The same applies to the frames that are contained within lost
packets. Instead, the information that might be carried in frames is packets. Instead, the information that might be carried in frames is
sent again in new frames as needed. sent again in new frames as needed.
New frames and packets are used to carry information that is New frames and packets are used to carry information that is
determined to have been lost. In general, information is sent again determined to have been lost. In general, information is sent again
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
skipping to change at page 71, line 33 skipping to change at page 75, line 37
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 encryption level are discarded.
o Application data sent in STREAM frames is retransmitted in new o Application data sent in STREAM frames is retransmitted in new
STREAM frames unless the endpoint has sent a RESET_STREAM for that STREAM frames unless the endpoint has sent a RESET_STREAM for that
stream. Once an endpoint sends a RESET_STREAM frame, no further stream. Once an endpoint sends a RESET_STREAM frame, no further
STREAM frames are needed. STREAM frames are needed.
o The most recent set of acknowledgments are sent in ACK frames. An o The most recent set of acknowledgments are sent in ACK frames. An
ACK frame SHOULD contain all unacknowledged acknowledgments, as ACK frame SHOULD contain all unacknowledged acknowledgments, as
described in Section 13.1.1. described in Section 13.2.1.
o Cancellation of stream transmission, as carried in a RESET_STREAM o Cancellation of stream transmission, as carried in a RESET_STREAM
frame, is sent until acknowledged or until all stream data is frame, is sent until acknowledged or until all stream data is
acknowledged by the peer (that is, either the "Reset Recvd" or acknowledged by the peer (that is, either the "Reset Recvd" or
"Data Recvd" state is reached on the sending part of the stream). "Data Recvd" state is reached on the sending part of the stream).
The content of a RESET_STREAM frame MUST NOT change when it is The content of a RESET_STREAM frame MUST NOT change when it is
sent again. sent again.
o Similarly, a request to cancel stream transmission, as encoded in o Similarly, a request to cancel stream transmission, as encoded in
a STOP_SENDING frame, is sent until the receiving part of the a STOP_SENDING frame, is sent until the receiving part of the
skipping to change at page 72, line 50 skipping to change at page 77, line 8
just once. The peer is expected to send more PATH_CHALLENGE just once. The peer is expected to send more PATH_CHALLENGE
frames as necessary to evoke additional PATH_RESPONSE frames. frames as necessary to evoke additional PATH_RESPONSE frames.
o New connection IDs are sent in NEW_CONNECTION_ID frames and o New connection IDs are sent in NEW_CONNECTION_ID frames and
retransmitted if the packet containing them is lost. retransmitted if the packet containing them is lost.
Retransmissions of this frame carry the same sequence number Retransmissions of this frame carry the same sequence number
value. Likewise, retired connection IDs are sent in value. Likewise, retired connection IDs are sent in
RETIRE_CONNECTION_ID frames and retransmitted if the packet RETIRE_CONNECTION_ID frames and retransmitted if the packet
containing them is lost. containing them is lost.
o NEW_TOKEN frames are retransmitted if the packet containing them
is lost. No special support is made for detecting reordered and
duplicated NEW_TOKEN frames other than a direct comparison of the
frame contents.
o PING and PADDING frames contain no information, so lost PING or o PING and PADDING frames contain no information, so lost PING or
PADDING frames do not require repair. PADDING frames do not require repair.
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 receiver MUST to retransmit copies of frames from lost packets. A receiver MUST
accept packets containing an outdated frame, such as a MAX_DATA frame accept packets containing an outdated frame, such as a MAX_DATA frame
carrying a smaller maximum data than one found in an older packet. carrying a smaller maximum data than one found in an older packet.
Upon detecting losses, a sender MUST take appropriate congestion Upon detecting losses, a sender MUST take appropriate congestion
control action. The details of loss detection and congestion control control action. The details of loss detection and congestion control
are described in [QUIC-RECOVERY]. are described in [QUIC-RECOVERY].
13.3. Explicit Congestion Notification 13.4. Explicit Congestion Notification
QUIC endpoints can use Explicit Congestion Notification (ECN) QUIC endpoints can use Explicit Congestion Notification (ECN)
[RFC3168] to detect and respond to network congestion. ECN allows a [RFC3168] to detect and respond to network congestion. ECN allows a
network node to indicate congestion in the network by setting a network node to indicate congestion in the network by setting a
codepoint in the IP header of a packet instead of dropping it. codepoint in the IP header of a packet instead of dropping it.
Endpoints react to congestion by reducing their sending rate in Endpoints react to congestion by reducing their sending rate in
response, as described in [QUIC-RECOVERY]. response, as described in [QUIC-RECOVERY].
To use ECN, QUIC endpoints first determine whether a path supports To use ECN, QUIC endpoints first determine whether a path supports
ECN marking and the peer is able to access the ECN codepoint in the ECN marking and the peer is able to access the ECN codepoint in the
IP header. A network path does not support ECN if ECN marked packets IP header. A network path does not support ECN if ECN marked packets
get dropped or ECN markings are rewritten on the path. An endpoint get dropped or ECN markings are rewritten on the path. An endpoint
verifies the path, both during connection establishment and when validates the use of ECN on the path, both during connection
migrating to a new path (see Section 9). establishment and when migrating to a new path (Section 9).
13.3.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.1 and Section 19.3). Note that this requires being able Section 13.2 and Section 19.3). Note that this requires being able
to read the ECN codepoints from the enclosing IP packet, which is not to 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.7) 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.1 with an ACK in the IP packet header, it responds per Section 13.2 with an ACK
frame without increasing any ECN counts. If an endpoint does not frame without increasing any ECN counts. If an endpoint does not
implement ECN support or does not have access to received ECN implement ECN support or does not have access to received ECN
codepoints, it does not increase ECN counts. codepoints, it does not increase ECN counts.
Coalesced packets (see Section 12.2) mean that several packets can Coalesced packets (see Section 12.2) mean that several packets can
share the same IP header. The ECN counter for the ECN codepoint share the same IP header. The ECN counter for the ECN codepoint
received in the associated IP header are incremented once for each received in the associated IP header are incremented once for each
QUIC packet, not per enclosing IP packet or UDP datagram. QUIC packet, not per enclosing IP packet or UDP datagram.
Each packet number space maintains separate acknowledgement state and Each packet number space maintains separate acknowledgement state and
separate ECN counts. For example, if one each of an Initial, 0-RTT, separate ECN counts. For example, if one each of an Initial, 0-RTT,
Handshake, and 1-RTT QUIC packet are coalesced, the corresponding Handshake, and 1-RTT QUIC packet are coalesced, the corresponding
counts for the Initial and Handshake packet number space will be counts for the Initial and Handshake packet number space will be
incremented by one and the counts for the 1-RTT packet number space incremented by one and the counts for the 1-RTT packet number space
will be increased by two. will be increased by two.
13.3.2. ECN Verification 13.4.2. ECN Validation
Each endpoint independently verifies and enables use of ECN by It is possible for faulty network devices to corrupt or erroneously
setting the IP header ECN codepoint to ECN Capable Transport (ECT) drop packets with ECN markings. To provide robust connectivity in
for the path from it to the other peer. Even if not setting ECN the presence of such devices, each endpoint independently validates
codepoints on packets it transmits, the endpoint SHOULD provide ECN counts and disables ECN if errors are detected.
feedback about ECN markings received (if accessible).
To verify both that a path supports ECN and the peer can provide ECN Endpoints validate ECN for packets sent on each network path
feedback, an endpoint sets the ECT(0) codepoint in the IP header of independently. An endpoint thus validates ECN on new connection
all outgoing packets [RFC8311]. establishment, when switching to a new server preferred address, and
on active connection migration to a new path.
If an ECT codepoint set in the IP header is not corrupted by a Even if an endpoint does not use ECN markings on packets it
network device, then a received packet contains either the codepoint transmits, the endpoint MUST provide feedback about ECN markings
sent by the peer or the Congestion Experienced (CE) codepoint set by received from the peer if they are accessible. Failing to report ECN
a network device that is experiencing congestion. counts will cause the peer to disable ECN marking.
If a QUIC packet sent with an ECT codepoint is newly acknowledged by 13.4.2.1. Sending ECN Markings
the peer in an ACK frame without ECN feedback, the endpoint stops
setting ECT codepoints in subsequent IP packets, with the expectation
that either the network path or the peer no longer supports ECN.
Network devices that corrupt or apply non-standard ECN markings might To start ECN validation, an endpoint SHOULD do the following when
result in reduced throughput or other undesirable side-effects. To sending packets on a new path to a peer:
reduce this risk, an endpoint uses the following steps to verify the
counts it receives in an ACK frame.
o The total increase in ECT(0), ECT(1), and CE counts MUST be no o Set the ECT(0) codepoint in the IP header of early outgoing
smaller than the total number of QUIC packets sent with an ECT packets sent on a new path to the peer [RFC8311].
codepoint that are newly acknowledged in this ACK frame. This
step detects any network remarking from ECT(0), ECT(1), or CE o If all packets that were sent with the ECT(0) codepoint are
codepoints to Not-ECT. eventually deemed lost [QUIC-RECOVERY], validation is deemed to
have failed.
To reduce the chances of misinterpreting congestive loss as packets
dropped by a faulty network element, an endpoint could set the ECT(0)
codepoint in the first ten outgoing packets on a path, or for a
period of three RTTs, whichever occurs first.
Implementations MAY experiment with and use other strategies for use
of ECN. Other methods of probing paths for ECN support are possible,
as are different marking strategies. Implementations can also use
the ECT(1) codepoint, as specified in [RFC8311].
13.4.2.2. Receiving ACK Frames
An endpoint that sets ECT(0) or ECT(1) codepoints on packets it
transmits MUST use the following steps on receiving an ACK frame to
validate ECN.
o If this ACK frame newly acknowledges a packet that the endpoint
sent with either ECT(0) or ECT(1) codepoints set, and if no ECN
feedback is present in the ACK frame, validation fails. This step
protects against both a network element that zeroes out ECN bits
and a peer that is unable to access ECN markings, since the peer
could respond without ECN feedback in these cases.
o For validation to succeed, the total increase in ECT(0), ECT(1),
and CE counts MUST be no smaller than the total number of QUIC
packets sent with an ECT codepoint that are newly acknowledged in
this ACK frame. This step detects any network remarking from
ECT(0), ECT(1), or CE codepoints to Not-ECT.
o Any increase in either ECT(0) or ECT(1) counts, plus any increase o Any increase in either ECT(0) or ECT(1) counts, plus any increase
in the CE count, MUST be no smaller than the number of packets in the CE count, MUST be no smaller than the number of packets
sent with the corresponding ECT codepoint that are newly sent with the corresponding ECT codepoint that are newly
acknowledged in this ACK frame. This step detects any erroneous acknowledged in this ACK frame. This step detects any erroneous
network remarking from ECT(0) to ECT(1) (or vice versa). network remarking from ECT(0) to ECT(1) (or vice versa).
Processing ECN counts out of order can result in validation failure.
An endpoint SHOULD NOT perform this validation if this ACK frame does
not advance the largest packet number acknowledged in this
connection.
An endpoint could miss acknowledgements for a packet when ACK frames An endpoint could miss acknowledgements for a packet when ACK frames
are lost. It is therefore possible for the total increase in ECT(0), are lost. It is therefore possible for the total increase in ECT(0),
ECT(1), and CE counts to be greater than the number of packets ECT(1), and CE counts to be greater than the number of packets
acknowledged in an ACK frame. When this happens, and if verification acknowledged in an ACK frame. When this happens, and if validation
succeeds, the local reference counts MUST be increased to match the succeeds, the local reference counts MUST be increased to match the
counts in the ACK frame. counts in the ACK frame.
Processing counts out of order can result in verification failure. 13.4.2.3. Validation Outcomes
An endpoint SHOULD NOT perform this verification if the ACK frame is
received in a packet with packet number lower than a previously
received ACK frame. Verifying based on ACK frames that arrive out of
order can result in disabling ECN unnecessarily.
Upon successful verification, an endpoint continues to set ECT If validation fails, then the endpoint stops sending ECN markings in
codepoints in subsequent packets with the expectation that the path subsequent IP packets with the expectation that either the network
is ECN-capable. path or the peer does not support ECN.
If verification fails, then the endpoint ceases setting ECT Upon successful validation, an endpoint can continue to set ECT
codepoints in subsequent IP packets with the expectation that either codepoints in subsequent packets with the expectation that the path
the network path or the peer does not support ECN. is ECN-capable. Network routing and path elements can change mid-
connection however; an endpoint MUST disable ECN if validation fails
at any point in the connection.
If an endpoint sets ECT codepoints on outgoing IP packets and Even if validation fails, an endpoint MAY revalidate ECN on the same
encounters a retransmission timeout due to the absence of path at any later time in the connection.
acknowledgments from the peer (see [QUIC-RECOVERY]), or if an
endpoint has reason to believe that an element on the network path
might be corrupting ECN codepoints, the endpoint MAY cease setting
ECT codepoints in subsequent packets. Doing so allows the connection
to be resilient to network elements that corrupt ECN codepoints in
the IP header or drop packets with ECT or CE codepoints in the IP
header.
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.
Clients MUST ensure they send the first Initial packet in a single IP Clients MUST ensure they send the first Initial packet in a single IP
packet. Similarly, the first Initial packet sent after receiving a packet. Similarly, the first Initial packet sent after receiving a
Retry packet MUST be sent in a single IP packet. Retry packet MUST be sent in a single IP packet.
skipping to change at page 82, line 51 skipping to change at page 87, line 31
of byte 0 contain a packet type. Packet types are listed in of 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 (X): The lower four bits (those with a mask of
0x0f) of byte 0 are type-specific. 0x0f) 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 lengths of the DCID Len: The byte following the version contains the length in
two connection ID fields that follow it. These lengths are bytes of the Destination Connection ID field that follows it.
encoded as two 4-bit unsigned integers. The Destination This length is encoded as an 8-bit unsigned integer. In QUIC
Connection ID Length (DCIL) field occupies the 4 high bits of the version 1, this value MUST NOT exceed 20. Endpoints that receive
byte and the Source Connection ID Length (SCIL) field occupies the a version 1 long header with a value larger than 20 MUST drop the
4 low bits of the byte. An encoded length of 0 indicates that the packet. Servers SHOULD be able to read longer connection IDs from
connection ID is also 0 bytes in length. Non-zero encoded lengths other QUIC versions in order to properly form a version
are increased by 3 to get the full length of the connection ID, negotiation packet.
producing a length between 4 and 18 bytes inclusive. For example,
a byte with the value 0x50 describes an 8-byte Destination
Connection ID and a zero-length Source Connection ID.
Destination Connection ID: The Destination Connection ID field Destination Connection ID: The Destination Connection ID field
follows the DCID Len and is between 0 and 20 bytes in length. follows the DCID Len and is between 0 and 20 bytes in length.
Section 7.2 describes the use of this field in more detail. Section 7.2 describes the use of this field in more detail.
SCID Len: The byte following the Destination Connection ID contains SCID Len: The byte following the Destination Connection ID contains
the length in bytes of the Source Connection ID field that follows the length in bytes of the Source Connection ID field that follows
it. This length is encoded as a 8-bit unsigned integer. In QUIC it. This length is encoded as a 8-bit unsigned integer. In QUIC
version 1, this value MUST NOT exceed 20 bytes. Endpoints that version 1, this value MUST NOT exceed 20 bytes. Endpoints that
receive a version 1 long header with a value larger than 20 MUST receive a version 1 long header with a value larger than 20 MUST
skipping to change at page 89, line 31 skipping to change at page 94, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ... | Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-RTT Packet 0-RTT Packet
Packet numbers for 0-RTT protected packets use the same space as Packet numbers for 0-RTT protected packets use the same space as
1-RTT protected packets. 1-RTT protected packets.
After a client receives a Retry packet, 0-RTT packets are likely to After a client receives a Retry packet, 0-RTT packets are likely to
have been lost or discarded by the server. A client MAY attempt to have been lost or discarded by the server. A client SHOULD attempt
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
result of responding to a Retry packet. Sending packets with the result of responding to a Retry packet. Sending packets with the
same packet number in that case is likely to compromise the packet same packet number in that case is likely to compromise the packet
protection for all 0-RTT packets because the same key and nonce could protection for all 0-RTT packets because the same key and nonce could
be used to protect different content. be used to protect different content.
A client only receives acknowledgments for its 0-RTT packets once the A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete. Consequently, a server might expect 0-RTT handshake is complete. Consequently, a server might expect 0-RTT
skipping to change at page 93, line 29 skipping to change at page 98, line 29
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 original_connection_id transport parameter (see
Section 18.1). If the server sends a Retry packet, it MUST include Section 18.2). If the server sends a Retry packet, it MUST include
the value of the Original Destination Connection ID field of the the value of the Original Destination Connection ID field of the
Retry packet (that is, the Destination Connection ID field from the Retry packet (that is, the Destination Connection ID field from the
client's first Initial packet) in the transport parameter. client's first Initial packet) in the transport parameter.
If the client received and processed a Retry packet, it MUST validate If the client received and processed a Retry packet, it MUST validate
that the original_connection_id transport parameter is present and that the original_connection_id transport parameter is present and
correct; otherwise, it MUST validate that the transport parameter is correct; otherwise, it MUST validate that the transport parameter is
absent. A client MUST treat a failed validation as a connection absent. A client MUST treat a failed validation as a connection
error of type TRANSPORT_PARAMETER_ERROR. error of type TRANSPORT_PARAMETER_ERROR.
skipping to change at page 96, line 5 skipping to change at page 101, line 5
disabled for a connection. Implementations MUST allow administrators disabled for a connection. Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on of clients and servers to disable the spin bit either globally or on
a per-connection basis. Even when the spin bit is not disabled by a per-connection basis. Even when the spin bit is not disabled by
the administrator, implementations MUST disable the spin bit for a the administrator, implementations MUST disable the spin bit for a
given connection with a certain likelihood. The random selection given connection with a certain likelihood. The random selection
process SHOULD be designed such that on average the spin bit is process SHOULD be designed such that on average the spin bit is
disabled for at least one eighth of network paths. The selection disabled for at least one eighth of network paths. The selection
process performed at the beginning of the connection SHOULD be process performed at the beginning of the connection SHOULD be
applied for all paths used by the connection. applied for all paths used by the connection.
In case multiple connections share the same network path, as
determined by having the same source and destination IP address and
UDP ports, endpoints should try to co-ordinate across all connections
to ensure a clear signal to any on-path measurement points.
When the spin bit is disabled, endpoints MAY set the spin bit to any When the spin bit is disabled, endpoints MAY set the spin bit to any
value, and MUST ignore any incoming value. It is RECOMMENDED that value, and MUST ignore any incoming value. It is RECOMMENDED that
endpoints set the spin bit to a random value either chosen endpoints set the spin bit to a random value either chosen
independently for each packet or chosen independently for each independently for each packet or chosen independently for each
connection ID. connection ID.
If the spin bit is enabled for the connection, the endpoint maintains If the spin bit is enabled for the connection, the endpoint maintains
a spin value and sets the spin bit in the short header to the a spin value and sets the spin bit in the short header to the
currently stored value when a packet with a short header is sent out. currently stored value when a packet with a short header is sent out.
The spin value is initialized to 0 in the endpoint at connection The spin value is initialized to 0 in the endpoint at connection
skipping to change at page 97, line 18 skipping to change at page 102, line 18
stateless_reset_token(2), stateless_reset_token(2),
max_packet_size(3), max_packet_size(3),
initial_max_data(4), initial_max_data(4),
initial_max_stream_data_bidi_local(5), initial_max_stream_data_bidi_local(5),
initial_max_stream_data_bidi_remote(6), initial_max_stream_data_bidi_remote(6),
initial_max_stream_data_uni(7), initial_max_stream_data_uni(7),
initial_max_streams_bidi(8), initial_max_streams_bidi(8),
initial_max_streams_uni(9), initial_max_streams_uni(9),
ack_delay_exponent(10), ack_delay_exponent(10),
max_ack_delay(11), max_ack_delay(11),
disable_migration(12), disable_active_migration(12),
preferred_address(13), preferred_address(13),
active_connection_id_limit(14), active_connection_id_limit(14),
(65535) (65535)
} TransportParameterId; } TransportParameterId;
struct { struct {
TransportParameterId parameter; TransportParameterId parameter;
opaque value<0..2^16-1>; opaque value<0..2^16-1>;
} TransportParameter; } TransportParameter;
skipping to change at page 97, line 41 skipping to change at page 102, line 41
Figure 15: Definition of TransportParameters Figure 15: Definition of TransportParameters
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 a TransportParameters value. TLS defined in [QUIC-TLS] contains a TransportParameters value. TLS
encoding rules are therefore used to describe the encoding of encoding rules are therefore used to describe the encoding of
transport parameters. transport parameters.
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. Transport Parameter Definitions 18.1. Reserved Transport Parameters
Transport parameters with an identifier of the form "31 * N + 27" for
integer values of N are reserved to exercise the requirement that
unknown transport parameters be ignored. These transport parameters
have no semantics, and may carry arbitrary values.
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) and have a default value of
0 if the transport parameter is absent, unless otherwise stated. 0 if the transport parameter is absent, unless otherwise stated.
The following transport parameters are defined: The following transport parameters are defined:
skipping to change at page 99, line 47 skipping to change at page 105, line 5
max_ack_delay (0x000b): The maximum ACK delay is an integer value max_ack_delay (0x000b): The maximum ACK delay is an integer value
indicating the maximum amount of time in milliseconds by which the indicating the maximum amount of time in milliseconds by which the
endpoint will delay sending acknowledgments. This value SHOULD endpoint will delay sending acknowledgments. This value SHOULD
include the receiver's expected delays in alarms firing. For include the receiver's expected delays in alarms firing. For
example, if a receiver sets a timer for 5ms and alarms commonly example, if a receiver sets a timer for 5ms and alarms commonly
fire up to 1ms late, then it should send a max_ack_delay of 6ms. fire up to 1ms late, then it should send a max_ack_delay of 6ms.
If this value is absent, a default of 25 milliseconds is assumed. If this value is absent, a default of 25 milliseconds is assumed.
Values of 2^14 or greater are invalid. Values of 2^14 or greater are invalid.
disable_migration (0x000c): The disable migration transport disable_active_migration (0x000c): The disable active migration
parameter is included if the endpoint does not support connection transport parameter is included if the endpoint does not support
migration (Section 9). Peers of an endpoint that sets this active connection migration (Section 9). Peers of an endpoint
transport parameter MUST NOT send any packets, including probing that sets this transport parameter MUST NOT send any packets,
packets (Section 9.1), from a local address or port other than including probing packets (Section 9.1), from a local address or
that used to perform the handshake. This parameter is a zero- port other than that used to perform the handshake. This
length value. parameter is a zero-length value.
preferred_address (0x000d): The server's preferred address is used preferred_address (0x000d): The server's preferred address is used
to effect a change in server address at the end of the handshake, to effect a change in server address at the end of the handshake,
as described in Section 9.6. The format of this transport as described in Section 9.6. The format of this transport
parameter is the PreferredAddress struct shown in Figure 16. This parameter is the PreferredAddress struct shown in Figure 16. This
transport parameter is only sent by a server. Servers MAY choose transport parameter is only sent by a server. Servers MAY choose
to only send a preferred address of one address family by sending to only send a preferred address of one address family by sending
an all-zero address and port (0.0.0.0:0 or ::.0) for the other an all-zero address and port (0.0.0.0:0 or ::.0) for the other
family. family. IP addresses are encoded in network byte order.
struct { struct {
opaque ipv4Address[4]; opaque ipv4Address[4];
uint16 ipv4Port; uint16 ipv4Port;
opaque ipv6Address[16]; opaque ipv6Address[16];
uint16 ipv6Port; uint16 ipv6Port;
opaque connectionId<0..18>; opaque connectionId<0..20>;
opaque statelessResetToken[16]; opaque statelessResetToken[16];
} PreferredAddress; } PreferredAddress;
Figure 16: Preferred Address format Figure 16: Preferred Address format
active_connection_id_limit (0x000e): The maximum number of active_connection_id_limit (0x000e): The maximum number of
connection IDs from the peer that an endpoint is willing to store. connection IDs from the peer that an endpoint is willing to store.
This value includes only connection IDs sent in NEW_CONNECTION_ID This value includes only connection IDs sent in NEW_CONNECTION_ID
frames. If this parameter is absent, a default of 0 is assumed. frames. If this parameter is absent, a default of 0 is assumed.
skipping to change at page 103, line 4 skipping to change at page 108, line 11
the largest packet number that the peer has received prior to the largest packet number that the peer has received prior to
generating the ACK frame. Unlike the packet number in the QUIC generating the ACK frame. Unlike the packet number in the QUIC
long or short header, the value in an ACK frame is not truncated. long or short header, the value in an ACK frame is not truncated.
ACK Delay: A variable-length integer representing the time delta in ACK Delay: A variable-length integer representing the time delta in
microseconds between when this ACK was sent and when the largest microseconds between when this ACK was sent and when the largest
acknowledged packet, as indicated in the Largest Acknowledged acknowledged packet, as indicated in the Largest Acknowledged
field, was received by this peer. The value of the ACK Delay field, was received by this peer. The value of the ACK Delay
field is scaled by multiplying the encoded value by 2 to the power field is scaled by multiplying the encoded value by 2 to the power
of the value of the "ack_delay_exponent" transport parameter set of the value of the "ack_delay_exponent" transport parameter set
by the sender of the ACK frame (see Section 18.1). Scaling in by the sender of the ACK frame (see Section 18.2). Scaling in
this fashion allows for a larger range of values with a shorter this 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
skipping to change at page 105, line 44 skipping to change at page 110, line 44
| ECT(0) Count (i) ... | ECT(0) Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT(1) Count (i) ... | ECT(1) Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Count (i) ... | ECN-CE Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The three ECN Counts are: The three ECN Counts are:
ECT(0) Count: A variable-length integer representing the total ECT(0) Count: A variable-length integer representing the total
number of packets received with the ECT(0) codepoint. number of packets received with the ECT(0) codepoint in the packet
number space of the ACK frame.
ECT(1) Count: A variable-length integer representing the total ECT(1) Count: A variable-length integer representing the total
number of packets received with the ECT(1) codepoint. number of packets received with the ECT(1) codepoint in the packet
number 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. packets received with the CE codepoint in the packet number space
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
skipping to change at page 107, line 29 skipping to change at page 112, line 34
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 Error Code: A variable-length integer containing the
application-specified reason the sender is ignoring the stream application-specified reason the sender is ignoring the stream
(see Section 20.1). (see Section 20.1).
19.6. CRYPTO Frame 19.6. CRYPTO Frame
The CRYPTO frame (type=0x06) is used to transmit cryptographic The CRYPTO frame (type=0x06) is used to transmit cryptographic
handshake messages. It can be sent in all packet types. The CRYPTO handshake messages. It can be sent in all packet types except 0-RTT.
frame offers the cryptographic protocol an in-order stream of bytes. The CRYPTO frame offers the cryptographic protocol an in-order stream
CRYPTO frames are functionally identical to STREAM frames, except of bytes. CRYPTO frames are functionally identical to STREAM frames,
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 as follows: The CRYPTO frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset (i) ... | Offset (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 108, line 38 skipping to change at page 114, line 4
The NEW_TOKEN frame is as follows: The NEW_TOKEN frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Length (i) ... | Token Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (*) ... | Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW_TOKEN frames contain the following fields: NEW_TOKEN frames contain the following fields:
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
token in bytes. token in bytes.
Token: An opaque blob that the client may use with a future Initial Token: An opaque blob that the client may use with a future Initial
packet. packet.
An endpoint might receive multiple NEW_TOKEN frames that contain the
same token value. Endpoints are responsible for discarding duplicate
values, which might be used to link connection attempts; see
Section 8.1.2.
Clients MUST NOT send NEW_TOKEN frames. Servers MUST treat receipt
of a NEW_TOKEN frame as a connection error of type
PROTOCOL_VIOLATION.
19.8. STREAM Frames 19.8. STREAM Frames
STREAM frames implicitly create a stream and carry stream data. The STREAM frames implicitly create a stream and carry stream data. The
STREAM frame takes the form 0b00001XXX (or the set of values from STREAM frame takes the form 0b00001XXX (or the set of values from
0x08 to 0x0f). The value of the three low-order bits of the frame 0x08 to 0x0f). The value of the three low-order bits of the frame
type determines the fields that are present in the frame. type determines the fields that are present in the frame.
o The OFF bit (0x04) in the frame type is set to indicate that there o The OFF bit (0x04) in the frame type is set to indicate that there
is an Offset field present. When set to 1, the Offset field is is an Offset field present. When set to 1, the Offset field is
present. When set to 0, the Offset field is absent and the Stream present. When set to 0, the Offset field is absent and the Stream
skipping to change at page 120, line 19 skipping to change at page 125, line 43
TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport
parameters that were badly formatted, included an invalid value, parameters that were badly formatted, included an invalid value,
was absent even though it is mandatory, was present though it is was absent even though it is mandatory, was present though it is
forbidden, or is otherwise in error. forbidden, or is otherwise in error.
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_MIGRATION (0xC): A peer has migrated to a different network
when the endpoint had disabled migration.
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.3 for details of registering new error codes. See Section 22.3 for details of registering new error codes.
In defining these error codes, several principles are applied. Error
conditions that might require specific action on the part of a
recipient are given unique codes. Errors that represent common
conditions are given specific codes. Absent either of these
conditions, error codes are used to identify a general function of
the stack, like flow control or transport parameter handling.
Finally, generic errors are provided for conditions where
implementations are unable or unwilling to use more specific codes.
20.1. Application Protocol Error Codes 20.1. Application Protocol Error Codes
Application protocol error codes are 62-bit unsigned integers, but Application protocol error codes are 62-bit unsigned integers, but
the management of application error codes is left to application the management of application error codes is left to application
protocols. Application protocol error codes are used for the protocols. Application protocol error codes are used for the
RESET_STREAM frame (Section 19.4), the STOP_SENDING frame RESET_STREAM frame (Section 19.4), the STOP_SENDING frame
(Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d
(Section 19.19). (Section 19.19).
21. Security Considerations 21. Security Considerations
skipping to change at page 123, line 22 skipping to change at page 129, line 7
21.6. Stream Commitment Attack 21.6. Stream Commitment Attack
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, transmission error may cause STREAM DATA frames opening intervals, loss or reordering may cause STREAM frames that open
streams to be received out of sequence. A receiver is obligated to streams to be received out of sequence. On receiving a higher-
open intervening streams if a higher-numbered stream ID is received. numbered stream ID, a receiver is required to open all intervening
Thus, on a new connection, opening stream 2000001 opens 1 million streams of the same type (see Section 3.2). Thus, on a new
streams, as required by the specification. connection, opening stream 4000000 opens 1 million and 1 client-
initiated bidirectional streams.
The number of active streams is limited by the The number of active streams is limited by the
initial_max_streams_bidi and initial_max_streams_uni transport initial_max_streams_bidi and initial_max_streams_uni transport
parameters, as explained in Section 4.5. If chosen judiciously, parameters, as explained in Section 4.5. If chosen judiciously,
these limits mitigate the effect of the stream commitment attack. these limits mitigate the effect of the stream commitment attack.
However, setting the limit too low could affect performance when However, setting the limit too low could affect performance when
applications expect to open large number of streams. applications expect to open large number of streams.
21.7. Explicit Congestion Notification Attacks 21.7. Peer Denial of Service
QUIC and TLS both contain messages that have legitimate uses in some
contexts, but that can be abused to cause a peer to expend processing
resources without having any observable impact on the state of the
connection.
Messages can also be used to change and revert state in small or
inconsequential ways, such as by sending small increments to flow
control limits.
If processing costs are disproportionately large in comparison to
bandwidth consumption or effect on state, then this could allow a
malicious peer to exhaust processing capacity.
While there are legitimate uses for all messages, implementations
SHOULD track cost of processing relative to progress and treat
excessive quantities of any non-productive packets as indicative of
an attack. Endpoints MAY respond to this condition with a connection
error, or by dropping packets.
21.8. Explicit Congestion Notification Attacks
An on-path attacker could manipulate the value of ECN codepoints in An on-path attacker could manipulate the value of ECN codepoints in
the IP header to influence the sender's rate. [RFC3168] discusses the IP header to influence the sender's rate. [RFC3168] discusses
manipulations and their effects in more detail. manipulations and their effects in more detail.
An on-the-side attacker can duplicate and send packets with modified An on-the-side attacker can duplicate and send packets with modified
ECN codepoints to affect the sender's rate. If duplicate packets are ECN codepoints to affect the sender's rate. If duplicate packets are
discarded by a receiver, an off-path attacker will need to race the discarded by a receiver, an off-path attacker will need to race the
duplicate packet against the original to be successful in this duplicate packet against the original to be successful in this
attack. Therefore, QUIC endpoints ignore the ECN codepoint field on attack. Therefore, QUIC endpoints ignore the ECN codepoint field on
an IP packet unless at least one QUIC packet in that IP packet is an IP packet unless at least one QUIC packet in that IP packet is
successfully processed; see Section 13.3. successfully processed; see Section 13.4.
21.8. Stateless Reset Oracle 21.9. Stateless Reset Oracle
Stateless resets create a possible denial of service attack analogous Stateless resets create a possible denial of service attack analogous
to a TCP reset injection. This attack is possible if an attacker is to a TCP reset injection. This attack is possible if an attacker is
able to cause a stateless reset token to be generated for a able to cause a stateless reset token to be generated for a
connection with a selected connection ID. An attacker that can cause connection with a selected connection ID. An attacker that can cause
this token to be generated can reset an active connection with the this token to be generated can reset an active connection with the
same connection ID. same connection ID.
If a packet can be routed to different instances that share a static If a packet can be routed to different instances that share a static
key, for example by changing an IP address or port, then an attacker key, for example by changing an IP address or port, then an attacker
skipping to change at page 124, line 32 skipping to change at page 130, line 34
In the case of a cluster that uses dynamic load balancing, it's In the case of a cluster that uses dynamic load balancing, it's
possible that a change in load balancer configuration could happen possible that a change in load balancer configuration could happen
while an active instance retains connection state; even if an while an active instance retains connection state; even if an
instance retains connection state, the change in routing and instance retains connection state, the change in routing and
resulting stateless reset will result in the connection being resulting stateless reset will result in the connection being
terminated. If there is no chance in the packet being routed to the terminated. If there is no chance in the packet being routed to the
correct instance, it is better to send a stateless reset than wait correct instance, it is better to send a stateless reset than wait
for connections to time out. However, this is acceptable only if the for connections to time out. However, this is acceptable only if the
routing cannot be influenced by an attacker. routing cannot be influenced by an attacker.
21.9. Version Downgrade 21.10. Version Downgrade
This document defines QUIC Version Negotiation packets Section 6, This document defines QUIC Version Negotiation packets Section 6,
which can be used to negotiate the QUIC version used between two which can be used to negotiate the QUIC version used between two
endpoints. However, this document does not specify how this endpoints. However, this document does not specify how this
negotiation will be performed between this version and subsequent negotiation will be performed between this version and subsequent
future versions. In particular, Version Negotiation packets do not future versions. In particular, Version Negotiation packets do not
contain any mechanism to prevent version downgrade attacks. Future contain any mechanism to prevent version downgrade attacks. Future
versions of QUIC that use Version Negotiation packets MUST define a versions of QUIC that use Version Negotiation packets MUST define a
mechanism that is robust against version downgrade attacks. mechanism that is robust against version downgrade attacks.
21.10. Targeted Attacks by Routing 21.11. Targeted Attacks by Routing
Deployments should limit the ability of an attacker to target a new Deployments should limit the ability of an attacker to target a new
connection to a particular server instance. This means that client- connection to a particular server instance. This means that client-
controlled fields, such as the initial Destination Connection ID used controlled fields, such as the initial Destination Connection ID used
on Initial and 0-RTT packets SHOULD NOT be used by themselves to make on Initial and 0-RTT packets SHOULD NOT be used by themselves to make
routing decisions. Ideally, routing decisions are made independently routing decisions. Ideally, routing decisions are made independently
of client-selected values; a Source Connection ID can be selected to of client-selected values; a Source Connection ID can be selected to
route later packets to the same server. route later packets to the same server.
22. IANA Considerations 22. IANA Considerations
skipping to change at page 126, line 8 skipping to change at page 132, line 8
readily accessible. Expert(s) are encouraged to be biased towards readily accessible. Expert(s) are encouraged to be biased towards
approving registrations unless they are abusive, frivolous, or approving registrations unless they are abusive, frivolous, or
actively harmful (not merely aesthetically displeasing, or actively harmful (not merely aesthetically displeasing, or
architecturally dubious). architecturally dubious).
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 |
+--------+-------------------------------------+---------------+ +--------+-------------------------------------+---------------+
| 0x0000 | original_connection_id | Section 18.1 | | 0x0000 | original_connection_id | Section 18.2 |
| | | | | | | |
| 0x0001 | idle_timeout | Section 18.1 | | 0x0001 | idle_timeout | Section 18.2 |
| | | | | | | |
| 0x0002 | stateless_reset_token | Section 18.1 | | 0x0002 | stateless_reset_token | Section 18.2 |
| | | | | | | |
| 0x0003 | max_packet_size | Section 18.1 | | 0x0003 | max_packet_size | Section 18.2 |
| | | | | | | |
| 0x0004 | initial_max_data | Section 18.1 | | 0x0004 | initial_max_data | Section 18.2 |
| | | | | | | |
| 0x0005 | initial_max_stream_data_bidi_local | Section 18.1 | | 0x0005 | initial_max_stream_data_bidi_local | Section 18.2 |
| | | | | | | |
| 0x0006 | initial_max_stream_data_bidi_remote | Section 18.1 | | 0x0006 | initial_max_stream_data_bidi_remote | Section 18.2 |
| | | | | | | |
| 0x0007 | initial_max_stream_data_uni | Section 18.1 | | 0x0007 | initial_max_stream_data_uni | Section 18.2 |
| | | | | | | |
| 0x0008 | initial_max_streams_bidi | Section 18.1 | | 0x0008 | initial_max_streams_bidi | Section 18.2 |
| | | | | | | |
| 0x0009 | initial_max_streams_uni | Section 18.1 | | 0x0009 | initial_max_streams_uni | Section 18.2 |
| | | | | | | |
| 0x000a | ack_delay_exponent | Section 18.1 | | 0x000a | ack_delay_exponent | Section 18.2 |
| | | | | | | |
| 0x000b | max_ack_delay | Section 18.1 | | 0x000b | max_ack_delay | Section 18.2 |
| | | | | | | |
| 0x000c | disable_migration | Section 18.1 | | 0x000c | disable_active_migration | Section 18.2 |
| | | | | | | |
| 0x000d | preferred_address | Section 18.1 | | 0x000d | preferred_address | Section 18.2 |
| | | | | | | |
| 0x000e | active_connection_id_limit | Section 18.1 | | 0x000e | active_connection_id_limit | 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
values of N (that is, "27", "58", "89", ...) MUST NOT be assigned by
IANA.
22.2. QUIC Frame Type Registry 22.2. QUIC Frame Type Registry
IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
"QUIC Protocol" heading. "QUIC Protocol" heading.
The "QUIC Frame Types" registry governs a 62-bit space. This space The "QUIC Frame Types" registry governs a 62-bit space. This space
is split into three spaces that are governed by different policies. is split into three spaces that are governed by different policies.
Values between 0x00 and 0x3f (in hexadecimal) are assigned via the Values between 0x00 and 0x3f (in hexadecimal) are assigned via the
Standards Action or IESG Review policies [RFC8126]. Values from 0x40 Standards Action or IESG Review policies [RFC8126]. Values from 0x40
to 0x3fff operate on the Specification Required policy [RFC8126]. to 0x3fff operate on the Specification Required policy [RFC8126].
skipping to change at page 129, line 41 skipping to change at page 135, line 41
| | | error | | | | | error | |
| | | | | | | | | |
| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 |
| | | transport | | | | | transport | |
| | | parameters | | | | | parameters | |
| | | | | | | | | |
| 0xA | PROTOCOL_VIOLATION | Generic | Section 20 | | 0xA | PROTOCOL_VIOLATION | Generic | Section 20 |
| | | protocol | | | | | protocol | |
| | | violation | | | | | violation | |
| | | | | | | | | |
| 0xC | INVALID_MIGRATION | Violated | Section 20 | | 0xD | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 |
| | | disabled | | | | | buffer | |
| | | migration | | | | | 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] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08
(work in progress), June 2019. (work in progress), June 2019.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-22 (work and Congestion Control", draft-ietf-quic-recovery-23 (work
in progress), July 2019. in progress), September 2019.
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
tls-22 (work in progress), July 2019. tls-23 (work in progress), September 2019.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 131, line 50 skipping to change at page 137, line 50
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-05 (work in progress), July draft-ietf-quic-invariants-07 (work in progress),
2019. September 2019.
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-05 Transport Protocol", draft-ietf-quic-manageability-05
(work in progress), July 2019. (work in progress), July 2019.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
skipping to change at page 132, line 43 skipping to change at page 138, line 43
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>. 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
skipping to change at page 134, line 5 skipping to change at page 140, line 12
return candidate_pn - pn_win return candidate_pn - pn_win
return candidate_pn return candidate_pn
Appendix B. Change Log Appendix B. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
B.1. Since draft-ietf-quic-transport-21 B.1. Since draft-ietf-quic-transport-22
o Rules for preventing correlation by connection ID tightened
(#2084, #2929)
o Clarified use of CONNECTION_CLOSE in Handshake packets (#2151,
#2541, #2688)
o Discourage regressions of largest acknowledged in ACK (#2205,
#2752)
o Improved robusness of validation process for ECN counts (#2534,
#2752)
o Require endpoints to ignore spurious migration attempts (#2342,
#2893)
o Transport parameter for disabling migration clarified to allow NAT
rebinding (#2389, #2893)
o Document principles for defining new error codes (#2388, #2880)
o Reserve transport parameters for greasing (#2550, #2873)
o A maximum ACK delay of 0 is used for handshake packet number
spaces (#2646, #2638)
o Improved rules for use of congestion control state on new paths
(#2685, #2918)
o Removed recommendation to coordinate spin for multiple connections
that share a path (#2763, #2882)
o Allow smaller stateless resets and recommend a smaller minimum on
packets that might trigger a stateless reset (#2770, #2869, #2927)
o Provide guidance around the interface to QUIC as used by
application protocols (#2805, #2857)
o Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825,
#2826)
o Tighter rules about processing of rejected 0-RTT packets (#2829,
#2840, #2841)
o Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)
o Cryptographic handshake needs to provide server transport
parameter encryption (#2920, #2921)
o Moved ACK generation guidance from recovery draft to transport
draft (#1860, #2916).
B.2. Since draft-ietf-quic-transport-21
o Connection ID lengths are now one octet, but limited in version 1 o 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)
B.2. Since draft-ietf-quic-transport-20 B.3. Since draft-ietf-quic-transport-20
o Error codes are encoded as variable-length integers (#2672, #2680) o Error codes are encoded as variable-length integers (#2672, #2680)
o NEW_CONNECTION_ID includes a request to retire old connection IDs o NEW_CONNECTION_ID includes a request to retire old connection IDs
(#2645, #2769) (#2645, #2769)
o Tighter rules for generating and explicitly eliciting ACK frames o Tighter rules for generating and explicitly eliciting ACK frames
(#2546, #2794) (#2546, #2794)
o Recommend having only one packet per encryption level in a o Recommend having only one packet per encryption level in a
datagram (#2308, #2747) datagram (#2308, #2747)
o More normative language about use of stateless reset (#2471, o More normative language about use of stateless reset (#2471,
#2574) #2574)
o Allow reuse of stateless reset tokens (#2732, #2733) o Allow reuse of stateless reset tokens (#2732, #2733)
o Allow, but not require, enforcing non-duplicate transport o Allow, but not require, enforcing non-duplicate transport
parameters (#2689, #2691) parameters (#2689, #2691)
o Added a active_connection_id_limit transport parameter (#1994, o Added an active_connection_id_limit transport parameter (#1994,
#1998) #1998)
o max_ack_delay transport parameter defaults to 0 (#2638, #2646) o max_ack_delay transport parameter defaults to 0 (#2638, #2646)
o When sending 0-RTT, only remembered transport parameters apply o When sending 0-RTT, only remembered transport parameters apply
(#2458, #2360, #2466, #2461) (#2458, #2360, #2466, #2461)
o Define handshake completion and confirmation; define clearer rules o Define handshake completion and confirmation; define clearer rules
when it encryption keys should be discarded (#2214, #2267, #2673) when it encryption keys should be discarded (#2214, #2267, #2673)
skipping to change at page 135, line 5 skipping to change at page 142, line 17
o PATH_RESPONSE no longer needs to be received on the validated path o PATH_RESPONSE no longer needs to be received on the validated path
(#2582, #2580, #2579, #2637) (#2582, #2580, #2579, #2637)
o PATH_RESPONSE frames are not stored and retransmitted (#2724, o PATH_RESPONSE frames are not stored and retransmitted (#2724,
#2729) #2729)
o Document hack for enabling routing of ICMP when doing PMTU probing o Document hack for enabling routing of ICMP when doing PMTU probing
(#1243, #2402) (#1243, #2402)
B.3. Since draft-ietf-quic-transport-19 B.4. Since draft-ietf-quic-transport-19
o Refine discussion of 0-RTT transport parameters (#2467, #2464) o Refine discussion of 0-RTT transport parameters (#2467, #2464)
o Fewer transport parameters need to be remembered for 0-RTT (#2624, o Fewer transport parameters need to be remembered for 0-RTT (#2624,
#2467) #2467)
o Spin bit text incorporated (#2564) o Spin bit text incorporated (#2564)
o Close the connection when maximum stream ID in MAX_STREAMS exceeds o Close the connection when maximum stream ID in MAX_STREAMS exceeds
2^62 - 1 (#2499, #2487) 2^62 - 1 (#2499, #2487)
skipping to change at page 135, line 32 skipping to change at page 142, line 44
o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) o The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
o Initial packets from clients need to be padded to 1200 unless a o Initial packets from clients need to be padded to 1200 unless a
Handshake packet is sent as well (#2522, #2523) Handshake packet is sent as well (#2522, #2523)
o CRYPTO frames can be discarded if too much data is buffered o CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524) (#1834, #2524)
o Stateless reset uses a short header packet (#2599, #2600) o Stateless reset uses a short header packet (#2599, #2600)
B.4. Since draft-ietf-quic-transport-18 B.5. Since draft-ietf-quic-transport-18
o Removed version negotiation; version negotiation, including o Removed version negotiation; version negotiation, including
authentication of the result, will be addressed in the next authentication of the result, will be addressed in the next
version of QUIC (#1773, #2313) version of QUIC (#1773, #2313)
o Added discussion of the use of IPv6 flow labels (#2348, #2399) o Added discussion of the use of IPv6 flow labels (#2348, #2399)
o A connection ID can't be retired in a packet that uses that o A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420) connection ID (#2101, #2420)
o Idle timeout transport parameter is in milliseconds (from seconds) o Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454) (#2453, #2454)
o Endpoints are required to use new connection IDs when they use new o Endpoints are required to use new connection IDs when they use new
network paths (#2413, #2414) network paths (#2413, #2414)
o Increased the set of permissible frames in 0-RTT (#2344, #2355) o Increased the set of permissible frames in 0-RTT (#2344, #2355)
B.5. Since draft-ietf-quic-transport-17 B.6. Since draft-ietf-quic-transport-17
o Stream-related errors now use STREAM_STATE_ERROR (#2305) o Stream-related errors now use STREAM_STATE_ERROR (#2305)
o Endpoints discard initial keys as soon as handshake keys are o Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
o Expanded conditions for ignoring ICMP packet too big messages o Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161) (#2108, #2161)
o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
skipping to change at page 136, line 44 skipping to change at page 144, line 7
#2301) #2301)
o Allow server preferred address for both IPv4 and IPv6 (#2122, o Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296) #2296)
o Corrected requirements for migration to a preferred address o Corrected requirements for migration to a preferred address
(#2146, #2349) (#2146, #2349)
o ACK of non-existent packet is illegal (#2298, #2302) o ACK of non-existent packet is illegal (#2298, #2302)
B.6. Since draft-ietf-quic-transport-16 B.7. Since draft-ietf-quic-transport-16
o Stream limits are defined as counts, not maximums (#1850, #1906) o Stream limits are defined as counts, not maximums (#1850, #1906)
o Require amplification attack defense after closing (#1905, #1911) o Require amplification attack defense after closing (#1905, #1911)
o Remove reservation of application error code 0 for STOPPING o Remove reservation of application error code 0 for STOPPING
(#1804, #1922) (#1804, #1922)
o Renumbered frames (#1945) o Renumbered frames (#1945)
skipping to change at page 137, line 41 skipping to change at page 145, line 4
#2013) #2013)
o Added mitigation for off-path migration attacks (#1278, #1749, o Added mitigation for off-path migration attacks (#1278, #1749,
#2033) #2033)
o Don't let the PMTU to drop below 1280 (#2063, #2069) o Don't let the PMTU to drop below 1280 (#2063, #2069)
o Require peers to replace retired connection IDs (#2085) o Require peers to replace retired connection IDs (#2085)
o Servers are required to ignore Version Negotiation packets (#2088) o Servers are required to ignore Version Negotiation packets (#2088)
o Tokens are repeated in all Initial packets (#2089) o Tokens are repeated in all Initial packets (#2089)
o Clarified how PING frames are sent after loss (#2094) o Clarified how PING frames are sent after loss (#2094)
o Initial keys are discarded once Handshake are available (#1951, o Initial keys are discarded once Handshake are available (#1951,
#2045) #2045)
o ICMP PTB validation clarifications (#2161, #2109, #2108) o ICMP PTB validation clarifications (#2161, #2109, #2108)
B.7. Since draft-ietf-quic-transport-15 B.8. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
B.8. Since draft-ietf-quic-transport-14 B.9. Since draft-ietf-quic-transport-14
o Merge ACK and ACK_ECN (#1778, #1801) o Merge ACK and ACK_ECN (#1778, #1801)
o Explicitly communicate max_ack_delay (#981, #1781) o Explicitly communicate max_ack_delay (#981, #1781)
o Validate original connection ID after Retry packets (#1710, #1486, o Validate original connection ID after Retry packets (#1710, #1486,
#1793) #1793)
o Idle timeout is optional and has no specified maximum (#1765) o Idle timeout is optional and has no specified maximum (#1765)
o Update connection ID handling; add RETIRE_CONNECTION_ID type o Update connection ID handling; add RETIRE_CONNECTION_ID type
(#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799,
#1821) #1821)
o Include a Token in all Initial packets (#1649, #1794) o Include a Token in all Initial packets (#1649, #1794)
o Prevent handshake deadlock (#1764, #1824) o Prevent handshake deadlock (#1764, #1824)
B.9. Since draft-ietf-quic-transport-13 B.10. Since draft-ietf-quic-transport-13
o Streams open when higher-numbered streams of the same type open o Streams open when higher-numbered streams of the same type open
(#1342, #1549) (#1342, #1549)
o Split initial stream flow control limit into 3 transport o Split initial stream flow control limit into 3 transport
parameters (#1016, #1542) parameters (#1016, #1542)
o All flow control transport parameters are optional (#1610) o All flow control transport parameters are optional (#1610)
o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
skipping to change at page 139, line 4 skipping to change at page 146, line 12
o Recommended defense against stateless reset spoofing (#1386, o Recommended defense against stateless reset spoofing (#1386,
#1554) #1554)
o Prevent infinite stateless reset exchanges (#1443, #1627) o Prevent infinite stateless reset exchanges (#1443, #1627)
o Forbid processing of the same packet number twice (#1405, #1624) o Forbid processing of the same packet number twice (#1405, #1624)
o Added a packet number decoding example (#1493) o Added a packet number decoding example (#1493)
o More precisely define idle timeout (#1429, #1614, #1652) o More precisely define idle timeout (#1429, #1614, #1652)
o Corrected format of Retry packet and prevented looping (#1492, o Corrected format of Retry packet and prevented looping (#1492,
#1451, #1448, #1498) #1451, #1448, #1498)
o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, o Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621) #1514, #1621)
o Permit Retry in response to 0-RTT (#1547, #1552) o Permit Retry in response to 0-RTT (#1547, #1552)
o Looser verification of ECN counters to account for ACK loss o Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565) (#1555, #1481, #1565)
o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) o Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
B.10. Since draft-ietf-quic-transport-12 B.11. Since draft-ietf-quic-transport-12
o Changes to integration of the TLS handshake (#829, #1018, #1094, o Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450, #1458) #1165, #1190, #1233, #1242, #1252, #1450, #1458)
* The cryptographic handshake uses CRYPTO frames, not stream 0 * The cryptographic handshake uses CRYPTO frames, not stream 0
* QUIC packet protection is used in place of TLS record * QUIC packet protection is used in place of TLS record
protection protection
* Separate QUIC packet number spaces are used for the handshake * Separate QUIC packet number spaces are used for the handshake
skipping to change at page 140, line 14 skipping to change at page 147, line 20
o Fixed sampling method for packet number encryption; the length o Fixed sampling method for packet number encryption; the length
field in long headers includes the packet number field in addition field in long headers includes the packet number field in addition
to the packet payload (#1387, #1389) to the packet payload (#1387, #1389)
o Stateless Reset is now symmetric and subject to size constraints o Stateless Reset is now symmetric and subject to size constraints
(#466, #1346) (#466, #1346)
o Added frame type extension mechanism (#58, #1473) o Added frame type extension mechanism (#58, #1473)
B.11. Since draft-ietf-quic-transport-11 B.12. Since draft-ietf-quic-transport-11
o Enable server to transition connections to a preferred address o Enable server to transition connections to a preferred address
(#560, #1251) (#560, #1251)
o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
#990, #734, #1317, #1267, #1079) #990, #734, #1317, #1267, #1079)
o Packet numbers use a variable-length encoding (#989, #1334) o Packet numbers use a variable-length encoding (#989, #1334)
o STREAM frames can now be empty (#1350) o STREAM frames can now be empty (#1350)
B.12. Since draft-ietf-quic-transport-10 B.13. Since draft-ietf-quic-transport-10
o Swap payload length and packed number fields in long header o Swap payload length and packed number fields in long header
(#1294) (#1294)
o Clarified that CONNECTION_CLOSE is allowed in Handshake packet o Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
o Spin bit reserved (#1283) o Spin bit reserved (#1283)
o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
skipping to change at page 140, line 45 skipping to change at page 148, line 4
o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
o A more complete connection migration (#1249) o A more complete connection migration (#1249)
o Refine opportunistic ACK defense text (#305, #1030, #1185) o Refine opportunistic ACK defense text (#305, #1030, #1185)
o A Stateless Reset Token isn't mandatory (#818, #1191) o A Stateless Reset Token isn't mandatory (#818, #1191)
o Removed implicit stream opening (#896, #1193) o Removed implicit stream opening (#896, #1193)
o An empty STREAM frame can be used to open a stream without sending o An empty STREAM frame can be used to open a stream without sending
data (#901, #1194) data (#901, #1194)
o Define stream counts in transport parameters rather than a maximum o Define stream counts in transport parameters rather than a maximum
stream ID (#1023, #1065) stream ID (#1023, #1065)
o STOP_SENDING is now prohibited before streams are used (#1050) o STOP_SENDING is now prohibited before streams are used (#1050)
o Recommend including ACK in Retry packets and allow PADDING (#1067, o Recommend including ACK in Retry packets and allow PADDING (#1067,
#882) #882)
o Endpoints now become closing after an idle timeout (#1178, #1179) o Endpoints now become closing after an idle timeout (#1178, #1179)
o Remove implication that Version Negotiation is sent when a packet o Remove implication that Version Negotiation is sent when a packet
of the wrong version is received (#1197) of the wrong version is received (#1197)
B.13. Since draft-ietf-quic-transport-09 B.14. Since draft-ietf-quic-transport-09
o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with
Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d.
(#1091, #725, #1086) (#1091, #725, #1086)
o A server can now only send 3 packets without validating the client o A server can now only send 3 packets without validating the client
address (#38, #1090) address (#38, #1090)
o Delivery order of stream data is no longer strongly specified o Delivery order of stream data is no longer strongly specified
(#252, #1070) (#252, #1070)
skipping to change at page 141, line 39 skipping to change at page 148, line 47
o Improved retransmission rules for all frame types: information is o Improved retransmission rules for all frame types: information is
retransmitted, not packets or frames (#463, #765, #1095, #1053) retransmitted, not packets or frames (#463, #765, #1095, #1053)
o Added an error code for server busy signals (#1137) o Added an error code for server busy signals (#1137)
o Endpoints now set the connection ID that their peer uses. o Endpoints now set the connection ID that their peer uses.
Connection IDs are variable length. Removed the Connection IDs are variable length. Removed the
omit_connection_id transport parameter and the corresponding short omit_connection_id transport parameter and the corresponding short
header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
B.14. Since draft-ietf-quic-transport-08 B.15. Since draft-ietf-quic-transport-08
o Clarified requirements for BLOCKED usage (#65, #924) o Clarified requirements for BLOCKED usage (#65, #924)
o BLOCKED frame now includes reason for blocking (#452, #924, #927, o BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
o GAP limitation in ACK Frame (#613) o GAP limitation in ACK Frame (#613)
o Improved PMTUD description (#614, #1036) o Improved PMTUD description (#614, #1036)
o Clarified stream state machine (#634, #662, #743, #894) o Clarified stream state machine (#634, #662, #743, #894)
o Reserved versions don't need to be generated deterministically o Reserved versions don't need to be generated deterministically
(#831, #931) (#831, #931)
o You don't always need the draining period (#871) o You don't always need the draining period (#871)
o Stateless reset clarified as version-specific (#930, #986) o Stateless reset clarified as version-specific (#930, #986)
o initial_max_stream_id_x transport parameters are optional (#970, o initial_max_stream_id_x transport parameters are optional (#970,
#971) #971)
o Ack Delay assumes a default value during the handshake (#1007, o Ack Delay assumes a default value during the handshake (#1007,
#1009) #1009)
o Removed transport parameters from NewSessionTicket (#1015) o Removed transport parameters from NewSessionTicket (#1015)
B.15. Since draft-ietf-quic-transport-07 B.16. Since draft-ietf-quic-transport-07
o The long header now has version before packet number (#926, #939) o The long header now has version before packet number (#926, #939)
o Rename and consolidate packet types (#846, #822, #847) o Rename and consolidate packet types (#846, #822, #847)
o Packet types are assigned new codepoints and the Connection ID o Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956) Flag is inverted (#426, #956)
o Removed type for Version Negotiation and use Version 0 (#963, o Removed type for Version Negotiation and use Version 0 (#963,
#968) #968)
skipping to change at page 143, line 15 skipping to change at page 150, line 25
o Address validation for connection migration (#161, #732, #878) o Address validation for connection migration (#161, #732, #878)
o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) o Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
o negotiated_version is sent in server transport parameters (#710, o negotiated_version is sent in server transport parameters (#710,
#959) #959)
o Increased the range over which packet numbers are randomized o Increased the range over which packet numbers are randomized
(#864, #850, #964) (#864, #850, #964)
B.16. Since draft-ietf-quic-transport-06 B.17. Since draft-ietf-quic-transport-06
o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
o Split error code space between application and transport (#485) o Split error code space between application and transport (#485)
o Stateless reset token moved to end (#820) o Stateless reset token moved to end (#820)
o 1-RTT-protected long header types removed (#848) o 1-RTT-protected long header types removed (#848)
o No acknowledgments during draining period (#852) o No acknowledgments during draining period (#852)
o Remove "application close" as a separate close type (#854) o Remove "application close" as a separate close type (#854)
o Remove timestamps from the ACK frame (#841) o Remove timestamps from the ACK frame (#841)
o Require transport parameters to only appear once (#792) o Require transport parameters to only appear once (#792)
B.17. Since draft-ietf-quic-transport-05 B.18. Since draft-ietf-quic-transport-05
o Stateless token is server-only (#726) o Stateless token is server-only (#726)
o Refactor section on connection termination (#733, #748, #328, o Refactor section on connection termination (#733, #748, #328,
#177) #177)
o Limit size of Version Negotiation packet (#585) o Limit size of Version Negotiation packet (#585)
o Clarify when and what to ack (#736) o Clarify when and what to ack (#736)
o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
o Clarify Keep-alive requirements (#729) o Clarify Keep-alive requirements (#729)
B.18. Since draft-ietf-quic-transport-04 B.19. Since draft-ietf-quic-transport-04
o Introduce STOP_SENDING frame, RESET_STREAM only resets in one o Introduce STOP_SENDING frame, RESET_STREAM only resets in one
direction (#165) direction (#165)
o Removed GOAWAY; application protocols are responsible for graceful o Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696) shutdown (#696)
o Reduced the number of error codes (#96, #177, #184, #211) o Reduced the number of error codes (#96, #177, #184, #211)
o Version validation fields can't move or change (#121) o Version validation fields can't move or change (#121)
skipping to change at page 144, line 34 skipping to change at page 151, line 42
o Increased the maximum length of the Largest Acknowledged field in o Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
o truncate_connection_id is renamed to omit_connection_id (#659) o truncate_connection_id is renamed to omit_connection_id (#659)
o CONNECTION_CLOSE terminates the connection like TCP RST (#330, o CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
B.19. Since draft-ietf-quic-transport-03 B.20. Since draft-ietf-quic-transport-03
o Change STREAM and RESET_STREAM layout o Change STREAM and RESET_STREAM layout
o Add MAX_STREAM_ID settings o Add MAX_STREAM_ID settings
B.20. Since draft-ietf-quic-transport-02 B.21. Since draft-ietf-quic-transport-02
o The size of the initial packet payload has a fixed minimum (#267, o The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
o Define when Version Negotiation packets are ignored (#284, #294, o Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
o The 64-bit FNV-1a algorithm is used for integrity protection of o The 64-bit FNV-1a algorithm is used for integrity protection of
unprotected packets (#167, #480, #481, #517) unprotected packets (#167, #480, #481, #517)
skipping to change at page 145, line 37 skipping to change at page 153, line 5
linkability (#232, #491, #496) linkability (#232, #491, #496)
o Transport parameters for 0-RTT are retained from a previous o Transport parameters for 0-RTT are retained from a previous
connection (#405, #513, #512) connection (#405, #513, #512)
* A client in 0-RTT no longer required to reset excess streams * A client in 0-RTT no longer required to reset excess streams
(#425, #479) (#425, #479)
o Expanded security considerations (#440, #444, #445, #448) o Expanded security considerations (#440, #444, #445, #448)
B.21. Since draft-ietf-quic-transport-01 B.22. Since draft-ietf-quic-transport-01
o Defined short and long packet headers (#40, #148, #361) o Defined short and long packet headers (#40, #148, #361)
o Defined a versioning scheme and stable fields (#51, #361) o Defined a versioning scheme and stable fields (#51, #361)
o Define reserved version values for "greasing" negotiation (#112, o Define reserved version values for "greasing" negotiation (#112,
#278) #278)
o The initial packet number is randomized (#35, #283) o The initial packet number is randomized (#35, #283)
skipping to change at page 147, line 36 skipping to change at page 155, line 5
o Remove error code and reason phrase from GOAWAY (#352, #355) o Remove error code and reason phrase from GOAWAY (#352, #355)
o GOAWAY includes a final stream number for both directions (#347) o GOAWAY includes a final stream number for both directions (#347)
o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
o Defined priority as the responsibility of the application protocol o Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
B.22. Since draft-ietf-quic-transport-00 B.23. Since draft-ietf-quic-transport-00
o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
o Defined versioning o Defined versioning
o Reworked description of packet and frame layout o Reworked description of packet and frame layout
o Error code space is divided into regions for each component o Error code space is divided into regions for each component
o Use big endian for all numeric values o Use big endian for all numeric values
B.23. Since draft-hamilton-quic-transport-protocol-01 B.24. Since draft-hamilton-quic-transport-protocol-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added IANA Considerations section o Added IANA Considerations section
o Moved Contributors and Acknowledgments to appendices o Moved Contributors and Acknowledgments to appendices
Acknowledgments Acknowledgments
Special thanks are due to the following for helping shape pre-IETF Special thanks are due to the following for helping shape pre-IETF
QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon,
Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund.
 End of changes. 154 change blocks. 
450 lines changed or deleted 800 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/