draft-ietf-quic-transport-30.txt   draft-ietf-quic-transport-31.txt 
QUIC J. Iyengar, Ed. QUIC J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: March 14, 2021 Mozilla Expires: 29 March 2021 Mozilla
September 10, 2020 25 September 2020
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-30 draft-ietf-quic-transport-31
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 March 14, 2021. This Internet-Draft will expire on 29 March 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 31 skipping to change at page 2, line 31
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 12 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 12
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 13 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 13
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 13
2.4. Operations on Streams . . . . . . . . . . . . . . . . . . 14 2.4. Operations on Streams . . . . . . . . . . . . . . . . . . 14
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 15 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 15
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 18 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 18
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 20 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 20
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 21 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 21
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 22 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 22
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 23 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 24 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 24
4.2. Increasing Flow Control Limits . . . . . . . . . . . . . 25 4.2. Increasing Flow Control Limits . . . . . . . . . . . . . 25
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 26 4.3. Flow Control Performance . . . . . . . . . . . . . . . . 26
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 26 4.4. Handling Stream Cancellation . . . . . . . . . . . . . . 27
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 27 4.5. Stream Final Size . . . . . . . . . . . . . . . . . . . . 27
4.6. Flow Control Performance . . . . . . . . . . . . . . . . 28 4.6. Controlling Concurrency . . . . . . . . . . . . . . . . . 28
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 29 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 29
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 30 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 31
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 31 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 32
5.2. Matching Packets to Connections . . . . . . . . . . . . . 33 5.2. Matching Packets to Connections . . . . . . . . . . . . . 33
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 33 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 34
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 34 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 34
5.2.3. Considerations for Simple Load Balancers . . . . . . 35 5.2.3. Considerations for Simple Load Balancers . . . . . . 35
5.3. Operations on Connections . . . . . . . . . . . . . . . . 35 5.3. Operations on Connections . . . . . . . . . . . . . . . . 36
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 36 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 37
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 37 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 37
6.2. Handling Version Negotiation Packets . . . . . . . . . . 37 6.2. Handling Version Negotiation Packets . . . . . . . . . . 38
6.2.1. Version Negotiation Between Draft Versions . . . . . 37 6.2.1. Version Negotiation Between Draft Versions . . . . . 38
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 38 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 39
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 38 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 39
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 40 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 40
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 41 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 42
7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 42 7.3. Authenticating Connection IDs . . . . . . . . . . . . . . 43
7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 44 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 45
7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 45 7.4.1. Values of Transport Parameters for 0-RTT . . . . . . 46
7.4.2. New Transport Parameters . . . . . . . . . . . . . . 47 7.4.2. New Transport Parameters . . . . . . . . . . . . . . 48
7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 47 7.5. Cryptographic Message Buffering . . . . . . . . . . . . . 48
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 48 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 49
8.1. Address Validation During Connection Establishment . . . 48 8.1. Address Validation During Connection Establishment . . . 49
8.1.1. Token Construction . . . . . . . . . . . . . . . . . 49 8.1.1. Token Construction . . . . . . . . . . . . . . . . . 50
8.1.2. Address Validation using Retry Packets . . . . . . . 50 8.1.2. Address Validation using Retry Packets . . . . . . . 51
8.1.3. Address Validation for Future Connections . . . . . . 51 8.1.3. Address Validation for Future Connections . . . . . . 52
8.1.4. Address Validation Token Integrity . . . . . . . . . 53 8.1.4. Address Validation Token Integrity . . . . . . . . . 54
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 54 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 55
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 55 8.2.1. Initiating Path Validation . . . . . . . . . . . . . 56
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 55 8.2.2. Path Validation Responses . . . . . . . . . . . . . . 57
8.5. Successful Path Validation . . . . . . . . . . . . . . . 55 8.2.3. Successful Path Validation . . . . . . . . . . . . . 57
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 56 8.2.4. Failed Path Validation . . . . . . . . . . . . . . . 57
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 56 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 58
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 57 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 59
9.2. Initiating Connection Migration . . . . . . . . . . . . . 58 9.2. Initiating Connection Migration . . . . . . . . . . . . . 59
9.3. Responding to Connection Migration . . . . . . . . . . . 58 9.3. Responding to Connection Migration . . . . . . . . . . . 60
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 59 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 60
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 60 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 61
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 60 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 61
9.4. Loss Detection and Congestion Control . . . . . . . . . . 61 9.4. Loss Detection and Congestion Control . . . . . . . . . . 62
9.5. Privacy Implications of Connection Migration . . . . . . 62 9.5. Privacy Implications of Connection Migration . . . . . . 63
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 64 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 65
9.6.1. Communicating a Preferred Address . . . . . . . . . . 64 9.6.1. Communicating a Preferred Address . . . . . . . . . . 65
9.6.2. Migration to a Preferred Address . . . . . . . . . . 64 9.6.2. Migration to a Preferred Address . . . . . . . . . . 66
9.6.3. Interaction of Client Migration and Preferred 9.6.3. Interaction of Client Migration and Preferred
Address . . . . . . . . . . . . . . . . . . . . . . . 65 Address . . . . . . . . . . . . . . . . . . . . . . . 66
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 66 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 67
10. Connection Termination . . . . . . . . . . . . . . . . . . . 66 10. Connection Termination . . . . . . . . . . . . . . . . . . . 67
10.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 67 10.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 68
10.1.1. Liveness Testing . . . . . . . . . . . . . . . . . . 67 10.1.1. Liveness Testing . . . . . . . . . . . . . . . . . . 68
10.1.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 67 10.1.2. Deferring Idle Timeout . . . . . . . . . . . . . . . 68
10.2. Immediate Close . . . . . . . . . . . . . . . . . . . . 68 10.2. Immediate Close . . . . . . . . . . . . . . . . . . . . 69
10.2.1. Closing Connection State . . . . . . . . . . . . . . 69 10.2.1. Closing Connection State . . . . . . . . . . . . . . 70
10.2.2. Draining Connection State . . . . . . . . . . . . . 70 10.2.2. Draining Connection State . . . . . . . . . . . . . 71
10.2.3. Immediate Close During the Handshake . . . . . . . . 71 10.2.3. Immediate Close During the Handshake . . . . . . . . 72
10.3. Stateless Reset . . . . . . . . . . . . . . . . . . . . 72 10.3. Stateless Reset . . . . . . . . . . . . . . . . . . . . 73
10.3.1. Detecting a Stateless Reset . . . . . . . . . . . . 75 10.3.1. Detecting a Stateless Reset . . . . . . . . . . . . 76
10.3.2. Calculating a Stateless Reset Token . . . . . . . . 76 10.3.2. Calculating a Stateless Reset Token . . . . . . . . 77
10.3.3. Looping . . . . . . . . . . . . . . . . . . . . . . 77 10.3.3. Looping . . . . . . . . . . . . . . . . . . . . . . 78
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 77 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 78
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 78 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 79
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 78 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 79
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 79 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 80
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 79 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 80
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 80 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 81
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 81 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 82
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 82 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 83
13. Packetization and Reliability . . . . . . . . . . . . . . . . 86 12.5. Frames and Number Spaces . . . . . . . . . . . . . . . . 87
13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 86 13. Packetization and Reliability . . . . . . . . . . . . . . . . 87
13.2. Generating Acknowledgements . . . . . . . . . . . . . . 87 13.1. Packet Processing . . . . . . . . . . . . . . . . . . . 88
13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 87 13.2. Generating Acknowledgements . . . . . . . . . . . . . . 88
13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 89 13.2.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 89
13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 89 13.2.2. Acknowledgement Frequency . . . . . . . . . . . . . 90
13.2.4. Limiting Ranges by Tracking ACK Frames . . . . . . . 90 13.2.3. Managing ACK Ranges . . . . . . . . . . . . . . . . 91
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 91 13.2.4. Limiting Ranges by Tracking ACK Frames . . . . . . . 92
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 91 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 92
13.2.7. PADDING Frames Consume Congestion Window . . . . . . 92 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 93
13.3. Retransmission of Information . . . . . . . . . . . . . 92 13.2.7. PADDING Frames Consume Congestion Window . . . . . . 93
13.4. Explicit Congestion Notification . . . . . . . . . . . . 95 13.3. Retransmission of Information . . . . . . . . . . . . . 93
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 95 13.4. Explicit Congestion Notification . . . . . . . . . . . . 96
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 96 13.4.1. Reporting ECN Counts . . . . . . . . . . . . . . . . 96
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 98 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 97
14.1. Initial Packet Size . . . . . . . . . . . . . . . . . . 99 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 99
14.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 99 14.1. Initial Packet Size . . . . . . . . . . . . . . . . . . 100
14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 100 14.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 100
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 101 14.2.1. Handling of ICMP Messages by PMTUD . . . . . . . . . 101
14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 101 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 102
14.3.2. Validating the QUIC Path with DPLPMTUD . . . . . . . 101 14.3.1. DPLPMTUD and Initial Connectivity . . . . . . . . . 102
14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 101 14.3.2. Validating the QUIC Path with DPLPMTUD . . . . . . . 102
14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 102 14.3.3. Handling of ICMP Messages by DPLPMTUD . . . . . . . 102
14.4.1. PMTU Probes Containing Source Connection ID . . . . 102 14.4. Sending QUIC PMTU Probes . . . . . . . . . . . . . . . . 103
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 102 14.4.1. PMTU Probes Containing Source Connection ID . . . . 103
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 103 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 103
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 104 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 104
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 104 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 105
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 105 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 105
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 108 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 106
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 109 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 109
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 112 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 110
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 113 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 113
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 114 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 114
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 115
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 117 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 117
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 118 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 119
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 119 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 120
18.1. Reserved Transport Parameters . . . . . . . . . . . . . 120 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 121
18.2. Transport Parameter Definitions . . . . . . . . . . . . 120 18.2. Transport Parameter Definitions . . . . . . . . . . . . 121
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 125 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 125
19.1. PADDING Frames . . . . . . . . . . . . . . . . . . . . . 125 19.1. PADDING Frames . . . . . . . . . . . . . . . . . . . . . 125
19.2. PING Frames . . . . . . . . . . . . . . . . . . . . . . 125 19.2. PING Frames . . . . . . . . . . . . . . . . . . . . . . 126
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 126 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 126
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 127 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 128
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 128 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 129
19.4. RESET_STREAM Frames . . . . . . . . . . . . . . . . . . 129 19.4. RESET_STREAM Frames . . . . . . . . . . . . . . . . . . 130
19.5. STOP_SENDING Frames . . . . . . . . . . . . . . . . . . 130 19.5. STOP_SENDING Frames . . . . . . . . . . . . . . . . . . 131
19.6. CRYPTO Frames . . . . . . . . . . . . . . . . . . . . . 131 19.6. CRYPTO Frames . . . . . . . . . . . . . . . . . . . . . 131
19.7. NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 132 19.7. NEW_TOKEN Frames . . . . . . . . . . . . . . . . . . . . 132
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 132 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 133
19.9. MAX_DATA Frames . . . . . . . . . . . . . . . . . . . . 134 19.9. MAX_DATA Frames . . . . . . . . . . . . . . . . . . . . 135
19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 134 19.10. MAX_STREAM_DATA Frames . . . . . . . . . . . . . . . . . 135
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 135 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 136
19.12. DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . . 136 19.12. DATA_BLOCKED Frames . . . . . . . . . . . . . . . . . . 137
19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 137 19.13. STREAM_DATA_BLOCKED Frames . . . . . . . . . . . . . . . 138
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 137 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 138
19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 138 19.15. NEW_CONNECTION_ID Frames . . . . . . . . . . . . . . . . 139
19.16. RETIRE_CONNECTION_ID Frames . . . . . . . . . . . . . . 140 19.16. RETIRE_CONNECTION_ID Frames . . . . . . . . . . . . . . 140
19.17. PATH_CHALLENGE Frames . . . . . . . . . . . . . . . . . 141 19.17. PATH_CHALLENGE Frames . . . . . . . . . . . . . . . . . 141
19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 141 19.18. PATH_RESPONSE Frames . . . . . . . . . . . . . . . . . . 142
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 142 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 142
19.20. HANDSHAKE_DONE Frames . . . . . . . . . . . . . . . . . 143 19.20. HANDSHAKE_DONE Frames . . . . . . . . . . . . . . . . . 143
19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 143 19.21. Extension Frames . . . . . . . . . . . . . . . . . . . . 144
20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 144 20. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 144
20.1. Transport Error Codes . . . . . . . . . . . . . . . . . 144 20.1. Transport Error Codes . . . . . . . . . . . . . . . . . 145
20.2. Application Protocol Error Codes . . . . . . . . . . . . 146 20.2. Application Protocol Error Codes . . . . . . . . . . . . 146
21. Security Considerations . . . . . . . . . . . . . . . . . . . 146 21. Security Considerations . . . . . . . . . . . . . . . . . . . 147
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 146 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 147
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 147 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 148
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 147 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 148
21.4. Request Forgery Attacks . . . . . . . . . . . . . . . . 148 21.4. Request Forgery Attacks . . . . . . . . . . . . . . . . 148
21.4.1. Control Options for Endpoints . . . . . . . . . . . 148 21.4.1. Control Options for Endpoints . . . . . . . . . . . 149
21.4.2. Request Forgery with Client Initial Packets . . . . 149 21.4.2. Request Forgery with Client Initial Packets . . . . 151
21.4.3. Request Forgery with Preferred Addresses . . . . . . 150 21.4.3. Request Forgery with Preferred Addresses . . . . . . 151
21.4.4. Request Forgery with Spoofed Migration . . . . . . . 151 21.4.4. Request Forgery with Spoofed Migration . . . . . . . 152
21.4.5. Generic Request Forgery Countermeasures . . . . . . 151 21.4.5. Generic Request Forgery Countermeasures . . . . . . 152
21.5. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 152 21.5. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 153
21.6. Stream Fragmentation and Reassembly Attacks . . . . . . 153 21.6. Stream Fragmentation and Reassembly Attacks . . . . . . 154
21.7. Stream Commitment Attack . . . . . . . . . . . . . . . . 153 21.7. Stream Commitment Attack . . . . . . . . . . . . . . . . 154
21.8. Peer Denial of Service . . . . . . . . . . . . . . . . . 154 21.8. Peer Denial of Service . . . . . . . . . . . . . . . . . 155
21.9. Explicit Congestion Notification Attacks . . . . . . . . 154 21.9. Explicit Congestion Notification Attacks . . . . . . . . 155
21.10. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 154 21.10. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 156
21.11. Version Downgrade . . . . . . . . . . . . . . . . . . . 155 21.11. Version Downgrade . . . . . . . . . . . . . . . . . . . 156
21.12. Targeted Attacks by Routing . . . . . . . . . . . . . . 155 21.12. Targeted Attacks by Routing . . . . . . . . . . . . . . 157
21.13. Overview of Security Properties . . . . . . . . . . . . 155 21.13. Overview of Security Properties . . . . . . . . . . . . 157
21.13.1. Handshake . . . . . . . . . . . . . . . . . . . . . 156 21.13.1. Handshake . . . . . . . . . . . . . . . . . . . . . 157
21.13.2. Protected Packets . . . . . . . . . . . . . . . . . 158 21.13.2. Protected Packets . . . . . . . . . . . . . . . . . 159
21.13.3. Connection Migration . . . . . . . . . . . . . . . 158 21.13.3. Connection Migration . . . . . . . . . . . . . . . 160
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 163 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164
22.1. Registration Policies for QUIC Registries . . . . . . . 163 22.1. Registration Policies for QUIC Registries . . . . . . . 164
22.1.1. Provisional Registrations . . . . . . . . . . . . . 163 22.1.1. Provisional Registrations . . . . . . . . . . . . . 164
22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 164 22.1.2. Selecting Codepoints . . . . . . . . . . . . . . . . 165
22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 164 22.1.3. Reclaiming Provisional Codepoints . . . . . . . . . 166
22.1.4. Permanent Registrations . . . . . . . . . . . . . . 165 22.1.4. Permanent Registrations . . . . . . . . . . . . . . 166
22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 165 22.2. QUIC Transport Parameter Registry . . . . . . . . . . . 167
22.3. QUIC Frame Types Registry . . . . . . . . . . . . . . . 167 22.3. QUIC Frame Types Registry . . . . . . . . . . . . . . . 168
22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 168 22.4. QUIC Transport Error Codes Registry . . . . . . . . . . 169
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 170 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 171
23.1. Normative References . . . . . . . . . . . . . . . . . . 170 23.1. Normative References . . . . . . . . . . . . . . . . . . 171
23.2. Informative References . . . . . . . . . . . . . . . . . 171 23.2. Informative References . . . . . . . . . . . . . . . . . 172
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 174 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 175
Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 175 Appendix B. Sample ECN Validation Algorithm . . . . . . . . . . 176
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 176 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 177
C.1. Since draft-ietf-quic-transport-29 . . . . . . . . . . . 176 C.1. Since draft-ietf-quic-transport-30 . . . . . . . . . . . 177
C.2. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 177 C.2. Since draft-ietf-quic-transport-29 . . . . . . . . . . . 177
C.3. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 177 C.3. Since draft-ietf-quic-transport-28 . . . . . . . . . . . 178
C.4. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 178 C.4. Since draft-ietf-quic-transport-27 . . . . . . . . . . . 178
C.5. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 178 C.5. Since draft-ietf-quic-transport-26 . . . . . . . . . . . 180
C.6. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 178 C.6. Since draft-ietf-quic-transport-25 . . . . . . . . . . . 180
C.7. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 180 C.7. Since draft-ietf-quic-transport-24 . . . . . . . . . . . 180
C.8. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 180 C.8. Since draft-ietf-quic-transport-23 . . . . . . . . . . . 181
C.9. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 181 C.9. Since draft-ietf-quic-transport-22 . . . . . . . . . . . 182
C.10. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 182 C.10. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 183
C.11. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 182 C.11. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 183
C.12. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 183 C.12. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 184
C.13. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 183 C.13. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 184
C.14. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 184 C.14. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 185
C.15. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 185 C.15. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 186
C.16. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 185 C.16. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 187
C.17. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 186 C.17. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 187
C.18. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 187 C.18. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 187
C.19. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 187 C.19. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 188
C.20. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 188 C.20. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 189
C.21. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 188 C.21. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 189
C.22. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 189 C.22. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 190
C.23. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 190 C.23. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 191
C.24. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 191 C.24. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 191
C.25. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 191 C.25. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 192
C.26. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 191 C.26. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 192
C.27. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 192 C.27. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 193
C.28. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 192 C.28. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 193
C.29. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 193 C.29. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 194
C.30. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 195 C.30. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 194
C.31. Since draft-hamilton-quic-transport-protocol-01 . . . . . 195 C.31. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 196
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 195 C.32. Since draft-hamilton-quic-transport-protocol-01 . . . . . 197
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 197 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 198
1. Overview 1. Overview
QUIC is a multiplexed and secure general-purpose transport protocol QUIC is a multiplexed and secure general-purpose transport protocol
that provides: that provides:
* Stream multiplexing * Stream multiplexing
* Stream- and connection-level flow control * Stream- and connection-level flow control
skipping to change at page 7, line 25 skipping to change at page 7, line 25
* Connection migration and resilience to NAT rebinding * Connection migration and resilience to NAT rebinding
* Authenticated and encrypted header and payload * Authenticated and encrypted header and payload
QUIC establishes a connection, which is a stateful interaction QUIC establishes a connection, which is a stateful interaction
between a client and server. The primary purpose of a connection is between a client and server. The primary purpose of a connection is
to support the structured exchange of data by an application to support the structured exchange of data by an application
protocol. protocol.
Streams are means by which an application protocol exchanges Application protocols exchange information over a QUIC connection via
information. Streams are ordered sequences of bytes. Two types of streams, which are ordered sequences of bytes. Two types of stream
stream can be created: bidirectional streams, which allow both can be created: bidirectional streams, which allow both endpoints to
endpoints to send data; and unidirectional streams, which allow a send data; and unidirectional streams, which allow a single endpoint
single endpoint to send. A credit-based scheme is used to limit to send data. A credit-based scheme is used to limit stream creation
stream creation and to bound the amount of data that can be sent. and to bound the amount of data that can be sent.
The QUIC handshake combines negotiation of cryptographic and The QUIC handshake combines negotiation of cryptographic and
transport parameters. The handshake is structured to permit the transport parameters. The handshake is structured to permit the
exchange of application data as soon as possible. This includes an exchange of application data as soon as possible. This includes an
option for clients to send data immediately (0-RTT), which might option for clients to send data immediately (0-RTT), which might
require prior communication to enable. require prior communication to enable.
QUIC connections are not strictly bound to a single network path. QUIC connections are not strictly bound to a single network path.
Connection migration uses connection identifiers to allow connections Connection migration uses connection identifiers to allow connections
to transfer to a new network path. to transfer to a new network path.
Frames are used in QUIC to communicate between endpoints. One or Frames are used in QUIC to communicate between endpoints. One or
more frames are assembled into packets. QUIC authenticates all more frames are assembled into a QUIC packet. QUIC authenticates all
packets and encrypts as much as is practical. QUIC packets are packets and encrypts as much as is practical. QUIC packets are
carried in UDP datagrams ([UDP]) to better facilitate deployment in carried in UDP datagrams ([UDP]) to better facilitate deployment in
existing systems and networks. existing systems and networks.
Once established, multiple options are provided for connection Once established, multiple options are provided for connection
termination. Applications can manage a graceful shutdown, endpoints termination. Applications can manage a graceful shutdown, endpoints
can negotiate a timeout period, errors can cause immediate connection can negotiate a timeout period, errors can cause immediate connection
teardown, and a stateless mechanism provides for termination of teardown, and a stateless mechanism provides for termination of
connections after one endpoint has lost state. connections after one endpoint has lost state.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
- Section 4 outlines the operation of flow control. - Section 4 outlines the operation of flow control.
* Connections are the context in which QUIC endpoints communicate. * Connections are the context in which QUIC endpoints communicate.
- Section 5 describes core concepts related to connections, - Section 5 describes core concepts related to connections,
- Section 6 describes version negotiation, - Section 6 describes version negotiation,
- Section 7 details the process for establishing connections, - Section 7 details the process for establishing connections,
- Section 8 specifies critical denial of service mitigation - Section 8 describes address validation and critical denial of
mechanisms, service mitigations,
- Section 9 describes how endpoints migrate a connection to a new - Section 9 describes how endpoints migrate a connection to a new
network path, network path,
- Section 10 lists the options for terminating an open - Section 10 lists the options for terminating an open
connection, and connection, and
- Section 11 provides general guidance for error handling. - Section 11 provides guidance for stream and connection error
handling.
* Packets and frames are the basic unit used by QUIC to communicate. * Packets and frames are the basic unit used by QUIC to communicate.
- Section 12 describes concepts related to packets and frames, - Section 12 describes concepts related to packets and frames,
- Section 13 defines models for the transmission, retransmission, - Section 13 defines models for the transmission, retransmission,
and acknowledgement of data, and and acknowledgement of data, and
- Section 14 specifies rules for managing the size of packets. - Section 14 specifies rules for managing the size of packets.
skipping to change at page 13, line 44 skipping to change at page 13, line 44
described in detail in Section 4. described in detail in Section 4.
2.3. Stream Prioritization 2.3. Stream Prioritization
Stream multiplexing can have a significant effect on application Stream multiplexing can have a significant effect on application
performance if resources allocated to streams are correctly performance if resources allocated to streams are correctly
prioritized. prioritized.
QUIC does not provide a mechanism for exchanging prioritization QUIC does not provide a mechanism for exchanging prioritization
information. Instead, it relies on receiving priority information information. Instead, it relies on receiving priority information
from the application that uses QUIC. from the application.
A QUIC implementation SHOULD provide ways in which an application can A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams. An implementation uses indicate the relative priority of streams. An implementation uses
information provided by the application to determine how to allocate information provided by the application to determine how to allocate
resources to active streams. resources to active streams.
2.4. Operations on Streams 2.4. Operations on Streams
This document does not define an API for QUIC, but instead defines a This document does not define an API for QUIC, but instead defines a
set of functions on streams that application protocols can rely upon. set of functions on streams that application protocols can rely upon.
An application protocol can assume that an implementation of QUIC An application protocol can assume that a QUIC implementation
provides an interface that includes the operations described in this provides an interface that includes the operations described in this
section. An implementation designed for use with a specific section. An implementation designed for use with a specific
application protocol might provide only those operations that are application protocol might provide only those operations that are
used by that protocol. used by that protocol.
On the sending part of a stream, an application protocol can: On the sending part of a stream, an application protocol can:
* write data, understanding when stream flow control credit * write data, understanding when stream flow control credit
(Section 4.1) has successfully been reserved to send the written (Section 4.1) has successfully been reserved to send the written
data; data;
skipping to change at page 15, line 13 skipping to change at page 15, line 13
streams on which an endpoint receives data (Section 3.2). streams on which an endpoint receives data (Section 3.2).
Unidirectional streams use the applicable state machine directly. Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines. For the most part, Bidirectional streams use both state machines. For the most part,
the use of these state machines is the same whether the stream is the use of these state machines is the same whether the stream is
unidirectional or bidirectional. The conditions for opening a stream unidirectional or bidirectional. The conditions for opening a stream
are slightly more complex for a bidirectional stream because the are slightly more complex for a bidirectional stream because the
opening of either the send or receive side causes the stream to open opening of either the send or receive side causes the stream to open
in both directions. in both directions.
These state machines shown in this section are largely informative. The state machines shown in this section are largely informative.
This document uses stream states to describe rules for when and how This document uses stream states to describe rules for when and how
different types of frames can be sent and the reactions that are different types of frames can be sent and the reactions that are
expected when different types of frames are received. Though these expected when different types of frames are received. Though these
state machines are intended to be useful in implementing QUIC, these state machines are intended to be useful in implementing QUIC, these
states are not intended to constrain implementations. An states are not intended to constrain implementations. An
implementation can define a different state machine as long as its implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements these behavior is consistent with an implementation that implements these
states. states.
Note: In some cases, a single event or action can cause a transition Note: In some cases, a single event or action can cause a transition
skipping to change at page 19, line 33 skipping to change at page 19, line 33
order for streams is consistent on both endpoints. order for streams is consistent on both endpoints.
In the "Recv" state, the endpoint receives STREAM and In the "Recv" state, the endpoint receives STREAM and
STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be
reassembled into the correct order for delivery to the application. reassembled into the correct order for delivery to the application.
As data is consumed by the application and buffer space becomes As data is consumed by the application and buffer space becomes
available, the endpoint sends MAX_STREAM_DATA frames to allow the available, the endpoint sends MAX_STREAM_DATA frames to allow the
peer to send more data. peer to send more data.
When a STREAM frame with a FIN bit is received, the final size of the When a STREAM frame with a FIN bit is received, the final size of the
stream is known; see Section 4.4. The receiving part of the stream stream is known; see Section 4.5. The receiving part of the stream
then enters the "Size Known" state. In this state, the endpoint no then enters the "Size Known" state. In this state, the endpoint no
longer needs to send MAX_STREAM_DATA frames, it only receives any longer needs to send MAX_STREAM_DATA frames, it only receives any
retransmissions of stream data. retransmissions of stream data.
Once all data for the stream has been received, the receiving part Once all data for the stream has been received, the receiving part
enters the "Data Recvd" state. This might happen as a result of enters the "Data Recvd" state. This might happen as a result of
receiving the same STREAM frame that causes the transition to "Size receiving the same STREAM frame that causes the transition to "Size
Known". After all data has been received, any STREAM or Known". After all data has been received, any STREAM or
STREAM_DATA_BLOCKED frames for the stream can be discarded. STREAM_DATA_BLOCKED frames for the stream can be discarded.
skipping to change at page 23, line 19 skipping to change at page 23, line 19
from the stream, but it is not a guarantee that incoming data will be from the stream, but it is not a guarantee that incoming data will be
ignored. ignored.
STREAM frames received after sending a STOP_SENDING frame are still STREAM frames received after sending a STOP_SENDING frame are still
counted toward connection and stream flow control, even though these counted toward connection and stream flow control, even though these
frames can be discarded upon receipt. frames can be discarded upon receipt.
A STOP_SENDING frame requests that the receiving endpoint send a A STOP_SENDING frame requests that the receiving endpoint send a
RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame
MUST send a RESET_STREAM frame if the stream is in the Ready or Send MUST send a RESET_STREAM frame if the stream is in the Ready or Send
state. If the stream is in the "Data Sent" state, an endpoint MAY state. If the stream is in the "Data Sent" state, the endpoint MAY
defer sending the RESET_STREAM frame until the packets containing defer sending the RESET_STREAM frame until the packets containing
outstanding data are acknowledged or declared lost. If any outstanding data are acknowledged or declared lost. If any
outstanding data is declared lost, the endpoint SHOULD send a outstanding data is declared lost, the endpoint SHOULD send a
RESET_STREAM frame instead of retransmitting the data. RESET_STREAM frame instead of retransmitting the data.
An endpoint SHOULD copy the error code from the STOP_SENDING frame to An endpoint SHOULD copy the error code from the STOP_SENDING frame to
the RESET_STREAM frame it sends, but MAY use any application error the RESET_STREAM frame it sends, but MAY use any application error
code. The endpoint that sends a STOP_SENDING frame MAY ignore the code. An endpoint that sends a STOP_SENDING frame MAY ignore the
error code carried in any RESET_STREAM frame it receives. error code in any RESET_STREAM frames subsequently received for that
stream.
STOP_SENDING SHOULD only be sent for a stream that has not been reset STOP_SENDING SHOULD only be sent for a stream that has not been reset
by the peer. STOP_SENDING is most useful for streams in the "Recv" by the peer. STOP_SENDING is most useful for streams in the "Recv"
or "Size Known" states. or "Size Known" states.
An endpoint is expected to send another STOP_SENDING frame if a An endpoint is expected to send another STOP_SENDING frame if a
packet containing a previous STOP_SENDING is lost. However, once packet containing a previous STOP_SENDING is lost. However, once
either all stream data or a RESET_STREAM frame has been received for either all stream data or a RESET_STREAM frame has been received for
the stream - that is, the stream is in any state other than "Recv" or the stream - that is, the stream is in any state other than "Recv" or
"Size Known" - sending a STOP_SENDING frame is unnecessary. "Size Known" - sending a STOP_SENDING frame is unnecessary.
skipping to change at page 24, line 5 skipping to change at page 24, line 14
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.6.
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 To avoid excessive buffering at multiple layers, QUIC implementations
about its buffering limits so that there is not excessive buffering SHOULD provide an interface for the cryptographic protocol
at multiple layers. implementation to communicate its buffering limits.
4.1. Data Flow Control 4.1. Data Flow Control
QUIC employs a limit-based flow-control scheme where a receiver QUIC employs a limit-based flow-control scheme where a receiver
advertises the limit of total bytes it is prepared to receive on a advertises the limit of total bytes it is prepared to receive on a
given stream or for the entire connection. This leads to two levels given stream or for the entire connection. This leads to two levels
of data flow control in QUIC: of data flow control in QUIC:
* Stream flow control, which prevents a single stream from consuming * Stream flow control, which prevents a single stream from consuming
the entire receive buffer for a connection by limiting the amount the entire receive buffer for a connection by limiting the amount
of data that can be sent on any stream. of data that can be sent on any stream.
* Connection flow control, which prevents senders from exceeding a * Connection flow control, which prevents senders from exceeding a
receiver's buffer capacity for the connection, by limiting the receiver's buffer capacity for the connection, by limiting the
total bytes of stream data sent in STREAM frames on all streams. total bytes of stream data sent in STREAM frames on all streams.
Senders MUST NOT send data in excess of either limit. Senders MUST NOT send data in excess of either limit.
A receiver sets initial limits for all streams by sending transport A receiver sets initial limits for all streams through transport
parameters during the handshake (Section 7.4). A receiver sends parameters during the handshake (Section 7.4). Subsequently, a
MAX_STREAM_DATA (Section 19.10) or MAX_DATA (Section 19.9) frames to receiver sends MAX_STREAM_DATA (Section 19.10) or MAX_DATA
the sender to advertise larger limits. (Section 19.9) frames to the sender to advertise larger limits.
A receiver can advertise a larger limit for a stream by sending a A receiver can advertise a larger limit for a stream by sending a
MAX_STREAM_DATA frame with the corresponding stream ID. A MAX_STREAM_DATA frame with the corresponding stream ID. A
MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a
stream. A receiver could use the current offset of data consumed to stream. A receiver could determine the flow control offset to be
determine the flow control offset to be advertised. advertised based on the current offset of data consumed on that
stream.
A receiver can advertise a larger limit for a connection by sending a A receiver can advertise a larger limit for a connection by sending a
MAX_DATA frame, which indicates the maximum of the sum of the MAX_DATA frame, which indicates the maximum of the sum of the
absolute byte offsets of all streams. A receiver maintains a absolute byte offsets of all streams. A receiver maintains a
cumulative sum of bytes received on all streams, which is used to cumulative sum of bytes received on all streams, which is used to
check for violations of the advertised connection or stream data check for violations of the advertised connection or stream data
limits. A receiver might use a sum of bytes consumed on all streams limits. A receiver could determine the maximum data limit to be
to determine the maximum data limit to be advertised. advertised based on the sum of bytes consumed on all streams.
Once a receiver advertises a limit for the connection or a stream, it Once a receiver advertises a limit for the connection or a stream, it
MAY advertise a smaller limit, but this has no effect. MAY advertise a smaller limit, but this has no effect.
A receiver MUST close the connection with a FLOW_CONTROL_ERROR error A receiver MUST close the connection with a FLOW_CONTROL_ERROR error
(Section 11) if the sender violates the advertised connection or (Section 11) if the sender violates the advertised connection or
stream data limits. stream data limits.
A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do
not increase flow control limits. not increase flow control limits.
If a sender has sent data up to the limit, it will be unable to send If a sender has sent data up to the limit, it will be unable to send
new data and is considered blocked. A sender SHOULD send a new data and is considered blocked. A sender SHOULD send a
STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate to the receiver
write but is blocked by flow control limits. If a sender is blocked that it has data to write but is blocked by flow control limits. If
for a period longer than the idle timeout (Section 10.1), the a sender is blocked for a period longer than the idle timeout
receiver might close the connection even when the sender has data (Section 10.1), the receiver might close the connection even when the
that is available for transmission. To keep the connection from sender has data that is available for transmission. To keep the
closing, a sender that is flow control limited SHOULD periodically connection from closing, a sender that is flow control limited SHOULD
send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it has no ack- periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it
eliciting packets in flight. has no ack-eliciting packets in flight.
4.2. Increasing Flow Control Limits 4.2. Increasing Flow Control Limits
Implementations decide when and how much credit to advertise in Implementations decide when and how much credit to advertise in
MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few
considerations. considerations.
To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or
MAX_DATA frame multiple times within a round trip or send it early MAX_DATA frame multiple times within a round trip or send it early
enough to allow for recovery from loss of the frame. enough to allow time for loss of the frame and subsequent recovery.
Control frames contribute to connection overhead. Therefore, Control frames contribute to connection overhead. Therefore,
frequently sending MAX_STREAM_DATA and MAX_DATA frames with small frequently sending MAX_STREAM_DATA and MAX_DATA frames with small
changes is undesirable. On the other hand, if updates are less changes is undesirable. On the other hand, if updates are less
frequent, larger increments to limits are necessary to avoid blocking frequent, larger increments to limits are necessary to avoid blocking
a sender, requiring larger resource commitments at the receiver. a sender, requiring larger resource commitments at the receiver.
There is a trade-off between resource commitment and overhead when There is a trade-off between resource commitment and overhead when
determining how large a limit is advertised. determining how large a limit is advertised.
A receiver can use an autotuning mechanism to tune the frequency and A receiver can use an autotuning mechanism to tune the frequency and
amount of advertised additional credit based on a round-trip time amount of advertised additional credit based on a round-trip time
estimate and the rate at which the receiving application consumes estimate and the rate at which the receiving application consumes
data, similar to common TCP implementations. As an optimization, an data, similar to common TCP implementations. As an optimization, an
endpoint could send frames related to flow control only when there endpoint could send frames related to flow control only when there
are other frames to send or when a peer is blocked, ensuring that are other frames to send, ensuring that flow control does not cause
flow control does not cause extra packets to be sent. extra packets to be sent.
A blocked sender is not required to send STREAM_DATA_BLOCKED or A blocked sender is not required to send STREAM_DATA_BLOCKED or
DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a DATA_BLOCKED frames. Therefore, a receiver MUST NOT wait for a
STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a
MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the
sender being blocked for the rest of the connection. Even if the sender being blocked for the rest of the connection. Even if the
sender sends these frames, waiting for them will result in the sender sender sends these frames, waiting for them will result in the sender
being blocked for at least an entire round trip. being blocked for at least an entire round trip.
When a sender receives credit after being blocked, it might be able When a sender receives credit after being blocked, it might be able
to send a large amount of data in response, resulting in short-term to send a large amount of data in response, resulting in short-term
congestion; see Section 6.9 in [QUIC-RECOVERY] for a discussion of congestion; see Section 6.9 in [QUIC-RECOVERY] for a discussion of
how a sender can avoid this congestion. how a sender can avoid this congestion.
4.3. Handling Stream Cancellation 4.3. Flow Control Performance
If an endpoint cannot ensure that its peer always has available flow
control credit that is greater than the peer's bandwidth-delay
product on this connection, its receive throughput will be limited by
flow control.
Packet loss can cause gaps in the receive buffer, preventing the
application from consuming data and freeing up receive buffer space.
Sending timely updates of flow control limits can improve
performance. Sending packets only to provide flow control updates
can increase network load and adversely affect performance. Sending
flow control updates along with other frames, such as ACK frames,
reduces the cost of those updates.
4.4. Handling Stream Cancellation
Endpoints need to eventually agree on the amount of flow control Endpoints need to eventually agree on the amount of flow control
credit that has been consumed, to avoid either exceeding flow control credit that has been consumed on every stream, to be able to account
limits or deadlocking. for all bytes for connection-level flow control.
On receipt of a RESET_STREAM frame, an endpoint will tear down state On receipt of a RESET_STREAM frame, an endpoint will tear down state
for the matching stream and ignore further data arriving on that for the matching stream and ignore further data arriving on that
stream. stream.
RESET_STREAM terminates one direction of a stream abruptly. For a RESET_STREAM terminates one direction of a stream abruptly. For a
bidirectional stream, RESET_STREAM has no effect on data flow in the bidirectional stream, RESET_STREAM has no effect on data flow in the
opposite direction. Both endpoints MUST maintain flow control state opposite direction. Both endpoints MUST maintain flow control state
for the stream in the unterminated direction until that direction for the stream in the unterminated direction until that direction
enters a terminal state, or until one of the endpoints sends enters a terminal state.
CONNECTION_CLOSE.
4.4. Stream Final Size 4.5. Stream Final Size
The final size is the amount of flow control credit that is consumed The final size is the amount of flow control credit that is consumed
by a stream. Assuming that every contiguous byte on the stream was by a stream. Assuming that every contiguous byte on the stream was
sent once, the final size is the number of bytes sent. More sent once, the final size is the number of bytes sent. More
generally, this is one higher than the offset of the byte with the generally, this is one higher than the offset of the byte with the
largest offset sent on the stream, or zero if no bytes were sent. largest offset sent on the stream, or zero if no bytes were sent.
The final size of a stream is always signaled to the recipient. The A sender always communicates the final size of a stream to the
final size is the sum of the Offset and Length fields of a STREAM receiver reliably, no matter how the stream is terminated. The final
frame with a FIN flag, noting that these fields might be implicit. size is the sum of the Offset and Length fields of a STREAM frame
with a FIN flag, noting that these fields might be implicit.
Alternatively, the Final Size field of a RESET_STREAM frame carries Alternatively, the Final Size field of a RESET_STREAM frame carries
this value. This ensures that all ways that a stream can be closed this value. This guarantees that both endpoints agree on how much
result in the number of bytes on the stream being reliably flow control credit was consumed by the sender on that stream.
transmitted. This guarantees that both endpoints agree on how much
flow control credit was consumed by the stream.
An endpoint will know the final size for a stream when the receiving An endpoint will know the final size for a stream when the receiving
part of the stream enters the "Size Known" or "Reset Recvd" state part of the stream enters the "Size Known" or "Reset Recvd" state
(Section 3). The receiver MUST use the final size of the stream to (Section 3). The receiver MUST use the final size of the stream to
account for all bytes sent on the stream in its connection level flow account for all bytes sent on the stream in its connection level flow
controller. controller.
An endpoint MUST NOT send data on a stream at or beyond the final An endpoint MUST NOT send data on a stream at or beyond the final
size. size.
Once a final size for a stream is known, it cannot change. If a Once a final size for a stream is known, it cannot change. If a
RESET_STREAM or STREAM frame is received indicating a change in the RESET_STREAM or STREAM frame is received indicating a change in the
final size for the stream, an endpoint SHOULD respond with a final size for the stream, an endpoint SHOULD respond with a
FINAL_SIZE_ERROR error; see Section 11. A receiver SHOULD treat FINAL_SIZE_ERROR error; see Section 11. A receiver SHOULD treat
receipt of data at or beyond the final size as a FINAL_SIZE_ERROR receipt of data at or beyond the final size as a FINAL_SIZE_ERROR
error, even after a stream is closed. Generating these errors is not error, even after a stream is closed. Generating these errors is not
mandatory, but only because requiring that an endpoint generate these mandatory, because requiring that an endpoint generate these errors
errors also means that the endpoint needs to maintain the final size also means that the endpoint needs to maintain the final size state
state for closed streams, which could mean a significant state for closed streams, which could mean a significant state commitment.
commitment.
4.5. Controlling Concurrency 4.6. Controlling Concurrency
An endpoint limits the cumulative number of incoming streams a peer An endpoint limits the cumulative number of incoming streams a peer
can open. Only streams with a stream ID less than (max_stream * 4 + can open. Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened; see Table 1. Initial initial_stream_id_for_type) can be opened; see Table 1. Initial
limits are set in the transport parameters; see Section 18.2. limits are set in the transport parameters; see Section 18.2.
Subsequent limits are advertised using MAX_STREAMS frames; see Subsequent limits are advertised using MAX_STREAMS frames; see
Section 19.11. Separate limits apply to unidirectional and Section 19.11. Separate limits apply to unidirectional and
bidirectional streams. bidirectional streams.
If a max_streams transport parameter or MAX_STREAMS frame is received If a max_streams transport parameter or a MAX_STREAMS frame is
with a value greater than 2^60, this would allow a maximum stream ID received with a value greater than 2^60, this would allow a maximum
that cannot be expressed as a variable-length integer; see stream ID that cannot be expressed as a variable-length integer; see
Section 16. If either is received, the connection MUST be closed Section 16. If either is received, the connection MUST be closed
immediately with a connection error of type FRAME_ENCODING_ERROR; see immediately with a connection error of type TRANSPORT_PARAMETER_ERROR
if the offending value was received in a transport parameter or of
type FRAME_ENCODING_ERROR if it was received in a frame; see
Section 10.2. Section 10.2.
Endpoints MUST NOT exceed the limit set by their peer. An endpoint Endpoints MUST NOT exceed the limit set by their peer. An endpoint
that receives a frame with a stream ID exceeding the limit it has that receives a frame with a stream ID exceeding the limit it has
sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR
(Section 11). (Section 11).
Once a receiver advertises a stream limit using the MAX_STREAMS Once a receiver advertises a stream limit using the MAX_STREAMS
frame, advertising a smaller limit has no effect. A receiver MUST frame, advertising a smaller limit has no effect. A receiver MUST
ignore any MAX_STREAMS frame that does not increase the stream limit. ignore any MAX_STREAMS frame that does not increase the stream limit.
As with stream and connection flow control, this document leaves when As with stream and connection flow control, this document leaves
and how many streams to advertise to a peer via MAX_STREAMS to implementations to decide when and how many streams should be
implementations. Implementations might choose to increase limits as advertised to a peer via MAX_STREAMS. Implementations might choose
streams close to keep the number of streams available to peers to increase limits as streams are closed, to keep the number of
roughly consistent. streams available to peers roughly consistent.
An endpoint that is unable to open a new stream due to the peer's An endpoint that is unable to open a new stream due to the peer's
limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This
signal is considered useful for debugging. An endpoint MUST NOT wait signal is considered useful for debugging. An endpoint MUST NOT wait
to receive this signal before advertising additional credit, since to receive this signal before advertising additional credit, since
doing so will mean that the peer will be blocked for at least an doing so will mean that the peer will be blocked for at least an
entire round trip, and potentially for longer if the peer chooses not entire round trip, and potentially indefinitely if the peer chooses
to send STREAMS_BLOCKED frames. not to send STREAMS_BLOCKED frames.
4.6. Flow Control Performance
An endpoint that is unable to ensure that a peer has flow control
credit on the order of the current BDP will have receive throughput
limited by flow control. Lost packets can cause gaps in the receive
buffer, delaying the application from consuming data and freeing up
flow control window.
Sending timely updates of flow control limits can improve
performance. Sending packets only to provide flow control updates
can increase network load and adversely affect performance. Sending
flow control updates along with other frames, such as ACK frames,
reduces the cost of those updates.
5. Connections 5. Connections
A QUIC connection is shared state between a client and a server. A QUIC connection is shared state between a client and a server.
Each connection starts with a handshake phase, during which the two Each connection starts with a handshake phase, during which the two
endpoints establish a shared secret using the cryptographic handshake endpoints establish a shared secret using the cryptographic handshake
protocol [QUIC-TLS] and negotiate the application protocol. The protocol [QUIC-TLS] and negotiate the application protocol. The
handshake (Section 7) confirms that both endpoints are willing to handshake (Section 7) confirms that both endpoints are willing to
communicate (Section 8.1) and establishes parameters for the communicate (Section 8.1) and establishes parameters for the
skipping to change at page 29, line 22 skipping to change at page 29, line 36
client. These capabilities allow an application protocol to offer client. These capabilities allow an application protocol to offer
the option of trading some security guarantees for reduced latency. the option of trading some security guarantees for reduced latency.
The use of connection IDs (Section 5.1) allows connections to migrate The use of connection IDs (Section 5.1) allows connections to migrate
to a new network path, both as a direct choice of an endpoint and to a new network path, both as a direct choice of an endpoint and
when forced by a change in a middlebox. Section 9 describes when forced by a change in a middlebox. Section 9 describes
mitigations for the security and privacy issues associated with mitigations for the security and privacy issues associated with
migration. migration.
For connections that are no longer needed or desired, there are For connections that are no longer needed or desired, there are
several ways for a client and server to terminate a connection several ways for a client and server to terminate a connection, as
(Section 10). described in Section 10.
5.1. Connection ID 5.1. Connection ID
Each connection possesses a set of connection identifiers, or Each connection possesses a set of connection identifiers, or
connection IDs, each of which can identify the connection. connection IDs, each of which can identify the connection.
Connection IDs are independently selected by endpoints; each endpoint Connection IDs are independently selected by endpoints; each endpoint
selects the connection IDs that its peer uses. selects the connection IDs that its peer uses.
The primary function of a connection ID is to ensure that changes in The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP) do not cause packets addressing at lower protocol layers (UDP, IP) do not cause packets
skipping to change at page 33, line 39 skipping to change at page 34, line 14
Packets that are matched to an existing connection are discarded if Packets that are matched to an existing connection are discarded if
the packets are inconsistent with the state of that connection. For the packets are inconsistent with the state of that connection. For
example, packets are discarded if they indicate a different protocol example, packets are discarded if they indicate a different protocol
version than that of the connection, or if the removal of packet version than that of the connection, or if the removal of packet
protection is unsuccessful once the expected keys are available. protection is unsuccessful once the expected keys are available.
Invalid packets that lack strong integrity protection, such as Invalid packets that lack strong integrity protection, such as
Initial, Retry, or Version Negotiation, MAY be discarded. An Initial, Retry, or Version Negotiation, MAY be discarded. An
endpoint MUST generate a connection error if processing the contents endpoint MUST generate a connection error if processing the contents
of these packets prior to discovering an error resulted in changes to of these packets prior to discovering an error, unless it fully
connection state that cannot be reverted. reverts these changes.
5.2.1. Client Packet Handling 5.2.1. Client Packet Handling
Valid packets sent to clients always include a Destination Connection Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects. Clients that choose to ID that matches a value the client selects. Clients that choose to
receive zero-length connection IDs can use the local address and port receive zero-length connection IDs can use the local address and port
to identify a connection. Packets that do not match an existing to identify a connection. Packets that do not match an existing
connection, based on Destination Connection ID or, if this value is connection, based on Destination Connection ID or, if this value is
zero-length, local IP address and port, are discarded. zero-length, local IP address and port, are discarded.
Due to packet reordering or loss, a client might receive packets for Due to packet reordering or loss, a client might receive packets for
a connection that are encrypted with a key it has not yet computed. a connection that are encrypted with a key it has not yet computed.
The client MAY drop these packets, or MAY buffer them in anticipation The client MAY drop these packets, or MAY buffer them in anticipation
of later packets that allow it to compute the key. of later packets that allow it to compute the key.
If a client receives a packet that has an unsupported version, it If a client receives a packet that uses a different version than it
MUST discard that packet. initially selected, it MUST discard that packet.
5.2.2. Server Packet Handling 5.2.2. Server Packet Handling
If a server receives a packet that indicates an unsupported version If a server receives a packet that indicates an unsupported version
but is large enough to initiate a new connection for any supported but is large enough to initiate a new connection for any supported
version, the server SHOULD send a Version Negotiation packet as version, the server SHOULD send a Version Negotiation packet as
described in Section 6.1. A server MAY limit the number of packets described in Section 6.1. A server MAY limit the number of packets
to which it responds with a Version Negotiation packet. Servers MUST to which it responds with a Version Negotiation packet. Servers MUST
drop smaller packets that specify unsupported versions. drop smaller packets that specify unsupported versions.
skipping to change at page 36, line 14 skipping to change at page 36, line 37
When implementing the server role, an application protocol can: When implementing the server role, an application protocol can:
* listen for incoming connections, which prepares for the exchange * listen for incoming connections, which prepares for the exchange
described in Section 7; described in Section 7;
* if Early Data is supported, embed application-controlled data in * if Early Data is supported, embed application-controlled data in
the TLS resumption ticket sent to the client; and the TLS resumption ticket sent to the client; and
* if Early Data is supported, retrieve application-controlled data * if Early Data is supported, retrieve application-controlled data
from the client's resumption ticket and enable rejecting Early from the client's resumption ticket and accept or reject Early
Data based on that information. Data based on that information.
In either role, an application protocol can: In either role, an application protocol can:
* configure minimum values for the initial number of permitted * configure minimum values for the initial number of permitted
streams of each type, as communicated in the transport parameters streams of each type, as communicated in the transport parameters
(Section 7.4); (Section 7.4);
* control resource allocation of various types, including flow * control resource allocation for receive buffers by setting flow
control and the number of permitted streams of each type; control limits both for streams and for the connection
* identify whether the handshake has completed successfully or is * identify whether the handshake has completed successfully or is
still ongoing; still ongoing;
* keep a connection from silently closing, either by generating PING * keep a connection from silently closing, either by generating PING
frames (Section 19.2) or by requesting that the transport send frames (Section 19.2) or by requesting that the transport send
additional frames before the idle timeout expires (Section 10.1); additional frames before the idle timeout expires (Section 10.1);
and and
* immediately close (Section 10.2) the connection. * immediately close (Section 10.2) the connection.
6. Version Negotiation 6. Version Negotiation
Version negotiation allows a server to indicate that it does not Version negotiation allows a server to indicate that it does not
support the version the client used. A server sends a Version support the version the client used. 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 UDP datagram they send to multiple QUIC versions SHOULD ensure that the first UDP datagram they
the largest of the minimum datagram sizes from all versions they send is sized to the largest of the minimum datagram sizes from all
support. This ensures that the server responds if there is a versions they support, using PADDING frames (Section 19.1) as
necessary. This ensures that the server responds if there is a
mutually supported version. A server might not send a Version mutually supported version. A server might not send a Version
Negotiation packet if the datagram it receives is smaller than the Negotiation packet if the datagram it receives is smaller than the
minimum size specified in a different version; see Section 14.1. minimum size specified in a different version; see Section 14.1.
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
skipping to change at page 39, line 21 skipping to change at page 39, line 49
- every connection produces distinct and unrelated keys, and - every connection produces distinct and unrelated keys, and
- keying material is usable for packet protection for both 0-RTT - keying material is usable for packet protection for both 0-RTT
and 1-RTT packets and 1-RTT packets
* authenticated values for transport parameters of both endpoints, * authenticated values for transport parameters of both endpoints,
and confidentiality protection for server transport parameters and confidentiality protection for server transport parameters
(see Section 7.4) (see Section 7.4)
* authenticated negotiation of an application protocol (TLS uses * authenticated negotiation of an application protocol (TLS uses
ALPN [RFC7301] for this purpose) ALPN [ALPN] for this purpose)
An endpoint verifies support for Explicit Congestion Notification Endpoints can use packets sent during the handshake to test for
(ECN) by observing whether the ACK frames acknowledging the first Explicit Congestion Notification (ECN) support; see Section 13.4. An
packets it sends carry ECN counts, as described in Section 13.4.2. endpoint verifies support for ECN by observing whether the ACK frames
acknowledging the first packets it sends carry ECN counts, as
described in Section 13.4.2.
The CRYPTO frame can be sent in different packet number spaces The CRYPTO frame can be sent in different packet number spaces
(Section 12.3). The offsets used by CRYPTO frames to ensure ordered (Section 12.3). The offsets used by CRYPTO frames to ensure ordered
delivery of cryptographic handshake data start from zero in each delivery of cryptographic handshake data start from zero in each
packet number space. packet number space.
Figure 4 shows a simplified handshake and the exchange of packets and Figure 4 shows a simplified handshake and the exchange of packets and
frames that are used to advance the handshake. Exchange of frames that are used to advance the handshake. Exchange of
application data during the handshake is enabled where possible, application data during the handshake is enabled where possible,
shown with a '*'. Once completed, endpoints are able to exchange shown with a '*'. Once completed, endpoints are able to exchange
skipping to change at page 40, line 5 skipping to change at page 40, line 37
Handshake (CRYPTO) Handshake (CRYPTO)
<---------- 1-RTT (*) <---------- 1-RTT (*)
Handshake (CRYPTO) Handshake (CRYPTO)
1-RTT (*) ----------> 1-RTT (*) ---------->
<---------- 1-RTT (HANDSHAKE_DONE,*) <---------- 1-RTT (HANDSHAKE_DONE,*)
1-RTT (*) <=========> 1-RTT (*) 1-RTT (*) <=========> 1-RTT (*)
Figure 4: Simplified QUIC Handshake Figure 4: Simplified QUIC Handshake
An endpoint validates support for Explicit Congestion Notification
(ECN) by observing whether the ACK frames acknowledging the first
packets it sends carry ECN counts, as described in Section 13.4.2.
Endpoints MUST explicitly negotiate an application protocol. This Endpoints MUST explicitly negotiate an application protocol. This
avoids situations where there is a disagreement about the protocol avoids situations where there is a disagreement about the protocol
that is in use. that is in use.
7.1. Example Handshake Flows 7.1. Example Handshake Flows
Details of how TLS is integrated with QUIC are provided in Details of how TLS is integrated with QUIC are provided in
[QUIC-TLS], but some examples are provided here. An extension of [QUIC-TLS], but some examples are provided here. An extension of
this exchange to support client address validation is shown in this exchange to support client address validation is shown in
Section 8.1.2. Section 8.1.2.
skipping to change at page 44, line 42 skipping to change at page 45, line 34
When the handshake does not include a Retry (Figure 7), the server When the handshake does not include a Retry (Figure 7), the server
sets original_destination_connection_id to "S1" and sets original_destination_connection_id to "S1" and
initial_source_connection_id to "S3". In this case, the server does initial_source_connection_id to "S3". In this case, the server does
not include a retry_source_connection_id transport parameter. not include a retry_source_connection_id transport parameter.
When the handshake includes a Retry (Figure 8), the server sets When the handshake includes a Retry (Figure 8), the server sets
original_destination_connection_id to "S1", original_destination_connection_id to "S1",
retry_source_connection_id to "S2", and initial_source_connection_id retry_source_connection_id to "S2", and initial_source_connection_id
to "S3". to "S3".
Each endpoint validates transport parameters set by the peer. The
client confirms that the retry_source_connection_id transport
parameter is absent if it did not process a Retry packet.
7.4. Transport Parameters 7.4. Transport Parameters
During connection establishment, both endpoints make authenticated During connection establishment, both endpoints make authenticated
declarations of their transport parameters. Endpoints are required declarations of their transport parameters. Endpoints are required
to comply with the restrictions that each parameter defines; the to comply with the restrictions that each parameter defines; the
description of each parameter includes rules for its handling. description of each parameter includes rules for its handling.
Transport parameters are declarations that are made unilaterally by Transport parameters are declarations that are made unilaterally by
each endpoint. Each endpoint can choose values for transport each endpoint. Each endpoint can choose values for transport
parameters independent of the values chosen by its peer. parameters independent of the values chosen by its peer.
skipping to change at page 46, line 25 skipping to change at page 47, line 13
transport parameter it cannot process. 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:
ack_delay_exponent, max_ack_delay, initial_source_connection_id, ack_delay_exponent, max_ack_delay, initial_source_connection_id,
original_destination_connection_id, preferred_address, original_destination_connection_id, preferred_address,
retry_source_connection_id, and stateless_reset_token. The client retry_source_connection_id, and stateless_reset_token. The client
MUST use the server's new values in the handshake instead; if the MUST use the server's new values in the handshake instead; if the
server does not provide new values, the default value is used. server does not provide new values, the default value is used.
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 that it is able to process.
these transport parameters, or store an integrity-protected copy of The server can remember these transport parameters, or store an
the values in the ticket and recover the information when accepting integrity-protected copy of the values in the ticket and recover the
0-RTT data. A server uses the transport parameters in determining information when accepting 0-RTT data. A server uses the transport
whether to accept 0-RTT data. parameters in determining whether to accept 0-RTT data.
If 0-RTT data is accepted by the server, the server MUST NOT reduce If 0-RTT data is accepted by the server, the server MUST NOT reduce
any limits or alter any values that might be violated by the client any limits or alter any values that might be violated by the client
with its 0-RTT data. In particular, a server that accepts 0-RTT data with its 0-RTT data. In particular, a server that accepts 0-RTT data
MUST NOT set values for the following parameters (Section 18.2) that MUST NOT set values for the following parameters (Section 18.2) that
are smaller than the remembered value of the parameters. are smaller than the remembered value of the parameters.
* active_connection_id_limit * active_connection_id_limit
* initial_max_data * initial_max_data
skipping to change at page 47, line 4 skipping to change at page 47, line 38
* initial_max_stream_data_bidi_local * initial_max_stream_data_bidi_local
* initial_max_stream_data_bidi_remote * initial_max_stream_data_bidi_remote
* initial_max_stream_data_uni * initial_max_stream_data_uni
* initial_max_streams_bidi * initial_max_streams_bidi
* initial_max_streams_uni * initial_max_streams_uni
Omitting or setting a zero value for certain transport parameters can Omitting or setting a zero value for certain transport parameters can
result in 0-RTT data being enabled, but not usable. The applicable result in 0-RTT data being enabled, but not usable. The applicable
subset of transport parameters that permit sending of application subset of transport parameters that permit sending of application
data SHOULD be set to non-zero values for 0-RTT. This includes data SHOULD be set to non-zero values for 0-RTT. This includes
initial_max_data and either initial_max_streams_bidi and initial_max_data and either initial_max_streams_bidi and
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_bidi_remote, or initial_max_streams_uni and
initial_max_stream_data_uni. initial_max_stream_data_uni.
A server MAY store and recover the previously sent values of the A server MAY store and recover the previously sent values of the
max_idle_timeout, max_udp_payload_size, and disable_active_migration max_idle_timeout, max_udp_payload_size, and disable_active_migration
parameters and reject 0-RTT if it selects smaller values. Lowering parameters and reject 0-RTT if it selects smaller values. Lowering
the values of these parameters while also accepting 0-RTT data could the values of these parameters while also accepting 0-RTT data could
degrade the performance of the connection. Specifically, lowering degrade the performance of the connection. Specifically, lowering
the max_udp_payload_size could result in dropped packets leading to the max_udp_payload_size could result in dropped packets leading to
worse performance compared to rejecting 0-RTT data outright. worse performance compared to rejecting 0-RTT data outright.
A server MUST either reject 0-RTT data or abort a handshake if the A server MUST reject 0-RTT data if the restored values for transport
implied values for transport parameters cannot be supported. parameters cannot be supported.
When sending frames in 0-RTT packets, a client MUST only use When sending frames in 0-RTT packets, a client MUST only use
remembered transport parameters; importantly, it MUST NOT use updated remembered transport parameters; importantly, it MUST NOT use updated
values that it learns from the server's updated transport parameters values that it learns from the server's updated transport parameters
or from frames received in 1-RTT packets. Updated values of or from frames received in 1-RTT packets. Updated values of
transport parameters from the handshake apply only to 1-RTT packets. transport parameters from the handshake apply only to 1-RTT packets.
For instance, flow control limits from remembered transport For instance, flow control limits from remembered transport
parameters apply to all 0-RTT packets even if those values are parameters apply to all 0-RTT packets even if those values are
increased by the handshake or by frames sent in 1-RTT packets. A increased by the handshake or by frames sent in 1-RTT packets. A
server MAY treat use of updated transport parameters in 0-RTT as a server MAY treat use of updated transport parameters in 0-RTT as a
skipping to change at page 47, line 43 skipping to change at page 48, line 36
7.4.2. New Transport Parameters 7.4.2. New Transport Parameters
New transport parameters can be used to negotiate new protocol New transport parameters can be used to negotiate new protocol
behavior. An endpoint MUST ignore transport parameters that it does behavior. An endpoint MUST ignore transport parameters that it does
not support. Absence of a transport parameter therefore disables any not support. Absence of a transport parameter therefore disables any
optional protocol feature that is negotiated using the parameter. As optional protocol feature that is negotiated using the parameter. As
described in Section 18.1, some identifiers are reserved in order to described in Section 18.1, some identifiers are reserved in order to
exercise this requirement. exercise this requirement.
A client that does not understand a transport parameter can discard
it and attempt 0-RTT on subsequent connections. However, if the
client adds support for a discarded transport parameter, it risks
violating the constraints that the transport parameter establishes if
it attempts 0-RTT. New transport parameters can avoid this problem
by setting a default of the most conservative value.
New transport parameters can be registered according to the rules in New transport parameters can be registered according to the rules in
Section 22.2. Section 22.2.
7.5. Cryptographic Message Buffering 7.5. Cryptographic Message Buffering
Implementations need to maintain a buffer of CRYPTO data received out Implementations need to maintain a buffer of CRYPTO data received out
of order. Because there is no flow control of CRYPTO frames, an of order. Because there is no flow control of CRYPTO frames, an
endpoint could potentially force its peer to buffer an unbounded endpoint could potentially force its peer to buffer an unbounded
amount of data. amount of data.
skipping to change at page 49, line 16 skipping to change at page 50, line 16
than three times as many bytes as the number of bytes they have than three times as many bytes as the number of bytes they have
received. This limits the magnitude of any amplification attack that received. This limits the magnitude of any amplification attack that
can be mounted using spoofed source addresses. For the purposes of can be mounted using spoofed source addresses. For the purposes of
avoiding amplification prior to address validation, servers MUST avoiding amplification prior to address validation, servers MUST
count all of the payload bytes received in datagrams that are count all of the payload bytes received in datagrams that are
uniquely attributed to a single connection. This includes datagrams uniquely attributed to a single connection. This includes datagrams
that contain packets that are successfully processed and datagrams that contain packets that are successfully processed and datagrams
that contain packets that are all discarded. that contain packets that are all discarded.
Clients MUST ensure that UDP datagrams containing Initial packets Clients MUST ensure that UDP datagrams containing Initial packets
have UDP payloads of at least 1200 bytes, adding padding to packets have UDP payloads of at least 1200 bytes, adding PADDING frames as
in the datagram as necessary. A client that sends padded datagrams necessary. A client that sends padded datagrams allows the server to
allows the server to send more data prior to completing address send more data prior to completing address validation.
validation.
Loss of an Initial or Handshake packet from the server can cause a Loss of an Initial or Handshake packet from the server can cause a
deadlock if the client does not send additional Initial or Handshake deadlock if the client does not send additional Initial or Handshake
packets. A deadlock could occur when the server reaches its anti- packets. A deadlock could occur when the server reaches its anti-
amplification limit and the client has received acknowledgements for amplification limit and the client has received acknowledgements for
all the data it has sent. In this case, when the client has no all the data it has sent. In this case, when the client has no
reason to send additional packets, the server will be unable to send reason to send additional packets, the server will be unable to send
more data because it has not validated the client's address. To more data because it has not validated the client's address. To
prevent this deadlock, clients MUST send a packet on a probe timeout prevent this deadlock, clients MUST send a packet on a probe timeout
(PTO, see Section 6.2 of [QUIC-RECOVERY]). Specifically, the client (PTO, see Section 6.2 of [QUIC-RECOVERY]). Specifically, the client
skipping to change at page 51, line 37 skipping to change at page 52, line 37
The server uses the NEW_TOKEN frame (Section 19.7) to provide the The server uses the NEW_TOKEN frame (Section 19.7) to provide the
client with an address validation token that can be used to validate client with an address validation token that can be used to validate
future connections. In a future connection, the client includes this future connections. In a future connection, the client includes this
token in Initial packets to provide address validation. The client token in Initial packets to provide address validation. The client
MUST include the token in all Initial packets it sends, unless a MUST include the token in all Initial packets it sends, unless a
Retry replaces the token with a newer one. The client MUST NOT use Retry replaces the token with a newer one. The client MUST NOT use
the token provided in a Retry for future connections. Servers MAY the token provided in a Retry for future connections. Servers MAY
discard any Initial packet that does not carry the expected token. discard any Initial packet that does not carry the expected token.
Unlike the token that is created for a Retry packet, which is used Unlike the token that is created for a Retry packet, which is used
immediately, the token sent in the NEW_TOKEN frame might be used immediately, the token sent in the NEW_TOKEN frame can be used after
after some period of time has passed. Thus, a token SHOULD have an some period of time has passed. Thus, a token SHOULD have an
expiration time, which could be either an explicit expiration time or expiration time, which could be either an explicit expiration time or
an issued timestamp that can be used to dynamically calculate the an issued timestamp that can be used to dynamically calculate the
expiration time. A server can store the expiration time or include expiration time. A server can store the expiration time or include
it in an encrypted form in the token. it in an encrypted form in the token.
A token issued with NEW_TOKEN MUST NOT include information that would A token issued with NEW_TOKEN MUST NOT include information that would
allow values to be linked by an observer to the connection on which allow values to be linked by an observer to the connection on which
it was issued, unless the values are encrypted. For example, it it was issued. For example, it cannot include the previous
cannot include the previous connection ID or addressing information. connection ID or addressing information, unless the values are
A server MUST ensure that every NEW_TOKEN frame it sends is unique encrypted. A server MUST ensure that every NEW_TOKEN frame it sends
across all clients, with the exception of those sent to repair losses is unique across all clients, with the exception of those sent to
of previously sent NEW_TOKEN frames. Information that allows the repair losses of previously sent NEW_TOKEN frames. Information that
server to distinguish between tokens from Retry and NEW_TOKEN MAY be allows the server to distinguish between tokens from Retry and
accessible to entities other than the server. NEW_TOKEN MAY be accessible to entities other than the server.
It is unlikely that the client port number is the same on two It is unlikely that the client port number is the same on two
different connections; validating the port is therefore unlikely to different connections; validating the port is therefore unlikely to
be successful. be successful.
A token received in a NEW_TOKEN frame is applicable to any server A token received in a NEW_TOKEN frame is applicable to any server
that the connection is considered authoritative for (e.g., server that the connection is considered authoritative for (e.g., server
names included in the certificate). When connecting to a server for names included in the certificate). When connecting to a server for
which the client retains an applicable and unused token, it SHOULD which the client retains an applicable and unused token, it SHOULD
include that token in the Token field of its Initial packet. include that token in the Token field of its Initial packet.
skipping to change at page 54, line 26 skipping to change at page 55, line 26
replay of tokens is prevented or limited. Servers SHOULD ensure that replay of tokens is prevented or limited. Servers SHOULD ensure that
tokens sent in Retry packets are only accepted for a short time. tokens sent in Retry packets are only accepted for a short time.
Tokens that are provided in NEW_TOKEN frames (Section 19.7) need to Tokens that are provided in NEW_TOKEN frames (Section 19.7) need to
be valid for longer, but SHOULD NOT be accepted multiple times in a be valid for longer, but SHOULD NOT be accepted multiple times in a
short period. Servers are encouraged to allow tokens to be used only short period. Servers are encouraged to allow tokens to be used only
once, if possible; tokens MAY include additional information about once, if possible; tokens MAY include additional information about
clients to further narrow applicability or reuse. clients to further narrow applicability or reuse.
8.2. Path Validation 8.2. Path Validation
Path validation is used during connection migration (see Section 9) Path validation is used by both peers during connection migration
by the migrating endpoint to verify reachability of a peer from a new (see Section 9) to verify reachability after a change of address. In
local address. In path validation, endpoints test reachability path validation, endpoints test reachability between a specific local
between a specific local address and a specific peer address, where address and a specific peer address, where an address is the two-
an address is the two-tuple of IP address and port. tuple of IP address and port.
Path validation tests that packets sent on a path to a peer are Path validation tests that packets sent on a path to a peer are
received by that peer. Path validation is used to ensure that received by that peer. Path validation is used to ensure that
packets received from a migrating peer do not carry a spoofed source packets received from a migrating peer do not carry a spoofed source
address. address.
Path validation does not validate that a peer can send in the return Path validation does not validate that a peer can send in the return
direction. The peer performs independent validation of the return direction. Acknowledgments cannot be used for return path validation
path. because they contain insufficient entropy and might be spoofed.
Endpoints independently determine reachability on each direction of a
path, and therefore return reachability can only be established by
the peer.
Path validation can be used at any time by either endpoint. For Path validation can be used at any time by either endpoint. For
instance, an endpoint might check that a peer is still in possession instance, an endpoint might check that a peer is still in possession
of its address after a period of quiescence. of its address after a period of quiescence.
Path validation is not designed as a NAT traversal mechanism. Though Path validation is not designed as a NAT traversal mechanism. Though
the mechanism described here might be effective for the creation of the mechanism described here might be effective for the creation of
NAT bindings that support NAT traversal, the expectation is that one NAT bindings that support NAT traversal, the expectation is that one
or other peer is able to receive packets without first having sent a or other peer is able to receive packets without first having sent a
packet on that path. Effective NAT traversal needs additional packet on that path. Effective NAT traversal needs additional
synchronization mechanisms that are not provided here. synchronization mechanisms that are not provided here.
An endpoint MAY include PATH_CHALLENGE and PATH_RESPONSE frames that An endpoint MAY include other frames with the PATH_CHALLENGE and
are used for path validation with other frames. In particular, an PATH_RESPONSE frames used for path validation. In particular, an
endpoint can pad a packet carrying a PATH_CHALLENGE for Path Maximum endpoint can include PADDING frames with a PATH_CHALLENGE frame for
Transfer Unit (PMTU) discovery (see Section 14.2.1), or an endpoint Path Maximum Transmission Unit Discovery (PMTUD; see Section 14.2.1);
can include a PATH_RESPONSE with its own PATH_CHALLENGE. it can also include its own PATH_CHALLENGE frame with a PATH_RESPONSE
frame.
When probing a new path, an endpoint might want to ensure that its An endpoint uses a new connection ID for probes sent from a new local
peer has an unused connection ID available for responses. The address; see Section 9.5. When probing a new path, an endpoint can
endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the ensure that its peer has an unused connection ID available for
same packet. This ensures that an unused connection ID will be responses. Sending NEW_CONNECTION_ID and PATH_CHALLENGE frames in
available to the peer when sending a response. the same packet, if the peer's active_connection_id_limit permits,
ensures that an unused connection ID will be available to the peer
when sending a response.
8.3. Initiating Path Validation An endpoint can choose to simultaneously probe multiple paths. The
number of simultaneous paths used for probes is limited by the number
of extra connection IDs its peer has previously supplied, since each
new local address used for a probe requires a previously unused
connection ID.
8.2.1. Initiating Path Validation
To initiate path validation, an endpoint sends a PATH_CHALLENGE frame To initiate path validation, an endpoint sends a PATH_CHALLENGE frame
containing an unpredictable payload on the path to be validated. containing an unpredictable payload on the path to be validated.
An endpoint MAY send multiple PATH_CHALLENGE frames to guard against An endpoint MAY send multiple PATH_CHALLENGE frames to guard against
packet loss. However, an endpoint SHOULD NOT send multiple packet loss. However, an endpoint SHOULD NOT send multiple
PATH_CHALLENGE frames in a single packet. An endpoint SHOULD NOT PATH_CHALLENGE frames in a single packet.
send a PATH_CHALLENGE more frequently than it would an Initial
packet, ensuring that connection migration is no more load on a new An endpoint SHOULD NOT probe a new path with packets containing a
path than establishing a new connection. PATH_CHALLENGE frame more frequently than it would send an Initial
packet. This ensures that connection migration is no more load on a
new path than establishing a new connection.
The endpoint MUST use unpredictable data in every PATH_CHALLENGE The endpoint MUST use unpredictable data in every PATH_CHALLENGE
frame so that it can associate the peer's response with the frame so that it can associate the peer's response with the
corresponding PATH_CHALLENGE. corresponding PATH_CHALLENGE.
8.4. Path Validation Responses 8.2.2. Path Validation Responses
On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by
echoing the data contained in the PATH_CHALLENGE frame in a echoing the data contained in the PATH_CHALLENGE frame in a
PATH_RESPONSE frame. A PATH_RESPONSE frame does not need to be sent PATH_RESPONSE frame. A PATH_RESPONSE frame does not need to be sent
on the network path where the PATH_CHALLENGE was received; a on the network path where the PATH_CHALLENGE was received; a
PATH_RESPONSE can be sent on any network path. An endpoint MUST NOT PATH_RESPONSE can be sent on any network path. An endpoint MUST NOT
delay transmission of a packet containing a PATH_RESPONSE frame delay transmission of a packet containing a PATH_RESPONSE frame
unless constrained by congestion control. unless constrained by congestion control.
An endpoint MUST NOT send more than one PATH_RESPONSE frame in An endpoint MUST NOT send more than one PATH_RESPONSE frame in
response to one PATH_CHALLENGE frame; see Section 13.3. The peer is response to one PATH_CHALLENGE frame; see Section 13.3. The peer is
expected to send more PATH_CHALLENGE frames as necessary to evoke expected to send more PATH_CHALLENGE frames as necessary to evoke
additional PATH_RESPONSE frames. additional PATH_RESPONSE frames.
8.5. Successful Path Validation 8.2.3. Successful Path Validation
Path validation succeeds when a PATH_RESPONSE frame is received that Path validation succeeds when a PATH_RESPONSE frame is received that
contains the data that was sent in a previous PATH_CHALLENGE frame. contains the data that was sent in a previous PATH_CHALLENGE frame.
This validates the path on which the PATH_CHALLENGE was sent. This validates the path on which the PATH_CHALLENGE was sent.
Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE
frame is not adequate validation, since the acknowledgment can be frame is not adequate validation, since the acknowledgment can be
spoofed by a malicious peer. spoofed by a malicious peer.
8.6. Failed Path Validation 8.2.4. Failed Path Validation
Path validation only fails when the endpoint attempting to validate Path validation only fails when the endpoint attempting to validate
the path abandons its attempt to validate the path. the path abandons its attempt to validate the path.
Endpoints SHOULD abandon path validation based on a timer. When Endpoints SHOULD abandon path validation based on a timer. When
setting this timer, implementations are cautioned that the new path setting this timer, implementations are cautioned that the new path
could have a longer round-trip time than the original. A value of could have a longer round-trip time than the original. A value of
three times the larger of the current Probe Timeout (PTO) or the three times the larger of the current Probe Timeout (PTO) or the
initial timeout (that is, 2*kInitialRtt) as defined in initial timeout (that is, 2*kInitialRtt) as defined in
[QUIC-RECOVERY] is RECOMMENDED. That is: [QUIC-RECOVERY] is RECOMMENDED. That is:
skipping to change at page 57, line 8 skipping to change at page 58, line 31
process by which an endpoint migrates to a new address. process by which an endpoint migrates to a new address.
The design of QUIC relies on endpoints retaining a stable address for The design of QUIC relies on endpoints retaining a stable address for
the duration of the handshake. An endpoint MUST NOT initiate the duration of the handshake. An endpoint MUST NOT initiate
connection migration before the handshake is confirmed, as defined in connection migration before the handshake is confirmed, as defined in
section 4.1.2 of [QUIC-TLS]. section 4.1.2 of [QUIC-TLS].
If the peer sent the disable_active_migration transport parameter, an If the peer sent the disable_active_migration transport parameter, an
endpoint also MUST NOT send packets (including probing packets; see endpoint also MUST NOT send packets (including probing packets; see
Section 9.1) from a different local address to the address the peer Section 9.1) from a different local address to the address the peer
used during the handshake. An endpoint that has sent this transport used during the handshake, unless the endpoint has acted on a
parameter, but detects that a peer has nonetheless migrated to a preferred_address transport parameter from the peer. If the peer
different remote address MUST either drop the incoming packets on violates this requirement, the endpoint MUST either drop the incoming
that path without generating a stateless reset or proceed with path packets on that path without generating a stateless reset or proceed
validation and allow the peer to migrate. Generating a stateless with path validation and allow the peer to migrate. Generating a
reset or closing the connection would allow third parties in the stateless reset or closing the connection would allow third parties
network to cause connections to close by spoofing or otherwise in the network to cause connections to close by spoofing or otherwise
manipulating observed traffic. manipulating observed traffic.
Not all changes of peer address are intentional, or active, Not all changes of peer address are intentional, or active,
migrations. The peer could experience NAT rebinding: a change of migrations. The peer could experience NAT rebinding: a change of
address due to a middlebox, usually a NAT, allocating a new outgoing address due to a middlebox, usually a NAT, allocating a new outgoing
port or even a new outgoing IP address for a flow. An endpoint MUST port or even a new outgoing IP address for a flow. An endpoint MUST
perform path validation (Section 8.2) if it detects any change to a perform path validation (Section 8.2) if it detects any change to a
peer's address, unless it has previously validated that address. peer's address, unless it has previously validated that address.
When an endpoint has no validated path on which to send packets, it When an endpoint has no validated path on which to send packets, it
skipping to change at page 57, line 46 skipping to change at page 59, line 22
9.1. Probing a New Path 9.1. Probing a New Path
An endpoint MAY probe for peer reachability from a new local address An endpoint MAY probe for peer reachability from a new local address
using path validation (Section 8.2) prior to migrating the connection using path validation (Section 8.2) prior to migrating the connection
to the new local address. Failure of path validation simply means to the new local address. Failure of path validation simply means
that the new path is not usable for this connection. Failure to that the new path is not usable for this connection. Failure to
validate a path does not cause the connection to end unless there are validate a path does not cause the connection to end unless there are
no valid alternative paths available. no valid alternative paths available.
An endpoint uses a new connection ID for probes sent from a new local
address; see Section 9.5 for further discussion. An endpoint that
uses a new local address needs to ensure that at least one new
connection ID is available at the peer. That can be achieved by
including a NEW_CONNECTION_ID frame in the probe.
Receiving a PATH_CHALLENGE frame from a peer indicates that the peer
is probing for reachability on a path. An endpoint sends a
PATH_RESPONSE frame in response, as per Section 8.2.
PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frames
are "probing frames", and all other frames are "non-probing frames". are "probing frames", and all other frames are "non-probing frames".
A packet containing only probing frames is a "probing packet", and a A packet containing only probing frames is a "probing packet", and a
packet containing any other frame is a "non-probing packet". packet containing any other frame is a "non-probing packet".
9.2. Initiating Connection Migration 9.2. Initiating Connection Migration
An endpoint can migrate a connection to a new local address by An endpoint can migrate a connection to a new local address by
sending packets containing non-probing frames from that address. sending packets containing non-probing frames from that address.
Each endpoint validates its peer's address during connection Each endpoint validates its peer's address during connection
establishment. Therefore, a migrating endpoint can send to its peer establishment. Therefore, a migrating endpoint can send to its peer
knowing that the peer is willing to receive at the peer's current knowing that the peer is willing to receive at the peer's current
address. Thus an endpoint can migrate to a new local address without address. Thus an endpoint can migrate to a new local address without
first validating the peer's address. first validating the peer's address.
When migrating, the new path might not support the endpoint's current
sending rate. Therefore, the endpoint resets its congestion
controller and RTT estimate, as described in Section 9.4.
The new path might not have the same ECN capability. Therefore, the
endpoint verifies ECN capability as described in Section 13.4.
To establish reachability on the new path, an endpoint initiates path To establish reachability on the new path, an endpoint initiates path
validation (Section 8.2) on the new path. An endpoint MAY defer path validation (Section 8.2) on the new path. An endpoint MAY defer path
validation until after a peer sends the next non-probing frame to its validation until after a peer sends the next non-probing frame to its
new address. new address.
Path validation is necessary to verify reachability of a peer on a When migrating, the new path might not support the endpoint's current
new network path. Acknowledgments cannot be used for path validation sending rate. Therefore, the endpoint resets its congestion
as they contain insufficient entropy and might be spoofed. No method controller and RTT estimate, as described in Section 9.4.
is provided to establish return reachability, as endpoints
independently determine reachability on each direction of a path. The new path might not have the same ECN capability. Therefore, the
endpoint validates ECN capability as described in Section 13.4.
9.3. Responding to Connection Migration 9.3. Responding to Connection Migration
Receiving a packet from a new peer address containing a non-probing Receiving a packet from a new peer address containing a non-probing
frame indicates that the peer has migrated to that address. frame indicates that the peer has migrated to that address.
In response to such a packet, an endpoint MUST start sending If the recipient permits the migration, it MUST send subsequent
subsequent packets to the new peer address and MUST initiate path packets to the new peer address and MUST initiate path validation
validation (Section 8.2) to verify the peer's ownership of the (Section 8.2) to verify the peer's ownership of the address if
unvalidated address. validation is not already underway.
An endpoint only changes the address to which it sends packets in
response to the highest-numbered non-probing packet. This ensures
that an endpoint does not send packets to an old peer address in the
case that it receives reordered packets.
An endpoint MAY send data to an unvalidated peer address, but it MUST An endpoint MAY send data to an unvalidated peer address, but it MUST
protect against potential attacks as described in Section 9.3.1 and protect against potential attacks as described in Section 9.3.1 and
Section 9.3.2. An endpoint MAY skip validation of a peer address if Section 9.3.2. An endpoint MAY skip validation of a peer address if
that address has been seen recently. In particular, if an endpoint that address has been seen recently. In particular, if an endpoint
returns to a previously-validated path after detecting some form of returns to a previously-validated path after detecting some form of
spurious migration, skipping address validation and restoring loss spurious migration, skipping address validation and restoring loss
detection and congestion state can reduce the performance impact of detection and congestion state can reduce the performance impact of
the attack. the attack.
An endpoint only changes the address that it sends packets to in
response to the highest-numbered non-probing packet. This ensures
that an endpoint does not send packets to an old peer address in the
case that it receives reordered packets.
After changing the address to which it sends non-probing packets, an After changing the address to which it sends non-probing packets, an
endpoint could abandon any path validation for other addresses. endpoint can abandon any path validation for other addresses.
Receiving a packet from a new peer address might be the result of a Receiving a packet from a new peer address could be the result of a
NAT rebinding at the peer. NAT rebinding at the peer.
After verifying a new client address, the server SHOULD send new After verifying a new client address, the server SHOULD send new
address validation tokens (Section 8) to the client. address validation tokens (Section 8) to the client.
9.3.1. Peer Address Spoofing 9.3.1. Peer Address Spoofing
It is possible that a peer is spoofing its source address to cause an It is possible that a peer is spoofing its source address to cause an
endpoint to send excessive amounts of data to an unwilling host. If endpoint to send excessive amounts of data to an unwilling host. If
the endpoint sends significantly more data than the spoofing peer, the endpoint sends significantly more data than the spoofing peer,
skipping to change at page 67, line 27 skipping to change at page 68, line 31
An endpoint restarts its idle timer when a packet from its peer is An endpoint restarts its idle timer when a packet from its peer is
received and processed successfully. An endpoint also restarts its received and processed successfully. An endpoint also restarts its
idle timer when sending an ack-eliciting packet if no other ack- idle timer when sending an ack-eliciting packet if no other ack-
eliciting packets have been sent since last receiving and processing eliciting packets have been sent since last receiving and processing
a packet. Restarting this timer when sending a packet ensures that a packet. Restarting this timer when sending a packet ensures that
connections are not closed after new activity is initiated. connections are not closed after new activity is initiated.
To avoid excessively small idle timeout periods, endpoints MUST To avoid excessively small idle timeout periods, endpoints MUST
increase the idle timeout period to be at least three times the increase the idle timeout period to be at least three times the
current Probe Timeout (PTO). This allows for multiple PTOs to expire current Probe Timeout (PTO). This allows for multiple PTOs to
prior to idle timeout, ensuring the idle timeout does not expire as a expire, and therefore multiple probes to be sent and lost, prior to
result of a single packet loss. idle timeout.
10.1.1. Liveness Testing 10.1.1. Liveness Testing
An endpoint that sends packets close to the effective timeout risks An endpoint that sends packets close to the effective timeout risks
having them be discarded at the peer, since the idle timeout period having them be discarded at the peer, since the idle timeout period
might have expired at the peer before these packets arrive. might have expired at the peer before these packets arrive.
An endpoint can send a PING or another ack-eliciting frame to test An endpoint can send a PING or another ack-eliciting frame to test
the connection for liveness if the peer could time out soon, such as the connection for liveness if the peer could time out soon, such as
within a PTO; see Section 6.2 of [QUIC-RECOVERY]. This is especially within a PTO; see Section 6.2 of [QUIC-RECOVERY]. This is especially
skipping to change at page 68, line 36 skipping to change at page 69, line 41
An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to
terminate the connection immediately. A CONNECTION_CLOSE frame terminate the connection immediately. A CONNECTION_CLOSE frame
causes all streams to immediately become closed; open streams can be causes all streams to immediately become closed; open streams can be
assumed to be implicitly reset. assumed to be implicitly reset.
After sending a CONNECTION_CLOSE frame, an endpoint immediately After sending a CONNECTION_CLOSE frame, an endpoint immediately
enters the closing state; see Section 10.2.1. After receiving a enters the closing state; see Section 10.2.1. After receiving a
CONNECTION_CLOSE frame, endpoints enter the draining state; see CONNECTION_CLOSE frame, endpoints enter the draining state; see
Section 10.2.2. Section 10.2.2.
Violations of the protocol lead to an immediate close.
An immediate close can be used after an application protocol has An immediate close can be used after an application protocol has
arranged to close a connection. This might be after the application arranged to close a connection. This might be after the application
protocol negotiates a graceful shutdown. The application protocol protocol negotiates a graceful shutdown. The application protocol
can exchange messages that are needed for both application endpoints can exchange messages that are needed for both application endpoints
to agree that the connection can be closed, after which the to agree that the connection can be closed, after which the
application requests that QUIC close the connection. When QUIC application requests that QUIC close the connection. When QUIC
consequently closes the connection, a CONNECTION_CLOSE frame with an consequently closes the connection, a CONNECTION_CLOSE frame with an
application-supplied error code will be used to signal closure to the application-supplied error code will be used to signal closure to the
peer. peer.
The closing and draining connection states exist to ensure that The closing and draining connection states exist to ensure that
connections close cleanly and that delayed or reordered packets are connections close cleanly and that delayed or reordered packets are
properly discarded. These states SHOULD persist for at least three properly discarded. These states SHOULD persist for at least three
times the current Probe Timeout (PTO) interval as defined in times the current Probe Timeout (PTO) interval as defined in
[QUIC-RECOVERY]. [QUIC-RECOVERY].
Disposing of connection state prior to exiting the closing or Disposing of connection state prior to exiting the closing or
draining state could cause could result in an endpoint generating a draining state could result in an endpoint generating a stateless
stateless reset unnecessarily when it receives a late-arriving reset unnecessarily when it receives a late-arriving packet.
packet. Endpoints that have some alternative means to ensure that Endpoints that have some alternative means to ensure that late-
late-arriving packets do not induce a response, such as those that arriving packets do not induce a response, such as those that are
are able to close the UDP socket, MAY end these states earlier to able to close the UDP socket, MAY end these states earlier to allow
allow for faster resource recovery. Servers that retain an open for faster resource recovery. Servers that retain an open socket for
socket for accepting new connections SHOULD NOT end the closing or accepting new connections SHOULD NOT end the closing or draining
draining states early. states early.
Once its closing or draining state ends, an endpoint SHOULD discard Once its closing or draining state ends, an endpoint SHOULD discard
all connection state. The endpoint MAY send a stateless reset in all connection state. The endpoint MAY send a stateless reset in
response to any further incoming packets belonging to this response to any further incoming packets belonging to this
connection. connection.
10.2.1. Closing Connection State 10.2.1. Closing Connection State
An endpoint enters the closing state after initiating an immediate An endpoint enters the closing state after initiating an immediate
close. close.
skipping to change at page 72, line 26 skipping to change at page 73, line 35
10.3. Stateless Reset 10.3. Stateless Reset
A stateless reset is provided as an option of last resort for an A stateless reset is provided as an option of last resort for an
endpoint that does not have access to the state of a connection. A endpoint that does not have access to the state of a connection. A
crash or outage might result in peers continuing to send data to an crash or outage might result in peers continuing to send data to an
endpoint that is unable to properly continue the connection. An endpoint that is unable to properly continue the connection. An
endpoint MAY send a stateless reset in response to receiving a packet endpoint MAY send a stateless reset in response to receiving a packet
that it cannot associate with an active connection. that it cannot associate with an active connection.
A stateless reset is not appropriate for signaling error conditions. A stateless reset is not appropriate for indicating errors in active
An endpoint that wishes to communicate a fatal connection error MUST connections. An endpoint that wishes to communicate a fatal
use a CONNECTION_CLOSE frame if it has sufficient state to do so. connection error MUST use a CONNECTION_CLOSE frame if it is able.
To support this process, a token is sent by endpoints. The token is To support this process, a token is sent by endpoints. The token is
carried in the Stateless Reset Token field of a NEW_CONNECTION_ID carried in the Stateless Reset Token field of a NEW_CONNECTION_ID
frame. Servers can also specify a stateless_reset_token transport frame. Servers can also specify a stateless_reset_token transport
parameter during the handshake that applies to the connection ID that parameter during the handshake that applies to the connection ID that
it selected during the handshake; clients cannot use this transport it selected during the handshake; clients cannot use this transport
parameter because their transport parameters do not have parameter because their transport parameters do not have
confidentiality protection. These tokens are protected by confidentiality protection. These tokens are protected by
encryption, so only client and server know their value. Tokens are encryption, so only client and server know their value. Tokens are
invalidated when their associated connection ID is retired via a invalidated when their associated connection ID is retired via a
skipping to change at page 73, line 24 skipping to change at page 74, line 32
To entities other than its intended recipient, a stateless reset will To entities other than its intended recipient, a stateless reset will
appear to be a packet with a short header. For the stateless reset appear to be a packet with a short header. For the stateless reset
to appear as a valid QUIC packet, the Unpredictable Bits field needs to appear as a valid QUIC packet, the Unpredictable Bits field needs
to include at least 38 bits of data (or 5 bytes, less the two fixed to include at least 38 bits of data (or 5 bytes, less the two fixed
bits). bits).
The resulting minimum size of 21 bytes does not guarantee that a The resulting minimum size of 21 bytes does not guarantee that a
stateless reset is difficult to distinguish from other packets if the stateless reset is difficult to distinguish from other packets if the
recipient requires the use of a connection ID. To achieve that end, recipient requires the use of a connection ID. To achieve that end,
the endpoint SHOULD pad all packets it sends to at least 22 bytes the endpoint SHOULD ensure that all packets it sends are at least 22
longer than the minimum connection ID that it might request the peer bytes longer than the minimum connection ID length that it requests
to include in packets that the peer sends. This ensures that any the peer to include in its packets, adding PADDING frames as
stateless reset sent by the peer is indistinguishable from a valid necessary. This ensures that any stateless reset sent by the peer is
packet sent to the endpoint. An endpoint that sends a stateless indistinguishable from a valid packet sent to the endpoint. An
reset in response to a packet that is 43 bytes or shorter SHOULD send endpoint that sends a stateless reset in response to a packet that is
a stateless reset that is one byte shorter than the packet it 43 bytes or shorter SHOULD send a stateless reset that is one byte
responds to. shorter than the packet it responds to.
These values assume that the Stateless Reset Token is the same length These values assume that the Stateless Reset Token is the same length
as the minimum expansion of the packet protection AEAD. Additional as the minimum expansion of the packet protection AEAD. Additional
unpredictable bytes are necessary if the endpoint could have unpredictable bytes are necessary if the endpoint could have
negotiated a packet protection scheme with a larger minimum negotiated a packet protection scheme with a larger minimum
expansion. expansion.
An endpoint MUST NOT send a stateless reset that is three times or An endpoint MUST NOT send a stateless reset that is three times or
more larger than the packet it receives to avoid being used for more larger than the packet it receives to avoid being used for
amplification. Section 10.3.3 describes additional limits on amplification. Section 10.3.3 describes additional limits on
skipping to change at page 78, line 15 skipping to change at page 79, line 15
A stateless reset (Section 10.3) is not suitable for any error that A stateless reset (Section 10.3) is not suitable for any error that
can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A
stateless reset MUST NOT be used by an endpoint that has the state stateless reset MUST NOT be used by an endpoint that has the state
necessary to send a frame on the connection. necessary to send a frame on the connection.
11.1. Connection Errors 11.1. Connection Errors
Errors that result in the connection being unusable, such as an Errors that result in the connection being unusable, such as an
obvious violation of protocol semantics or corruption of state that obvious violation of protocol semantics or corruption of state that
affects an entire connection, MUST be signaled using a affects an entire connection, MUST be signaled using a
CONNECTION_CLOSE frame (Section 19.19). An endpoint MAY close the CONNECTION_CLOSE frame (Section 19.19).
connection in this manner even if the error only affects a single
stream.
Application-specific protocol errors are signaled using the Application-specific protocol errors are signaled using the
CONNECTION_CLOSE frame with a frame type of 0x1d. Errors that are CONNECTION_CLOSE frame with a frame type of 0x1d. Errors that are
specific to the transport, including all those described in this specific to the transport, including all those described in this
document, are carried in the CONNECTION_CLOSE frame with a frame type document, are carried in the CONNECTION_CLOSE frame with a frame type
of 0x1c. of 0x1c.
A CONNECTION_CLOSE frame could be sent in a packet that is lost. An A CONNECTION_CLOSE frame could be sent in a packet that is lost. An
endpoint SHOULD be prepared to retransmit a packet containing a endpoint SHOULD be prepared to retransmit a packet containing a
CONNECTION_CLOSE frame if it receives more packets on a terminated CONNECTION_CLOSE frame if it receives more packets on a terminated
skipping to change at page 85, line 16 skipping to change at page 86, line 16
H: Handshake (Section 17.2.4) H: Handshake (Section 17.2.4)
0: 0-RTT (Section 17.2.3) 0: 0-RTT (Section 17.2.3)
1: 1-RTT (Section 17.3) 1: 1-RTT (Section 17.3)
ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial ih: Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial
or Handshake packets. or Handshake packets.
Section 4 of [QUIC-TLS] provides more detail about these For more detail about these restrictions, see Section 12.5. Note
restrictions. Note that all frames can appear in 1-RTT packets. An that all frames can appear in 1-RTT packets. An endpoint MUST treat
endpoint MUST treat receipt of a frame in a packet type that is not receipt of a frame in a packet type that is not permitted as a
permitted as a connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
The "Spec" column in Table 3 summarizes any special rules governing The "Spec" column in Table 3 summarizes any special rules governing
the processing or generation of the frame type, as indicated by the the processing or generation of the frame type, as indicated by the
following characters: following characters:
N: Packets containing only frames with this marking are not ack- N: Packets containing only frames with this marking are not ack-
eliciting; see Section 13.2. eliciting; see Section 13.2.
C: Packets containing only frames with this marking do not count C: Packets containing only frames with this marking do not count
toward bytes in flight for congestion control purposes; see toward bytes in flight for congestion control purposes; see
skipping to change at page 86, line 13 skipping to change at page 87, line 13
possible encoding. For frame types defined in this document, this possible encoding. For frame types defined in this document, this
means a single-byte encoding, even though it is possible to encode means a single-byte encoding, even though it is possible to encode
these values as a two-, four- or eight-byte variable-length integer. these values as a two-, four- or eight-byte variable-length integer.
For instance, though 0x4001 is a legitimate two-byte encoding for a For instance, though 0x4001 is a legitimate two-byte encoding for a
variable-length integer with a value of 1, PING frames are always variable-length integer with a value of 1, PING frames are always
encoded as a single byte with the value 0x01. This rule applies to encoded as a single byte with the value 0x01. This rule applies to
all current and future QUIC frame types. An endpoint MAY treat the all current and future QUIC frame types. An endpoint MAY treat the
receipt of a frame type that uses a longer encoding than necessary as receipt of a frame type that uses a longer encoding than necessary as
a connection error of type PROTOCOL_VIOLATION. a connection error of type PROTOCOL_VIOLATION.
12.5. Frames and Number Spaces
Some frames are prohibited in different packet number spaces. The
rules here generalize those of TLS, in that frames associated with
establishing the connection can usually appear in packets in any
packet number space, whereas those associated with transferring data
can only appear in the application data packet number space:
* PADDING, PING, and CRYPTO frames MAY appear in any packet number
space.
* CONNECTION_CLOSE frames signaling errors at the QUIC layer (type
0x1c) MAY appear in any packet number space. CONNECTION_CLOSE
frames signaling application errors (type 0x1d) MUST only appear
in the application data packet number space.
* ACK frames MAY appear in any packet number space, but can only
acknowledge packets that appeared in that packet number space.
However, as noted below, 0-RTT packets cannot contain ACK frames.
* All other frame types MUST only be sent in the application data
packet number space.
Note that it is not possible to send the following frames in 0-RTT
packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt
of these frames in 0-RTT packets as a connection error of type
PROTOCOL_VIOLATION.
13. Packetization and Reliability 13. Packetization and Reliability
A sender sends one or more frames in a QUIC packet; see Section 12.4. A sender sends one or more frames in a QUIC packet; see Section 12.4.
A sender can minimize per-packet bandwidth and computational costs by A sender can minimize per-packet bandwidth and computational costs by
including as many frames as possible in each QUIC packet. A sender including as many frames as possible in each QUIC packet. A sender
MAY wait for a short period of time to collect multiple frames before MAY wait for a short period of time to collect multiple frames before
sending a packet that is not maximally packed, to avoid sending out sending a packet that is not maximally packed, to avoid sending out
large numbers of small packets. An implementation MAY use knowledge large numbers of small packets. An implementation MAY use knowledge
about application sending behavior or heuristics to determine whether about application sending behavior or heuristics to determine whether
skipping to change at page 95, line 8 skipping to change at page 96, line 31
[QUIC-RECOVERY]), or on other events, such as reaching a memory [QUIC-RECOVERY]), or on other events, such as reaching a memory
limit. limit.
Upon detecting losses, a sender MUST take appropriate congestion Upon detecting losses, a sender MUST take appropriate congestion
control action. The details of loss detection and congestion control control action. The details of loss detection and congestion control
are described in [QUIC-RECOVERY]. are described in [QUIC-RECOVERY].
13.4. Explicit Congestion Notification 13.4. Explicit Congestion Notification
QUIC endpoints can use Explicit Congestion Notification (ECN) QUIC endpoints can use Explicit Congestion Notification (ECN)
[RFC3168] to detect and respond to network congestion. ECN allows a [RFC3168] to detect and respond to network congestion. ECN allows an
network node to indicate congestion in the network by setting a endpoint to set an ECT codepoint in the ECN field of an IP packet. A
codepoint in the IP header of a packet instead of dropping it. network node can then indicate congestion by setting the CE codepoint
Endpoints react to congestion by reducing their sending rate in in the ECN field instead of dropping the packet [RFC8087]. Endpoints
react to reported congestion by reducing their sending rate in
response, as described in [QUIC-RECOVERY]. response, as described in [QUIC-RECOVERY].
Note that supporting ECN requires being able to set and read the ECN To enable ECN, a sending QUIC endpoint first determines whether a
codepoints in the IP headers of datagrams carrying QUIC packets. On path supports ECN marking and whether the peer reports the ECN values
platforms where this is not possible, QUIC cannot support ECN. in received IP headers; see Section 13.4.2.
To use ECN, QUIC endpoints first determine whether a path supports 13.4.1. Reporting ECN Counts
ECN marking and the peer is able to access the ECN codepoint in the
IP header. A network path does not support ECN if ECN marked packets
get dropped or ECN markings are rewritten on the path. An endpoint
validates the use of ECN on the path, both during connection
establishment and when migrating to a new path (Section 9).
13.4.1. ECN Counts Use of ECN requires the receiving endpoint to read the ECN field from
an IP packet, which is not possible on all platforms. If an endpoint
does not implement ECN support or does not have access to received
ECN fields, it does not report ECN counts for packets it receives.
On receiving a QUIC packet with an ECT or CE codepoint, an ECN- Even if an endpoint does not set an ECT field on packets it sends,
enabled endpoint that can access the ECN codepoints from the the endpoint MUST provide feedback about ECN markings it receives, if
enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE these are accessible. Failing to report the ECN counts will cause
count, and includes these counts in subsequent ACK frames; see the sender to disable use of ECN for this connection.
Section 13.2 and Section 19.3.
An IP packet that results in no QUIC packets being processed does not On receiving an IP packet with an ECT(0), ECT(1) or CE codepoint, an
increase ECN counts. A QUIC packet detected by a receiver as a ECN-enabled endpoint accesses the ECN field and increases the
duplicate does not affect the receiver's local ECN codepoint counts; corresponding ECT(0), ECT(1), or CE count. These ECN counts are
see Section 21.9 for relevant security concerns. included in subsequent ACK frames; see Section 13.2 and Section 19.3.
If an endpoint receives a QUIC packet without an ECT or CE codepoint Each packet number space maintains separate acknowledgement state and
in the IP packet header, it responds per Section 13.2 with an ACK separate ECN counts. Coalesced QUIC packets (see Section 12.2) share
frame without increasing any ECN counts. If an endpoint does not the same IP header so the ECN counts are incremented once for each
implement ECN support or does not have access to received ECN coalesced QUIC packet.
codepoints, it does not increase ECN counts.
Coalesced packets (see Section 12.2) mean that several packets can For example, if one each of an Initial, Handshake, and 1-RTT QUIC
share the same IP header. The ECN counts for the ECN codepoint packet are coalesced into a single UDP datagram, the ECN counts for
received in the associated IP header are incremented once for each all three packet number spaces will be incremented by one each, based
QUIC packet, not per enclosing IP packet or UDP datagram. on the ECN field of the single IP header.
Each packet number space maintains separate acknowledgement state and ECN counts are only incremented when QUIC packets from the received
separate ECN counts. For example, if one each of an Initial, 0-RTT, IP packet are processed. As such, duplicate QUIC packets are not
Handshake, and 1-RTT QUIC packet are coalesced, the corresponding processed and do not increase ECN counts; see Section 21.9 for
counts for the Initial and Handshake packet number space will be relevant security concerns.
incremented by one and the counts for the application data packet
number space will be increased by two.
13.4.2. ECN Validation 13.4.2. ECN Validation
It is possible for faulty network devices to corrupt or erroneously It is possible for faulty network devices to corrupt or erroneously
drop packets with ECN markings. To provide robust connectivity in drop packets that carry a non-zero ECN codepoint. To ensure
the presence of such devices, each endpoint independently validates connectivity in the presence of such devices, an endpoint validates
ECN counts and disables ECN if the path is not showing consistent the ECN counts for each network path and disables use of ECN on that
support for ECN. path if errors are detected.
Endpoints validate ECN for packets sent on each network path
independently. An endpoint thus validates ECN on new connection
establishment, when switching to a server's preferred address, and on
active connection migration to a new path. Appendix B describes one
possible algorithm for testing paths for ECN support.
Even if an endpoint does not use ECN markings on packets it
transmits, the endpoint MUST provide feedback about ECN markings
received from the peer if they are accessible. Failing to report ECN
counts will cause the peer to disable ECN marking.
13.4.2.1. Sending ECN Markings To perform ECN validation for a new path:
To start ECN validation, an endpoint SHOULD do the following when * The endpoint sets an ECT(0) codepoint in the IP header of early
sending packets on a new path to a peer: outgoing packets sent on a new path to the peer ([RFC8311]).
* Set the ECT(0) codepoint in the IP header of early outgoing * The endpoint monitors whether all packets sent with an ECT
packets sent on a new path to the peer ([RFC8311]). codepoint are eventually deemed lost (Section 6 of
[QUIC-RECOVERY]), indicating that ECN validation has failed.
* If all packets that were sent with the ECT(0) codepoint are If an endpoint has cause to expect that IP packets with an ECT
eventually deemed lost (Section 6 of [QUIC-RECOVERY]), validation codepoint might be dropped by a faulty network element, the endpoint
is deemed to have failed. could set an ECT codepoint for only the first ten outgoing packets on
a path, or for a period of three PTOs (see Section 6.2 of
[QUIC-RECOVERY]). If all packets marked with non-zero ECN codepoints
are subsequently lost, it can disable marking on the assumption that
the marking causes in loss.
To reduce the chances of misinterpreting congestive loss as packets An endpoint thus attempts to use ECN and validates this for each new
dropped by a faulty network element, an endpoint could set the ECT(0) connection, when switching to a server's preferred address, and on
codepoint for only the first ten outgoing packets on a path, or for a active connection migration to a new path. Appendix B describes one
period of three RTTs, whichever occurs first. possible algorithm.
Other methods of probing paths for ECN support are possible, as are Other methods of probing paths for ECN support are possible, as are
different marking strategies. Implementations MAY use other methods different marking strategies. Implementations MAY use other methods
defined in RFCs; see [RFC8311]. Implementations that use the ECT(1) defined in RFCs; see [RFC8311]. Implementations that use the ECT(1)
codepoint need to perform ECN validation using ECT(1) counts. codepoint need to perform ECN validation using the reported ECT(1)
counts.
13.4.2.2. Receiving ACK Frames 13.4.2.1. Receiving ACK Frames with ECN Counts
Erroneous application of ECN marks in the network can result in Erroneous application of CE markings by the network can result in
degraded connection performance. An endpoint that receives an ACK degraded connection performance. An endpoint that receives an ACK
frame with ECN counts therefore validates the counts before using frame with ECN counts therefore validates the counts before using
them. It performs this validation by comparing newly received counts them. It performs this validation by comparing newly received counts
against those from the last successfully processed ACK frame. Any against those from the last successfully processed ACK frame. Any
increase in ECN counts is validated based on the markings that were increase in the ECN counts is validated based on the ECN markings
applied to packets that are newly acknowledged in the ACK frame. that were applied to packets that are newly acknowledged in the ACK
frame.
If an ACK frame newly acknowledges a packet that the endpoint sent If an ACK frame newly acknowledges a packet that the endpoint sent
with either ECT(0) or ECT(1) codepoints set, ECN validation fails if with either the ECT(0) or ECT(1) codepoint set, ECN validation fails
ECN counts are not present in the ACK frame. This check detects a if the corresponding ECN counts are not present in the ACK frame.
network element that zeroes out ECN bits or a peer that is unable to This check detects a network element that zeroes the ECN field or a
access ECN markings. peer that does not report ECN markings.
ECN validation fails if the sum of the increase in ECT(0) and ECN-CE ECN validation also fails if the sum of the increase in ECT(0) and
counts is less than the number of newly acknowledged packets that ECN-CE counts is less than the number of newly acknowledged packets
were originally sent with an ECT(0) marking. Similarly, ECN that were originally sent with an ECT(0) marking. Similarly, ECN
validation fails if the sum of the increases to ECT(1) and ECN-CE validation fails if the sum of the increases to ECT(1) and ECN-CE
counts is less than the number of newly acknowledged packets sent counts is less than the number of newly acknowledged packets sent
with an ECT(1) marking. These checks can detect removal of ECN with an ECT(1) marking. These checks can detect remarking of ECN-CE
markings in the network. markings by the network.
An endpoint could miss acknowledgements for a packet when ACK frames An endpoint could miss acknowledgements for a packet when ACK frames
are lost. It is therefore possible for the total increase in ECT(0), are lost. It is therefore possible for the total increase in ECT(0),
ECT(1), and ECN-CE counts to be greater than the number of packets ECT(1), and ECN-CE counts to be greater than the number of packets
acknowledged in an ACK frame. This is why counts are permitted to be that are newly acknowledged by an ACK frame. This is why ECN counts
larger than might be accounted for by newly acknowledged packets. are permitted to be larger than the total number of packets that are
acknowledged.
ECN validation MAY fail if the total count for an ECT(0) or ECT(1) Validating ECN counts from reordered ACK frames can result in
marking exceeds the total number of packets sent with the failure. An endpoint MUST NOT fail ECN validation as a result of
corresponding marking. In particular, an endpoint that never applies processing an ACK frame that does not increase the largest
a particular marking can fail validation when a non-zero count for acknowledged packet number.
the corresponding marking is received. This check can detect when
packets are marked ECT(0) or ECT(1) in the network.
Processing ECN counts out of order can result in validation failure. ECN validation can fail if the received total count for either ECT(0)
An endpoint SHOULD skip ECN validation on an ACK frame that does not or ECT(1) exceeds the total number of packets sent with each
increase the largest acknowledged packet number. corresponding ECT codepoint. In particular, validation will fail
when an endpoint receives a non-zero ECN count corresponding to an
ECT codepoint that it never applied. This check detects when packets
are remarked to ECT(0) or ECT(1) in the network.
13.4.2.3. Validation Outcomes 13.4.2.2. ECN Validation Outcomes
If validation fails, then the endpoint stops sending ECN markings in If validation fails, then the endpoint MUST disable ECN. It stops
subsequent IP packets with the expectation that either the network setting the ECT codepoint in IP packets that it sends, assuming that
path or the peer does not support ECN. either the network path or the peer does not support ECN.
Upon successful validation, an endpoint can continue to set ECT Even if validation fails, an endpoint MAY revalidate ECN for the same
codepoints in subsequent packets with the expectation that the path path at any later time in the connection. An endpoint could continue
is ECN-capable. Network routing and path elements can change mid- to periodically attempt validation.
connection however; an endpoint MUST disable ECN if validation fails
at any point in the connection.
Even if validation fails, an endpoint MAY revalidate ECN on the same Upon successful validation, an endpoint MAY continue to set an ECT
path at any later time in the connection. codepoint in subsequent packets it sends, with the expectation that
the path is ECN-capable. Network routing and path elements can
however change mid-connection; an endpoint MUST disable ECN if
validation later fails.
14. Packet Size 14. Packet Size
The QUIC packet size includes the QUIC header and protected payload, The QUIC packet size includes the QUIC header and protected payload,
but not the UDP or IP headers. but not the UDP or IP headers.
QUIC depends upon a minimum IP packet size of at least 1280 bytes. QUIC depends upon a minimum IP packet size of at least 1280 bytes.
This is the IPv6 minimum size ([IPv6]) and is also supported by most This is the IPv6 minimum size ([IPv6]) and is also supported by most
modern IPv4 networks. Assuming the minimum IP header size, this modern IPv4 networks. Assuming the minimum IP header size, this
results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252 results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252
skipping to change at page 98, line 40 skipping to change at page 100, line 6
Section 14.3). Section 14.3).
Enforcement of the max_udp_payload_size transport parameter Enforcement of the max_udp_payload_size transport parameter
(Section 18.2) might act as an additional limit on the maximum packet (Section 18.2) might act as an additional limit on the maximum packet
size. A sender can avoid exceeding this limit, once the value is size. A sender can avoid exceeding this limit, once the value is
known. However, prior to learning the value of the transport known. However, prior to learning the value of the transport
parameter, endpoints risk datagrams being lost if they send packets parameter, endpoints risk datagrams being lost if they send packets
larger than the smallest allowed maximum packet size of 1200 bytes. larger than the smallest allowed maximum packet size of 1200 bytes.
UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4
([IPv4]), the DF bit MUST be set to prevent fragmentation on the ([IPv4]), the DF bit MUST be set if possible, to prevent
path. fragmentation on the path.
14.1. Initial Packet Size 14.1. Initial Packet Size
A client MUST expand the payload of all UDP datagrams carrying A client MUST expand the payload of all UDP datagrams carrying
Initial packets to at least the smallest allowed maximum packet size Initial packets to at least the smallest allowed maximum packet size
(1200 bytes) by adding PADDING frames to the Initial packet or by (1200 bytes) by adding PADDING frames to the Initial packet or by
coalescing the Initial packet; see Section 12.2. Sending a UDP coalescing the Initial packet; see Section 12.2. Sending a UDP
datagram of this size ensures that the network path from the client datagram of this size ensures that the network path from the client
to the server supports a reasonable Path Maximum Transmission Unit to the server supports a reasonable Path Maximum Transmission Unit
(PMTU). This also helps reduce the amplitude of amplification (PMTU). This also helps reduce the amplitude of amplification
skipping to change at page 104, line 29 skipping to change at page 105, line 34
+------+--------+-------------+-----------------------+ +------+--------+-------------+-----------------------+
Table 4: Summary of Integer Encodings Table 4: Summary of Integer Encodings
For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in
hexadecimal) decodes to the decimal value 151288809941952652; the hexadecimal) decodes to the decimal value 151288809941952652; the
four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte
sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37
(as does the two byte sequence 40 25). (as does the two byte sequence 40 25).
Versions (Section 15) and error codes (Section 20) are described Versions (Section 15) and packet numbers sent in the header
using integers, but do not use this encoding. (Section 17.1) are described using integers, but do not use this
encoding.
17. Packet Formats 17. Packet Formats
All numeric values are encoded in network byte order (that is, big- All numeric values are encoded in network byte order (that is, big-
endian) and all field sizes are in bits. Hexadecimal notation is endian) and all field sizes are in bits. Hexadecimal notation is
used for describing the value of fields. used for describing the value of fields.
17.1. Packet Number Encoding and Decoding 17.1. Packet Number Encoding and Decoding
Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3). Packet numbers are integers in the range 0 to 2^62-1 (Section 12.3).
When present in long or short packet headers, they are encoded in 1 When present in long or short packet headers, they are encoded in 1
to 4 bytes. The number of bits required to represent the packet to 4 bytes. The number of bits required to represent the packet
number is reduced by including only the least significant bits of the number is reduced by including only the least significant bits of the
packet number. packet number.
The encoded packet number is protected as described in Section 5.4 of The encoded packet number is protected as described in Section 5.4 of
[QUIC-TLS]. [QUIC-TLS].
Prior to receiving an acknowledgement for a packet number space, the Prior to receiving an acknowledgement for a packet number space, the
full packet number MUST be included. full packet number MUST be included; it is not to be truncated as
described below.
After an acknowledgement is received for a packet number space, the After an acknowledgement is received for a packet number space, the
sender MUST use a packet number size able to represent more than sender MUST use a packet number size able to represent more than
twice as large a range than the difference between the largest twice as large a range than the difference between the largest
acknowledged packet and packet number being sent. A peer receiving acknowledged packet and packet number being sent. A peer receiving
the packet will then correctly decode the packet number, unless the the packet will then correctly decode the packet number, unless the
packet is delayed in transit such that it arrives after many higher- packet is delayed in transit such that it arrives after many higher-
numbered packets have been received. An endpoint SHOULD use a large numbered packets have been received. An endpoint SHOULD use a large
enough packet number encoding to allow the packet number to be enough packet number encoding to allow the packet number to be
recovered even if the packet arrives after packets that are sent recovered even if the packet arrives after packets that are sent
skipping to change at page 116, line 42 skipping to change at page 117, line 42
contain confidential information that will most likely be contain confidential information that will most likely be
retransmitted on receiving a Retry packet. The keys used to protect retransmitted on receiving a Retry packet. The keys used to protect
these new 0-RTT packets will not change as a result of responding to these new 0-RTT packets will not change as a result of responding to
a Retry packet. However, the data sent in these packets could be a Retry packet. However, the data sent in these packets could be
different than what was sent earlier. Sending these new packets with different than what was sent earlier. Sending these new packets with
the same packet number is likely to compromise the packet protection the same packet number is likely to compromise the packet protection
for those packets because the same key and nonce could be used to for those packets because the same key and nonce could be used to
protect different content. A server MAY abort the connection if it protect different content. A server MAY abort the connection if it
detects that the client reset the packet number. detects that the client reset the packet number.
A server acknowledges the use of a Retry packet for a connection The connection IDs used on Initial and Retry packets exchanged
using the retry_source_connection_id transport parameter; see between client and server are copied to the transport parameters and
Section 18.2. If the server sends a Retry packet, it also validated as described in Section 7.3.
subsequently includes the value of the Source Connection ID field
from the Retry packet in its retry_source_connection_id transport
parameter.
If the client received and processed a Retry packet, it MUST validate
that the retry_source_connection_id transport parameter is present
and correct; otherwise, it MUST validate that the transport parameter
is absent. A client MUST treat a failed validation as a connection
error of type PROTOCOL_VIOLATION.
17.3. Short Header Packets 17.3. Short Header Packets
This version of QUIC defines a single packet type that uses the short This version of QUIC defines a single packet type that uses the short
packet header. packet header.
Short Header Packet { Short Header Packet {
Header Form (1) = 0, Header Form (1) = 0,
Fixed Bit (1) = 1, Fixed Bit (1) = 1,
Spin Bit (1), Spin Bit (1),
skipping to change at page 130, line 16 skipping to change at page 130, line 50
Stream ID: A variable-length integer encoding of the Stream ID of Stream ID: A variable-length integer encoding of the Stream ID of
the stream being terminated. the stream being terminated.
Application Protocol Error Code: A variable-length integer Application Protocol Error Code: A variable-length integer
containing the application protocol error code (see Section 20.2) containing the application protocol error code (see Section 20.2)
that indicates why the stream is being closed. that indicates why the stream is being closed.
Final Size: A variable-length integer indicating the final size of Final Size: A variable-length integer indicating the final size of
the stream by the RESET_STREAM sender, in unit of bytes; see the stream by the RESET_STREAM sender, in unit of bytes; see
Section 4.4. Section 4.5.
19.5. STOP_SENDING Frames 19.5. STOP_SENDING Frames
An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that An endpoint uses a STOP_SENDING frame (type=0x05) to communicate that
incoming data is being discarded on receipt at application request. incoming data is being discarded on receipt at application request.
STOP_SENDING requests that a peer cease transmission on a stream. STOP_SENDING requests that a peer cease transmission on a stream.
A STOP_SENDING frame can be sent for streams in the Recv or Size A STOP_SENDING frame can be sent for streams in the Recv or Size
Known states; see Section 3.1. Receiving a STOP_SENDING frame for a Known states; see Section 3.1. Receiving a STOP_SENDING frame for a
locally-initiated stream that has not yet been created MUST be locally-initiated stream that has not yet been created MUST be
skipping to change at page 133, line 17 skipping to change at page 133, line 45
present. When set to 0, the Offset field is absent and the Stream present. When set to 0, the Offset field is absent and the Stream
Data starts at an offset of 0 (that is, the frame contains the Data starts at an offset of 0 (that is, the frame contains the
first bytes of the stream, or the end of a stream that includes no first bytes of the stream, or the end of a stream that includes no
data). data).
* The LEN bit (0x02) in the frame type is set to indicate that there * The LEN bit (0x02) in the frame type is set to indicate that there
is a Length field present. If this bit is set to 0, the Length is a Length field present. If this bit is set to 0, the Length
field is absent and the Stream Data field extends to the end of field is absent and the Stream Data field extends to the end of
the packet. If this bit is set to 1, the Length field is present. the packet. If this bit is set to 1, the Length field is present.
* The FIN bit (0x01) of the frame type is set only on frames that * The FIN bit (0x01) indicates that the frame marks the end of the
contain the final size of the stream. Setting this bit indicates stream. The final size of the stream is the sum of the offset and
that the frame marks the end of the stream. the length of this frame.
An endpoint MUST terminate the connection with error An endpoint MUST terminate the connection with error
STREAM_STATE_ERROR if it receives a STREAM frame for a locally- STREAM_STATE_ERROR if it receives a STREAM frame for a locally-
initiated stream that has not yet been created, or for a send-only initiated stream that has not yet been created, or for a send-only
stream. stream.
STREAM frames are formatted as shown in Figure 32. STREAM frames are formatted as shown in Figure 32.
STREAM Frame { STREAM Frame {
Type (i) = 0x08..0x0f, Type (i) = 0x08..0x0f,
skipping to change at page 134, line 39 skipping to change at page 135, line 27
Figure 33: MAX_DATA Frame Format Figure 33: MAX_DATA Frame Format
MAX_DATA frames contain the following field: MAX_DATA frames contain the following field:
Maximum Data: A variable-length integer indicating the maximum Maximum Data: A variable-length integer indicating the maximum
amount of data that can be sent on the entire connection, in units amount of data that can be sent on the entire connection, in units
of bytes. of bytes.
All data sent in STREAM frames counts toward this limit. The sum of All data sent in STREAM frames counts toward this limit. The sum of
the largest received offsets on all streams - including streams in the final sizes on all streams - including streams in terminal states
terminal states - MUST NOT exceed the value advertised by a receiver. - MUST NOT exceed the value advertised by a receiver. An endpoint
An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR MUST terminate a connection with a FLOW_CONTROL_ERROR error if it
error if it receives more data than the maximum data value that it receives more data than the maximum data value that it has sent.
has sent. This includes violations of remembered limits in Early This includes violations of remembered limits in Early Data; see
Data; see Section 7.4.1. Section 7.4.1.
19.10. MAX_STREAM_DATA Frames 19.10. MAX_STREAM_DATA Frames
A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform
a peer of the maximum amount of data that can be sent on a stream. a peer of the maximum amount of data that can be sent on a stream.
A MAX_STREAM_DATA frame can be sent for streams in the Recv state; A MAX_STREAM_DATA frame can be sent for streams in the Recv state;
see Section 3.1. Receiving a MAX_STREAM_DATA frame for a locally- see Section 3.1. Receiving a MAX_STREAM_DATA frame for a locally-
initiated stream that has not yet been created MUST be treated as a initiated stream that has not yet been created MUST be treated as a
connection error of type STREAM_STATE_ERROR. An endpoint that connection error of type STREAM_STATE_ERROR. An endpoint that
skipping to change at page 139, line 38 skipping to change at page 140, line 26
error. A receiver can use the sequence number supplied in the error. A receiver can use the sequence number supplied in the
NEW_CONNECTION_ID frame to handle receiving the same NEW_CONNECTION_ID frame to handle receiving the same
NEW_CONNECTION_ID frame multiple times. NEW_CONNECTION_ID frame multiple times.
If an endpoint receives a NEW_CONNECTION_ID frame that repeats a If an endpoint receives a NEW_CONNECTION_ID frame that repeats a
previously issued connection ID with a different Stateless Reset previously issued connection ID with a different Stateless Reset
Token or a different sequence number, or if a sequence number is used Token or a different sequence number, or if a sequence number is used
for different connection IDs, the endpoint MAY treat that receipt as for different connection IDs, the endpoint MAY treat that receipt as
a connection error of type PROTOCOL_VIOLATION. a connection error of type PROTOCOL_VIOLATION.
The Retire Prior To field counts connection IDs established during The Retire Prior To field applies to connection IDs established
connection setup and the preferred_address transport parameter; see during connection setup and the preferred_address transport
Section 5.1.2. The Retire Prior To field MUST be less than or equal parameter; see Section 5.1.2. The Retire Prior To field MUST be less
to the Sequence Number field. Receiving a value greater than the than or equal to the Sequence Number field. Receiving a value
Sequence Number MUST be treated as a connection error of type greater than the Sequence Number MUST be treated as a connection
FRAME_ENCODING_ERROR. error of type FRAME_ENCODING_ERROR.
Once a sender indicates a Retire Prior To value, smaller values sent Once a sender indicates a Retire Prior To value, smaller values sent
in subsequent NEW_CONNECTION_ID frames have no effect. A receiver in subsequent NEW_CONNECTION_ID frames have no effect. A receiver
MUST ignore any Retire Prior To fields that do not increase the MUST ignore any Retire Prior To fields that do not increase the
largest received Retire Prior To value. largest received Retire Prior To value.
An endpoint that receives a NEW_CONNECTION_ID frame with a sequence An endpoint that receives a NEW_CONNECTION_ID frame with a sequence
number smaller than the Retire Prior To field of a previously number smaller than the Retire Prior To field of a previously
received NEW_CONNECTION_ID frame MUST send a corresponding received NEW_CONNECTION_ID frame MUST send a corresponding
RETIRE_CONNECTION_ID frame that retires the newly received connection RETIRE_CONNECTION_ID frame that retires the newly received connection
skipping to change at page 143, line 6 skipping to change at page 143, line 40
length of the reason phrase in bytes. Because a CONNECTION_CLOSE length of the reason phrase in bytes. Because a CONNECTION_CLOSE
frame cannot be split between packets, any limits on packet size frame cannot be split between packets, any limits on packet size
will also limit the space available for a reason phrase. will also limit the space available for a reason phrase.
Reason Phrase: A human-readable explanation for why the connection Reason Phrase: A human-readable explanation for why the connection
was closed. This can be zero length if the sender chooses not to was closed. This can be zero length if the sender chooses not to
give details beyond the Error Code. This SHOULD be a UTF-8 give details beyond the Error Code. This SHOULD be a UTF-8
encoded string [RFC3629]. encoded string [RFC3629].
The application-specific variant of CONNECTION_CLOSE (type 0x1d) can The application-specific variant of CONNECTION_CLOSE (type 0x1d) can
only be sent using 0-RTT or 1-RTT packets; see Section 4 of only be sent using 0-RTT or 1-RTT packets; see Section 12.5. When an
[QUIC-TLS]. When an application wishes to abandon a connection application wishes to abandon a connection during the handshake, an
during the handshake, an endpoint can send a CONNECTION_CLOSE frame endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error
(type 0x1c) with an error code of APPLICATION_ERROR in an Initial or code of APPLICATION_ERROR in an Initial or a Handshake packet.
a Handshake packet.
19.20. HANDSHAKE_DONE Frames 19.20. HANDSHAKE_DONE Frames
The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal The server uses a HANDSHAKE_DONE frame (type=0x1e) to signal
confirmation of the handshake to the client. confirmation of the handshake to the client.
HANDSHAKE_DONE frames are formatted as shown in Figure 44, which HANDSHAKE_DONE frames are formatted as shown in Figure 44, which
shows that HANDSHAKE_DONE frames have no content. shows that HANDSHAKE_DONE frames have no content.
HANDSHAKE_DONE Frame { HANDSHAKE_DONE Frame {
skipping to change at page 145, line 30 skipping to change at page 146, line 18
INVALID_TOKEN (0xb): A server received a client Initial that INVALID_TOKEN (0xb): A server received a client Initial that
contained an invalid Token field. contained an invalid Token field.
APPLICATION_ERROR (0xc): The application or application protocol APPLICATION_ERROR (0xc): The application or application protocol
caused the connection to be closed. caused the connection to be closed.
CRYPTO_BUFFER_EXCEEDED (0xd): An endpoint has received more data in CRYPTO_BUFFER_EXCEEDED (0xd): An endpoint has received more data in
CRYPTO frames than it can buffer. CRYPTO frames than it can buffer.
AEAD_LIMIT_REACHED (0xe): An endpoint has reached the KEY_UPDATE_ERROR (0xe): An endpoint detected errors in performing
key updates; see Section 6 of [QUIC-TLS].
AEAD_LIMIT_REACHED (0xf): An endpoint has reached the
confidentiality or integrity limit for the AEAD algorithm used by confidentiality or integrity limit for the AEAD algorithm used by
the given connection. the given connection.
CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range
of 256 values is reserved for carrying error codes specific to the of 256 values is reserved for carrying error codes specific to the
cryptographic handshake that is used. Codes for errors occurring cryptographic handshake that is used. Codes for errors occurring
when TLS is used for the crypto handshake are described in when TLS is used for the crypto handshake are described in
Section 4.8 of [QUIC-TLS]. Section 4.8 of [QUIC-TLS].
See Section 22.4 for details of registering new error codes. See Section 22.4 for details of registering new error codes.
skipping to change at page 148, line 45 skipping to change at page 149, line 34
This section discusses ways in which QUIC might be used for request This section discusses ways in which QUIC might be used for request
forgery attacks. forgery attacks.
This section also describes limited countermeasures that can be This section also describes limited countermeasures that can be
implemented by QUIC endpoints. These mitigations can be employed implemented by QUIC endpoints. These mitigations can be employed
unilaterally by a QUIC implementation or deployment, without unilaterally by a QUIC implementation or deployment, without
potential targets for request forgery attacks taking action. However potential targets for request forgery attacks taking action. However
these countermeasures could be insufficient if UDP-based services do these countermeasures could be insufficient if UDP-based services do
not properly authorize requests. not properly authorize requests.
Because the migration attack described in Section 21.4.4 is quite
powerful and does not have adequate countermeasures, QUIC server
implementations should assume that attackers can cause them to
generate arbitrary UDP payloads to arbitrary destinations. QUIC
servers SHOULD NOT be deployed in networks that also have
inadequately secured UDP endpoints.
Although it is not generally possible to ensure that clients are not
co-located with vulnerable endpoints, this version of QUIC does not
allow servers to migrate, thus preventing spoofed migration attacks
on clients. Any future extension which allows server migration MUST
also define countermeasures for forgery attacks.
21.4.1. Control Options for Endpoints 21.4.1. Control Options for Endpoints
QUIC offers some opportunities for an attacker to influence or QUIC offers some opportunities for an attacker to influence or
control where its peer sends UDP datagrams: control where its peer sends UDP datagrams:
* initial connection establishment (Section 7), where a server is * initial connection establishment (Section 7), where a server is
able to choose where a client sends datagrams, for example by able to choose where a client sends datagrams, for example by
populating DNS records; populating DNS records;
* preferred addresses (Section 9.6), where a server is able to * preferred addresses (Section 9.6), where a server is able to
skipping to change at page 150, line 21 skipping to change at page 151, line 31
However, the Token field is open to server control and does allow a However, the Token field is open to server control and does allow a
server to use clients to mount request forgery attacks. Use of server to use clients to mount request forgery attacks. Use of
tokens provided with the NEW_TOKEN frame (Section 8.1.3) offers the tokens provided with the NEW_TOKEN frame (Section 8.1.3) offers the
only option for request forgery during connection establishment. only option for request forgery during connection establishment.
Clients however are not obligated to use the NEW_TOKEN frame. Clients however are not obligated to use the NEW_TOKEN frame.
Request forgery attacks that rely on the Token field can be avoided Request forgery attacks that rely on the Token field can be avoided
if clients send an empty Token field when the server address has if clients send an empty Token field when the server address has
changed from when the NEW_TOKEN frame was received. changed from when the NEW_TOKEN frame was received.
Therefore, clients SHOULD NOT send a token received in a NEW_TOKEN Clients could avoid using NEW_TOKEN if the server address changes.
frame from one server address in an Initial packet that is sent to a However, not including a Token field could adversely affect
different server address. As strict equality might reduce the performance. Servers could rely on NEW_TOKEN to enable sending of
utility of this mechanism, clients MAY employ heuristics that result data in excess of the three times limit on sending data; see
in different server addresses being treated as equivalent, such as Section 8.1. In particular, this affects cases where clients use
treating addresses with a shared prefix of sufficient length as being 0-RTT to request data from servers.
functionally equivalent (for instance, /24 in IPv4 or /56 in IPv6).
In addition, clients SHOULD treat a preferred address that is
successfully validated as equivalent to the address on which the
connection was made; see Section 9.6.
Sending a Retry packet (Section 17.2.5) offers a server the option to Sending a Retry packet (Section 17.2.5) offers a server the option to
change the Token field. After sending a Retry, the server can also change the Token field. After sending a Retry, the server can also
control the Destination Connection ID field of subsequent Initial control the Destination Connection ID field of subsequent Initial
packets from the client. This also might allow indirect control over packets from the client. This also might allow indirect control over
the encrypted content of Initial packets. However, the exchange of a the encrypted content of Initial packets. However, the exchange of a
Retry packet validates the server's address, thereby preventing the Retry packet validates the server's address, thereby preventing the
use of subsequent Initial packets for request forgery. use of subsequent Initial packets for request forgery.
21.4.3. Request Forgery with Preferred Addresses 21.4.3. Request Forgery with Preferred Addresses
skipping to change at page 151, line 45 skipping to change at page 152, line 50
21.4.5. Generic Request Forgery Countermeasures 21.4.5. Generic Request Forgery Countermeasures
The most effective defense against request forgery attacks is to The most effective defense against request forgery attacks is to
modify vulnerable services to use strong authentication. However, modify vulnerable services to use strong authentication. However,
this is not always something that is within the control of a QUIC this is not always something that is within the control of a QUIC
deployment. This section outlines some others steps that QUIC deployment. This section outlines some others steps that QUIC
endpoints could take unilaterally. These additional steps are all endpoints could take unilaterally. These additional steps are all
discretionary as, depending on circumstances, they could interfere discretionary as, depending on circumstances, they could interfere
with or prevent legitimate uses. with or prevent legitimate uses.
Services offered over loopback interfaces (that is, the IPv6 address Services offered over loopback interfaces often lack proper
::1 or the IPv4 address 127.0.0.1) often lack proper authentication. authentication. Endpoints MAY prevent connection attempts or
Endpoints MAY prevent connection attempts or migration to a loopback migration to a loopback address. Endpoints SHOULD NOT allow
address. Endpoints SHOULD NOT allow connections or migration to a connections or migration to a loopback address if the same service
loopback address if the same service was previously available at a was previously available at a different interface or if the address
different interface or if the address was provided by a service at a was provided by a service at a non-loopback address. Endpoints that
non-loopback address. Endpoints that depend on these capabilities depend on these capabilities could offer an option to disable these
could offer an option to disable these protections. protections.
Similarly, endpoints could regard a change in address to link-local Similarly, endpoints could regard a change in address to link-local
address [RFC4291] or an address in a private use range [RFC1918] from address [RFC4291] or an address in a private use range [RFC1918] from
a global, unique-local [RFC4193], or non-private address as a a global, unique-local [RFC4193], or non-private address as a
potential attempt at request forgery. Endpoints could refuse to use potential attempt at request forgery. Endpoints could refuse to use
these addresses entirely, but that carries a significant risk of these addresses entirely, but that carries a significant risk of
interfering with legitimate uses. Endpoints SHOULD NOT refuse to use interfering with legitimate uses. Endpoints SHOULD NOT refuse to use
an address unless they have specific knowledge about the network an address unless they have specific knowledge about the network
indicating that sending datagrams to unvalidated addresses in a given indicating that sending datagrams to unvalidated addresses in a given
range is not safe. range is not safe.
skipping to change at page 153, line 7 skipping to change at page 154, line 14
QUIC deployments SHOULD provide mitigations for the Slowloris QUIC deployments SHOULD provide mitigations for the Slowloris
attacks, such as increasing the maximum number of clients the server attacks, such as increasing the maximum number of clients the server
will allow, limiting the number of connections a single IP address is will allow, limiting the number of connections a single IP address is
allowed to make, imposing restrictions on the minimum transfer speed allowed to make, imposing restrictions on the minimum transfer speed
a connection is allowed to have, and restricting the length of time a connection is allowed to have, and restricting the length of time
an endpoint is allowed to stay connected. an endpoint is allowed to stay connected.
21.6. Stream Fragmentation and Reassembly Attacks 21.6. Stream Fragmentation and Reassembly Attacks
An adversarial sender might intentionally send fragments of stream An adversarial sender might intentionally not send portions of the
data in an attempt to cause disproportionate receive buffer memory stream data, causing the receiver to commit resources for the unsent
commitment and/or creation of a large and inefficient data structure. data. This could cause a disproportionate receive buffer memory
commitment and/or the creation of a large and inefficient data
structure at the receiver.
An adversarial receiver might intentionally not acknowledge packets An adversarial receiver might intentionally not acknowledge packets
containing stream data in an attempt to force the sender to store the containing stream data in an attempt to force the sender to store the
unacknowledged stream data for retransmission. unacknowledged stream data for retransmission.
The attack on receivers is mitigated if flow control windows The attack on receivers is mitigated if flow control windows
correspond to available memory. However, some receivers will over- correspond to available memory. However, some receivers will over-
commit memory and advertise flow control offsets in the aggregate commit memory and advertise flow control offsets in the aggregate
that exceed actual available memory. The over-commitment strategy that exceed actual available memory. The over-commitment strategy
can lead to better performance when endpoints are well behaved, but can lead to better performance when endpoints are well behaved, but
skipping to change at page 153, line 46 skipping to change at page 155, line 7
Section 2.1. However, when several streams are initiated at short Section 2.1. However, when several streams are initiated at short
intervals, loss or reordering may cause STREAM frames that open intervals, loss or reordering may cause STREAM frames that open
streams to be received out of sequence. On receiving a higher- streams to be received out of sequence. On receiving a higher-
numbered stream ID, a receiver is required to open all intervening numbered stream ID, a receiver is required to open all intervening
streams of the same type; see Section 3.2. Thus, on a new streams of the same type; see Section 3.2. Thus, on a new
connection, opening stream 4000000 opens 1 million and 1 client- connection, opening stream 4000000 opens 1 million and 1 client-
initiated bidirectional streams. initiated bidirectional streams.
The number of active streams is limited by the The number of active streams is limited by the
initial_max_streams_bidi and initial_max_streams_uni transport initial_max_streams_bidi and initial_max_streams_uni transport
parameters, as explained in Section 4.5. If chosen judiciously, parameters, as explained in Section 4.6. If chosen judiciously,
these limits mitigate the effect of the stream commitment attack. these limits mitigate the effect of the stream commitment attack.
However, setting the limit too low could affect performance when However, setting the limit too low could affect performance when
applications expect to open large number of streams. applications expect to open large number of streams.
21.8. Peer Denial of Service 21.8. Peer Denial of Service
QUIC and TLS both contain frames or messages that have legitimate QUIC and TLS both contain frames or messages that have legitimate
uses in some contexts, but that can be abused to cause a peer to uses in some contexts, but that can be abused to cause a peer to
expend processing resources without having any observable impact on expend processing resources without having any observable impact on
the state of the connection. the state of the connection.
skipping to change at page 154, line 28 skipping to change at page 155, line 35
malicious peer to exhaust processing capacity. malicious peer to exhaust processing capacity.
While there are legitimate uses for all messages, implementations While there are legitimate uses for all messages, implementations
SHOULD track cost of processing relative to progress and treat SHOULD track cost of processing relative to progress and treat
excessive quantities of any non-productive packets as indicative of excessive quantities of any non-productive packets as indicative of
an attack. Endpoints MAY respond to this condition with a connection an attack. Endpoints MAY respond to this condition with a connection
error, or by dropping packets. error, or by dropping packets.
21.9. Explicit Congestion Notification Attacks 21.9. Explicit Congestion Notification Attacks
An on-path attacker could manipulate the value of ECN codepoints in An on-path attacker could manipulate the value of ECN fields in the
the IP header to influence the sender's rate. [RFC3168] discusses IP header to influence the sender's rate. [RFC3168] discusses
manipulations and their effects in more detail. manipulations and their effects in more detail.
An on-the-side attacker can duplicate and send packets with modified An on-the-side attacker can duplicate and send packets with modified
ECN codepoints to affect the sender's rate. If duplicate packets are ECN fields to affect the sender's rate. If duplicate packets are
discarded by a receiver, an off-path attacker will need to race the discarded by a receiver, an off-path attacker will need to race the
duplicate packet against the original to be successful in this duplicate packet against the original to be successful in this
attack. Therefore, QUIC endpoints ignore the ECN codepoint field on attack. Therefore, QUIC endpoints ignore the ECN field on an IP
an IP packet unless at least one QUIC packet in that IP packet is packet unless at least one QUIC packet in that IP packet is
successfully processed; see Section 13.4. successfully processed; see Section 13.4.
21.10. Stateless Reset Oracle 21.10. Stateless Reset Oracle
Stateless resets create a possible denial of service attack analogous Stateless resets create a possible denial of service attack analogous
to a TCP reset injection. This attack is possible if an attacker is to a TCP reset injection. This attack is possible if an attacker is
able to cause a stateless reset token to be generated for a able to cause a stateless reset token to be generated for a
connection with a selected connection ID. An attacker that can cause connection with a selected connection ID. An attacker that can cause
this token to be generated can reset an active connection with the this token to be generated can reset an active connection with the
same connection ID. same connection ID.
skipping to change at page 169, line 6 skipping to change at page 170, line 6
in this registry MUST include the following fields: in this registry MUST include the following fields:
Code: A short mnemonic for the parameter. Code: A short mnemonic for the parameter.
Description: A brief description of the error code semantics, which Description: A brief description of the error code semantics, which
MAY be a summary if a specification reference is provided. MAY be a summary if a specification reference is provided.
The initial contents of this registry are shown in Table 7. The initial contents of this registry are shown in Table 7.
+======+===========================+================+===============+ +======+===========================+================+===============+
|Value | Error | Description | Specification | |Value | Error |Description | Specification |
+======+===========================+================+===============+ +======+===========================+================+===============+
| 0x0 | NO_ERROR | No error | Section 20 | |0x0 | NO_ERROR |No error | Section 20 |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x1 | INTERNAL_ERROR | Implementation | Section 20 | |0x1 | INTERNAL_ERROR |Implementation | Section 20 |
| | | error | | | | |error | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x2 | CONNECTION_REFUSED |Server refuses a| Section 20 | |0x2 | CONNECTION_REFUSED |Server refuses a| Section 20 |
| | | connection | | | | |connection | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x3 | FLOW_CONTROL_ERROR | Flow control | Section 20 | |0x3 | FLOW_CONTROL_ERROR |Flow control | Section 20 |
| | | error | | | | |error | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x4 | STREAM_LIMIT_ERROR |Too many streams| Section 20 | |0x4 | STREAM_LIMIT_ERROR |Too many streams| Section 20 |
| | | opened | | | | |opened | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x5 | STREAM_STATE_ERROR | Frame received | Section 20 | |0x5 | STREAM_STATE_ERROR |Frame received | Section 20 |
| | | in invalid | | | | |in invalid | |
| | | stream state | | | | |stream state | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x6 | FINAL_SIZE_ERROR |Change to final | Section 20 | |0x6 | FINAL_SIZE_ERROR |Change to final | Section 20 |
| | | size | | | | |size | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | |0x7 | FRAME_ENCODING_ERROR |Frame encoding | Section 20 |
| | | error | | | | |error | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | |0x8 | TRANSPORT_PARAMETER_ERROR |Error in | Section 20 |
| | | transport | | | | |transport | |
| | | parameters | | | | |parameters | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0x9 | CONNECTION_ID_LIMIT_ERROR | Too many | Section 20 | |0x9 | CONNECTION_ID_LIMIT_ERROR |Too many | Section 20 |
| | | connection IDs | | | | |connection IDs | |
| | | received | | | | |received | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xa | PROTOCOL_VIOLATION |Generic protocol| Section 20 | |0xa | PROTOCOL_VIOLATION |Generic protocol| Section 20 |
| | | violation | | | | |violation | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xb | INVALID_TOKEN | Invalid Token | Section 20 | |0xb | INVALID_TOKEN |Invalid Token | Section 20 |
| | | Received | | | | |Received | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xc | APPLICATION_ERROR | Application | Section 20 | |0xc | APPLICATION_ERROR |Application | Section 20 |
| | | error | | | | |error | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
| 0xd | CRYPTO_BUFFER_EXCEEDED | CRYPTO data | Section 20 | |0xd | CRYPTO_BUFFER_EXCEEDED |CRYPTO data | Section 20 |
| | | buffer | | | | |buffer | |
| | | overflowed | | | | |overflowed | |
+------+---------------------------+----------------+---------------+
|0xe | KEY_UPDATE_ERROR |Invalid packet | Section 20 |
| | |protection | |
| | |update | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
|0xf | AEAD_LIMIT_REACHED |Excessive use of| Section 20 |
| | |packet | |
| | |protection keys | |
+------+---------------------------+----------------+---------------+
Table 7: Initial QUIC Transport Error Codes Entries Table 7: Initial QUIC Transport Error Codes Entries
23. References 23. References
23.1. Normative References 23.1. Normative References
[DPLPMTUD] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and [DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
T. Voelker, "Packetization Layer Path MTU Discovery for Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", Work in Progress, Internet-Draft, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
draft-ietf-tsvwg-datagram-plpmtud-22, June 10, 2020, September 2020, <https://www.rfc-editor.org/info/rfc8899>.
<http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-
datagram-plpmtud-22.txt>.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", Work in Progress, Internet-Draft, and Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-30, September 10, 2020, draft-ietf-quic-recovery-31, 25 September 2020,
<https://tools.ietf.org/html/draft-ietf-quic-recovery-30>. <https://tools.ietf.org/html/draft-ietf-quic-recovery-31>.
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", Work in Progress, Layer Security (TLS) to Secure QUIC", Work in Progress,
Internet-Draft, draft-ietf-quic-tls-30, September 10, Internet-Draft, draft-ietf-quic-tls-31, 25 September 2020,
2020, <https://tools.ietf.org/html/draft-ietf-quic-tls-31>.
<https://tools.ietf.org/html/draft-ietf-quic-tls-30>.
[RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery", [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
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>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
skipping to change at page 172, line 16 skipping to change at page 173, line 20
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", RFC 2267, DOI 10.17487/RFC2267, January Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
1998, <https://www.rfc-editor.org/info/rfc2267>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust defenses [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust defenses
for cross-site request forgery", for cross-site request forgery", Proceedings of the 15th
DOI 10.1145/1455770.1455782, Proceedings of the 15th ACM ACM conference on Computer and communications security -
conference on Computer and communications security - CCS '08, DOI 10.1145/1455770.1455782, 2008,
CCS '08, 2008, <https://doi.org/10.1145/1455770.1455782>. <https://doi.org/10.1145/1455770.1455782>.
[EARLY-DESIGN] [EARLY-DESIGN]
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP", 2
December 2, 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[GATEWAY] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S., [GATEWAY] Hätönen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
Sarolahti, P., and M. Kojo, "An experimental study of home Sarolahti, P., and M. Kojo, "An experimental study of home
gateway characteristics", DOI 10.1145/1879141.1879174, gateway characteristics", Proceedings of the 10th annual
Proceedings of the 10th annual conference on Internet conference on Internet measurement - IMC '10,
measurement - IMC '10, 2010, DOI 10.1145/1879141.1879174, 2010,
<https://doi.org/10.1145/1879141.1879174>. <https://doi.org/10.1145/1879141.1879174>.
[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>.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic- Work in Progress, Internet-Draft, draft-ietf-quic-
invariants-10, September 10, 2020, invariants-11, 25 September 2020,
<https://tools.ietf.org/html/draft-ietf-quic-invariants- <https://tools.ietf.org/html/draft-ietf-quic-invariants-
10>. 11>.
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-07, July 8, 2020, draft-ietf-quic-manageability-07, 8 July 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic- <http://www.ietf.org/internet-drafts/draft-ietf-quic-
manageability-07.txt>. manageability-07.txt>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
skipping to change at page 174, line 19 skipping to change at page 175, line 25
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
"Transport Layer Security (TLS) Application-Layer Protocol Explicit Congestion Notification (ECN)", RFC 8087,
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, DOI 10.17487/RFC8087, March 2017,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. <https://www.rfc-editor.org/info/rfc8087>.
[SEC-CONS] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [SEC-CONS] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[SLOWLORIS] [SLOWLORIS]
RSnake Hansen, R., "Welcome to Slowloris...", June 2009, RSnake Hansen, R., "Welcome to Slowloris...", June 2009,
<https://web.archive.org/web/20150315054838/ <https://web.archive.org/web/20150315054838/
http://ha.ckers.org/slowloris/>. http://ha.ckers.org/slowloris/>.
skipping to change at page 176, line 5 skipping to change at page 177, line 5
support. Endpoints can implement different methods. support. Endpoints can implement different methods.
The path is assigned an ECN state that is one of "testing", The path is assigned an ECN state that is one of "testing",
"unknown", "failed", or "capable". On paths with a "testing" or "unknown", "failed", or "capable". On paths with a "testing" or
"capable" state the endpoint sends packets with an ECT marking, by "capable" state the endpoint sends packets with an ECT marking, by
default ECT(0); otherwise, the endpoint sends unmarked packets. default ECT(0); otherwise, the endpoint sends unmarked packets.
To start testing a path, the ECN state is set to "testing" and To start testing a path, the ECN state is set to "testing" and
existing ECN counts are remembered as a baseline. existing ECN counts are remembered as a baseline.
The testing period runs for a number of packets or round-trip times, The testing period runs for a number of packets or a limited time, as
as determined by the endpoint. The goal is not to limit the duration determined by the endpoint. The goal is not to limit the duration of
of the testing period, but to ensure that enough marked packets are the testing period, but to ensure that enough marked packets are sent
sent for received ECN counts to provide a clear indication of how the for received ECN counts to provide a clear indication of how the path
path treats marked packets. Section 13.4.2.2 suggests limiting this treats marked packets. Section 13.4.2 suggests limiting this to 10
to 10 packets or 3 round-trip times. packets or 3 times the probe timeout.
After the testing period ends, the ECN state for the path becomes After the testing period ends, the ECN state for the path becomes
"unknown". From the "unknown" state, successful validation of the "unknown". From the "unknown" state, successful validation of the
ECN counts an ACK frame (see Section 13.4.2.2) causes the ECN state ECN counts an ACK frame (see Section 13.4.2.1) causes the ECN state
for the path to become "capable", unless no marked packet has been for the path to become "capable", unless no marked packet has been
acknowledged. acknowledged.
If validation of ECN counts fails at any time, the ECN state for the If validation of ECN counts fails at any time, the ECN state for the
affected path becomes "failed". An endpoint can also mark the ECN affected path becomes "failed". An endpoint can also mark the ECN
state for a path as "failed" if marked packets are all declared lost state for a path as "failed" if marked packets are all declared lost
or if they are all CE marked. or if they are all CE marked.
Following this algorithm ensures that ECN is rarely disabled for Following this algorithm ensures that ECN is rarely disabled for
paths that properly support ECN. Any path that incorrectly modifies paths that properly support ECN. Any path that incorrectly modifies
skipping to change at page 176, line 36 skipping to change at page 177, line 36
marked packets are discarded by the path, the short duration of the marked packets are discarded by the path, the short duration of the
testing period limits the number of losses incurred. testing period limits the number of losses incurred.
Appendix C. Change Log Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-transport-29 C.1. Since draft-ietf-quic-transport-30
* Require the same connection ID on coalesced packets (#3800, #3930) * Use TRANSPORT_PARAMETER_ERROR for an invalid transport parameter
(#4099, #4100)
* Add a new error code for AEAD_LIMIT_REACHED code to avoid conflict
(#4087, #4088)
* Allow use of address validation token when server address changes
(#4076, #4089)
C.2. Since draft-ietf-quic-transport-29
* Require the same connection ID on coalesced packets (#3800, #3930)
* Allow caching of packets that can't be decrypted, by allowing the * Allow caching of packets that can't be decrypted, by allowing the
reported acknowledgment delay to exceed max_ack_delay prior to reported acknowledgment delay to exceed max_ack_delay prior to
confirming the handshake (#3821, #3980, #4035, #3874) confirming the handshake (#3821, #3980, #4035, #3874)
* Allow connection ID to be used for address validation (#3834, * Allow connection ID to be used for address validation (#3834,
#3924) #3924)
* Required protocol operations are no longer directed at * Required protocol operations are no longer directed at
implementations, but are features provided to application implementations, but are features provided to application
protocols (#3838, #3935) protocols (#3838, #3935)
skipping to change at page 177, line 20 skipping to change at page 178, line 33
* Recommend retention of state for lost packets to allow for late * Recommend retention of state for lost packets to allow for late
arrival and avoid unnecessary retransmission (#3956, #3957) arrival and avoid unnecessary retransmission (#3956, #3957)
* Allow a server to reject connections if a client reuses packet * Allow a server to reject connections if a client reuses packet
numbers after Retry (#3989, #3990) numbers after Retry (#3989, #3990)
* Limit recommendation for immediate acknowledgment to when ack- * Limit recommendation for immediate acknowledgment to when ack-
eliciting packets are reordered (#4001, #4000) eliciting packets are reordered (#4001, #4000)
C.2. Since draft-ietf-quic-transport-28 C.3. Since draft-ietf-quic-transport-28
* Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED * Made SERVER_BUSY error (0x2) more generic, now CONNECTION_REFUSED
(#3709, #3690, #3694) (#3709, #3690, #3694)
* Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs * Allow TRANSPORT_PARAMETER_ERROR when validating connection IDs
(#3703, #3691) (#3703, #3691)
* Integrate QUIC-specific language from draft-ietf-tsvwg-datagram- * Integrate QUIC-specific language from draft-ietf-tsvwg-datagram-
plpmtud (#3695, #3702) plpmtud (#3695, #3702)
* disable_active_migration does not apply to the addresses offered * disable_active_migration does not apply to the addresses offered
in server_preferred_address (#3608, #3670) in server_preferred_address (#3608, #3670)
C.3. Since draft-ietf-quic-transport-27 C.4. Since draft-ietf-quic-transport-27
* Allowed CONNECTION_CLOSE in any packet number space, with a * Allowed CONNECTION_CLOSE in any packet number space, with a
requirement to use a new transport-level error for application- requirement to use a new transport-level error for application-
specific errors in Initial and Handshake packets (#3430, #3435, specific errors in Initial and Handshake packets (#3430, #3435,
#3440) #3440)
* Clearer requirements for address validation (#2125, #3327) * Clearer requirements for address validation (#2125, #3327)
* Security analysis of handshake and migration (#2143, #2387, #2925) * Security analysis of handshake and migration (#2143, #2387, #2925)
* The entire payload of a datagram is used when counting bytes for * The entire payload of a datagram is used when counting bytes for
skipping to change at page 178, line 34 skipping to change at page 180, line 5
* Clarified that largest acknowledged needs to be saved, but not * Clarified that largest acknowledged needs to be saved, but not
necessarily signaled in all cases (#3541, #3581) necessarily signaled in all cases (#3541, #3581)
* Addressed linkability risk with the use of preferred_address * Addressed linkability risk with the use of preferred_address
(#3559, #3563) (#3559, #3563)
* Added authentication of handshake connection IDs (#3439, #3499) * Added authentication of handshake connection IDs (#3439, #3499)
* Opening a stream in the wrong direction is an error (#3527) * Opening a stream in the wrong direction is an error (#3527)
C.4. Since draft-ietf-quic-transport-26 C.5. Since draft-ietf-quic-transport-26
* Change format of transport parameters to use varints (#3294, * Change format of transport parameters to use varints (#3294,
#3169) #3169)
C.5. Since draft-ietf-quic-transport-25 C.6. Since draft-ietf-quic-transport-25
* Define the use of CONNECTION_CLOSE prior to establishing * Define the use of CONNECTION_CLOSE prior to establishing
connection state (#3269, #3297, #3292) connection state (#3269, #3297, #3292)
* Allow use of address validation tokens after client address * Allow use of address validation tokens after client address
changes (#3307, #3308) changes (#3307, #3308)
* Define the timer for address validation (#2910, #3339) * Define the timer for address validation (#2910, #3339)
C.6. Since draft-ietf-quic-transport-24 C.7. Since draft-ietf-quic-transport-24
* Added HANDSHAKE_DONE to signal handshake confirmation (#2863, * Added HANDSHAKE_DONE to signal handshake confirmation (#2863,
#3142, #3145) #3142, #3145)
* Add integrity check to Retry packets (#3014, #3274, #3120) * Add integrity check to Retry packets (#3014, #3274, #3120)
* Specify handling of reordered NEW_CONNECTION_ID frames (#3194, * Specify handling of reordered NEW_CONNECTION_ID frames (#3194,
#3202) #3202)
* Require checking of sequence numbers in RETIRE_CONNECTION_ID * Require checking of sequence numbers in RETIRE_CONNECTION_ID
skipping to change at page 180, line 5 skipping to change at page 181, line 25
* Idle timeout is symmetric (#2602, #3099) * Idle timeout is symmetric (#2602, #3099)
* Prohibit IP fragmentation (#3243, #3280) * Prohibit IP fragmentation (#3243, #3280)
* Define the use of provisional registration for all registries * Define the use of provisional registration for all registries
(#3109, #3020, #3102, #3170) (#3109, #3020, #3102, #3170)
* Packets on one path must not adjust values for a different path * Packets on one path must not adjust values for a different path
(#2909, #3139) (#2909, #3139)
C.7. Since draft-ietf-quic-transport-23 C.8. Since draft-ietf-quic-transport-23
* Allow ClientHello to span multiple packets (#2928, #3045) * Allow ClientHello to span multiple packets (#2928, #3045)
* Client Initial size constraints apply to UDP datagram payload * Client Initial size constraints apply to UDP datagram payload
(#3053, #3051) (#3053, #3051)
* Stateless reset changes (#2152, #2993) * Stateless reset changes (#2152, #2993)
- tokens need to be compared in constant time - tokens need to be compared in constant time
skipping to change at page 180, line 33 skipping to change at page 182, line 4
* A new connection ID is necessary when responding to migration * A new connection ID is necessary when responding to migration
(#2778, #2969) (#2778, #2969)
* Stronger requirements for connection ID retirement (#3046, #3096) * Stronger requirements for connection ID retirement (#3046, #3096)
* NEW_TOKEN cannot be empty (#2978, #2977) * NEW_TOKEN cannot be empty (#2978, #2977)
* PING can be sent at any encryption level (#3034, #3035) * PING can be sent at any encryption level (#3034, #3035)
* CONNECTION_CLOSE is not ack-eliciting (#3097, #3098) * CONNECTION_CLOSE is not ack-eliciting (#3097, #3098)
* Frame encoding error conditions updated (#3027, #3042) * Frame encoding error conditions updated (#3027, #3042)
* Non-ack-eliciting packets cannot be sent in response to non-ack- * Non-ack-eliciting packets cannot be sent in response to non-ack-
eliciting packets (#3100, #3104) eliciting packets (#3100, #3104)
* Servers have to change connection IDs in Retry (#2837, #3147) * Servers have to change connection IDs in Retry (#2837, #3147)
C.8. Since draft-ietf-quic-transport-22 C.9. Since draft-ietf-quic-transport-22
* Rules for preventing correlation by connection ID tightened * Rules for preventing correlation by connection ID tightened
(#2084, #2929) (#2084, #2929)
* Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, * Clarified use of CONNECTION_CLOSE in Handshake packets (#2151,
#2541, #2688) #2541, #2688)
* Discourage regressions of largest acknowledged in ACK (#2205, * Discourage regressions of largest acknowledged in ACK (#2205,
#2752) #2752)
skipping to change at page 181, line 48 skipping to change at page 183, line 19
#2840, #2841) #2840, #2841)
* Explanation of the effect of Retry on 0-RTT packets (#2842, #2852) * Explanation of the effect of Retry on 0-RTT packets (#2842, #2852)
* Cryptographic handshake needs to provide server transport * Cryptographic handshake needs to provide server transport
parameter encryption (#2920, #2921) parameter encryption (#2920, #2921)
* Moved ACK generation guidance from recovery draft to transport * Moved ACK generation guidance from recovery draft to transport
draft (#1860, #2916). draft (#1860, #2916).
C.9. Since draft-ietf-quic-transport-21 C.10. Since draft-ietf-quic-transport-21
* Connection ID lengths are now one octet, but limited in version 1 * Connection ID lengths are now one octet, but limited in version 1
to 20 octets of length (#2736, #2749) to 20 octets of length (#2736, #2749)
C.10. Since draft-ietf-quic-transport-20 C.11. Since draft-ietf-quic-transport-20
* Error codes are encoded as variable-length integers (#2672, #2680) * Error codes are encoded as variable-length integers (#2672, #2680)
* NEW_CONNECTION_ID includes a request to retire old connection IDs * NEW_CONNECTION_ID includes a request to retire old connection IDs
(#2645, #2769) (#2645, #2769)
* Tighter rules for generating and explicitly eliciting ACK frames * Tighter rules for generating and explicitly eliciting ACK frames
(#2546, #2794) (#2546, #2794)
* Recommend having only one packet per encryption level in a * Recommend having only one packet per encryption level in a
skipping to change at page 182, line 49 skipping to change at page 184, line 20
* PATH_RESPONSE no longer needs to be received on the validated path * PATH_RESPONSE no longer needs to be received on the validated path
(#2582, #2580, #2579, #2637) (#2582, #2580, #2579, #2637)
* PATH_RESPONSE frames are not stored and retransmitted (#2724, * PATH_RESPONSE frames are not stored and retransmitted (#2724,
#2729) #2729)
* Document hack for enabling routing of ICMP when doing PMTU probing * Document hack for enabling routing of ICMP when doing PMTU probing
(#1243, #2402) (#1243, #2402)
C.11. Since draft-ietf-quic-transport-19 C.12. Since draft-ietf-quic-transport-19
* Refine discussion of 0-RTT transport parameters (#2467, #2464) * Refine discussion of 0-RTT transport parameters (#2467, #2464)
* Fewer transport parameters need to be remembered for 0-RTT (#2624, * Fewer transport parameters need to be remembered for 0-RTT (#2624,
#2467) #2467)
* Spin bit text incorporated (#2564) * Spin bit text incorporated (#2564)
* Close the connection when maximum stream ID in MAX_STREAMS exceeds * Close the connection when maximum stream ID in MAX_STREAMS exceeds
2^62 - 1 (#2499, #2487) 2^62 - 1 (#2499, #2487)
* New connection ID required for intentional migration (#2414, * New connection ID required for intentional migration (#2414,
#2413) #2413)
skipping to change at page 183, line 27 skipping to change at page 184, line 47
* The "QUIC bit" is ignored in Version Negotiation (#2400, #2561) * The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)
* Initial packets from clients need to be padded to 1200 unless a * Initial packets from clients need to be padded to 1200 unless a
Handshake packet is sent as well (#2522, #2523) Handshake packet is sent as well (#2522, #2523)
* CRYPTO frames can be discarded if too much data is buffered * CRYPTO frames can be discarded if too much data is buffered
(#1834, #2524) (#1834, #2524)
* Stateless reset uses a short header packet (#2599, #2600) * Stateless reset uses a short header packet (#2599, #2600)
C.12. Since draft-ietf-quic-transport-18 C.13. Since draft-ietf-quic-transport-18
* Removed version negotiation; version negotiation, including * Removed version negotiation; version negotiation, including
authentication of the result, will be addressed in the next authentication of the result, will be addressed in the next
version of QUIC (#1773, #2313) version of QUIC (#1773, #2313)
* Added discussion of the use of IPv6 flow labels (#2348, #2399) * Added discussion of the use of IPv6 flow labels (#2348, #2399)
* A connection ID can't be retired in a packet that uses that * A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420) connection ID (#2101, #2420)
* Idle timeout transport parameter is in milliseconds (from seconds) * Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454) (#2453, #2454)
* Endpoints are required to use new connection IDs when they use new * Endpoints are required to use new connection IDs when they use new
network paths (#2413, #2414) network paths (#2413, #2414)
* Increased the set of permissible frames in 0-RTT (#2344, #2355) * Increased the set of permissible frames in 0-RTT (#2344, #2355)
C.13. Since draft-ietf-quic-transport-17 C.14. Since draft-ietf-quic-transport-17
* Stream-related errors now use STREAM_STATE_ERROR (#2305) * Stream-related errors now use STREAM_STATE_ERROR (#2305)
* Endpoints discard initial keys as soon as handshake keys are * Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
* Expanded conditions for ignoring ICMP packet too big messages * Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161) (#2108, #2161)
* Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, * Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
skipping to change at page 184, line 37 skipping to change at page 186, line 10
#2301) #2301)
* Allow server preferred address for both IPv4 and IPv6 (#2122, * Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296) #2296)
* Corrected requirements for migration to a preferred address * Corrected requirements for migration to a preferred address
(#2146, #2349) (#2146, #2349)
* ACK of non-existent packet is illegal (#2298, #2302) * ACK of non-existent packet is illegal (#2298, #2302)
C.14. Since draft-ietf-quic-transport-16 C.15. Since draft-ietf-quic-transport-16
* Stream limits are defined as counts, not maximums (#1850, #1906) * Stream limits are defined as counts, not maximums (#1850, #1906)
* Require amplification attack defense after closing (#1905, #1911) * Require amplification attack defense after closing (#1905, #1911)
* Remove reservation of application error code 0 for STOPPING * Remove reservation of application error code 0 for STOPPING
(#1804, #1922) (#1804, #1922)
* Renumbered frames (#1945) * Renumbered frames (#1945)
skipping to change at page 185, line 32 skipping to change at page 187, line 4
* Allow STOP_SENDING to open a remote bidirectional stream (#1797, * Allow STOP_SENDING to open a remote bidirectional stream (#1797,
#2013) #2013)
* Added mitigation for off-path migration attacks (#1278, #1749, * Added mitigation for off-path migration attacks (#1278, #1749,
#2033) #2033)
* Don't let the PMTU to drop below 1280 (#2063, #2069) * Don't let the PMTU to drop below 1280 (#2063, #2069)
* Require peers to replace retired connection IDs (#2085) * Require peers to replace retired connection IDs (#2085)
* Servers are required to ignore Version Negotiation packets (#2088) * Servers are required to ignore Version Negotiation packets (#2088)
* Tokens are repeated in all Initial packets (#2089) * Tokens are repeated in all Initial packets (#2089)
* Clarified how PING frames are sent after loss (#2094) * Clarified how PING frames are sent after loss (#2094)
* Initial keys are discarded once Handshake are available (#1951, * Initial keys are discarded once Handshake are available (#1951,
#2045) #2045)
* ICMP PTB validation clarifications (#2161, #2109, #2108) * ICMP PTB validation clarifications (#2161, #2109, #2108)
C.15. Since draft-ietf-quic-transport-15 C.16. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
C.16. Since draft-ietf-quic-transport-14 C.17. Since draft-ietf-quic-transport-14
* Merge ACK and ACK_ECN (#1778, #1801) * Merge ACK and ACK_ECN (#1778, #1801)
* Explicitly communicate max_ack_delay (#981, #1781) * Explicitly communicate max_ack_delay (#981, #1781)
* Validate original connection ID after Retry packets (#1710, #1486, * Validate original connection ID after Retry packets (#1710, #1486,
#1793) #1793)
* Idle timeout is optional and has no specified maximum (#1765) * Idle timeout is optional and has no specified maximum (#1765)
* Update connection ID handling; add RETIRE_CONNECTION_ID type * Update connection ID handling; add RETIRE_CONNECTION_ID type
(#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799,
#1821) #1821)
* Include a Token in all Initial packets (#1649, #1794) * Include a Token in all Initial packets (#1649, #1794)
* Prevent handshake deadlock (#1764, #1824) * Prevent handshake deadlock (#1764, #1824)
C.17. Since draft-ietf-quic-transport-13 C.18. Since draft-ietf-quic-transport-13
* Streams open when higher-numbered streams of the same type open * Streams open when higher-numbered streams of the same type open
(#1342, #1549) (#1342, #1549)
* Split initial stream flow control limit into 3 transport * Split initial stream flow control limit into 3 transport
parameters (#1016, #1542) parameters (#1016, #1542)
* All flow control transport parameters are optional (#1610) * All flow control transport parameters are optional (#1610)
* Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) * Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
skipping to change at page 187, line 7 skipping to change at page 188, line 28
* Permit 0-RTT after receiving Version Negotiation or Retry (#1507, * Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621) #1514, #1621)
* Permit Retry in response to 0-RTT (#1547, #1552) * Permit Retry in response to 0-RTT (#1547, #1552)
* Looser verification of ECN counters to account for ACK loss * Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565) (#1555, #1481, #1565)
* Remove frame type field from APPLICATION_CLOSE (#1508, #1528) * Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
C.18. Since draft-ietf-quic-transport-12 C.19. Since draft-ietf-quic-transport-12
* Changes to integration of the TLS handshake (#829, #1018, #1094, * Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450, #1458) #1165, #1190, #1233, #1242, #1252, #1450, #1458)
- The cryptographic handshake uses CRYPTO frames, not stream 0 - The cryptographic handshake uses CRYPTO frames, not stream 0
- QUIC packet protection is used in place of TLS record - QUIC packet protection is used in place of TLS record
protection protection
- Separate QUIC packet number spaces are used for the handshake - Separate QUIC packet number spaces are used for the handshake
skipping to change at page 187, line 50 skipping to change at page 189, line 23
* Fixed sampling method for packet number encryption; the length * Fixed sampling method for packet number encryption; the length
field in long headers includes the packet number field in addition field in long headers includes the packet number field in addition
to the packet payload (#1387, #1389) to the packet payload (#1387, #1389)
* Stateless Reset is now symmetric and subject to size constraints * Stateless Reset is now symmetric and subject to size constraints
(#466, #1346) (#466, #1346)
* Added frame type extension mechanism (#58, #1473) * Added frame type extension mechanism (#58, #1473)
C.19. Since draft-ietf-quic-transport-11 C.20. Since draft-ietf-quic-transport-11
* Enable server to transition connections to a preferred address * Enable server to transition connections to a preferred address
(#560, #1251) (#560, #1251)
* Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, * Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
#990, #734, #1317, #1267, #1079) #990, #734, #1317, #1267, #1079)
* Packet numbers use a variable-length encoding (#989, #1334) * Packet numbers use a variable-length encoding (#989, #1334)
* STREAM frames can now be empty (#1350) * STREAM frames can now be empty (#1350)
C.20. Since draft-ietf-quic-transport-10 C.21. Since draft-ietf-quic-transport-10
* Swap payload length and packed number fields in long header * Swap payload length and packed number fields in long header
(#1294) (#1294)
* Clarified that CONNECTION_CLOSE is allowed in Handshake packet * Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
* Spin bit reserved (#1283) * Spin bit reserved (#1283)
* Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) * Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
skipping to change at page 188, line 31 skipping to change at page 190, line 4
* Spin bit reserved (#1283) * Spin bit reserved (#1283)
* Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) * Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
* A more complete connection migration (#1249) * A more complete connection migration (#1249)
* Refine opportunistic ACK defense text (#305, #1030, #1185) * Refine opportunistic ACK defense text (#305, #1030, #1185)
* A Stateless Reset Token isn't mandatory (#818, #1191) * A Stateless Reset Token isn't mandatory (#818, #1191)
* Removed implicit stream opening (#896, #1193) * Removed implicit stream opening (#896, #1193)
* An empty STREAM frame can be used to open a stream without sending * An empty STREAM frame can be used to open a stream without sending
data (#901, #1194) data (#901, #1194)
* Define stream counts in transport parameters rather than a maximum * Define stream counts in transport parameters rather than a maximum
stream ID (#1023, #1065) stream ID (#1023, #1065)
* STOP_SENDING is now prohibited before streams are used (#1050) * STOP_SENDING is now prohibited before streams are used (#1050)
* Recommend including ACK in Retry packets and allow PADDING (#1067, * Recommend including ACK in Retry packets and allow PADDING (#1067,
#882) #882)
* Endpoints now become closing after an idle timeout (#1178, #1179) * Endpoints now become closing after an idle timeout (#1178, #1179)
* Remove implication that Version Negotiation is sent when a packet * Remove implication that Version Negotiation is sent when a packet
of the wrong version is received (#1197) of the wrong version is received (#1197)
C.21. Since draft-ietf-quic-transport-09 C.22. Since draft-ietf-quic-transport-09
* Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with * Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with
Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d.
(#1091, #725, #1086) (#1091, #725, #1086)
* A server can now only send 3 packets without validating the client * A server can now only send 3 packets without validating the client
address (#38, #1090) address (#38, #1090)
* Delivery order of stream data is no longer strongly specified * Delivery order of stream data is no longer strongly specified
(#252, #1070) (#252, #1070)
skipping to change at page 189, line 29 skipping to change at page 191, line 5
* Improved retransmission rules for all frame types: information is * Improved retransmission rules for all frame types: information is
retransmitted, not packets or frames (#463, #765, #1095, #1053) retransmitted, not packets or frames (#463, #765, #1095, #1053)
* Added an error code for server busy signals (#1137) * Added an error code for server busy signals (#1137)
* Endpoints now set the connection ID that their peer uses. * Endpoints now set the connection ID that their peer uses.
Connection IDs are variable length. Removed the Connection IDs are variable length. Removed the
omit_connection_id transport parameter and the corresponding short omit_connection_id transport parameter and the corresponding short
header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
C.22. Since draft-ietf-quic-transport-08 C.23. Since draft-ietf-quic-transport-08
* Clarified requirements for BLOCKED usage (#65, #924) * Clarified requirements for BLOCKED usage (#65, #924)
* BLOCKED frame now includes reason for blocking (#452, #924, #927, * BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
* GAP limitation in ACK Frame (#613) * GAP limitation in ACK Frame (#613)
* Improved PMTUD description (#614, #1036) * Improved PMTUD description (#614, #1036)
skipping to change at page 190, line 10 skipping to change at page 191, line 33
* Stateless reset clarified as version-specific (#930, #986) * Stateless reset clarified as version-specific (#930, #986)
* initial_max_stream_id_x transport parameters are optional (#970, * initial_max_stream_id_x transport parameters are optional (#970,
#971) #971)
* ACK delay assumes a default value during the handshake (#1007, * ACK delay assumes a default value during the handshake (#1007,
#1009) #1009)
* Removed transport parameters from NewSessionTicket (#1015) * Removed transport parameters from NewSessionTicket (#1015)
C.23. Since draft-ietf-quic-transport-07 C.24. Since draft-ietf-quic-transport-07
* The long header now has version before packet number (#926, #939) * The long header now has version before packet number (#926, #939)
* Rename and consolidate packet types (#846, #822, #847) * Rename and consolidate packet types (#846, #822, #847)
* Packet types are assigned new codepoints and the Connection ID * Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956) Flag is inverted (#426, #956)
* Removed type for Version Negotiation and use Version 0 (#963, * Removed type for Version Negotiation and use Version 0 (#963,
#968) #968)
skipping to change at page 191, line 5 skipping to change at page 192, line 28
* Address validation for connection migration (#161, #732, #878) * Address validation for connection migration (#161, #732, #878)
* Clearly defined retransmission rules for BLOCKED (#452, #65, #924) * Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
* negotiated_version is sent in server transport parameters (#710, * negotiated_version is sent in server transport parameters (#710,
#959) #959)
* Increased the range over which packet numbers are randomized * Increased the range over which packet numbers are randomized
(#864, #850, #964) (#864, #850, #964)
C.24. Since draft-ietf-quic-transport-06 C.25. Since draft-ietf-quic-transport-06
* Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) * Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
* Split error code space between application and transport (#485) * Split error code space between application and transport (#485)
* Stateless reset token moved to end (#820) * Stateless reset token moved to end (#820)
* 1-RTT-protected long header types removed (#848) * 1-RTT-protected long header types removed (#848)
* No acknowledgments during draining period (#852) * No acknowledgments during draining period (#852)
* Remove "application close" as a separate close type (#854) * Remove "application close" as a separate close type (#854)
* Remove timestamps from the ACK frame (#841) * Remove timestamps from the ACK frame (#841)
* Require transport parameters to only appear once (#792) * Require transport parameters to only appear once (#792)
C.25. Since draft-ietf-quic-transport-05 C.26. Since draft-ietf-quic-transport-05
* Stateless token is server-only (#726) * Stateless token is server-only (#726)
* Refactor section on connection termination (#733, #748, #328, * Refactor section on connection termination (#733, #748, #328,
#177) #177)
* Limit size of Version Negotiation packet (#585) * Limit size of Version Negotiation packet (#585)
* Clarify when and what to ack (#736) * Clarify when and what to ack (#736)
* Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED * Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
* Clarify Keep-alive requirements (#729) * Clarify Keep-alive requirements (#729)
C.26. Since draft-ietf-quic-transport-04 C.27. Since draft-ietf-quic-transport-04
* Introduce STOP_SENDING frame, RESET_STREAM only resets in one * Introduce STOP_SENDING frame, RESET_STREAM only resets in one
direction (#165) direction (#165)
* Removed GOAWAY; application protocols are responsible for graceful * Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696) shutdown (#696)
* Reduced the number of error codes (#96, #177, #184, #211) * Reduced the number of error codes (#96, #177, #184, #211)
* Version validation fields can't move or change (#121) * Version validation fields can't move or change (#121)
skipping to change at page 192, line 24 skipping to change at page 193, line 47
* Increased the maximum length of the Largest Acknowledged field in * Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
* truncate_connection_id is renamed to omit_connection_id (#659) * truncate_connection_id is renamed to omit_connection_id (#659)
* CONNECTION_CLOSE terminates the connection like TCP RST (#330, * CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
* Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) * Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
C.27. Since draft-ietf-quic-transport-03 C.28. Since draft-ietf-quic-transport-03
* Change STREAM and RESET_STREAM layout * Change STREAM and RESET_STREAM layout
* Add MAX_STREAM_ID settings * Add MAX_STREAM_ID settings
C.28. Since draft-ietf-quic-transport-02 C.29. Since draft-ietf-quic-transport-02
* The size of the initial packet payload has a fixed minimum (#267, * The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
* Define when Version Negotiation packets are ignored (#284, #294, * Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
* The 64-bit FNV-1a algorithm is used for integrity protection of * The 64-bit FNV-1a algorithm is used for integrity protection of
unprotected packets (#167, #480, #481, #517) unprotected packets (#167, #480, #481, #517)
skipping to change at page 193, line 27 skipping to change at page 194, line 51
linkability (#232, #491, #496) linkability (#232, #491, #496)
* Transport parameters for 0-RTT are retained from a previous * Transport parameters for 0-RTT are retained from a previous
connection (#405, #513, #512) connection (#405, #513, #512)
- A client in 0-RTT no longer required to reset excess streams - A client in 0-RTT no longer required to reset excess streams
(#425, #479) (#425, #479)
* Expanded security considerations (#440, #444, #445, #448) * Expanded security considerations (#440, #444, #445, #448)
C.29. Since draft-ietf-quic-transport-01 C.30. Since draft-ietf-quic-transport-01
* Defined short and long packet headers (#40, #148, #361) * Defined short and long packet headers (#40, #148, #361)
* Defined a versioning scheme and stable fields (#51, #361) * Defined a versioning scheme and stable fields (#51, #361)
* Define reserved version values for "greasing" negotiation (#112, * Define reserved version values for "greasing" negotiation (#112,
#278) #278)
* The initial packet number is randomized (#35, #283) * The initial packet number is randomized (#35, #283)
* Narrow the packet number encoding range requirement (#67, #286, * Narrow the packet number encoding range requirement (#67, #286,
skipping to change at page 195, line 25 skipping to change at page 196, line 49
* Remove error code and reason phrase from GOAWAY (#352, #355) * Remove error code and reason phrase from GOAWAY (#352, #355)
* GOAWAY includes a final stream number for both directions (#347) * GOAWAY includes a final stream number for both directions (#347)
* Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a * Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
* Defined priority as the responsibility of the application protocol * Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
C.30. Since draft-ietf-quic-transport-00 C.31. Since draft-ietf-quic-transport-00
* Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag * Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
* Defined versioning * Defined versioning
* Reworked description of packet and frame layout * Reworked description of packet and frame layout
* Error code space is divided into regions for each component * Error code space is divided into regions for each component
* Use big endian for all numeric values * Use big endian for all numeric values
C.31. Since draft-hamilton-quic-transport-protocol-01 C.32. Since draft-hamilton-quic-transport-protocol-01
* Adopted as base for draft-ietf-quic-tls * Adopted as base for draft-ietf-quic-tls
* Updated authors/editors list * Updated authors/editors list
* Added IANA Considerations section * Added IANA Considerations section
* Moved Contributors and Acknowledgments to appendices * Moved Contributors and Acknowledgments to appendices
Contributors Contributors
skipping to change at page 196, line 30 skipping to change at page 198, line 4
* David Schinazi * David Schinazi
* Dmitri Tikhonov * Dmitri Tikhonov
* Eric Kinnear * Eric Kinnear
* Eric Rescorla * Eric Rescorla
* Gorry Fairhurst * Gorry Fairhurst
* Ian Swett * Ian Swett
* Igor Lubashev * Igor Lubashev
* 奥 一穂 (Kazuho Oku) * 奥 一穂 (Kazuho Oku)
* Lars Eggert
* Lucas Pardue * Lucas Pardue
* Magnus Westerlund * Magnus Westerlund
* Marten Seemann * Marten Seemann
* Martin Duke * Martin Duke
* Mike Bishop * Mike Bishop
 End of changes. 212 change blocks. 
687 lines changed or deleted 745 lines changed or added

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