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: November 17, 2019 Mozilla
April 23, 2019 May 16, 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 November 17, 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 . . . . . . . . . . . . . 36
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 . . . . . . . . . . . . . . . . 42
8.5. Successful Path Validation . . . . . . . . . . . . . . . 42 8.5. Successful Path Validation . . . . . . . . . . . . . . . 42
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 42 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 43 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 43
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 . . . . . . . . . . . . . . . . . . . 60
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 61 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 61
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 61 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 61
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 61 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 62
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 62 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 62
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 63 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 63
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 64 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 64
13. Packetization and Reliability . . . . . . . . . . . . . . . . 67 13. Packetization and Reliability . . . . . . . . . . . . . . . . 67
13.1. Packet Processing and Acknowledgment . . . . . . . . . . 68 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 68
13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 68 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 68
13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 69 13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 69
13.2. Retransmission of Information . . . . . . . . . . . . . 69 13.2. Retransmission of Information . . . . . . . . . . . . . 69
13.3. Explicit Congestion Notification . . . . . . . . . . . . 72 13.3. Explicit Congestion Notification . . . . . . . . . . . . 72
13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 72 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 72
13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 73 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 73
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 74 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 74
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 75 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 75
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 76 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 76
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 77 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 77
14.3.1. PMTU Probes Containing Source Connection ID . . . . 77
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 77 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 77
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 78 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 78
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 79 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 79
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 79 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 79
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 80 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 80
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 83 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 83
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 84 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 84
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 87 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 87
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 88 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 88
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 89 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 89
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 91 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 91
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 93 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 93
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 94 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 94
18.1. Transport Parameter Definitions . . . . . . . . . . . . 95 18.1. Transport Parameter Definitions . . . . . . . . . . . . 95
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 98 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 98
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 98 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 99
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 99 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 99
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 99 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 99
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 101 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 101
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 102 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 103
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 103 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 104
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 104 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 104
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 104 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 105
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 105 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 106
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 106 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 106
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 107 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 108
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 108 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 108
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 109 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 109
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 110 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 110
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 110 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 111
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 111 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 111
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 111 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 112
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 113 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 113
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 114 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 114
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 114 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 115
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 114 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 115
19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 115 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 116
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 116 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 116
20.1. Application Protocol Error Codes . . . . . . . . . . . . 117 20.1. Application Protocol Error Codes . . . . . . . . . . . . 118
21. Security Considerations . . . . . . . . . . . . . . . . . . . 117
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 117 21. Security Considerations . . . . . . . . . . . . . . . . . . . 118
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 118 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 118
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 119
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 119 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 119
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 119 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 119
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 119 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 120
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 120 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 120
21.7. Explicit Congestion Notification Attacks . . . . . . . . 120 21.7. Explicit Congestion Notification Attacks . . . . . . . . 121
21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 121 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 121
21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 121 21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 122
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 121 21.10. Targeted Attacks by Routing . . . . . . . . . . . . . . 122
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 121 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 122
22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 123 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 123
22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 124 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 124
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 126 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 126
23.1. Normative References . . . . . . . . . . . . . . . . . . 126 23.1. Normative References . . . . . . . . . . . . . . . . . . 127
23.2. Informative References . . . . . . . . . . . . . . . . . 127 23.2. Informative References . . . . . . . . . . . . . . . . . 128
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 129 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 130
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 129 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 130
B.1. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 130 B.1. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 131
B.2. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 130 B.2. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 131
B.3. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 131 B.3. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 132
B.4. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 131 B.4. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 132
B.5. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 133 B.5. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 134
B.6. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 133 B.6. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 134
B.7. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 133 B.7. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 134
B.8. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 134 B.8. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 135
B.9. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 135 B.9. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 136
B.10. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 135 B.10. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 136
B.11. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 136 B.11. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 137
B.12. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 136 B.12. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 137
B.13. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 137 B.13. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 138
B.14. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 138 B.14. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 139
B.15. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 138 B.15. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 139
B.16. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 138 B.16. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 139
B.17. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 139 B.17. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 140
B.18. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 139 B.18. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 140
B.19. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 140 B.19. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 141
B.20. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 142 B.20. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 143
B.21. Since draft-hamilton-quic-transport-protocol-01 . . . . . 142 B.21. Since draft-hamilton-quic-transport-protocol-01 . . . . . 143
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 143 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 144
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 144
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.
skipping to change at page 35, line 6 skipping to change at page 35, line 33
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 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 an Probe Timeout
(PTO, see Section 6.2.2 of [QUIC-RECOVERY]), it is advisable to test (PTO; see Section 6.2.2 of [QUIC-RECOVERY]), it is advisable to test
for liveness before sending any data that cannot be retried safely. for liveness before sending any data that cannot be retried safely.
Note that it is likely that only applications or application Note that it is likely that only applications or application
protocols will know what information can be retried. protocols 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.
skipping to change at page 56, line 32 skipping to change at page 56, line 47
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 41
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 62, line 18 skipping to change at page 62, line 34
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.
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
skipping to change at page 70, line 28 skipping to change at page 70, 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 74, 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 77, 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 91, line 21 skipping to change at page 91, line 21
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 95, line 20 skipping to change at page 95, line 20
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 96, line 12
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 is only sent by
a server. a server.
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).
skipping to change at page 97, line 33 skipping to change at page 97, line 33
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 98, line 38
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 101, line 4
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 115, line 23 skipping to change at page 115, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 16-bit error code which indicates the reason for
closing this connection. A CONNECTION_CLOSE frame of type 0x1c closing this connection. A CONNECTION_CLOSE frame of type 0x1c
uses codes from the space defined in Section 20. A 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 116, line 34
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 16-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.
skipping to change at page 121, line 43 skipping to change at page 122, 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 123, 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 126, line 6 skipping to change at page 127, 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 128, 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 131, 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. 78 change blocks. 
156 lines changed or deleted 191 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/