draft-ietf-quic-transport-20.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: October 25, 2019 Mozilla Expires: December 7, 2019 Mozilla
April 23, 2019 June 5, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-20 draft-ietf-quic-transport-latest
Abstract Abstract
This document defines the core of the QUIC transport protocol. This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation. control and the use of TLS for key negotiation.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 25, 2019. This Internet-Draft will expire on December 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 10 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 11 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 12
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 13 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 14
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 16 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 17
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 20
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 21
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 22
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 23
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 25
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 26
5.2. Matching Packets to Connections . . . . . . . . . . . . . 26 5.2. Matching Packets to Connections . . . . . . . . . . . . . 26
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 27 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 27
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 27 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 28
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 28 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 28
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 28 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 29
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 29
6.2. Handling Version Negotiation Packets . . . . . . . . . . 29 6.2. Handling Version Negotiation Packets . . . . . . . . . . 29
6.2.1. Version Negotiation Between Draft Versions . . . . . 29 6.2.1. Version Negotiation Between Draft Versions . . . . . 30
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 30
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 30 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 30
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 31 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 32
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 33
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 34 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 34
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 35
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 36
7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 36 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 37
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 36 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37
8.1. Address Validation During Connection Establishment . . . 37 8.1. Address Validation During Connection Establishment . . . 37
8.1.1. Address Validation using Retry Packets . . . . . . . 37 8.1.1. Address Validation using Retry Packets . . . . . . . 38
8.1.2. Address Validation for Future Connections . . . . . . 38 8.1.2. Address Validation for Future Connections . . . . . . 39
8.1.3. Address Validation Token Integrity . . . . . . . . . 40 8.1.3. Address Validation Token Integrity . . . . . . . . . 41
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 40 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 41
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 41 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 42
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 42 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 43
8.5. Successful Path Validation . . . . . . . . . . . . . . . 42 8.5. Successful Path Validation . . . . . . . . . . . . . . . 43
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 42 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 43 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 44
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 44 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 44
9.2. Initiating Connection Migration . . . . . . . . . . . . . 44 9.2. Initiating Connection Migration . . . . . . . . . . . . . 45
9.3. Responding to Connection Migration . . . . . . . . . . . 45 9.3. Responding to Connection Migration . . . . . . . . . . . 45
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 45 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 46
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 46 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 47
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 47 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 47
9.4. Loss Detection and Congestion Control . . . . . . . . . . 48 9.4. Loss Detection and Congestion Control . . . . . . . . . . 48
9.5. Privacy Implications of Connection Migration . . . . . . 49 9.5. Privacy Implications of Connection Migration . . . . . . 49
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 49 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 50
9.6.1. Communicating A Preferred Address . . . . . . . . . . 50 9.6.1. Communicating A Preferred Address . . . . . . . . . . 50
9.6.2. Responding to Connection Migration . . . . . . . . . 50 9.6.2. Responding to Connection Migration . . . . . . . . . 51
9.6.3. Interaction of Client Migration and Preferred Address 51 9.6.3. Interaction of Client Migration and Preferred Address 51
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 51 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 52
10. Connection Termination . . . . . . . . . . . . . . . . . . . 52 10. Connection Termination . . . . . . . . . . . . . . . . . . . 52
10.1. Closing and Draining Connection States . . . . . . . . . 52 10.1. Closing and Draining Connection States . . . . . . . . . 52
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 53 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 54
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 54 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 54
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 55 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 55
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 58 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 58
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 58 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 58
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 59 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 59
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 60 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 60
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 60 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 61
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 61 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 61
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 61 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 62
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 61 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 62
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 62 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 63
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 63 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 63
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 64 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 65
13. Packetization and Reliability . . . . . . . . . . . . . . . . 67 13. Packetization and Reliability . . . . . . . . . . . . . . . . 68
13.1. Packet Processing and Acknowledgment . . . . . . . . . . 68 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 69
13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 68 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 69
13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 69 13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 70
13.2. Retransmission of Information . . . . . . . . . . . . . 69 13.2. Retransmission of Information . . . . . . . . . . . . . 70
13.3. Explicit Congestion Notification . . . . . . . . . . . . 72 13.3. Explicit Congestion Notification . . . . . . . . . . . . 73
13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 72 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 73
13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 73 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 74
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 74 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 75
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 75 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 76
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 76 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 77
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 77 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 78
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 77 14.3.1. PMTU Probes Containing Source Connection ID . . . . 78
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 78 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 78
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 79 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 79
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 79 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 80
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 80 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 80
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 83 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 81
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 84 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 84
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 87 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 85
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 88 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 88
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 89 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 89
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 91 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 90
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 93 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 93
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 94 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 94
18.1. Transport Parameter Definitions . . . . . . . . . . . . 95 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 96
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 98 18.1. Transport Parameter Definitions . . . . . . . . . . . . 97
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 98 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 100
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 99 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 100
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 99 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 100
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 101 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 101
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 102 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 102
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 103 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 104
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 104 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 105
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 104 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 105
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 105 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 106
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 106 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 107
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 107 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 107
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 108 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 109
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 109 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 109
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 110 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 110
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 110 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 111
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 111 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 112
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 111 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 112
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 113 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 113
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 114 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 114
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 114 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 115
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 114 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 116
19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 115 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 116
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 116 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 117
20.1. Application Protocol Error Codes . . . . . . . . . . . . 117 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 117
21. Security Considerations . . . . . . . . . . . . . . . . . . . 117 20.1. Application Protocol Error Codes . . . . . . . . . . . . 119
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 117
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 118 21. Security Considerations . . . . . . . . . . . . . . . . . . . 119
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 119 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 119
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 119 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 120
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 119 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 120
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 120 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 120
21.7. Explicit Congestion Notification Attacks . . . . . . . . 120 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 121
21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 121 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 121
21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 121 21.7. Explicit Congestion Notification Attacks . . . . . . . . 122
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 121 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 122
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 121 21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 123
22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 123 21.10. Targeted Attacks by Routing . . . . . . . . . . . . . . 123
22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 124 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 123
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 126 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 123
23.1. Normative References . . . . . . . . . . . . . . . . . . 126 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 124
23.2. Informative References . . . . . . . . . . . . . . . . . 127 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 125
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 129 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 127
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 129 23.1. Normative References . . . . . . . . . . . . . . . . . . 128
B.1. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 130 23.2. Informative References . . . . . . . . . . . . . . . . . 129
B.2. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 130 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 131
B.3. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 131 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 131
B.4. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 131 B.1. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 132
B.5. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 133 B.2. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 132
B.6. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 133 B.3. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 133
B.7. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 133 B.4. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 133
B.8. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 134 B.5. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 135
B.9. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 135 B.6. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 135
B.10. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 135 B.7. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 135
B.11. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 136 B.8. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 136
B.12. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 136 B.9. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 137
B.13. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 137 B.10. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 137
B.14. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 138 B.11. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 138
B.15. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 138 B.12. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 138
B.16. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 138 B.13. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 139
B.17. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 139 B.14. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 140
B.18. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 139 B.15. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 140
B.19. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 140 B.16. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 140
B.20. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 142 B.17. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 141
B.21. Since draft-hamilton-quic-transport-protocol-01 . . . . . 142 B.18. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 141
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 143 B.19. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 142
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 143 B.20. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 144
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143 B.21. Since draft-hamilton-quic-transport-protocol-01 . . . . . 144
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 145
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 145
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 9, line 23 skipping to change at page 9, line 26
stream limits. stream limits.
2.1. Stream Types and Identifiers 2.1. Stream Types and Identifiers
Streams can be unidirectional or bidirectional. Unidirectional Streams can be unidirectional or bidirectional. Unidirectional
streams carry data in one direction: from the initiator of the stream streams carry data in one direction: from the initiator of the stream
to its peer. Bidirectional streams allow for data to be sent in both to its peer. Bidirectional streams allow for data to be sent in both
directions. directions.
Streams are identified within a connection by a numeric value, Streams are identified within a connection by a numeric value,
referred to as the stream ID. Stream IDs are unique to a stream. A referred to as the stream ID. A stream ID is a 62-bit integer (0 to
QUIC endpoint MUST NOT reuse a stream ID within a connection. Stream 2^62-1) that is unique for all streams on a connection. Stream IDs
IDs are encoded as variable-length integers (see Section 16). are encoded as variable-length integers (see Section 16). A QUIC
endpoint MUST NOT reuse a stream ID within a connection.
The least significant bit (0x1) of the stream ID identifies the The least significant bit (0x1) of the stream ID identifies the
initiator of the stream. Client-initiated streams have even-numbered initiator of the stream. Client-initiated streams have even-numbered
stream IDs (with the bit set to 0), and server-initiated streams have stream IDs (with the bit set to 0), and server-initiated streams have
odd-numbered stream IDs (with the bit set to 1). odd-numbered stream IDs (with the bit set to 1).
The second least significant bit (0x2) of the stream ID distinguishes The second least significant bit (0x2) of the stream ID distinguishes
between bidirectional streams (with the bit set to 0) and between bidirectional streams (with the bit set to 0) and
unidirectional streams (with the bit set to 1). unidirectional streams (with the bit set to 1).
skipping to change at page 19, line 15 skipping to change at page 20, line 4
4. Flow Control 4. Flow Control
It is necessary to limit the amount of data that a receiver could It is necessary to limit the amount of data that a receiver could
buffer, to prevent a fast sender from overwhelming a slow receiver, buffer, to prevent a fast sender from overwhelming a slow receiver,
or to prevent a malicious sender from consuming a large amount of or to prevent a malicious sender from consuming a large amount of
memory at a receiver. To enable a receiver to limit memory memory at a receiver. To enable a receiver to limit memory
commitment to a connection and to apply back pressure on the sender, commitment to a connection and to apply back pressure on the sender,
streams are flow controlled both individually and as an aggregate. A streams are flow controlled both individually and as an aggregate. A
QUIC receiver controls the maximum amount of data the sender can send QUIC receiver controls the maximum amount of data the sender can send
on a stream at any time, as described in Section 4.1 and Section 4.2 on a stream at any time, as described in Section 4.1 and Section 4.2
Similarly, to limit concurrency within a connection, a QUIC endpoint Similarly, to limit concurrency within a connection, a QUIC endpoint
controls the maximum cumulative number of streams that its peer can controls the maximum cumulative number of streams that its peer can
initiate, as described in Section 4.5. initiate, as described in Section 4.5.
Data sent in CRYPTO frames is not flow controlled in the same way as Data sent in CRYPTO frames is not flow controlled in the same way as
stream data. QUIC relies on the cryptographic protocol stream data. QUIC relies on the cryptographic protocol
implementation to avoid excessive buffering of data, see [QUIC-TLS]. implementation to avoid excessive buffering of data; see [QUIC-TLS].
The implementation SHOULD provide an interface to QUIC to tell it The implementation SHOULD provide an interface to QUIC to tell it
about its buffering limits so that there is not excessive buffering about its buffering limits so that there is not excessive buffering
at multiple layers. at multiple layers.
4.1. Data Flow Control 4.1. Data Flow Control
QUIC employs a credit-based flow-control scheme similar to that in QUIC employs a credit-based flow-control scheme similar to that in
HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is HTTP/2 [HTTP2], where a receiver advertises the number of bytes it is
prepared to receive on a given stream and for the entire connection. prepared to receive on a given stream and for the entire connection.
This leads to two levels of data flow control in QUIC: This leads to two levels of data flow control in QUIC:
skipping to change at page 24, line 13 skipping to change at page 25, line 7
by the endpoint upon receipt. by the endpoint upon receipt.
Connection IDs MUST NOT contain any information that can be used by Connection IDs MUST NOT contain any information that can be used by
an external observer to correlate them with other connection IDs for an external observer to correlate them with other connection IDs for
the same connection. As a trivial example, this means the same the same connection. As a trivial example, this means the same
connection ID MUST NOT be issued more than once on the same connection ID MUST NOT be issued more than once on the same
connection. connection.
Packets with long headers include Source Connection ID and Packets with long headers include Source Connection ID and
Destination Connection ID fields. These fields are used to set the Destination Connection ID fields. These fields are used to set the
connection IDs for new connections, see Section 7.2 for details. connection IDs for new connections; see Section 7.2 for details.
Packets with short headers (Section 17.3) only include the Packets with short headers (Section 17.3) only include the
Destination Connection ID and omit the explicit length. The length Destination Connection ID and omit the explicit length. The length
of the Destination Connection ID field is expected to be known to of the Destination Connection ID field is expected to be known to
endpoints. Endpoints using a load balancer that routes based on endpoints. Endpoints using a load balancer that routes based on
connection ID could agree with the load balancer on a fixed length connection ID could agree with the load balancer on a fixed length
for connection IDs, or agree on an encoding scheme. A fixed portion for connection IDs, or agree on an encoding scheme. A fixed portion
could encode an explicit length, which allows the entire connection could encode an explicit length, which allows the entire connection
ID to vary in length and still be used by the load balancer. ID to vary in length and still be used by the load balancer.
skipping to change at page 25, line 18 skipping to change at page 26, line 10
ID randomly selected by the client in the Initial packet and any ID randomly selected by the client in the Initial packet and any
connection ID provided by a Retry packet are not assigned sequence connection ID provided by a Retry packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection numbers unless a server opts to retain them as its initial connection
ID. ID.
When an endpoint issues a connection ID, it MUST accept packets that When an endpoint issues a connection ID, it MUST accept packets that
carry this connection ID for the duration of the connection or until carry this connection ID for the duration of the connection or until
its peer invalidates the connection ID via a RETIRE_CONNECTION_ID its peer invalidates the connection ID via a RETIRE_CONNECTION_ID
frame (Section 19.16). frame (Section 19.16).
Endpoints store received connection IDs for future use. An endpoint
that receives excessive connection IDs MAY discard those it cannot
store without sending a RETIRE_CONNECTION_ID frame. An endpoint that
issues connection IDs cannot expect its peer to store and use all
issued connection IDs.
An endpoint SHOULD ensure that its peer has a sufficient number of An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs. While each endpoint available and unused connection IDs. Endpoints store received
independently chooses how many connection IDs to issue, endpoints connection IDs for future use. An endpoint uses the
SHOULD provide and maintain at least eight connection IDs. The active_connection_id_limit transport parameter to advertise the
endpoint SHOULD do this by supplying a new connection ID when a number of connection IDs it can store for future use. An endpoint
connection ID is retired by its peer or when the endpoint receives a SHOULD NOT provide more connection IDs than the peer's limit. If an
packet with a previously unused connection ID. However, it MAY limit endpoint has provided its peer with the maximum number of connection
the frequency or the total number of connection IDs issued for each IDs, it SHOULD only provide a new connection ID when the peer retires
connection to avoid the risk of running out of connection IDs (see one. An endpoint MAY limit the frequency or the total number of
Section 10.4.2). connection IDs issued for each connection to avoid the risk of
running out of connection IDs (see Section 10.4.2).
An endpoint that initiates migration and requires non-zero-length An endpoint that initiates migration and requires non-zero-length
connection IDs SHOULD ensure that the pool of connection IDs connection IDs SHOULD ensure that the pool of connection IDs
available to its peer allows the peer to use a new connection ID on available to its peer allows the peer to use a new connection ID on
migration, as the peer will close the connection if the pool is migration, as the peer will close the connection if the pool is
exhausted. exhausted.
5.1.2. Consuming and Retiring Connection IDs 5.1.2. Consuming and Retiring Connection IDs
An endpoint can change the connection ID it uses for a peer to An endpoint can change the connection ID it uses for a peer to
another available one at any time during the connection. An endpoint another available one at any time during the connection. An endpoint
consumes connection IDs in response to a migrating peer, see consumes connection IDs in response to a migrating peer; see
Section 9.5 for more. Section 9.5 for more.
An endpoint maintains a set of connection IDs received from its peer, An endpoint maintains a set of connection IDs received from its peer,
any of which it can use when sending packets. When the endpoint any of which it can use when sending packets. When the endpoint
wishes to remove a connection ID from use, it sends a wishes to remove a connection ID from use, it sends a
RETIRE_CONNECTION_ID frame to its peer. Sending a RETIRE_CONNECTION_ID frame to its peer. Sending a
RETIRE_CONNECTION_ID frame indicates that the connection ID won't be RETIRE_CONNECTION_ID frame indicates that the connection ID won't be
used again and requests that the peer replace it with a new used again and requests that the peer replace it with a new
connection ID using a NEW_CONNECTION_ID frame. connection ID using a NEW_CONNECTION_ID frame.
skipping to change at page 28, line 22 skipping to change at page 29, line 10
5.3. Life of a QUIC Connection 5.3. Life of a QUIC Connection
TBD. TBD.
6. Version Negotiation 6. Version Negotiation
Version negotiation ensures that client and server agree to a QUIC Version negotiation ensures that client and server agree to a QUIC
version that is mutually supported. A server sends a Version version that is mutually supported. A server sends a Version
Negotiation packet in response to each packet that might initiate a Negotiation packet in response to each packet that might initiate a
new connection, see Section 5.2 for details. new connection; see Section 5.2 for details.
The size of the first packet sent by a client will determine whether The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet. Clients that support a server sends a Version Negotiation packet. Clients that support
multiple QUIC versions SHOULD pad the first packet they send to the multiple QUIC versions SHOULD pad the first packet they send to the
largest of the minimum packet sizes across all versions they support. largest of the minimum packet sizes across all versions they support.
This ensures that the server responds if there is a mutually This ensures that the server responds if there is a mutually
supported version. supported version.
6.1. Sending Version Negotiation Packets 6.1. Sending Version Negotiation Packets
If the version selected by the client is not acceptable to the If the version selected by the client is not acceptable to the
server, the server responds with a Version Negotiation packet (see server, the server responds with a Version Negotiation packet (see
Section 17.2.1). This includes a list of versions that the server Section 17.2.1). This includes a list of versions that the server
will accept. An endpoint MUST NOT send a Version Negotiation packet will accept. An endpoint MUST NOT send a Version Negotiation packet
in response to receiving a Version Negotiation packet. in response to receiving a Version Negotiation packet.
This system allows a server to process packets with unsupported This system allows a server to process packets with unsupported
versions without retaining state. Though either the Initial packet versions without retaining state. Though either the Initial packet
or the Version Negotiation packet that is sent in response could be or the Version Negotiation packet that is sent in response could be
lost, the client will send new packets until it successfully receives lost, the client will send new packets until it successfully receives
a response or it abandons the connection attempt. a response or it abandons the connection attempt. As a result, the
client discards all state for the connection and does not send any
more packets on the connection.
A server MAY limit the number of Version Negotiation packets it A server MAY limit the number of Version Negotiation packets it
sends. For instance, a server that is able to recognize packets as sends. For instance, a server that is able to recognize packets as
0-RTT might choose not to send Version Negotiation packets in 0-RTT might choose not to send Version Negotiation packets in
response to 0-RTT packets with the expectation that it will response to 0-RTT packets with the expectation that it will
eventually receive an Initial packet. eventually receive an Initial packet.
6.2. Handling Version Negotiation Packets 6.2. Handling Version Negotiation Packets
When a client receives a Version Negotiation packet, it MUST abandon When a client receives a Version Negotiation packet, it MUST abandon
skipping to change at page 34, line 8 skipping to change at page 34, line 35
A client MUST only change the value it sends in the Destination A client MUST only change the value it sends in the Destination
Connection ID in response to the first packet of each type it Connection ID in response to the first packet of each type it
receives from the server (Retry or Initial); a server MUST set its receives from the server (Retry or Initial); a server MUST set its
value based on the Initial packet. Any additional changes are not value based on the Initial packet. Any additional changes are not
permitted; if subsequent packets of those types include a different permitted; if subsequent packets of those types include a different
Source Connection ID, they MUST be discarded. This avoids problems Source Connection ID, they MUST be discarded. This avoids problems
that might arise from stateless processing of multiple Initial that might arise from stateless processing of multiple Initial
packets producing different connection IDs. packets producing different connection IDs.
The connection ID can change over the lifetime of a connection, The connection ID can change over the lifetime of a connection,
especially in response to connection migration (Section 9), see especially in response to connection migration (Section 9); see
Section 5.1.1 for details. Section 5.1.1 for details.
7.3. Transport Parameters 7.3. Transport Parameters
During connection establishment, both endpoints make authenticated During connection establishment, both endpoints make authenticated
declarations of their transport parameters. These declarations are declarations of their transport parameters. These declarations are
made unilaterally by each endpoint. Endpoints are required to comply made unilaterally by each endpoint. Endpoints are required to comply
with the restrictions implied by these parameters; the description of with the restrictions implied by these parameters; the description of
each parameter includes rules for its handling. each parameter includes rules for its handling.
The encoding of the transport parameters is detailed in Section 18. The encoding of the transport parameters is detailed in Section 18.
QUIC includes the encoded transport parameters in the cryptographic QUIC includes the encoded transport parameters in the cryptographic
handshake. Once the handshake completes, the transport parameters handshake. Once the handshake completes, the transport parameters
declared by the peer are available. Each endpoint validates the declared by the peer are available. Each endpoint validates the
value provided by its peer. value provided by its peer.
Definitions for each of the defined transport parameters are included Definitions for each of the defined transport parameters are included
in Section 18.1. An endpoint MUST treat receipt of a transport in Section 18.1.
parameter with an invalid value as a connection error of type
TRANSPORT_PARAMETER_ERROR. Any given parameter MUST appear at most An endpoint MUST treat receipt of a transport parameter with an
once in a given transport parameters extension. An endpoint MUST invalid value as a connection error of type
treat receipt of duplicate transport parameters as a connection error TRANSPORT_PARAMETER_ERROR.
of type TRANSPORT_PARAMETER_ERROR.
An endpoint MUST NOT send a parameter more than once in a given
transport parameters extension. An endpoint SHOULD treat receipt of
duplicate transport parameters as a connection error of type
TRANSPORT_PARAMETER_ERROR.
A server MUST include the original_connection_id transport parameter A server MUST include the original_connection_id transport parameter
(Section 18.1) if it sent a Retry packet to enable validation of the (Section 18.1) if it sent a Retry packet to enable validation of the
Retry, as described in Section 17.2.5. Retry, as described in Section 17.2.5.
7.3.1. Values of Transport Parameters for 0-RTT 7.3.1. Values of Transport Parameters for 0-RTT
Both endpoints store the value of the server transport parameters Both endpoints store the value of the server transport parameters
from a connection and apply them to any 0-RTT packets that are sent from a connection and apply them to any 0-RTT packets that are sent
in subsequent connections to that peer, except for transport in subsequent connections to that peer, except for transport
skipping to change at page 35, line 6 skipping to change at page 35, line 37
parameters apply to the new connection until the handshake completes parameters apply to the new connection until the handshake completes
and the client starts sending 1-RTT packets. Once the handshake and the client starts sending 1-RTT packets. Once the handshake
completes, the client uses the transport parameters established in completes, the client uses the transport parameters established in
the handshake. the handshake.
The definition of new transport parameters (Section 7.3.2) MUST The definition of new transport parameters (Section 7.3.2) MUST
specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A specify whether they MUST, MAY, or MUST NOT be stored for 0-RTT. A
client need not store a transport parameter it cannot process. client need not store a transport parameter it cannot process.
A client MUST NOT use remembered values for the following parameters: A client MUST NOT use remembered values for the following parameters:
original_connection_id, preferred_address, stateless_reset_token, and original_connection_id, preferred_address, stateless_reset_token,
ack_delay_exponent. The client MUST use the server's new values in ack_delay_exponent and active_connection_id_limit. The client MUST
the handshake instead, and absent new values from the server, the use the server's new values in the handshake instead, and absent new
default value. values from the server, the default value.
A client that attempts to send 0-RTT data MUST remember all other A client that attempts to send 0-RTT data MUST remember all other
transport parameters used by the server. The server can remember transport parameters used by the server. The server can remember
these transport parameters, or store an integrity-protected copy of these transport parameters, or store an integrity-protected copy of
the values in the ticket and recover the information when accepting the values in the ticket and recover the information when accepting
0-RTT data. A server uses the transport parameters in determining 0-RTT data. A server uses the transport parameters in determining
whether to accept 0-RTT data. whether to accept 0-RTT data.
If 0-RTT data is accepted by the server, the server MUST NOT reduce If 0-RTT data is accepted by the server, the server MUST NOT reduce
any limits or alter any values that might be violated by the client any limits or alter any values that might be violated by the client
skipping to change at page 35, line 47 skipping to change at page 36, line 30
result in 0-RTT data being enabled, but not usable. The applicable result in 0-RTT data being enabled, but not usable. The applicable
subset of transport parameters that permit sending of application subset of transport parameters that permit sending of application
data SHOULD be set to non-zero values for 0-RTT. This includes data SHOULD be set to non-zero values for 0-RTT. This includes
initial_max_data and either initial_max_streams_bidi and initial_max_data and either initial_max_streams_bidi and
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_bidi_remote, or initial_max_streams_uni and
initial_max_stream_data_uni. initial_max_stream_data_uni.
A server MUST either reject 0-RTT data or abort a handshake if the A server MUST either reject 0-RTT data or abort a handshake if the
implied values for transport parameters cannot be supported. implied values for transport parameters cannot be supported.
When sending frames in 0-RTT packets, a client MUST only use
remembered transport parameters; importantly, it MUST NOT use updated
values that it learns from the server's updated transport parameters
or from frames received in 1-RTT packets. Updated values of
transport parameters from the handshake apply only to 1-RTT packets.
For instance, flow control limits from remembered transport
parameters apply to all 0-RTT packets even if those values are
increased by the handshake or by frames sent in 1-RTT packets. A
server MAY treat use of updated transport parameters in 0-RTT as a
connection error of type PROTOCOL_VIOLATION.
7.3.2. New Transport Parameters 7.3.2. New Transport Parameters
New transport parameters can be used to negotiate new protocol New transport parameters can be used to negotiate new protocol
behavior. An endpoint MUST ignore transport parameters that it does behavior. An endpoint MUST ignore transport parameters that it does
not support. Absence of a transport parameter therefore disables any not support. Absence of a transport parameter therefore disables any
optional protocol feature that is negotiated using the parameter. optional protocol feature that is negotiated using the parameter.
New transport parameters can be registered according to the rules in New transport parameters can be registered according to the rules in
Section 22.1. Section 22.1.
skipping to change at page 39, line 7 skipping to change at page 39, line 50
The server uses the NEW_TOKEN frame Section 19.7 to provide the The server uses the NEW_TOKEN frame Section 19.7 to provide the
client with an address validation token that can be used to validate client with an address validation token that can be used to validate
future connections. The client includes this token in Initial future connections. The client includes this token in Initial
packets to provide address validation in a future connection. The packets to provide address validation in a future connection. The
client MUST include the token in all Initial packets it sends, unless client MUST include the token in all Initial packets it sends, unless
a Retry or NEW_TOKEN frame replaces the token with a newer one. The a Retry or NEW_TOKEN frame replaces the token with a newer one. The
client MUST NOT use the token provided in a Retry for future client MUST NOT use the token provided in a Retry for future
connections. Servers MAY discard any Initial packet that does not connections. Servers MAY discard any Initial packet that does not
carry the expected token. carry the expected token.
A token SHOULD be constructed for the server to easily distinguish it
from tokens that are sent in Retry packets as they are carried in the
same field.
The token MUST NOT include information that would allow it to be
linked by an on-path observer to the connection on which it was
issued. For example, it cannot include the connection ID or
addressing information unless the values are encrypted.
Unlike the token that is created for a Retry packet, there might be Unlike the token that is created for a Retry packet, there might be
some time between when the token is created and when the token is some time between when the token is created and when the token is
subsequently used. Thus, a token SHOULD include an expiration time. subsequently used. Thus, a token SHOULD have an expiration time,
The server MAY include either an explicit expiration time or an which could be either an explicit expiration time or an issued
issued timestamp and dynamically calculate the expiration time. It timestamp that can be used to dynamically calculate the expiration
is also unlikely that the client port number is the same on two time. A server can store the expiration time or include it in an
encrypted form in the token.
It is unlikely that the client port number is the same on two
different connections; validating the port is therefore unlikely to different connections; validating the port is therefore unlikely to
be successful. be successful.
A token SHOULD be constructed for the server to easily distinguish it
from tokens that are sent in Retry packets as they are carried in the
same field.
If the client has a token received in a NEW_TOKEN frame on a previous If the client has a token received in a NEW_TOKEN frame on a previous
connection to what it believes to be the same server, it SHOULD connection to what it believes to be the same server, it SHOULD
include that value in the Token field of its Initial packet. include that value in the Token field of its Initial packet.
Including a token might allow the server to validate the client Including a token might allow the server to validate the client
address without an additional round trip. address without an additional round trip.
A token allows a server to correlate activity between the connection A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used. where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server MAY Clients that want to break continuity of identity with a server MAY
discard tokens provided using the NEW_TOKEN frame. A token obtained discard tokens provided using the NEW_TOKEN frame. A token obtained
skipping to change at page 42, line 11 skipping to change at page 43, line 11
The endpoint MUST use unpredictable data in every PATH_CHALLENGE The endpoint MUST use unpredictable data in every PATH_CHALLENGE
frame so that it can associate the peer's response with the frame so that it can associate the peer's response with the
corresponding PATH_CHALLENGE. corresponding PATH_CHALLENGE.
8.4. Path Validation Responses 8.4. Path Validation Responses
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond On receiving a PATH_CHALLENGE frame, an endpoint MUST respond
immediately by echoing the data contained in the PATH_CHALLENGE frame immediately by echoing the data contained in the PATH_CHALLENGE frame
in a PATH_RESPONSE frame. in a PATH_RESPONSE frame.
To ensure that packets can be both sent to and received from the
peer, the PATH_RESPONSE MUST be sent on the same path as the
triggering PATH_CHALLENGE. That is, from the same local address on
which the PATH_CHALLENGE was received, to the same remote address
from which the PATH_CHALLENGE was received.
8.5. Successful Path Validation 8.5. Successful Path Validation
A new address is considered valid when a PATH_RESPONSE frame is A new address is considered valid when a PATH_RESPONSE frame is
received that meets the following criteria: received that contains the data that was sent in a previous
PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing
o It contains the data that was sent in a previous PATH_CHALLENGE. a PATH_CHALLENGE frame is not adequate validation, since the
Receipt of an acknowledgment for a packet containing a acknowledgment can be spoofed by a malicious peer.
PATH_CHALLENGE frame is not adequate validation, since the
acknowledgment can be spoofed by a malicious peer.
o It was sent from the same remote address to which the
corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame
is received from a different remote address than the one to which
the PATH_CHALLENGE was sent, path validation is considered to have
failed, even if the data matches that sent in the PATH_CHALLENGE.
o It was received on the same local address from which the
corresponding PATH_CHALLENGE was sent.
Note that receipt on a different local address does not result in Note that receipt on a different local address does not result in
path validation failure, as it might be a result of a forwarded path validation failure, as it might be a result of a forwarded
packet (see Section 9.3.3) or misrouting. It is possible that a packet (see Section 9.3.3) or misrouting. It is possible that a
valid PATH_RESPONSE might be received in the future. valid PATH_RESPONSE might be received in the future.
8.6. Failed Path Validation 8.6. Failed Path Validation
Path validation only fails when the endpoint attempting to validate Path validation only fails when the endpoint attempting to validate
the path abandons its attempt to validate the path. the path abandons its attempt to validate the path.
skipping to change at page 43, line 25 skipping to change at page 44, line 8
a new path to become available or close the connection. a new path to become available or close the connection.
A path validation might be abandoned for other reasons besides A path validation might be abandoned for other reasons besides
failure. Primarily, this happens if a connection migration to a new failure. Primarily, this happens if a connection migration to a new
path is initiated while a path validation on the old path is in path is initiated while a path validation on the old path is in
progress. progress.
9. Connection Migration 9. Connection Migration
The use of a connection ID allows connections to survive changes to The use of a connection ID allows connections to survive changes to
endpoint addresses (that is, IP address and/or port), such as those endpoint addresses (IP address and port), such as those caused by an
caused by an endpoint migrating to a new network. This section endpoint migrating to a new network. This section describes the
describes the process by which an endpoint migrates to a new address. process by which an endpoint migrates to a new address.
An endpoint MUST NOT initiate connection migration before the An endpoint MUST NOT initiate connection migration before the
handshake is finished and the endpoint has 1-RTT keys. The design of handshake is finished and the endpoint has 1-RTT keys. The design of
QUIC relies on endpoints retaining a stable address for the duration QUIC relies on endpoints retaining a stable address for the duration
of the handshake. of the handshake.
An endpoint also MUST NOT initiate connection migration if the peer An endpoint also MUST NOT initiate connection migration if the peer
sent the "disable_migration" transport parameter during the sent the "disable_migration" transport parameter during the
handshake. An endpoint which has sent this transport parameter, but handshake. An endpoint which has sent this transport parameter, but
detects that a peer has nonetheless migrated to a different network detects that a peer has nonetheless migrated to a different network
MAY treat this as a connection error of type INVALID_MIGRATION. MAY treat this as a connection error of type INVALID_MIGRATION.
Similarly, an endpoint MUST NOT initiate migration if its peer Similarly, an endpoint MUST NOT initiate migration if its peer
supplies a zero-length connection ID as packets without a Destination supplies a zero-length connection ID as packets without a Destination
Connection ID cannot be attributed to a connection based on address Connection ID cannot be attributed to a connection based on address
tuple. tuple.
Not all changes of peer address are intentional migrations. The peer Not all changes of peer address are intentional migrations. The peer
could experience NAT rebinding: a change of address due to a could experience NAT rebinding: a change of address due to a
middlebox, usually a NAT, allocating a new outgoing port or even a middlebox, usually a NAT, allocating a new outgoing port or even a
new outgoing IP address for a flow. NAT rebinding is not connection new outgoing IP address for a flow. An endpoint MUST perform path
migration as defined in this section, though an endpoint SHOULD validation (Section 8.2) if it detects any change to a peer's
perform path validation (Section 8.2) if it detects a change in the address, unless it has previously validated that address.
IP address of its peer.
When an endpoint has no validated path on which to send packets, it When an endpoint has no validated path on which to send packets, it
MAY discard connection state. An endpoint capable of connection MAY discard connection state. An endpoint capable of connection
migration MAY wait for a new path to become available before migration MAY wait for a new path to become available before
discarding connection state. discarding connection state.
This document limits migration of connections to new client This document limits migration of connections to new client
addresses, except as described in Section 9.6. Clients are addresses, except as described in Section 9.6. Clients are
responsible for initiating all migrations. Servers do not send non- responsible for initiating all migrations. Servers do not send non-
probing packets (see Section 9.1) toward a client address until they probing packets (see Section 9.1) toward a client address until they
skipping to change at page 53, line 46 skipping to change at page 54, line 18
If the idle timeout is enabled, a connection is silently closed and If the idle timeout is enabled, a connection is silently closed and
the state is discarded when it remains idle for longer than both the the state is discarded when it remains idle for longer than both the
advertised idle timeout (see Section 18.1) and three times the advertised idle timeout (see Section 18.1) and three times the
current Probe Timeout (PTO). current Probe Timeout (PTO).
Each endpoint advertises its own idle timeout to its peer. An Each endpoint advertises its own idle timeout to its peer. An
endpoint restarts any timer it maintains when a packet from its peer endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully. The timer is also restarted is received and processed successfully. The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an when sending a packet containing frames other than ACK or PADDING (an
ACK-eliciting packet, see [QUIC-RECOVERY]), but only if no other ACK- ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK-
eliciting packets have been sent since last receiving a packet. eliciting packets have been sent since last receiving a packet.
Restarting when sending packets ensures that connections do not Restarting when sending packets ensures that connections do not
prematurely time out when initiating new activity. prematurely time out when initiating new activity.
The value for an idle timeout can be asymmetric. The value The value for an idle timeout can be asymmetric. The value
advertised by an endpoint is only used to determine whether the advertised by an endpoint is only used to determine whether the
connection is live at that endpoint. An endpoint that sends packets connection is live at that endpoint. An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the packets discarded if its peer enters the draining state before the
packets arrive. If a peer could timeout within an Probe Timeout packets arrive. If a peer could timeout within a Probe Timeout (PTO;
(PTO, see Section 6.2.2 of [QUIC-RECOVERY]), it is advisable to test see Section 6.3 of [QUIC-RECOVERY]), it is advisable to test for
for liveness before sending any data that cannot be retried safely. liveness before sending any data that cannot be retried safely. Note
Note that it is likely that only applications or application that it is likely that only applications or application protocols
protocols will know what information can be retried. will know what information can be retried.
10.3. Immediate Close 10.3. Immediate Close
An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to
terminate the connection immediately. A CONNECTION_CLOSE frame terminate the connection immediately. A CONNECTION_CLOSE frame
causes all streams to immediately become closed; open streams can be causes all streams to immediately become closed; open streams can be
assumed to be implicitly reset. assumed to be implicitly reset.
After sending a CONNECTION_CLOSE frame, endpoints immediately enter After sending a CONNECTION_CLOSE frame, endpoints immediately enter
the closing state. During the closing period, an endpoint that sends the closing state. During the closing period, an endpoint that sends
skipping to change at page 55, line 30 skipping to change at page 55, line 50
If the endpoint does not have Handshake keys, or it is not certain If the endpoint does not have Handshake keys, or it is not certain
that the peer has Handshake keys, it MAY send CONNECTION_CLOSE frames that the peer has Handshake keys, it MAY send CONNECTION_CLOSE frames
in an Initial packet. If multiple packets are sent, they can be in an Initial packet. If multiple packets are sent, they can be
coalesced (see Section 12.2) to facilitate retransmission. coalesced (see Section 12.2) to facilitate retransmission.
10.4. Stateless Reset 10.4. Stateless Reset
A stateless reset is provided as an option of last resort for an A stateless reset is provided as an option of last resort for an
endpoint that does not have access to the state of a connection. A endpoint that does not have access to the state of a connection. A
crash or outage might result in peers continuing to send data to an crash or outage might result in peers continuing to send data to an
endpoint that is unable to properly continue the connection. A endpoint that is unable to properly continue the connection. An
stateless reset is not appropriate for signaling error conditions. endpoint MAY send a stateless reset in response to receiving a packet
that it cannot associate with an active connection.
A stateless reset is not appropriate for signaling error conditions.
An endpoint that wishes to communicate a fatal connection error MUST An endpoint that wishes to communicate a fatal connection error MUST
use a CONNECTION_CLOSE frame if it has sufficient state to do so. use a CONNECTION_CLOSE frame if it has sufficient state to do so.
To support this process, a token is sent by endpoints. The token is To support this process, a token is sent by endpoints. The token is
carried in the NEW_CONNECTION_ID frame sent by either peer, and carried in the NEW_CONNECTION_ID frame sent by either peer, and
servers can specify the stateless_reset_token transport parameter servers can specify the stateless_reset_token transport parameter
during the handshake (clients cannot because their transport during the handshake (clients cannot because their transport
parameters don't have confidentiality protection). This value is parameters don't have confidentiality protection). This value is
protected by encryption, so only client and server know this value. protected by encryption, so only client and server know this value.
Tokens are invalidated when their associated connection ID is retired Tokens are invalidated when their associated connection ID is retired
skipping to change at page 56, line 32 skipping to change at page 56, line 48
possible - indistinguishable from a regular packet with a short possible - indistinguishable from a regular packet with a short
header. header.
A stateless reset uses an entire UDP datagram, starting with the A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header. The remainder of the first byte first two bits of the packet header. The remainder of the first byte
and an arbitrary number of bytes following it that are set to and an arbitrary number of bytes following it that are set to
unpredictable values. The last 16 bytes of the datagram contain a unpredictable values. The last 16 bytes of the datagram contain a
Stateless Reset Token. Stateless Reset Token.
To entities other than its intended recipient, a stateless reset will To entities other than its intended recipient, a stateless reset will
be appear to be a packet with a short header. For the packet to appear to be a packet with a short header. For the packet to appear
appear as valid, the Unpredictable Bits field needs to include at as valid, the Unpredictable Bits field needs to include at least 182
least 182 bits of data (or 23 bytes, less the two fixed bits). This bits of data (or 23 bytes, less the two fixed bits). This is
is intended to allow for a Destination Connection ID of the maximum intended to allow for a Destination Connection ID of the maximum
length permitted, with a minimal packet number, and payload. The length permitted, with a minimal packet number, and payload. The
Stateless Reset Token corresponds to the minimum expansion of the Stateless Reset Token corresponds to the minimum expansion of the
packet protection AEAD. More unpredictable bytes might be necessary packet protection AEAD. More unpredictable bytes might be necessary
if the endpoint could have negotiated a packet protection scheme with if the endpoint could have negotiated a packet protection scheme with
a larger minimum AEAD expansion. a larger minimum AEAD expansion.
An endpoint SHOULD NOT send a stateless reset that is significantly An endpoint SHOULD NOT send a stateless reset that is significantly
larger than the packet it receives. Endpoints MUST discard packets larger than the packet it receives. Endpoints MUST discard packets
that are too small to be valid QUIC packets. With the set of AEAD that are too small to be valid QUIC packets. With the set of AEAD
functions defined in [QUIC-TLS], packets that are smaller than 21 functions defined in [QUIC-TLS], packets that are smaller than 21
skipping to change at page 57, line 27 skipping to change at page 57, line 42
Connection ID will therefore differ from the value used in previous Connection ID will therefore differ from the value used in previous
packets. A random Destination Connection ID makes the connection ID packets. A random Destination Connection ID makes the connection ID
appear to be the result of moving to a new connection ID that was appear to be the result of moving to a new connection ID that was
provided using a NEW_CONNECTION_ID frame (Section 19.15). provided using a NEW_CONNECTION_ID frame (Section 19.15).
Using a randomized connection ID results in two problems: Using a randomized connection ID results in two problems:
o The packet might not reach the peer. If the Destination o The packet might not reach the peer. If the Destination
Connection ID is critical for routing toward the peer, then this Connection ID is critical for routing toward the peer, then this
packet could be incorrectly routed. This might also trigger packet could be incorrectly routed. This might also trigger
another Stateless Reset in response, see Section 10.4.3. A another Stateless Reset in response; see Section 10.4.3. A
Stateless Reset that is not correctly routed is an ineffective Stateless Reset that is not correctly routed is an ineffective
error detection and recovery mechanism. In this case, endpoints error detection and recovery mechanism. In this case, endpoints
will need to rely on other methods - such as timers - to detect will need to rely on other methods - such as timers - to detect
that the connection has failed. that the connection has failed.
o The randomly generated connection ID can be used by entities other o The randomly generated connection ID can be used by entities other
than the peer to identify this as a potential stateless reset. An than the peer to identify this as a potential stateless reset. An
endpoint that occasionally uses different connection IDs might endpoint that occasionally uses different connection IDs might
introduce some uncertainty about this. introduce some uncertainty about this.
skipping to change at page 58, line 11 skipping to change at page 58, line 22
prior to losing state). Designers of new versions of QUIC need to be prior to losing state). Designers of new versions of QUIC need to be
aware of this and either reuse this design, or use a portion of the aware of this and either reuse this design, or use a portion of the
packet other than the last 16 bytes for carrying data. packet other than the last 16 bytes for carrying data.
10.4.1. Detecting a Stateless Reset 10.4.1. Detecting a Stateless Reset
An endpoint detects a potential stateless reset when an incoming An endpoint detects a potential stateless reset when an incoming
packet either cannot be associated with a connection, cannot be packet either cannot be associated with a connection, cannot be
decrypted, or is marked as a duplicate packet. The endpoint MUST decrypted, or is marked as a duplicate packet. The endpoint MUST
then compare the last 16 bytes of the packet with all Stateless Reset then compare the last 16 bytes of the packet with all Stateless Reset
Tokens that are associated with connection IDs that are currently in Tokens that are associated with connection IDs that the endpoint
use. This includes Stateless Reset Tokens from NEW_CONNECTION_ID recently used to send packets from the IP address and port on which
frames and the server's transport parameters. An endpoint MUST NOT the datagram is received. This includes Stateless Reset Tokens from
check for any Stateless Reset Tokens associated with connection IDs NEW_CONNECTION_ID frames and the server's transport parameters. An
it has not used or for connection IDs that have been retired. endpoint MUST NOT check for any Stateless Reset Tokens associated
with connection IDs it has not used or for connection IDs that have
been retired.
If the last 16 bytes of the packet values are identical to a If the last 16 bytes of the packet values are identical to a
Stateless Reset Token, the endpoint MUST enter the draining period Stateless Reset Token, the endpoint MUST enter the draining period
and not send any further packets on this connection. If the and not send any further packets on this connection. If the
comparison fails, the packet can be discarded. comparison fails, the packet can be discarded.
10.4.2. Calculating a Stateless Reset Token 10.4.2. Calculating a Stateless Reset Token
The stateless reset token MUST be difficult to guess. In order to The stateless reset token MUST be difficult to guess. In order to
create a Stateless Reset Token, an endpoint could randomly generate create a Stateless Reset Token, an endpoint could randomly generate
skipping to change at page 59, line 12 skipping to change at page 59, line 26
without state. In addition, it cannot provide a zero-length without state. In addition, it cannot provide a zero-length
connection ID. connection ID.
Revealing the Stateless Reset Token allows any entity to terminate Revealing the Stateless Reset Token allows any entity to terminate
the connection, so a value can only be used once. This method for the connection, so a value can only be used once. This method for
choosing the Stateless Reset Token means that the combination of choosing the Stateless Reset Token means that the combination of
connection ID and static key MUST NOT be used for another connection. connection ID and static key MUST NOT be used for another connection.
A denial of service attack is possible if the same connection ID is A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the cause a packet to be routed to an instance that has no state but the
same static key (see Section 21.8). A connection ID from a same static key; see Section 21.8. A connection ID from a connection
connection that is reset by revealing the Stateless Reset Token MUST that is reset by revealing the Stateless Reset Token MUST NOT be
NOT be reused for new connections at nodes that share a static key. reused for new connections at nodes that share a static key.
The same Stateless Reset Token MAY be used for multiple connection
IDs on the same connection. However, reuse of a Stateless Reset
Token might expose an endpoint to denial of service if associated
connection IDs are forgotten while the associated token is still
active at a peer. An endpoint MUST ensure that packets with
Destination Connection ID field values that correspond to a reused
Stateless Reset Token are attributed to the same connection as long
as the Stateless Reset Token is still usable, even when the
connection ID has been retired. Otherwise, an attacker might be able
to send a packet with a retired connection ID and cause the endpoint
to produce a Stateless Reset that it can use to disrupt the
connection, just as with the attacks in Section 21.8.
Note that Stateless Reset packets do not have any cryptographic Note that Stateless Reset packets do not have any cryptographic
protection. protection.
10.4.3. Looping 10.4.3. Looping
The design of a Stateless Reset is such that without knowing the The design of a Stateless Reset is such that without knowing the
stateless reset token it is indistinguishable from a valid packet. stateless reset token it is indistinguishable from a valid packet.
For instance, if a server sends a Stateless Reset to another server For instance, if a server sends a Stateless Reset to another server
it might receive another Stateless Reset in response, which could it might receive another Stateless Reset in response, which could
skipping to change at page 62, line 18 skipping to change at page 62, line 51
encryption level - and therefore the keys - that are used. Packets encryption level - and therefore the keys - that are used. Packets
protected with 0-RTT and 1-RTT keys are expected to have protected with 0-RTT and 1-RTT keys are expected to have
confidentiality and data origin authentication; the cryptographic confidentiality and data origin authentication; the cryptographic
handshake ensures that only the communicating endpoints receive the handshake ensures that only the communicating endpoints receive the
corresponding keys. corresponding keys.
The packet number field contains a packet number, which has The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet additional confidentiality protection that is applied after packet
protection is applied (see [QUIC-TLS] for details). The underlying protection is applied (see [QUIC-TLS] for details). The underlying
packet number increases with each packet sent in a given packet packet number increases with each packet sent in a given packet
number space, see Section 12.3 for details. number space; see Section 12.3 for details.
12.2. Coalescing Packets 12.2. Coalescing Packets
Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake Initial (Section 17.2.2), 0-RTT (Section 17.2.3), and Handshake
(Section 17.2.4) packets contain a Length field, which determines the (Section 17.2.4) packets contain a Length field, which determines the
end of the packet. The length includes both the Packet Number and end of the packet. The length includes both the Packet Number and
Payload fields, both of which are confidentiality protected and Payload fields, both of which are confidentiality protected and
initially of unknown length. The length of the Payload field is initially of unknown length. The length of the Payload field is
learned once header protection is removed. learned once header protection is removed.
Using the Length field, a sender can coalesce multiple QUIC packets Using the Length field, a sender can coalesce multiple QUIC packets
into one UDP datagram. This can reduce the number of UDP datagrams into one UDP datagram. This can reduce the number of UDP datagrams
needed to complete the cryptographic handshake and starting sending needed to complete the cryptographic handshake and start sending
data. Receivers MUST be able to process coalesced packets. data. This can also be used to construct PMTU probes (see
Section 14.3.1). Receivers MUST be able to process coalesced
packets.
Coalescing packets in order of increasing encryption levels (Initial, Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be 0-RTT, Handshake, 1-RTT) makes it more likely the receiver will be
able to process all the packets in a single pass. A packet with a able to process all the packets in a single pass. A packet with a
short header does not include a length, so it can only be the last short header does not include a length, so it can only be the last
packet included in a UDP datagram. packet included in a UDP datagram. An endpoint SHOULD NOT coalesce
multiple packets at the same encryption level.
Senders MUST NOT coalesce QUIC packets for different connections into Senders MUST NOT coalesce QUIC packets for different connections into
a single UDP datagram. Receivers SHOULD ignore any subsequent a single UDP datagram. Receivers SHOULD ignore any subsequent
packets with a different Destination Connection ID than the first packets with a different Destination Connection ID than the first
packet in the datagram. packet in the datagram.
Every QUIC packet that is coalesced into a single UDP datagram is Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete. Though the values of some fields in the separate and complete. Though the values of some fields in the
packet header might be redundant, no fields are omitted. The packet header might be redundant, no fields are omitted. The
receiver of coalesced QUIC packets MUST individually process each receiver of coalesced QUIC packets MUST individually process each
skipping to change at page 70, line 28 skipping to change at page 71, line 28
o Cancellation of stream transmission, as carried in a RESET_STREAM o Cancellation of stream transmission, as carried in a RESET_STREAM
frame, is sent until acknowledged or until all stream data is frame, is sent until acknowledged or until all stream data is
acknowledged by the peer (that is, either the "Reset Recvd" or acknowledged by the peer (that is, either the "Reset Recvd" or
"Data Recvd" state is reached on the sending part of the stream). "Data Recvd" state is reached on the sending part of the stream).
The content of a RESET_STREAM frame MUST NOT change when it is The content of a RESET_STREAM frame MUST NOT change when it is
sent again. sent again.
o Similarly, a request to cancel stream transmission, as encoded in o Similarly, a request to cancel stream transmission, as encoded in
a STOP_SENDING frame, is sent until the receiving part of the a STOP_SENDING frame, is sent until the receiving part of the
stream enters either a "Data Recvd" or "Reset Recvd" state, see stream enters either a "Data Recvd" or "Reset Recvd" state; see
Section 3.5. Section 3.5.
o Connection close signals, including packets that contain o Connection close signals, including packets that contain
CONNECTION_CLOSE frames, are not sent again when packet loss is CONNECTION_CLOSE frames, are not sent again when packet loss is
detected, but as described in Section 10. detected, but as described in Section 10.
o The current connection maximum data is sent in MAX_DATA frames. o The current connection maximum data is sent in MAX_DATA frames.
An updated value is sent in a MAX_DATA frame if the packet An updated value is sent in a MAX_DATA frame if the packet
containing the most recently sent MAX_DATA frame is declared lost, containing the most recently sent MAX_DATA frame is declared lost,
or when the endpoint decides to update the limit. Care is or when the endpoint decides to update the limit. Care is
skipping to change at page 74, line 42 skipping to change at page 75, line 42
packet. Similarly, the first Initial packet sent after receiving a packet. Similarly, the first Initial packet sent after receiving a
Retry packet MUST be sent in a single IP packet. Retry packet MUST be sent in a single IP packet.
The payload of a UDP datagram carrying the first Initial packet MUST The payload of a UDP datagram carrying the first Initial packet MUST
be expanded to at least 1200 bytes, by adding PADDING frames to the be expanded to at least 1200 bytes, by adding PADDING frames to the
Initial packet and/or by combining the Initial packet with a 0-RTT Initial packet and/or by combining the Initial packet with a 0-RTT
packet (see Section 12.2). Sending a UDP datagram of this size packet (see Section 12.2). Sending a UDP datagram of this size
ensures that the network path supports a reasonable Maximum ensures that the network path supports a reasonable Maximum
Transmission Unit (MTU), and helps reduce the amplitude of Transmission Unit (MTU), and helps reduce the amplitude of
amplification attacks caused by server responses toward an unverified amplification attacks caused by server responses toward an unverified
client address, see Section 8. client address; see Section 8.
The datagram containing the first Initial packet from a client MAY The datagram containing the first Initial packet from a client MAY
exceed 1200 bytes if the client believes that the Path Maximum exceed 1200 bytes if the client believes that the Path Maximum
Transmission Unit (PMTU) supports the size that it chooses. Transmission Unit (PMTU) supports the size that it chooses.
A server MAY send a CONNECTION_CLOSE frame with error code A server MAY send a CONNECTION_CLOSE frame with error code
PROTOCOL_VIOLATION in response to the first Initial packet it PROTOCOL_VIOLATION in response to the first Initial packet it
receives from a client if the UDP datagram is smaller than 1200 receives from a client if the UDP datagram is smaller than 1200
bytes. It MUST NOT send any other frame type in response, or bytes. It MUST NOT send any other frame type in response, or
otherwise behave as if any part of the offending packet was processed otherwise behave as if any part of the offending packet was processed
as valid. as valid.
The server MUST also limit the number of bytes it sends before The server MUST also limit the number of bytes it sends before
validating the address of the client, see Section 8. validating the address of the client; see Section 8.
14.1. Path Maximum Transmission Unit (PMTU) 14.1. Path Maximum Transmission Unit (PMTU)
The PMTU is the maximum size of the entire IP packet including the IP The PMTU is the maximum size of the entire IP packet including the IP
header, UDP header, and UDP payload. The UDP payload includes the header, UDP header, and UDP payload. The UDP payload includes the
QUIC packet header, protected payload, and any authentication fields. QUIC packet header, protected payload, and any authentication fields.
The PMTU can depend upon the current path characteristics. The PMTU can depend upon the current path characteristics.
Therefore, the current largest UDP payload an implementation will Therefore, the current largest UDP payload an implementation will
send is referred to as the QUIC maximum packet size. send is referred to as the QUIC maximum packet size.
skipping to change at page 77, line 25 skipping to change at page 78, line 25
These frames might not be retransmitted if a probe packet containing These frames might not be retransmitted if a probe packet containing
them is lost. However, these frames do consume congestion window, them is lost. However, these frames do consume congestion window,
which could delay the transmission of subsequent application data. which could delay the transmission of subsequent application data.
A PING frame can be included in a PMTU probe to ensure that a valid A PING frame can be included in a PMTU probe to ensure that a valid
probe is acknowledged. probe is acknowledged.
The considerations for processing ICMP messages in the previous The considerations for processing ICMP messages in the previous
section also apply if these messages are used by DPLPMTUD. section also apply if these messages are used by DPLPMTUD.
14.3.1. PMTU Probes Containing Source Connection ID
Endpoints that rely on the destination connection ID for routing QUIC
packets are likely to require that the connection ID be included in
PMTU probe packets to route any resulting ICMP messages
(Section 14.2) back to the correct endpoint. However, only long
header packets (Section 17.2) contain source connection IDs, and long
header packets are not decrypted or acknowledged by the peer once the
handshake is complete. One way to construct a PMTU probe is to
coalesce (see Section 12.2) a Handshake packet (Section 17.2.4) with
a short header packet in a single UDP datagram. If the UDP datagram
reaches the endpoint, the Handshake packet will be ignored, but the
short header packet will be acknowledged. If the UDP datagram
elicits an ICMP message, that message will likely contain the source
connection ID within the quoted portion of the UDP datagram.
15. Versions 15. Versions
QUIC versions are identified using a 32-bit unsigned number. QUIC versions are identified using a 32-bit unsigned number.
The version 0x00000000 is reserved to represent version negotiation. The version 0x00000000 is reserved to represent version negotiation.
This version of the specification is identified by the number This version of the specification is identified by the number
0x00000001. 0x00000001.
Other versions of QUIC might have different properties to this Other versions of QUIC might have different properties to this
version. The properties of QUIC that are guaranteed to be consistent version. The properties of QUIC that are guaranteed to be consistent
skipping to change at page 88, line 22 skipping to change at page 89, line 22
all packets up to the current packet number are in flight, starting all packets up to the current packet number are in flight, starting
from a packet number of 0. Thus, 0-RTT packets could need to use a from a packet number of 0. Thus, 0-RTT packets could need to use a
longer packet number encoding. longer packet number encoding.
A client SHOULD instead generate a fresh cryptographic handshake A client SHOULD instead generate a fresh cryptographic handshake
message and start packet numbers from 0. This ensures that new 0-RTT message and start packet numbers from 0. This ensures that new 0-RTT
packets will not use the same keys, avoiding any risk of key and packets will not use the same keys, avoiding any risk of key and
nonce reuse; this also prevents 0-RTT packets from previous handshake nonce reuse; this also prevents 0-RTT packets from previous handshake
attempts from being accepted as part of the connection. attempts from being accepted as part of the connection.
A client MUST NOT send 0-RTT packets once it starts processing 1-RTT
packets from the server. This means that 0-RTT packets cannot
contain any response to frames from 1-RTT packets. For instance, a
client cannot send an ACK frame in a 0-RTT packet, because that can
only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT
packet MUST be carried in a 1-RTT packet.
A server SHOULD treat a violation of remembered limits as a
connection error of an appropriate type (for instance, a
FLOW_CONTROL_ERROR for exceeding stream data limits).
17.2.4. Handshake Packet 17.2.4. Handshake Packet
A Handshake packet uses long headers with a type value of 0x2, A Handshake packet uses long headers with a type value of 0x2,
followed by the Length and Packet Number fields. The first byte followed by the Length and Packet Number fields. The first byte
contains the Reserved and Packet Number Length bits. It is used to contains the Reserved and Packet Number Length bits. It is used to
carry acknowledgments and cryptographic handshake messages from the carry acknowledgments and cryptographic handshake messages from the
server and client. server and client.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|1| 2 |R R|P P| |1|1| 2 |R R|P P|
skipping to change at page 89, line 27 skipping to change at page 90, line 51
packets with other frames as a connection error. packets with other frames as a connection error.
Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at Like Initial packets (see Section 17.2.2.1), data in CRYPTO frames at
the Handshake encryption level is discarded - and no longer the Handshake encryption level is discarded - and no longer
retransmitted - when Handshake protection keys are discarded. retransmitted - when Handshake protection keys are discarded.
17.2.5. Retry Packet 17.2.5. Retry Packet
A Retry packet uses a long packet header with a type value of 0x3. A Retry packet uses a long packet header with a type value of 0x3.
It carries an address validation token created by the server. It is It carries an address validation token created by the server. It is
used by a server that wishes to perform a stateless retry (see used by a server that wishes to perform a retry (see Section 8.1).
Section 8.1).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|1| 3 | ODCIL | |1|1| 3 | ODCIL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) | | Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)| |DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 91, line 21 skipping to change at page 92, line 45
token values from the Retry packet (see Section 7.2). Aside from token values from the Retry packet (see Section 7.2). Aside from
this, the Initial packet sent by the client is subject to the same this, the Initial packet sent by the client is subject to the same
restrictions as the first Initial packet. A client can either reuse restrictions as the first Initial packet. A client can either reuse
the cryptographic handshake message or construct a new one at its the cryptographic handshake message or construct a new one at its
discretion. discretion.
A client MAY attempt 0-RTT after receiving a Retry packet by sending A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server. A client 0-RTT packets to the connection ID provided by the server. A client
that sends additional 0-RTT packets without constructing a new that sends additional 0-RTT packets without constructing a new
cryptographic handshake message MUST NOT reset the packet number to 0 cryptographic handshake message MUST NOT reset the packet number to 0
after a Retry packet, see Section 17.2.3. after a Retry packet; see Section 17.2.3.
A server acknowledges the use of a Retry packet for a connection A server acknowledges the use of a Retry packet for a connection
using the original_connection_id transport parameter (see using the original_connection_id transport parameter (see
Section 18.1). If the server sends a Retry packet, it MUST include Section 18.1). If the server sends a Retry packet, it MUST include
the value of the Original Destination Connection ID field of the the value of the Original Destination Connection ID field of the
Retry packet (that is, the Destination Connection ID field from the Retry packet (that is, the Destination Connection ID field from the
client's first Initial packet) in the transport parameter. client's first Initial packet) in the transport parameter.
If the client received and processed a Retry packet, it MUST validate If the client received and processed a Retry packet, it MUST validate
that the original_connection_id transport parameter is present and that the original_connection_id transport parameter is present and
skipping to change at page 93, line 48 skipping to change at page 95, line 16
chooses to support the spin bit MUST implement it as specified in chooses to support the spin bit MUST implement it as specified in
this section. this section.
Each endpoint unilaterally decides if the spin bit is enabled or Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection. Implementations MUST allow administrators disabled for a connection. Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on of clients and servers to disable the spin bit either globally or on
a per-connection basis. Even when the spin bit is not disabled by a per-connection basis. Even when the spin bit is not disabled by
the administrator, implementations MUST disable the spin bit for a the administrator, implementations MUST disable the spin bit for a
given connection with a certain likelihood. The random selection given connection with a certain likelihood. The random selection
process SHOULD be designed such that on average the spin bit is process SHOULD be designed such that on average the spin bit is
disabled for at least one eighth of connections. The selection disabled for at least one eighth of network paths. The selection
process performed at the beginning of the connection SHOULD be process performed at the beginning of the connection SHOULD be
applied for all paths used by the connection. applied for all paths used by the connection.
In case multiple connections share the same five-tuple, that is, have In case multiple connections share the same network path, as
the same source and destination IP address and UDP ports, endpoints determined by having the same source and destination IP address and
should try to co-ordinate across all connections to ensure a clear UDP ports, endpoints should try to co-ordinate across all connections
signal to any on-path measurement points. to ensure a clear signal to any on-path measurement points.
When the spin bit is disabled, endpoints MAY set the spin bit to any When the spin bit is disabled, endpoints MAY set the spin bit to any
value, and MUST ignore any incoming value. It is RECOMMENDED that value, and MUST ignore any incoming value. It is RECOMMENDED that
endpoints set the spin bit to a random value either chosen endpoints set the spin bit to a random value either chosen
independently for each packet or chosen independently for each independently for each packet or chosen independently for each
connection ID. connection ID.
If the spin bit is enabled for the connection, the endpoint maintains If the spin bit is enabled for the connection, the endpoint maintains
a spin value and sets the spin bit in the short header to the a spin value and sets the spin bit in the short header to the
currently stored value when a packet with a short header is sent out. currently stored value when a packet with a short header is sent out.
skipping to change at page 95, line 20 skipping to change at page 96, line 28
initial_max_data(4), initial_max_data(4),
initial_max_stream_data_bidi_local(5), initial_max_stream_data_bidi_local(5),
initial_max_stream_data_bidi_remote(6), initial_max_stream_data_bidi_remote(6),
initial_max_stream_data_uni(7), initial_max_stream_data_uni(7),
initial_max_streams_bidi(8), initial_max_streams_bidi(8),
initial_max_streams_uni(9), initial_max_streams_uni(9),
ack_delay_exponent(10), ack_delay_exponent(10),
max_ack_delay(11), max_ack_delay(11),
disable_migration(12), disable_migration(12),
preferred_address(13), preferred_address(13),
active_connection_id_limit(14),
(65535) (65535)
} TransportParameterId; } TransportParameterId;
struct { struct {
TransportParameterId parameter; TransportParameterId parameter;
opaque value<0..2^16-1>; opaque value<0..2^16-1>;
} TransportParameter; } TransportParameter;
TransportParameter TransportParameters<0..2^16-1>; TransportParameter TransportParameters<0..2^16-1>;
skipping to change at page 96, line 12 skipping to change at page 97, line 24
The following transport parameters are defined: The following transport parameters are defined:
original_connection_id (0x0000): The value of the Destination original_connection_id (0x0000): The value of the Destination
Connection ID field from the first Initial packet sent by the Connection ID field from the first Initial packet sent by the
client. This transport parameter is only sent by a server. A client. This transport parameter is only sent by a server. A
server MUST include the original_connection_id transport parameter server MUST include the original_connection_id transport parameter
if it sent a Retry packet. if it sent a Retry packet.
idle_timeout (0x0001): The idle timeout is a value in milliseconds idle_timeout (0x0001): The idle timeout is a value in milliseconds
that is encoded as an integer, see (Section 10.2). If this that is encoded as an integer; see (Section 10.2). If this
parameter is absent or zero then the idle timeout is disabled. parameter is absent or zero then the idle timeout is disabled.
stateless_reset_token (0x0002): A stateless reset token is used in stateless_reset_token (0x0002): A stateless reset token is used in
verifying a stateless reset, see Section 10.4. This parameter is verifying a stateless reset; see Section 10.4. This parameter is
a sequence of 16 bytes. This transport parameter is only sent by a sequence of 16 bytes. This transport parameter MUST NOT be sent
a server. by a client, but MAY be sent by a server. A server that does not
send this transport parameter cannot use stateless reset
(Section 10.4) for the connection ID negotiated during the
handshake.
max_packet_size (0x0003): The maximum packet size parameter is an max_packet_size (0x0003): The maximum packet size parameter is an
integer value that limits the size of packets that the endpoint is integer value that limits the size of packets that the endpoint is
willing to receive. This indicates that packets larger than this willing to receive. This indicates that packets larger than this
limit will be dropped. The default for this parameter is the limit will be dropped. The default for this parameter is the
maximum permitted UDP payload of 65527. Values below 1200 are maximum permitted UDP payload of 65527. Values below 1200 are
invalid. This limit only applies to protected packets invalid. This limit only applies to protected packets
(Section 12.1). (Section 12.1).
initial_max_data (0x0004): The initial maximum data parameter is an initial_max_data (0x0004): The initial maximum data parameter is an
skipping to change at page 97, line 33 skipping to change at page 98, line 47
streams parameter is an integer value that contains the initial streams parameter is an integer value that contains the initial
maximum number of unidirectional streams the peer may initiate. maximum number of unidirectional streams the peer may initiate.
If this parameter is absent or zero, the peer cannot open If this parameter is absent or zero, the peer cannot open
unidirectional streams until a MAX_STREAMS frame is sent. Setting unidirectional streams until a MAX_STREAMS frame is sent. Setting
this parameter is equivalent to sending a MAX_STREAMS this parameter is equivalent to sending a MAX_STREAMS
(Section 19.11) of the corresponding type with the same value. (Section 19.11) of the corresponding type with the same value.
ack_delay_exponent (0x000a): The ACK delay exponent is an integer ack_delay_exponent (0x000a): The ACK delay exponent is an integer
value indicating an exponent used to decode the ACK Delay field in value indicating an exponent used to decode the ACK Delay field in
the ACK frame (Section 19.3). If this value is absent, a default the ACK frame (Section 19.3). If this value is absent, a default
value of 3 is assumed (indicating a multiplier of 8). The default value of 3 is assumed (indicating a multiplier of 8). Values
value is also used for ACK frames that are sent in Initial and above 20 are invalid.
Handshake packets. Values above 20 are invalid.
max_ack_delay (0x000b): The maximum ACK delay is an integer value max_ack_delay (0x000b): The maximum ACK delay is an integer value
indicating the maximum amount of time in milliseconds by which the indicating the maximum amount of time in milliseconds by which the
endpoint will delay sending acknowledgments. This value SHOULD endpoint will delay sending acknowledgments. This value SHOULD
include the receiver's expected delays in alarms firing. For include the receiver's expected delays in alarms firing. For
example, if a receiver sets a timer for 5ms and alarms commonly example, if a receiver sets a timer for 5ms and alarms commonly
fire up to 1ms late, then it should send a max_ack_delay of 6ms. fire up to 1ms late, then it should send a max_ack_delay of 6ms.
If this value is absent, a default of 25 milliseconds is assumed. If this value is absent, a default of 25 milliseconds is assumed.
Values of 2^14 or greater are invalid. Values of 2^14 or greater are invalid.
skipping to change at page 98, line 38 skipping to change at page 100, line 5
are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on
every stream of the corresponding type immediately after opening. If every stream of the corresponding type immediately after opening. If
the transport parameter is absent, streams of that type start with a the transport parameter is absent, streams of that type start with a
flow control limit of 0. flow control limit of 0.
A client MUST NOT include an original connection ID, a stateless A client MUST NOT include an original connection ID, a stateless
reset token, or a preferred address. A server MUST treat receipt of reset token, or a preferred address. A server MUST treat receipt of
any of these transport parameters as a connection error of type any of these transport parameters as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
active_connection_id_limit (0x000e): The maximum number of
connection IDs from the peer that an endpoint is willing to store.
This value includes only connection IDs sent in NEW_CONNECTION_ID
frames. If this parameter is absent, a default of 0 is assumed.
19. Frame Types and Formats 19. Frame Types and Formats
As described in Section 12.4, packets contain one or more frames. As described in Section 12.4, packets contain one or more frames.
This section describes the format and semantics of the core QUIC This section describes the format and semantics of the core QUIC
frame types. frame types.
19.1. PADDING Frame 19.1. PADDING Frame
The PADDING frame (type=0x00) has no semantic value. PADDING frames The PADDING frame (type=0x00) has no semantic value. PADDING frames
can be used to increase the size of a packet. Padding can be used to can be used to increase the size of a packet. Padding can be used to
skipping to change at page 100, line 41 skipping to change at page 102, line 17
the largest packet number that the peer has received prior to the largest packet number that the peer has received prior to
generating the ACK frame. Unlike the packet number in the QUIC generating the ACK frame. Unlike the packet number in the QUIC
long or short header, the value in an ACK frame is not truncated. long or short header, the value in an ACK frame is not truncated.
ACK Delay: A variable-length integer representing the time delta in ACK Delay: A variable-length integer representing the time delta in
microseconds between when this ACK was sent and when the largest microseconds between when this ACK was sent and when the largest
acknowledged packet, as indicated in the Largest Acknowledged acknowledged packet, as indicated in the Largest Acknowledged
field, was received by this peer. The value of the ACK Delay field, was received by this peer. The value of the ACK Delay
field is scaled by multiplying the encoded value by 2 to the power field is scaled by multiplying the encoded value by 2 to the power
of the value of the "ack_delay_exponent" transport parameter set of the value of the "ack_delay_exponent" transport parameter set
by the sender of the ACK frame. The "ack_delay_exponent" defaults by the sender of the ACK frame (see Section 18.1). Scaling in
to 3, or a multiplier of 8 (see Section 18.1). Scaling in this this fashion allows for a larger range of values with a shorter
fashion allows for a larger range of values with a shorter encoding at the cost of lower resolution. Because the receiver
encoding at the cost of lower resolution. doesn't use the ACK Delay for Initial and Handshake packets, a
sender SHOULD send a value of 0.
ACK Range Count: A variable-length integer specifying the number of ACK Range Count: A variable-length integer specifying the number of
Gap and ACK Range fields in the frame. Gap and ACK Range fields in the frame.
First ACK Range: A variable-length integer indicating the number of First ACK Range: A variable-length integer indicating the number of
contiguous packets preceding the Largest Acknowledged that are contiguous packets preceding the Largest Acknowledged that are
being acknowledged. The First ACK Range is encoded as an ACK being acknowledged. The First ACK Range is encoded as an ACK
Range (see Section 19.3.1) starting from the Largest Acknowledged. Range (see Section 19.3.1) starting from the Largest Acknowledged.
That is, the smallest packet acknowledged in the range is That is, the smallest packet acknowledged in the range is
determined by subtracting the First ACK Range value from the determined by subtracting the First ACK Range value from the
Largest Acknowledged. Largest Acknowledged.
ACK Ranges: Contains additional ranges of packets which are ACK Ranges: Contains additional ranges of packets which are
alternately not acknowledged (Gap) and acknowledged (ACK Range), alternately not acknowledged (Gap) and acknowledged (ACK Range);
see Section 19.3.1. see Section 19.3.1.
ECN Counts: The three ECN Counts, see Section 19.3.2. ECN Counts: The three ECN Counts; see Section 19.3.2.
19.3.1. ACK Ranges 19.3.1. ACK Ranges
The ACK Ranges field consists of alternating Gap and ACK Range values The ACK Ranges field consists of alternating Gap and ACK Range values
in descending packet number order. The number of Gap and ACK Range in descending packet number order. The number of Gap and ACK Range
values is determined by the ACK Range Count field; one of each value values is determined by the ACK Range Count field; one of each value
is present for each value in the ACK Range Count field. is present for each value in the ACK Range Count field.
ACK Ranges are structured as follows: ACK Ranges are structured as follows:
skipping to change at page 103, line 48 skipping to change at page 105, line 25
An endpoint that receives a RESET_STREAM frame for a send-only stream An endpoint that receives a RESET_STREAM frame for a send-only stream
MUST terminate the connection with error STREAM_STATE_ERROR. MUST terminate the connection with error STREAM_STATE_ERROR.
The RESET_STREAM frame is as follows: The RESET_STREAM frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Error Code (16) | | Application Error Code (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Final Size (i) ... | Final Size (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RESET_STREAM frames contain the following fields: RESET_STREAM frames contain the following fields:
Stream ID: A variable-length integer encoding of the Stream ID of Stream ID: A variable-length integer encoding of the Stream ID of
the stream being terminated. the stream being terminated.
Application Protocol Error Code: A 16-bit application protocol error Application Protocol Error Code: A variable-length integer
code (see Section 20.1) which indicates why the stream is being containing the application protocol error code (see Section 20.1)
closed. which indicates why the stream is being closed.
Final Size: A variable-length integer indicating the final size of Final Size: A variable-length integer indicating the final size of
the stream by the RESET_STREAM sender, in unit of bytes. the stream by the RESET_STREAM sender, in unit of bytes.
19.5. STOP_SENDING Frame 19.5. STOP_SENDING Frame
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that
incoming data is being discarded on receipt at application request. incoming data is being discarded on receipt at application request.
STOP_SENDING requests that a peer cease transmission on a stream. STOP_SENDING requests that a peer cease transmission on a stream.
skipping to change at page 104, line 36 skipping to change at page 106, line 14
endpoint that receives a STOP_SENDING frame for a receive-only stream endpoint that receives a STOP_SENDING frame for a receive-only stream
MUST terminate the connection with error STREAM_STATE_ERROR. MUST terminate the connection with error STREAM_STATE_ERROR.
The STOP_SENDING frame is as follows: The STOP_SENDING frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Error Code (16) | | Application Error Code (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
STOP_SENDING frames contain the following fields: STOP_SENDING frames contain the following fields:
Stream ID: A variable-length integer carrying the Stream ID of the Stream ID: A variable-length integer carrying the Stream ID of the
stream being ignored. stream being ignored.
Application Error Code: A 16-bit, application-specified reason the Application Error Code: A variable-length integer containing the
sender is ignoring the stream (see Section 20.1). application-specified reason the sender is ignoring the stream
(see Section 20.1).
19.6. CRYPTO Frame 19.6. CRYPTO Frame
The CRYPTO frame (type=0x06) is used to transmit cryptographic The CRYPTO frame (type=0x06) is used to transmit cryptographic
handshake messages. It can be sent in all packet types. The CRYPTO handshake messages. It can be sent in all packet types. The CRYPTO
frame offers the cryptographic protocol an in-order stream of bytes. frame offers the cryptographic protocol an in-order stream of bytes.
CRYPTO frames are functionally identical to STREAM frames, except CRYPTO frames are functionally identical to STREAM frames, except
that they do not bear a stream identifier; they are not flow that they do not bear a stream identifier; they are not flow
controlled; and they do not carry markers for optional offset, controlled; and they do not carry markers for optional offset,
optional length, and the end of the stream. optional length, and the end of the stream.
The CRYPTO frame is as follows: The CRYPTO frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 106, line 8 skipping to change at page 107, line 34
A server sends a NEW_TOKEN frame (type=0x07) to provide the client A server sends a NEW_TOKEN frame (type=0x07) to provide the client
with a token to send in the header of an Initial packet for a future with a token to send in the header of an Initial packet for a future
connection. connection.
The NEW_TOKEN frame is as follows: The NEW_TOKEN frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Length (i) ... | Token Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (*) ... | Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW_TOKEN frames contain the following fields: NEW_TOKEN frames contain the following fields:
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
token in bytes. token in bytes.
Token: An opaque blob that the client may use with a future Initial Token: An opaque blob that the client may use with a future Initial
skipping to change at page 115, line 10 skipping to change at page 116, line 32
signal an error with the application that uses QUIC. signal an error with the application that uses QUIC.
If there are open streams that haven't been explicitly closed, they If there are open streams that haven't been explicitly closed, they
are implicitly closed when the connection is closed. are implicitly closed when the connection is closed.
The CONNECTION_CLOSE frames are as follows: The CONNECTION_CLOSE frames are as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (16) | [ Frame Type (i) ] ... | Error Code (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Frame Type (i) ] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase Length (i) ... | Reason Phrase Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (*) ... | Reason Phrase (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CONNECTION_CLOSE frames contain the following fields: CONNECTION_CLOSE frames contain the following fields:
Error Code: A 16-bit error code which indicates the reason for Error Code: A variable length integer error code which indicates the
closing this connection. A CONNECTION_CLOSE frame of type 0x1c reason for closing this connection. A CONNECTION_CLOSE frame of
uses codes from the space defined in Section 20. A type 0x1c uses codes from the space defined in Section 20. A
CONNECTION_CLOSE frame of type 0x1d uses codes from the CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space, see Section 20.1 application protocol error code space; see Section 20.1
Frame Type: A variable-length integer encoding the type of frame Frame Type: A variable-length integer encoding the type of frame
that triggered the error. A value of 0 (equivalent to the mention that triggered the error. A value of 0 (equivalent to the mention
of the PADDING frame) is used when the frame type is unknown. The of the PADDING frame) is used when the frame type is unknown. The
application-specific variant of CONNECTION_CLOSE (type 0x1d) does application-specific variant of CONNECTION_CLOSE (type 0x1d) does
not include this field. not include this field.
Reason Phrase Length: A variable-length integer specifying the Reason Phrase Length: A variable-length integer specifying the
length of the reason phrase in bytes. Because a CONNECTION_CLOSE length of the reason phrase in bytes. Because a CONNECTION_CLOSE
frame cannot be split between packets, any limits on packet size frame cannot be split between packets, any limits on packet size
skipping to change at page 116, line 12 skipping to change at page 117, line 36
first ensure that a peer is able to understand the frame. An first ensure that a peer is able to understand the frame. An
endpoint can use a transport parameter to signal its willingness to endpoint can use a transport parameter to signal its willingness to
receive one or more extension frame types with the one transport receive one or more extension frame types with the one transport
parameter. parameter.
Extension frames MUST be congestion controlled and MUST cause an ACK Extension frames MUST be congestion controlled and MUST cause an ACK
frame to be sent. The exception is extension frames that replace or frame to be sent. The exception is extension frames that replace or
supplement the ACK frame. Extension frames are not included in flow supplement the ACK frame. Extension frames are not included in flow
control unless specified in the extension. control unless specified in the extension.
An IANA registry is used to manage the assignment of frame types, see An IANA registry is used to manage the assignment of frame types; see
Section 22.2. Section 22.2.
20. Transport Error Codes 20. Transport Error Codes
QUIC error codes are 16-bit unsigned integers. QUIC error codes are 62-bit unsigned integers.
This section lists the defined QUIC transport error codes that may be This section lists the defined QUIC transport error codes that may be
used in a CONNECTION_CLOSE frame. These errors apply to the entire used in a CONNECTION_CLOSE frame. These errors apply to the entire
connection. connection.
NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to NO_ERROR (0x0): An endpoint uses this with CONNECTION_CLOSE to
signal that the connection is being closed abruptly in the absence signal that the connection is being closed abruptly in the absence
of any error. of any error.
INTERNAL_ERROR (0x1): The endpoint encountered an internal error and INTERNAL_ERROR (0x1): The endpoint encountered an internal error and
skipping to change at page 117, line 35 skipping to change at page 119, line 11
CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range
of 256 values is reserved for carrying error codes specific to the of 256 values is reserved for carrying error codes specific to the
cryptographic handshake that is used. Codes for errors occurring cryptographic handshake that is used. Codes for errors occurring
when TLS is used for the crypto handshake are described in when TLS is used for the crypto handshake are described in
Section 4.8 of [QUIC-TLS]. Section 4.8 of [QUIC-TLS].
See Section 22.3 for details of registering new error codes. See Section 22.3 for details of registering new error codes.
20.1. Application Protocol Error Codes 20.1. Application Protocol Error Codes
Application protocol error codes are 16-bit unsigned integers, but Application protocol error codes are 62-bit unsigned integers, but
the management of application error codes are left to application the management of application error codes are left to application
protocols. Application protocol error codes are used for the protocols. Application protocol error codes are used for the
RESET_STREAM frame (Section 19.4), the STOP_SENDING frame RESET_STREAM frame (Section 19.4), the STOP_SENDING frame
(Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d
(Section 19.19). (Section 19.19).
21. Security Considerations 21. Security Considerations
21.1. Handshake Denial of Service 21.1. Handshake Denial of Service
skipping to change at page 120, line 45 skipping to change at page 122, line 22
21.7. Explicit Congestion Notification Attacks 21.7. Explicit Congestion Notification Attacks
An on-path attacker could manipulate the value of ECN codepoints in An on-path attacker could manipulate the value of ECN codepoints in
the IP header to influence the sender's rate. [RFC3168] discusses the IP header to influence the sender's rate. [RFC3168] discusses
manipulations and their effects in more detail. manipulations and their effects in more detail.
An on-the-side attacker can duplicate and send packets with modified An on-the-side attacker can duplicate and send packets with modified
ECN codepoints to affect the sender's rate. If duplicate packets are ECN codepoints to affect the sender's rate. If duplicate packets are
discarded by a receiver, an off-path attacker will need to race the discarded by a receiver, an off-path attacker will need to race the
duplicate packet against the original to be successful in this duplicate packet against the original to be successful in this
attack. Therefore, QUIC receivers ignore ECN codepoints set in attack. Therefore, QUIC endpoints ignore the ECN codepoint field on
duplicate packets (see Section 13.3). an IP packet unless at least one QUIC packet in that IP packet is
successfully processed; see Section 13.3.
21.8. Stateless Reset Oracle 21.8. Stateless Reset Oracle
Stateless resets create a possible denial of service attack analogous Stateless resets create a possible denial of service attack analogous
to a TCP reset injection. This attack is possible if an attacker is to a TCP reset injection. This attack is possible if an attacker is
able to cause a stateless reset token to be generated for a able to cause a stateless reset token to be generated for a
connection with a selected connection ID. An attacker that can cause connection with a selected connection ID. An attacker that can cause
this token to be generated can reset an active connection with the this token to be generated can reset an active connection with the
same connection ID. same connection ID.
skipping to change at page 121, line 43 skipping to change at page 123, line 16
This document defines QUIC Version Negotiation packets Section 6, This document defines QUIC Version Negotiation packets Section 6,
which can be used to negotiate the QUIC version used between two which can be used to negotiate the QUIC version used between two
endpoints. However, this document does not specify how this endpoints. However, this document does not specify how this
negotiation will be performed between this version and subsequent negotiation will be performed between this version and subsequent
future versions. In particular, Version Negotiation packets do not future versions. In particular, Version Negotiation packets do not
contain any mechanism to prevent version downgrade attacks. Future contain any mechanism to prevent version downgrade attacks. Future
versions of QUIC that use Version Negotiation packets MUST define a versions of QUIC that use Version Negotiation packets MUST define a
mechanism that is robust against version downgrade attacks. mechanism that is robust against version downgrade attacks.
21.10. Targeted Attacks by Routing
Deployments should limit the ability of an attacker to target a new
connection to a particular server instance. This means that client-
controlled fields, such as the initial Destination Connection ID used
on Initial and 0-RTT packets SHOULD NOT be used by themselves to make
routing decisions. Ideally, routing decisions are made independently
of client-selected values; a Source Connection ID can be selected to
route later packets to the same server.
22. IANA Considerations 22. IANA Considerations
22.1. QUIC Transport Parameter Registry 22.1. QUIC Transport Parameter Registry
IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" IANA [SHALL add/has added] a registry for "QUIC Transport Parameters"
under a "QUIC Protocol" heading. under a "QUIC Protocol" heading.
The "QUIC Transport Parameters" registry governs a 16-bit space. The "QUIC Transport Parameters" registry governs a 16-bit space.
This space is split into two spaces that are governed by different This space is split into two spaces that are governed by different
policies. Values with the first byte in the range 0x00 to 0xfe (in policies. Values with the first byte in the range 0x00 to 0xfe (in
skipping to change at page 123, line 35 skipping to change at page 124, line 39
| | | | | | | |
| 0x0009 | initial_max_streams_uni | Section 18.1 | | 0x0009 | initial_max_streams_uni | Section 18.1 |
| | | | | | | |
| 0x000a | ack_delay_exponent | Section 18.1 | | 0x000a | ack_delay_exponent | Section 18.1 |
| | | | | | | |
| 0x000b | max_ack_delay | Section 18.1 | | 0x000b | max_ack_delay | Section 18.1 |
| | | | | | | |
| 0x000c | disable_migration | Section 18.1 | | 0x000c | disable_migration | Section 18.1 |
| | | | | | | |
| 0x000d | preferred_address | Section 18.1 | | 0x000d | preferred_address | Section 18.1 |
| | | |
| 0x000e | active_connection_id_limit | Section 18.1 |
+--------+-------------------------------------+---------------+ +--------+-------------------------------------+---------------+
Table 6: Initial QUIC Transport Parameters Entries Table 6: Initial QUIC Transport Parameters Entries
22.2. QUIC Frame Type Registry 22.2. QUIC Frame Type Registry
IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
"QUIC Protocol" heading. "QUIC Protocol" heading.
The "QUIC Frame Types" registry governs a 62-bit space. This space The "QUIC Frame Types" registry governs a 62-bit space. This space
skipping to change at page 124, line 32 skipping to change at page 125, line 39
unless they are abusive, frivolous, or actively harmful (not merely unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious). aesthetically displeasing, or architecturally dubious).
The initial contents of this registry are tabulated in Table 3. The initial contents of this registry are tabulated in Table 3.
22.3. QUIC Transport Error Codes Registry 22.3. QUIC Transport Error Codes Registry
IANA [SHALL add/has added] a registry for "QUIC Transport Error IANA [SHALL add/has added] a registry for "QUIC Transport Error
Codes" under a "QUIC Protocol" heading. Codes" under a "QUIC Protocol" heading.
The "QUIC Transport Error Codes" registry governs a 16-bit space. The "QUIC Transport Error Codes" registry governs a 62-bit space.
This space is split into two spaces that are governed by different This space is split into three spaces that are governed by different
policies. Values with the first byte in the range 0x00 to 0xfe (in policies. Values between 0x00 and 0x3f (in hexadecimal) are assigned
hexadecimal) are assigned via the Specification Required policy via the Standards Action or IESG Review policies [RFC8126]. Values
[RFC8126]. Values with the first byte 0xff are reserved for Private from 0x40 to 0x3fff operate on the Specification Required policy
Use [RFC8126]. [RFC8126]. All other values are assigned to Private Use [RFC8126].
Registrations MUST include the following fields: Registrations MUST include the following fields:
Value: The numeric value of the assignment (registrations will be Value: The numeric value of the assignment (registrations will be
between 0x0000 and 0xfeff). between 0x0000 and 0x3fff).
Code: A short mnemonic for the parameter. Code: A short mnemonic for the parameter.
Description: A brief description of the error code semantics, which Description: A brief description of the error code semantics, which
MAY be a summary if a specification reference is provided. MAY be a summary if a specification reference is provided.
Specification: A reference to a publicly available specification for Specification: A reference to a publicly available specification for
the value. the value.
The initial contents of this registry are shown in Table 7. Values The nominated expert(s) verify that a specification exists and is
from 0xFF00 to 0xFFFF are reserved for Private Use [RFC8126]. readily accessible. Expert(s) are encouraged to be biased towards
approving registrations unless they are abusive, frivolous, or
actively harmful (not merely aesthetically displeasing, or
architecturally dubious).
The initial contents of this registry are shown in Table 7.
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| Valu | Error | Description | Specification | | Valu | Error | Description | Specification |
| e | | | | | e | | | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x0 | NO_ERROR | No error | Section 20 | | 0x0 | NO_ERROR | No error | Section 20 |
| | | | | | | | | |
| 0x1 | INTERNAL_ERROR | Implementation | Section 20 | | 0x1 | INTERNAL_ERROR | Implementation | Section 20 |
| | | error | | | | | error | |
| | | | | | | | | |
skipping to change at page 126, line 6 skipping to change at page 128, line 4
| | | violation | | | | | violation | |
| | | | | | | | | |
| 0xC | INVALID_MIGRATION | Violated | Section 20 | | 0xC | INVALID_MIGRATION | Violated | Section 20 |
| | | disabled | | | | | disabled | |
| | | migration | | | | | migration | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
Table 7: Initial QUIC Transport Error Codes Entries Table 7: Initial QUIC Transport Error Codes Entries
23. References 23. References
23.1. Normative References 23.1. Normative References
[DPLPMTUD] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-07 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-07
(work in progress), February 2019. (work in progress), February 2019.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-20 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[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-
tls-20 (work in progress). latest (work in progress).
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 127, line 50 skipping to change at page 129, line 50
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-04 (work in progress). draft-ietf-quic-invariants-latest (work in progress).
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-03 Transport Protocol", draft-ietf-quic-manageability-04
(work in progress), October 2018. (work in progress), April 2019.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
skipping to change at page 130, line 34 skipping to change at page 132, line 34
o Initial packets from clients need to be padded to 1200 unless a o Initial packets from clients need to be padded to 1200 unless a
Handshake packet is sent as well (#2522, #2523) Handshake packet is sent as well (#2522, #2523)
o CRYPTO frames can be discarded if too much data is buffered o CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524) (#1834, #2524)
o Stateless reset uses a short header packet (#2599, #2600) o Stateless reset uses a short header packet (#2599, #2600)
B.2. Since draft-ietf-quic-transport-18 B.2. Since draft-ietf-quic-transport-18
o Removed version negotation; version negotiation, including o Removed version negotiation; version negotiation, including
authentication of the result, will be addressed in the next authentication of the result, will be addressed in the next
version of QUIC (#1773, #2313) version of QUIC (#1773, #2313)
o Added discussion of the use of IPv6 flow labels (#2348, #2399) o Added discussion of the use of IPv6 flow labels (#2348, #2399)
o A connection ID can't be retired in a packet that uses that o A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420) connection ID (#2101, #2420)
o Idle timeout transport parameter is in milliseconds (from seconds) o Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454) (#2453, #2454)
o Endpoints are required to use new connnection IDs when they use o Endpoints are required to use new connection IDs when they use new
new network paths (#2413, #2414) network paths (#2413, #2414)
o Increased the set of permissible frames in 0-RTT (#2344, #2355) o Increased the set of permissible frames in 0-RTT (#2344, #2355)
B.3. Since draft-ietf-quic-transport-17 B.3. 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)
 End of changes. 98 change blocks. 
303 lines changed or deleted 384 lines changed or added

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