draft-ietf-quic-transport-22.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: January 10, 2020 Mozilla Expires: February 18, 2020 Mozilla
July 9, 2019 August 17, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-22 draft-ietf-quic-transport-latest
Abstract Abstract
This document defines the core of the QUIC transport protocol. This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation. control and the use of TLS for key negotiation.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2020. This Internet-Draft will expire on February 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7 1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9 2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10 2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11 2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 11
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Required Operations on Streams . . . . . . . . . . . . . 11
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 12 3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 12
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 14 3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 14
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16 3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 17
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 17 3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 17
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18 3.5. Solicited State Transitions . . . . . . . . . . . . . . . 19
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 20 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 20
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 21 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 21
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 22 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 22
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 23
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 23 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 23
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 25 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 25
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 26 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 26
5.2. Matching Packets to Connections . . . . . . . . . . . . . 27 5.2. Matching Packets to Connections . . . . . . . . . . . . . 27
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 27 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 28
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 28 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 28
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 29 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 29
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 29 5.4. Required Operations on Connections . . . . . . . . . . . 29
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 29 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 30
6.2. Handling Version Negotiation Packets . . . . . . . . . . 29 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 30
6.2.1. Version Negotiation Between Draft Versions . . . . . 30 6.2. Handling Version Negotiation Packets . . . . . . . . . . 31
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 30 6.2.1. Version Negotiation Between Draft Versions . . . . . 31
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 31 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 31
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 32 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 32
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 33 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 33
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 35 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 34
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 35 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 36
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 37 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 36
7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 37 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 38
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37 7.4. Cryptographic Message Buffering . . . . . . . . . . . . . 38
8.1. Address Validation During Connection Establishment . . . 38 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 38
8.1.1. Address Validation using Retry Packets . . . . . . . 39 8.1. Address Validation During Connection Establishment . . . 39
8.1.2. Address Validation for Future Connections . . . . . . 39 8.1.1. Address Validation using Retry Packets . . . . . . . 40
8.1.3. Address Validation Token Integrity . . . . . . . . . 41 8.1.2. Address Validation for Future Connections . . . . . . 40
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 42 8.1.3. Address Validation Token Integrity . . . . . . . . . 42
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 43 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 43
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 43 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 44
8.5. Successful Path Validation . . . . . . . . . . . . . . . 43 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 44
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43 8.5. Successful Path Validation . . . . . . . . . . . . . . . 44
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 44 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 44
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 45 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 45
9.2. Initiating Connection Migration . . . . . . . . . . . . . 45 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 46
9.3. Responding to Connection Migration . . . . . . . . . . . 46 9.2. Initiating Connection Migration . . . . . . . . . . . . . 46
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 47 9.3. Responding to Connection Migration . . . . . . . . . . . 47
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 47 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 48
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 48 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 48
9.4. Loss Detection and Congestion Control . . . . . . . . . . 49 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 49
9.5. Privacy Implications of Connection Migration . . . . . . 50 9.4. Loss Detection and Congestion Control . . . . . . . . . . 50
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 50 9.5. Privacy Implications of Connection Migration . . . . . . 51
9.6.1. Communicating a Preferred Address . . . . . . . . . . 51 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 51
9.6.2. Responding to Connection Migration . . . . . . . . . 51 9.6.1. Communicating a Preferred Address . . . . . . . . . . 52
9.6.3. Interaction of Client Migration and Preferred Address 52 9.6.2. Responding to Connection Migration . . . . . . . . . 52
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 52 9.6.3. Interaction of Client Migration and Preferred Address 53
10. Connection Termination . . . . . . . . . . . . . . . . . . . 53 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 53
10.1. Closing and Draining Connection States . . . . . . . . . 53 10. Connection Termination . . . . . . . . . . . . . . . . . . . 54
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 54 10.1. Closing and Draining Connection States . . . . . . . . . 54
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 55 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 55
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 56 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 56
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 59 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 57
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 59 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 60
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 60 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 60
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 61 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 61
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 61 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 62
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 62 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 63
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 62 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 63
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 63 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 64
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 63 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 64
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 64 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 65
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 66 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 66
13. Packetization and Reliability . . . . . . . . . . . . . . . . 68 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 67
13.1. Packet Processing and Acknowledgment . . . . . . . . . . 69 13. Packetization and Reliability . . . . . . . . . . . . . . . . 70
13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 69 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 71
13.1.2. Limiting ACK Ranges . . . . . . . . . . . . . . . . 70 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 71
13.1.3. ACK Frames and Packet Protection . . . . . . . . . . 70 13.1.2. Limiting ACK Ranges . . . . . . . . . . . . . . . . 72
13.2. Retransmission of Information . . . . . . . . . . . . . 71 13.1.3. ACK Frames and Packet Protection . . . . . . . . . . 72
13.3. Explicit Congestion Notification . . . . . . . . . . . . 73 13.2. Retransmission of Information . . . . . . . . . . . . . 73
13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 73 13.3. Explicit Congestion Notification . . . . . . . . . . . . 75
13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 74 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 75
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 75 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 76
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 76 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 77
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 77 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 78
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 78 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 79
14.3.1. PMTU Probes Containing Source Connection ID . . . . 78 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 80
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 79 14.3.1. PMTU Probes Containing Source Connection ID . . . . 80
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 80 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 81
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 80 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 82
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 81 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 82
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 82 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 83
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 84 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 84
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 86 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 86
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 88 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 88
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 90 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 90
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 91 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 92
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 93 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 93
17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 95 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 95
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 96 17.3.1. Latency Spin Bit . . . . . . . . . . . . . . . . . . 97
18.1. Transport Parameter Definitions . . . . . . . . . . . . 97 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 98
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 100 18.1. Reserved Transport Parameters . . . . . . . . . . . . . 99
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 101 18.2. Transport Parameter Definitions . . . . . . . . . . . . 99
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 101 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 103
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 101 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 103
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 103 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 103
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 105 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 103
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 106 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 105
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 106 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 107
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 107 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 108
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 108 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 108
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 108 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 109
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 110 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 110
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 110 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 111
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 111 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 112
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 112 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 113
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 113 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 114
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 113 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 115
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 114 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 115
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 116 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 116
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 116 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 116
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 117 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 118
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 117 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 119
19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 118 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 120
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 119 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 120
20.1. Application Protocol Error Codes . . . . . . . . . . . . 120 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 121
21. Security Considerations . . . . . . . . . . . . . . . . . . . 120 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 121
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 120 20.1. Application Protocol Error Codes . . . . . . . . . . . . 123
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 121 21. Security Considerations . . . . . . . . . . . . . . . . . . . 123
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 122 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 123
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 122 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 124
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 122 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 124
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 123 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 125
21.7. Explicit Congestion Notification Attacks . . . . . . . . 123 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 125
21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 124 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 125
21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 124 21.7. Peer Denial of Service . . . . . . . . . . . . . . . . . 126
21.10. Targeted Attacks by Routing . . . . . . . . . . . . . . 124 21.8. Explicit Congestion Notification Attacks . . . . . . . . 126
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 21.9. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 127
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 125 21.10. Version Downgrade . . . . . . . . . . . . . . . . . . . 127
22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 126 21.11. Targeted Attacks by Routing . . . . . . . . . . . . . . 127
22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 127 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 128
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 129 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 128
23.1. Normative References . . . . . . . . . . . . . . . . . . 130 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 129
23.2. Informative References . . . . . . . . . . . . . . . . . 131 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 130
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 133 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 132
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 133 23.1. Normative References . . . . . . . . . . . . . . . . . . 132
B.1. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 134 23.2. Informative References . . . . . . . . . . . . . . . . . 134
B.2. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 134 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 136
B.3. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 135 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 136
B.4. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 135 B.1. Since draft-ietf-quic-transport-21 . . . . . . . . . . . 136
B.5. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 136 B.2. Since draft-ietf-quic-transport-20 . . . . . . . . . . . 136
B.6. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 136 B.3. Since draft-ietf-quic-transport-19 . . . . . . . . . . . 137
B.7. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 138 B.4. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 138
B.8. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 138 B.5. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 138
B.9. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 138 B.6. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 139
B.10. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 139 B.7. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 140
B.11. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 140 B.8. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 140
B.12. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 140 B.9. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 141
B.13. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 141 B.10. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 142
B.14. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 141 B.11. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 142
B.15. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 142 B.12. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 143
B.16. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 143 B.13. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 143
B.17. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 143 B.14. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 144
B.18. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 143 B.15. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 145
B.19. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 144 B.16. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 146
B.20. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 144 B.17. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 146
B.21. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 145 B.18. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 146
B.22. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 147 B.19. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 147
B.23. Since draft-hamilton-quic-transport-protocol-01 . . . . . 147 B.20. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 147
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 148 B.21. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 148
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 148 B.22. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 150
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 148 B.23. Since draft-hamilton-quic-transport-protocol-01 . . . . . 150
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 150
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151
1. Introduction 1. Introduction
QUIC is a multiplexed and secure general-purpose transport protocol QUIC is a multiplexed and secure general-purpose transport protocol
that provides: that provides:
o Stream multiplexing o Stream multiplexing
o Stream and connection-level flow control o Stream and connection-level flow control
skipping to change at page 8, line 48 skipping to change at page 8, line 51
x (i) ...: Indicates that x uses the variable-length encoding in x (i) ...: Indicates that x uses the variable-length encoding in
Section 16 Section 16
x (*) ...: Indicates that x is variable-length x (*) ...: Indicates that x is variable-length
2. Streams 2. Streams
Streams in QUIC provide a lightweight, ordered byte-stream Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application. Streams can be unidirectional or abstraction to an application. Streams can be unidirectional or
bidirecational. An alternative view of QUIC unidirectional streams bidirectional. An alternative view of QUIC unidirectional streams is
is a "message" abstraction of practically unlimited length. a "message" abstraction of practically unlimited length.
Streams can be created by sending data. Other processes associated Streams can be created by sending data. Other processes associated
with stream management - ending, cancelling, and managing flow with stream management - ending, cancelling, and managing flow
control - are all designed to impose minimal overheads. For control - are all designed to impose minimal overheads. For
instance, a single STREAM frame (Section 19.8) can open, carry data instance, a single STREAM frame (Section 19.8) can open, carry data
for, and close a stream. Streams can also be long-lived and can last for, and close a stream. Streams can also be long-lived and can last
the entire duration of a connection. the entire duration of a connection.
Streams can be created by either endpoint, can concurrently send data Streams can be created by either endpoint, can concurrently send data
interleaved with other streams, and can be cancelled. QUIC does not interleaved with other streams, and can be cancelled. QUIC does not
skipping to change at page 11, line 24 skipping to change at page 11, line 24
QUIC does not provide a mechanism for exchanging prioritization QUIC does not provide a mechanism for exchanging prioritization
information. Instead, it relies on receiving priority information information. Instead, it relies on receiving priority information
from the application that uses QUIC. from the application that uses QUIC.
A QUIC implementation SHOULD provide ways in which an application can A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams. When deciding which indicate the relative priority of streams. When deciding which
streams to dedicate resources to, the implementation SHOULD use the streams to dedicate resources to, the implementation SHOULD use the
information provided by the application. information provided by the application.
2.4. Required Operations on Streams
There are certain operations which an application MUST be able to
perform when interacting with QUIC streams. This document does not
specify an API, but any implementation of this version of QUIC MUST
expose the ability to perform the operations described in this
section on a QUIC stream.
On the sending part of a stream, application protocols need to be
able to:
o write data, understanding when stream flow control credit
(Section 4.1) has successfully been reserved to send the written
data
o end the stream (clean termination), resulting in a STREAM frame
(Section 19.8) with the FIN bit set; and
o reset the stream (abrupt termination), resulting in a RESET_STREAM
frame (Section 19.4), even if the stream was already ended.
On the receiving part of a stream, application protocols need to be
able to:
o read data
o abort reading of the stream and request closure, possibly
resulting in a STOP_SENDING frame (Section 19.5)
Applications also need to be informed of state changes on streams,
including when the peer has opened or reset a stream, when a peer
aborts reading on a stream, when new data is available, and when data
can or cannot be written to the stream due to flow control.
3. Stream States 3. Stream States
This section describes streams in terms of their send or receive This section describes streams in terms of their send or receive
components. Two state machines are described: one for the streams on components. Two state machines are described: one for the streams on
which an endpoint transmits data (Section 3.1), and another for which an endpoint transmits data (Section 3.1), and another for
streams on which an endpoint receives data (Section 3.2). streams on which an endpoint receives data (Section 3.2).
Unidirectional streams use the applicable state machine directly. Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines. For the most part, Bidirectional streams use both state machines. For the most part,
the use of these state machines is the same whether the stream is the use of these state machines is the same whether the stream is
skipping to change at page 18, line 44 skipping to change at page 19, line 7
+-----------------------+---------------------+---------------------+ +-----------------------+---------------------+---------------------+
Table 2: Possible Mapping of Stream States to HTTP/2 Table 2: Possible Mapping of Stream States to HTTP/2
Note (*1): A stream is considered "idle" if it has not yet been Note (*1): A stream is considered "idle" if it has not yet been
created, or if the receiving part of the stream is in the "Recv" created, or if the receiving part of the stream is in the "Recv"
state without yet having received any frames. state without yet having received any frames.
3.5. Solicited State Transitions 3.5. Solicited State Transitions
If an endpoint is no longer interested in the data it is receiving on If an application is no longer interested in the data it is receiving
a stream, it MAY send a STOP_SENDING frame identifying that stream to on a stream, it can abort reading the stream and specify an
prompt closure of the stream in the opposite direction. This application error code.
typically indicates that the receiving application is no longer
reading data it receives from the stream, but it is not a guarantee If the stream is in the "Recv or "Size Known" states, the transport
that incoming data will be ignored. SHOULD signal this by sending a STOP_SENDING frame to prompt closure
of the stream in the opposite direction. This typically indicates
that the receiving application is no longer reading data it receives
from the stream, but it is not a guarantee that incoming data will be
ignored.
STREAM frames received after sending STOP_SENDING are still counted STREAM frames received after sending STOP_SENDING are still counted
toward connection and stream flow control, even though these frames toward connection and stream flow control, even though these frames
can be discarded upon receipt. can be discarded upon receipt.
A STOP_SENDING frame requests that the receiving endpoint send a A STOP_SENDING frame requests that the receiving endpoint send a
RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame
MUST send a RESET_STREAM frame if the stream is in the Ready or Send MUST send a RESET_STREAM frame if the stream is in the Ready or Send
state. If the stream is in the Data Sent state and any outstanding state. If the stream is in the Data Sent state and any outstanding
data is declared lost, an endpoint SHOULD send a RESET_STREAM frame data is declared lost, an endpoint SHOULD send a RESET_STREAM frame
skipping to change at page 23, line 28 skipping to change at page 23, line 41
mandatory, but only because requiring that an endpoint generate these mandatory, but only because requiring that an endpoint generate these
errors also means that the endpoint needs to maintain the final size errors also means that the endpoint needs to maintain the final size
state for closed streams, which could mean a significant state state for closed streams, which could mean a significant state
commitment. commitment.
4.5. Controlling Concurrency 4.5. Controlling Concurrency
An endpoint limits the cumulative number of incoming streams a peer An endpoint limits the cumulative number of incoming streams a peer
can open. Only streams with a stream ID less than (max_stream * 4 + can open. Only streams with a stream ID less than (max_stream * 4 +
initial_stream_id_for_type) can be opened (see Table 5). Initial initial_stream_id_for_type) can be opened (see Table 5). Initial
limits are set in the transport parameters (see Section 18.1) and limits are set in the transport parameters (see Section 18.2) and
subsequently limits are advertised using MAX_STREAMS frames subsequently limits are advertised using MAX_STREAMS frames
(Section 19.11). Separate limits apply to unidirectional and (Section 19.11). Separate limits apply to unidirectional and
bidirectional streams. bidirectional streams.
If a max_streams transport parameter or MAX_STREAMS frame is received If a max_streams transport parameter or MAX_STREAMS frame is received
with a value greater than 2^60, this would allow a maximum stream ID with a value greater than 2^60, this would allow a maximum stream ID
that cannot be expressed as a variable-length integer (see that cannot be expressed as a variable-length integer (see
Section 16). If either is received, the connection MUST be closed Section 16). If either is received, the connection MUST be closed
immediately with a connection error of type STREAM_LIMIT_ERROR (see immediately with a connection error of type STREAM_LIMIT_ERROR (see
Section 10.3). Section 10.3).
skipping to change at page 29, line 11 skipping to change at page 29, line 25
packet. Clients are not able to send Handshake packets prior to packet. Clients are not able to send Handshake packets prior to
receiving a server response, so servers SHOULD ignore any such receiving a server response, so servers SHOULD ignore any such
packets. packets.
Servers MUST drop incoming packets under all other circumstances. Servers MUST drop incoming packets under all other circumstances.
5.3. Life of a QUIC Connection 5.3. Life of a QUIC Connection
TBD. TBD.
5.4. Required Operations on Connections
There are certain operations which an application MUST be able to
perform when interacting with the QUIC transport. This document does
not specify an API, but any implementation of this version of QUIC
MUST expose the ability to perform the operations described in this
section on a QUIC connection.
When implementing the client role, applications need to be able to:
o open a connection, which begins the exchange described in
Section 7;
o enable 0-RTT; and
o be informed when 0-RTT has been accepted or rejected by a server.
When implementing the server role, applications need to be able to:
o listen for incoming connections, which prepares for the exchange
described in Section 7;
o if Early Data is supported, embed application-controlled data in
the TLS resumption ticket sent to the client; and
o if Early Data is supported, retrieve application-controlled data
from the client's resumption ticket and enable rejecting Early
Data based on that information.
In either role, applications need to be able to:
o configure minimum values for the initial number of permitted
streams of each type, as communicated in the transport parameters
(Section 7.3);
o control resource allocation of various types, including flow
control and the number of permitted streams of each type;
o identify whether the handshake has completed successfully or is
still ongoing
o keep a connection from silently closing, either by generating PING
frames (Section 19.2) or by requesting that the transport send
additional frames before the idle timeout expires (Section 10.2);
and
o immediately close (Section 10.3) the connection.
6. Version Negotiation 6. Version Negotiation
Version negotiation ensures that client and server agree to a QUIC Version negotiation ensures that client and server agree to a QUIC
version that is mutually supported. A server sends a Version version that is mutually supported. A server sends a Version
Negotiation packet in response to each packet that might initiate a Negotiation packet in response to each packet that might initiate a
new connection; see Section 5.2 for details. new connection; see Section 5.2 for details.
The size of the first packet sent by a client will determine whether The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet. Clients that support a server sends a Version Negotiation packet. Clients that support
multiple QUIC versions SHOULD pad the first packet they send to the multiple QUIC versions SHOULD pad the first packet they send to the
skipping to change at page 30, line 9 skipping to change at page 31, line 22
When a client receives a Version Negotiation packet, it MUST abandon When a client receives a Version Negotiation packet, it MUST abandon
the current connection attempt. Version Negotiation packets are the current connection attempt. Version Negotiation packets are
designed to allow future versions of QUIC to negotiate the version in designed to allow future versions of QUIC to negotiate the version in
use between endpoints. Future versions of QUIC might change how use between endpoints. Future versions of QUIC might change how
implementations that support multiple versions of QUIC react to implementations that support multiple versions of QUIC react to
Version Negotiation packets when attempting to establish a connection Version Negotiation packets when attempting to establish a connection
using this version. How to perform version negotiation is left as using this version. How to perform version negotiation is left as
future work defined by future versions of QUIC. In particular, that future work defined by future versions of QUIC. In particular, that
future work will need to ensure robustness against version downgrade future work will need to ensure robustness against version downgrade
attacks Section 21.9. attacks Section 21.10.
6.2.1. Version Negotiation Between Draft Versions 6.2.1. Version Negotiation Between Draft Versions
[[RFC editor: please remove this section before publication.]] [[RFC editor: please remove this section before publication.]]
When a draft implementation receives a Version Negotiation packet, it When a draft implementation receives a Version Negotiation packet, it
MAY use it to attempt a new connection with one of the versions MAY use it to attempt a new connection with one of the versions
listed in the packet, instead of abandoning the current connection listed in the packet, instead of abandoning the current connection
attempt Section 6.2. attempt Section 6.2.
skipping to change at page 31, line 32 skipping to change at page 32, line 41
* a client is optionally authenticated, * a client is optionally authenticated,
* every connection produces distinct and unrelated keys, * every connection produces distinct and unrelated keys,
* keying material is usable for packet protection for both 0-RTT * keying material is usable for packet protection for both 0-RTT
and 1-RTT packets, and and 1-RTT packets, and
* 1-RTT keys have forward secrecy * 1-RTT keys have forward secrecy
o authenticated values for the transport parameters of the peer (see o authenticated values for transport parameters of both endpoints,
Section 7.3) and confidentiality protection for server transport parameters
(see Section 7.3)
o authenticated negotiation of an application protocol (TLS uses o authenticated negotiation of an application protocol (TLS uses
ALPN [RFC7301] for this purpose) ALPN [RFC7301] for this purpose)
The first CRYPTO frame from a client MUST be sent in a single packet. The first CRYPTO frame from a client MUST be sent in a single packet.
Any second attempt that is triggered by address validation (see Any second attempt that is triggered by address validation (see
Section 8.1) MUST also be sent within a single packet. This avoids Section 8.1) MUST also be sent within a single packet. This avoids
having to reassemble a message from multiple packets. having to reassemble a message from multiple packets.
The first client packet of the cryptographic handshake protocol MUST The first client packet of the cryptographic handshake protocol MUST
skipping to change at page 35, line 21 skipping to change at page 36, line 21
each parameter includes rules for its handling. each parameter includes rules for its handling.
The encoding of the transport parameters is detailed in Section 18. The encoding of the transport parameters is detailed in Section 18.
QUIC includes the encoded transport parameters in the cryptographic QUIC includes the encoded transport parameters in the cryptographic
handshake. Once the handshake completes, the transport parameters handshake. Once the handshake completes, the transport parameters
declared by the peer are available. Each endpoint validates the declared by the peer are available. Each endpoint validates the
value provided by its peer. value provided by its peer.
Definitions for each of the defined transport parameters are included Definitions for each of the defined transport parameters are included
in Section 18.1. in Section 18.2.
An endpoint MUST treat receipt of a transport parameter with an An endpoint MUST treat receipt of a transport parameter with an
invalid value as a connection error of type invalid value as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
An endpoint MUST NOT send a parameter more than once in a given An endpoint MUST NOT send a parameter more than once in a given
transport parameters extension. An endpoint SHOULD treat receipt of transport parameters extension. An endpoint SHOULD treat receipt of
duplicate transport parameters as a connection error of type duplicate transport parameters as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
A server MUST include the original_connection_id transport parameter A server MUST include the original_connection_id transport parameter
(Section 18.1) if it sent a Retry packet to enable validation of the (Section 18.2) if it sent a Retry packet to enable validation of the
Retry, as described in Section 17.2.5. Retry, as described in Section 17.2.5.
7.3.1. Values of Transport Parameters for 0-RTT 7.3.1. Values of Transport Parameters for 0-RTT
Both endpoints store the value of the server transport parameters Both endpoints store the value of the server transport parameters
from a connection and apply them to any 0-RTT packets that are sent from a connection and apply them to any 0-RTT packets that are sent
in subsequent connections to that peer, except for transport in subsequent connections to that peer, except for transport
parameters that are explicitly excluded. Remembered transport parameters that are explicitly excluded. Remembered transport
parameters apply to the new connection until the handshake completes parameters apply to the new connection until the handshake completes
and the client starts sending 1-RTT packets. Once the handshake and the client starts sending 1-RTT packets. Once the handshake
skipping to change at page 36, line 18 skipping to change at page 37, line 18
A client that attempts to send 0-RTT data MUST remember all other A client that attempts to send 0-RTT data MUST remember all other
transport parameters used by the server. The server can remember transport parameters used by the server. The server can remember
these transport parameters, or store an integrity-protected copy of these transport parameters, or store an integrity-protected copy of
the values in the ticket and recover the information when accepting the values in the ticket and recover the information when accepting
0-RTT data. A server uses the transport parameters in determining 0-RTT data. A server uses the transport parameters in determining
whether to accept 0-RTT data. whether to accept 0-RTT data.
If 0-RTT data is accepted by the server, the server MUST NOT reduce If 0-RTT data is accepted by the server, the server MUST NOT reduce
any limits or alter any values that might be violated by the client any limits or alter any values that might be violated by the client
with its 0-RTT data. In particular, a server that accepts 0-RTT data with its 0-RTT data. In particular, a server that accepts 0-RTT data
MUST NOT set values for the following parameters (Section 18.1) that MUST NOT set values for the following parameters (Section 18.2) that
are smaller than the remembered value of the parameters. are smaller than the remembered value of the parameters.
o initial_max_data o initial_max_data
o initial_max_stream_data_bidi_local o initial_max_stream_data_bidi_local
o initial_max_stream_data_bidi_remote o initial_max_stream_data_bidi_remote
o initial_max_stream_data_uni o initial_max_stream_data_uni
skipping to change at page 37, line 12 skipping to change at page 38, line 12
parameters apply to all 0-RTT packets even if those values are parameters apply to all 0-RTT packets even if those values are
increased by the handshake or by frames sent in 1-RTT packets. A increased by the handshake or by frames sent in 1-RTT packets. A
server MAY treat use of updated transport parameters in 0-RTT as a server MAY treat use of updated transport parameters in 0-RTT as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
7.3.2. New Transport Parameters 7.3.2. New Transport Parameters
New transport parameters can be used to negotiate new protocol New transport parameters can be used to negotiate new protocol
behavior. An endpoint MUST ignore transport parameters that it does behavior. An endpoint MUST ignore transport parameters that it does
not support. Absence of a transport parameter therefore disables any not support. Absence of a transport parameter therefore disables any
optional protocol feature that is negotiated using the parameter. optional protocol feature that is negotiated using the parameter. As
described in Section 18.1, some identifiers are reserved in order to
exercise this requirement.
New transport parameters can be registered according to the rules in New transport parameters can be registered according to the rules in
Section 22.1. Section 22.1.
7.4. Cryptographic Message Buffering 7.4. Cryptographic Message Buffering
Implementations need to maintain a buffer of CRYPTO data received out Implementations need to maintain a buffer of CRYPTO data received out
of order. Because there is no flow control of CRYPTO frames, an of order. Because there is no flow control of CRYPTO frames, an
endpoint could potentially force its peer to buffer an unbounded endpoint could potentially force its peer to buffer an unbounded
amount of data. amount of data.
skipping to change at page 44, line 37 skipping to change at page 45, line 37
The use of a connection ID allows connections to survive changes to The use of a connection ID allows connections to survive changes to
endpoint addresses (IP address and port), such as those caused by an endpoint addresses (IP address and port), such as those caused by an
endpoint migrating to a new network. This section describes the endpoint migrating to a new network. This section describes the
process by which an endpoint migrates to a new address. process by which an endpoint migrates to a new address.
The design of QUIC relies on endpoints retaining a stable address for The design of QUIC relies on endpoints retaining a stable address for
the duration of the handshake. An endpoint MUST NOT initiate the duration of the handshake. An endpoint MUST NOT initiate
connection migration before the handshake is confirmed, as defined in connection migration before the handshake is confirmed, as defined in
section 4.1.2 of [QUIC-TLS]. section 4.1.2 of [QUIC-TLS].
An endpoint also MUST NOT initiate connection migration if the peer An endpoint also MUST NOT send packets from a different local
sent the "disable_migration" transport parameter during the address, actively initiating migration, if the peer sent the
handshake. An endpoint which has sent this transport parameter, but "disable_active_migration" transport parameter during the handshake.
detects that a peer has nonetheless migrated to a different network An endpoint which has sent this transport parameter, but detects that
MAY treat this as a connection error of type INVALID_MIGRATION. a peer has nonetheless migrated to a different network MUST either
Similarly, an endpoint MUST NOT initiate migration if its peer drop the incoming packets on that path without generating a stateless
supplies a zero-length connection ID as packets without a Destination reset or proceed with path validation and allow the peer to migrate.
Connection ID cannot be attributed to a connection based on address Generating a stateless reset or closing the connection would allow
tuple. third parties in the network to cause connections to close by
spoofing or otherwise manipulating observed traffic.
Not all changes of peer address are intentional migrations. The peer Not all changes of peer address are intentional, or active,
could experience NAT rebinding: a change of address due to a migrations. The peer could experience NAT rebinding: a change of
middlebox, usually a NAT, allocating a new outgoing port or even a address due to a middlebox, usually a NAT, allocating a new outgoing
new outgoing IP address for a flow. An endpoint MUST perform path port or even a new outgoing IP address for a flow. An endpoint MUST
validation (Section 8.2) if it detects any change to a peer's perform path validation (Section 8.2) if it detects any change to a
address, unless it has previously validated that address. peer's address, unless it has previously validated that address.
When an endpoint has no validated path on which to send packets, it When an endpoint has no validated path on which to send packets, it
MAY discard connection state. An endpoint capable of connection MAY discard connection state. An endpoint capable of connection
migration MAY wait for a new path to become available before migration MAY wait for a new path to become available before
discarding connection state. discarding connection state.
This document limits migration of connections to new client This document limits migration of connections to new client
addresses, except as described in Section 9.6. Clients are addresses, except as described in Section 9.6. Clients are
responsible for initiating all migrations. Servers do not send non- responsible for initiating all migrations. Servers do not send non-
probing packets (see Section 9.1) toward a client address until they probing packets (see Section 9.1) toward a client address until they
skipping to change at page 49, line 15 skipping to change at page 50, line 15
is rare on IPv6 paths. Endpoints can also look for duplicated is rare on IPv6 paths. Endpoints can also look for duplicated
packets. Conversely, a change in connection ID is more likely to packets. Conversely, a change in connection ID is more likely to
indicate an intentional migration rather than an attack. indicate an intentional migration rather than an attack.
9.4. Loss Detection and Congestion Control 9.4. Loss Detection and Congestion Control
The capacity available on the new path might not be the same as the The capacity available on the new path might not be the same as the
old path. Packets sent on the old path SHOULD NOT contribute to old path. Packets sent on the old path SHOULD NOT contribute to
congestion control or RTT estimation for the new path. congestion control or RTT estimation for the new path.
On confirming a peer's ownership of its new address, an endpoint On confirming a peer's ownership of its new address, an endpoint MUST
SHOULD immediately reset the congestion controller and round-trip immediately reset the congestion controller and round-trip time
time estimator for the new path. estimator for the new path to initial values (see Sections A.3 and
B.3 in [QUIC-RECOVERY]) unless it has knowledge that a previous send
An endpoint MUST NOT return to the send rate used for the previous rate or round-trip time estimate is valid for the new path. For
path unless it is reasonably sure that the previous send rate is instance, an endpoint might infer that a change in only the client's
valid for the new path. For instance, a change in the client's port port number is indicative of a NAT rebinding, meaning that the new
number is likely indicative of a rebinding in a middlebox and not a path is likely to have similar bandwidth and round-trip time.
complete change in path. This determination likely depends on However, this determination will be imperfect. If the determination
heuristics, which could be imperfect; if the new path capacity is is incorrect, the congestion controller and the RTT estimator are
significantly reduced, ultimately this relies on the congestion expected to adapt to the new path. Generally, implementations are
controller responding to congestion signals and reducing send rates advised to be cautious when using previous values on a new path.
appropriately.
There may be apparent reordering at the receiver when an endpoint There may be apparent reordering at the receiver when an endpoint
sends data and probes from/to multiple addresses during the migration sends data and probes from/to multiple addresses during the migration
period, since the two resulting paths may have different round-trip period, since the two resulting paths may have different round-trip
times. A receiver of packets on multiple paths will still send ACK times. A receiver of packets on multiple paths will still send ACK
frames covering all received packets. frames covering all received packets.
While multiple paths might be used during connection migration, a While multiple paths might be used during connection migration, a
single congestion control context and a single loss recovery context single congestion control context and a single loss recovery context
(as described in [QUIC-RECOVERY]) may be adequate. For instance, an (as described in [QUIC-RECOVERY]) may be adequate. For instance, an
skipping to change at page 54, line 40 skipping to change at page 55, line 40
new source address, indicating a connection migration (Section 9). new source address, indicating a connection migration (Section 9).
An endpoint in the closing state MUST strictly limit the number of An endpoint in the closing state MUST strictly limit the number of
packets it sends to this new address until the address is validated packets it sends to this new address until the address is validated
(see Section 8.2). A server in the closing state MAY instead choose (see Section 8.2). A server in the closing state MAY instead choose
to discard packets received from a new source address. to discard packets received from a new source address.
10.2. Idle Timeout 10.2. Idle Timeout
If the idle timeout is enabled, a connection is silently closed and If the idle timeout is enabled, a connection is silently closed and
the state is discarded when it remains idle for longer than both the the state is discarded when it remains idle for longer than both the
advertised idle timeout (see Section 18.1) and three times the advertised idle timeout (see Section 18.2) and three times the
current Probe Timeout (PTO). current Probe Timeout (PTO).
Each endpoint advertises its own idle timeout to its peer. An Each endpoint advertises its own idle timeout to its peer. An
endpoint restarts any timer it maintains when a packet from its peer endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully. The timer is also restarted is received and processed successfully. The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an when sending a packet containing frames other than ACK or PADDING (an
ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK- ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK-
eliciting packets have been sent since last receiving a packet. eliciting packets have been sent since last receiving a packet.
Restarting when sending packets ensures that connections do not Restarting when sending packets ensures that connections do not
prematurely time out when initiating new activity. prematurely time out when initiating new activity.
skipping to change at page 60, line 24 skipping to change at page 61, line 24
without state. In addition, it cannot provide a zero-length without state. In addition, it cannot provide a zero-length
connection ID. connection ID.
Revealing the Stateless Reset Token allows any entity to terminate Revealing the Stateless Reset Token allows any entity to terminate
the connection, so a value can only be used once. This method for the connection, so a value can only be used once. This method for
choosing the Stateless Reset Token means that the combination of choosing the Stateless Reset Token means that the combination of
connection ID and static key MUST NOT be used for another connection. connection ID and static key MUST NOT be used for another connection.
A denial of service attack is possible if the same connection ID is A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the cause a packet to be routed to an instance that has no state but the
same static key; see Section 21.8. A connection ID from a connection same static key; see Section 21.9. A connection ID from a connection
that is reset by revealing the Stateless Reset Token MUST NOT be that is reset by revealing the Stateless Reset Token MUST NOT be
reused for new connections at nodes that share a static key. reused for new connections at nodes that share a static key.
The same Stateless Reset Token MAY be used for multiple connection The same Stateless Reset Token MAY be used for multiple connection
IDs on the same connection. However, reuse of a Stateless Reset IDs on the same connection. However, reuse of a Stateless Reset
Token might expose an endpoint to denial of service if associated Token might expose an endpoint to denial of service if associated
connection IDs are forgotten while the associated token is still connection IDs are forgotten while the associated token is still
active at a peer. An endpoint MUST ensure that packets with active at a peer. An endpoint MUST ensure that packets with
Destination Connection ID field values that correspond to a reused Destination Connection ID field values that correspond to a reused
Stateless Reset Token are attributed to the same connection as long Stateless Reset Token are attributed to the same connection as long
as the Stateless Reset Token is still usable, even when the as the Stateless Reset Token is still usable, even when the
connection ID has been retired. Otherwise, an attacker might be able connection ID has been retired. Otherwise, an attacker might be able
to send a packet with a retired connection ID and cause the endpoint to send a packet with a retired connection ID and cause the endpoint
to produce a Stateless Reset that it can use to disrupt the to produce a Stateless Reset that it can use to disrupt the
connection, just as with the attacks in Section 21.8. connection, just as with the attacks in Section 21.9.
Note that Stateless Reset packets do not have any cryptographic Note that Stateless Reset packets do not have any cryptographic
protection. protection.
10.4.3. Looping 10.4.3. Looping
The design of a Stateless Reset is such that without knowing the The design of a Stateless Reset is such that without knowing the
stateless reset token it is indistinguishable from a valid packet. stateless reset token it is indistinguishable from a valid packet.
For instance, if a server sends a Stateless Reset to another server For instance, if a server sends a Stateless Reset to another server
it might receive another Stateless Reset in response, which could it might receive another Stateless Reset in response, which could
skipping to change at page 61, line 40 skipping to change at page 62, line 40
An endpoint that detects an error SHOULD signal the existence of that An endpoint that detects an error SHOULD signal the existence of that
error to its peer. Both transport-level and application-level errors error to its peer. Both transport-level and application-level errors
can affect an entire connection (see Section 11.1), while only can affect an entire connection (see Section 11.1), while only
application-level errors can be isolated to a single stream (see application-level errors can be isolated to a single stream (see
Section 11.2). Section 11.2).
The most appropriate error code (Section 20) SHOULD be included in The most appropriate error code (Section 20) SHOULD be included in
the frame that signals the error. Where this specification the frame that signals the error. Where this specification
identifies error conditions, it also identifies the error code that identifies error conditions, it also identifies the error code that
is used. is used; though these are worded as requirements, different
implementation strategies might lead to different errors being
reported. In particular, an endpoint MAY use any applicable error
code when it detects an error condition; a generic error code (such
as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place
of specific error codes.
A stateless reset (Section 10.4) is not suitable for any error that A stateless reset (Section 10.4) is not suitable for any error that
can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame. A
stateless reset MUST NOT be used by an endpoint that has the state stateless reset MUST NOT be used by an endpoint that has the state
necessary to send a frame on the connection. necessary to send a frame on the connection.
11.1. Connection Errors 11.1. Connection Errors
Errors that result in the connection being unusable, such as an Errors that result in the connection being unusable, such as an
obvious violation of protocol semantics or corruption of state that obvious violation of protocol semantics or corruption of state that
skipping to change at page 62, line 36 skipping to change at page 63, line 43
An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT
signal the existence of the error to its peer. signal the existence of the error to its peer.
11.2. Stream Errors 11.2. Stream Errors
If an application-level error affects a single stream, but otherwise If an application-level error affects a single stream, but otherwise
leaves the connection in a recoverable state, the endpoint can send a leaves the connection in a recoverable state, the endpoint can send a
RESET_STREAM frame (Section 19.4) with an appropriate error code to RESET_STREAM frame (Section 19.4) with an appropriate error code to
terminate just the affected stream. terminate just the affected stream.
RESET_STREAM MUST be instigated by the protocol using QUIC, either RESET_STREAM MUST be instigated by the protocol using QUIC.
directly or through the receipt of a STOP_SENDING frame from a peer. RESET_STREAM carries an application error code. Only the application
RESET_STREAM carries an application error code. Resetting a stream protocol is able to cause a stream to be terminated. A local
without knowledge of the application protocol could cause the instance of the application protocol uses a direct API call and a
protocol to enter an unrecoverable state. Application protocols remote instance uses the STOP_SENDING frame, which triggers an
might require certain streams to be reliably delivered in order to automatic RESET_STREAM.
guarantee consistent state between endpoints.
Resetting a stream without knowledge of the application protocol
could cause the protocol to enter an unrecoverable state.
Application protocols might require certain streams to be reliably
delivered in order to guarantee consistent state between endpoints.
Application protocols SHOULD define rules for handling streams that
are prematurely cancelled by either endpoint.
12. Packets and Frames 12. Packets and Frames
QUIC endpoints communicate by exchanging packets. Packets have QUIC endpoints communicate by exchanging packets. Packets have
confidentiality and integrity protection (see Section 12.1) and are confidentiality and integrity protection (see Section 12.1) and are
carried in UDP datagrams (see Section 12.2). carried in UDP datagrams (see Section 12.2).
This version of QUIC uses the long packet header (see Section 17.2) This version of QUIC uses the long packet header (see Section 17.2)
during connection establishment. Packets with the long header are during connection establishment. Packets with the long header are
Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake Initial (Section 17.2.2), 0-RTT (Section 17.2.3), Handshake
skipping to change at page 70, line 26 skipping to change at page 72, line 26
To limit ACK Ranges (see Section 19.3.1) to those that have not yet To limit ACK Ranges (see Section 19.3.1) to those that have not yet
been received by the sender, the receiver SHOULD track which ACK been received by the sender, the receiver SHOULD track which ACK
frames have been acknowledged by its peer. The receiver SHOULD frames have been acknowledged by its peer. The receiver SHOULD
exclude already acknowledged packets from future ACK frames whenever exclude already acknowledged packets from future ACK frames whenever
these packets would unnecessarily contribute to the ACK frame size. these packets would unnecessarily contribute to the ACK frame size.
When the receiver is only sending non-ACK-eliciting packets, it can When the receiver is only sending non-ACK-eliciting packets, it can
bundle a PING or other small ACK-eliciting frame with a fraction of bundle a PING or other small ACK-eliciting frame with a fraction of
them, such as once per round trip, to enable dropping unnecessary ACK them, such as once per round trip, to enable dropping unnecessary ACK
ranges and any state for previously sent packets. The receiver MUST ranges and any state for previously sent packets. The receiver MUST
NOT bundle an ACK-elicing frame, such as a PING, with all packets NOT bundle an ACK-eliciting frame, such as a PING, with all packets
that would otherwise be non-ACK-eliciting, in order to avoid an that would otherwise be non-ACK-eliciting, in order to avoid an
infinite feedback loop of acknowledgements. infinite feedback loop of acknowledgements.
To limit receiver state or the size of ACK frames, a receiver MAY To limit receiver state or the size of ACK frames, a receiver MAY
limit the number of ACK Ranges it sends. A receiver can do this even limit the number of ACK Ranges it sends. A receiver can do this even
without receiving acknowledgment of its ACK frames, with the without receiving acknowledgment of its ACK frames, with the
knowledge this could cause the sender to unnecessarily retransmit knowledge this could cause the sender to unnecessarily retransmit
some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare
packets lost after sufficiently newer packets are acknowledged. packets lost after sufficiently newer packets are acknowledged.
Therefore, the receiver SHOULD repeatedly acknowledge newly received Therefore, the receiver SHOULD repeatedly acknowledge newly received
packets in preference to packets received in the past. packets in preference to packets received in the past.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it
did not send as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition. This includes receiving an ACK
frame containing a packet number that the endpoint has not sent, as
well as acknowledgements for 0-RTT packets when the server has
rejected the use of 0-RTT.
13.1.3. ACK Frames and Packet Protection 13.1.3. ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed (see Section 12.1). For number space as the packet being ACKed (see Section 12.1). For
instance, packets that are protected with 1-RTT keys MUST be instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys. acknowledged in packets that are also protected with 1-RTT keys.
Packets that a client sends with 0-RTT packet protection MUST be Packets that a client sends with 0-RTT packet protection MUST be
acknowledged by the server in packets protected by 1-RTT keys. This acknowledged by the server in packets protected by 1-RTT keys. This
can mean that the client is unable to use these acknowledgments if can mean that the client is unable to use these acknowledgments if
skipping to change at page 73, line 46 skipping to change at page 76, line 6
On receiving a QUIC packet with an ECT or CE codepoint, an ECN- On receiving a QUIC packet with an ECT or CE codepoint, an ECN-
enabled endpoint that can access the ECN codepoints from the enabled endpoint that can access the ECN codepoints from the
enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE
count, and includes these counts in subsequent ACK frames (see count, and includes these counts in subsequent ACK frames (see
Section 13.1 and Section 19.3). Note that this requires being able Section 13.1 and Section 19.3). Note that this requires being able
to read the ECN codepoints from the enclosing IP packet, which is not to read the ECN codepoints from the enclosing IP packet, which is not
possible on all platforms. possible on all platforms.
A packet detected by a receiver as a duplicate does not affect the A packet detected by a receiver as a duplicate does not affect the
receiver's local ECN codepoint counts; see (Section 21.7) for receiver's local ECN codepoint counts; see (Section 21.8) for
relevant security concerns. relevant security concerns.
If an endpoint receives a QUIC packet without an ECT or CE codepoint If an endpoint receives a QUIC packet without an ECT or CE codepoint
in the IP packet header, it responds per Section 13.1 with an ACK in the IP packet header, it responds per Section 13.1 with an ACK
frame without increasing any ECN counts. If an endpoint does not frame without increasing any ECN counts. If an endpoint does not
implement ECN support or does not have access to received ECN implement ECN support or does not have access to received ECN
codepoints, it does not increase ECN counts. codepoints, it does not increase ECN counts.
Coalesced packets (see Section 12.2) mean that several packets can Coalesced packets (see Section 12.2) mean that several packets can
share the same IP header. The ECN counter for the ECN codepoint share the same IP header. The ECN counter for the ECN codepoint
skipping to change at page 82, line 51 skipping to change at page 84, line 51
of byte 0 contain a packet type. Packet types are listed in of byte 0 contain a packet type. Packet types are listed in
Table 5. Table 5.
Type-Specific Bits (X): The lower four bits (those with a mask of Type-Specific Bits (X): The lower four bits (those with a mask of
0x0f) of byte 0 are type-specific. 0x0f) of byte 0 are type-specific.
Version: The QUIC Version is a 32-bit field that follows the first Version: The QUIC Version is a 32-bit field that follows the first
byte. This field indicates which version of QUIC is in use and byte. This field indicates which version of QUIC is in use and
determines how the rest of the protocol fields are interpreted. determines how the rest of the protocol fields are interpreted.
DCID Len: The byte following the version contains the lengths of the DCID Len: The byte following the version contains the length in
two connection ID fields that follow it. These lengths are bytes of the Destination Connection ID field that follows it.
encoded as two 4-bit unsigned integers. The Destination
Connection ID Length (DCIL) field occupies the 4 high bits of the This length is encoded as an 8-bit unsigned integer. In QUIC
byte and the Source Connection ID Length (SCIL) field occupies the version 1, this value MUST NOT exceed 20. Endpoints that receive
4 low bits of the byte. An encoded length of 0 indicates that the a version 1 long header with a value larger than 20 MUST drop the
connection ID is also 0 bytes in length. Non-zero encoded lengths packet. Servers SHOULD be able to read longer connection IDs from
are increased by 3 to get the full length of the connection ID, other QUIC versions in order to properly form a version
producing a length between 4 and 18 bytes inclusive. For example, negotiation packet.
a byte with the value 0x50 describes an 8-byte Destination
Connection ID and a zero-length Source Connection ID.
Destination Connection ID: The Destination Connection ID field Destination Connection ID: The Destination Connection ID field
follows the DCID Len and is between 0 and 20 bytes in length. follows the DCID Len and is between 0 and 20 bytes in length.
Section 7.2 describes the use of this field in more detail. Section 7.2 describes the use of this field in more detail.
SCID Len: The byte following the Destination Connection ID contains SCID Len: The byte following the Destination Connection ID contains
the length in bytes of the Source Connection ID field that follows the length in bytes of the Source Connection ID field that follows
it. This length is encoded as a 8-bit unsigned integer. In QUIC it. This length is encoded as a 8-bit unsigned integer. In QUIC
version 1, this value MUST NOT exceed 20 bytes. Endpoints that version 1, this value MUST NOT exceed 20 bytes. Endpoints that
receive a version 1 long header with a value larger than 20 MUST receive a version 1 long header with a value larger than 20 MUST
skipping to change at page 89, line 31 skipping to change at page 91, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ... | Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-RTT Packet 0-RTT Packet
Packet numbers for 0-RTT protected packets use the same space as Packet numbers for 0-RTT protected packets use the same space as
1-RTT protected packets. 1-RTT protected packets.
After a client receives a Retry packet, 0-RTT packets are likely to After a client receives a Retry packet, 0-RTT packets are likely to
have been lost or discarded by the server. A client MAY attempt to have been lost or discarded by the server. A client SHOULD attempt
resend data in 0-RTT packets after it sends a new Initial packet. to resend data in 0-RTT packets after it sends a new Initial packet.
A client MUST NOT reset the packet number it uses for 0-RTT packets, A client MUST NOT reset the packet number it uses for 0-RTT packets,
since the keys used to protect 0-RTT packets will not change as a since the keys used to protect 0-RTT packets will not change as a
result of responding to a Retry packet. Sending packets with the result of responding to a Retry packet. Sending packets with the
same packet number in that case is likely to compromise the packet same packet number in that case is likely to compromise the packet
protection for all 0-RTT packets because the same key and nonce could protection for all 0-RTT packets because the same key and nonce could
be used to protect different content. be used to protect different content.
A client only receives acknowledgments for its 0-RTT packets once the A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete. Consequently, a server might expect 0-RTT handshake is complete. Consequently, a server might expect 0-RTT
skipping to change at page 93, line 29 skipping to change at page 95, line 29
0-RTT packets to the connection ID provided by the server. A client 0-RTT packets to the connection ID provided by the server. A client
MUST NOT change the cryptographic handshake message it sends in MUST NOT change the cryptographic handshake message it sends in
response to receiving a Retry. response to receiving a Retry.
A client MUST NOT reset the packet number for any packet number space A client MUST NOT reset the packet number for any packet number space
after processing a Retry packet; Section 17.2.3 contains more after processing a Retry packet; Section 17.2.3 contains more
information on this. information on this.
A server acknowledges the use of a Retry packet for a connection A server acknowledges the use of a Retry packet for a connection
using the original_connection_id transport parameter (see using the original_connection_id transport parameter (see
Section 18.1). If the server sends a Retry packet, it MUST include Section 18.2). If the server sends a Retry packet, it MUST include
the value of the Original Destination Connection ID field of the the value of the Original Destination Connection ID field of the
Retry packet (that is, the Destination Connection ID field from the Retry packet (that is, the Destination Connection ID field from the
client's first Initial packet) in the transport parameter. client's first Initial packet) in the transport parameter.
If the client received and processed a Retry packet, it MUST validate If the client received and processed a Retry packet, it MUST validate
that the original_connection_id transport parameter is present and that the original_connection_id transport parameter is present and
correct; otherwise, it MUST validate that the transport parameter is correct; otherwise, it MUST validate that the transport parameter is
absent. A client MUST treat a failed validation as a connection absent. A client MUST treat a failed validation as a connection
error of type TRANSPORT_PARAMETER_ERROR. error of type TRANSPORT_PARAMETER_ERROR.
skipping to change at page 96, line 5 skipping to change at page 98, line 5
disabled for a connection. Implementations MUST allow administrators disabled for a connection. Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on of clients and servers to disable the spin bit either globally or on
a per-connection basis. Even when the spin bit is not disabled by a per-connection basis. Even when the spin bit is not disabled by
the administrator, implementations MUST disable the spin bit for a the administrator, implementations MUST disable the spin bit for a
given connection with a certain likelihood. The random selection given connection with a certain likelihood. The random selection
process SHOULD be designed such that on average the spin bit is process SHOULD be designed such that on average the spin bit is
disabled for at least one eighth of network paths. The selection disabled for at least one eighth of network paths. The selection
process performed at the beginning of the connection SHOULD be process performed at the beginning of the connection SHOULD be
applied for all paths used by the connection. applied for all paths used by the connection.
In case multiple connections share the same network path, as
determined by having the same source and destination IP address and
UDP ports, endpoints should try to co-ordinate across all connections
to ensure a clear signal to any on-path measurement points.
When the spin bit is disabled, endpoints MAY set the spin bit to any When the spin bit is disabled, endpoints MAY set the spin bit to any
value, and MUST ignore any incoming value. It is RECOMMENDED that value, and MUST ignore any incoming value. It is RECOMMENDED that
endpoints set the spin bit to a random value either chosen endpoints set the spin bit to a random value either chosen
independently for each packet or chosen independently for each independently for each packet or chosen independently for each
connection ID. connection ID.
If the spin bit is enabled for the connection, the endpoint maintains If the spin bit is enabled for the connection, the endpoint maintains
a spin value and sets the spin bit in the short header to the a spin value and sets the spin bit in the short header to the
currently stored value when a packet with a short header is sent out. currently stored value when a packet with a short header is sent out.
The spin value is initialized to 0 in the endpoint at connection The spin value is initialized to 0 in the endpoint at connection
skipping to change at page 97, line 18 skipping to change at page 99, line 18
stateless_reset_token(2), stateless_reset_token(2),
max_packet_size(3), max_packet_size(3),
initial_max_data(4), initial_max_data(4),
initial_max_stream_data_bidi_local(5), initial_max_stream_data_bidi_local(5),
initial_max_stream_data_bidi_remote(6), initial_max_stream_data_bidi_remote(6),
initial_max_stream_data_uni(7), initial_max_stream_data_uni(7),
initial_max_streams_bidi(8), initial_max_streams_bidi(8),
initial_max_streams_uni(9), initial_max_streams_uni(9),
ack_delay_exponent(10), ack_delay_exponent(10),
max_ack_delay(11), max_ack_delay(11),
disable_migration(12), disable_active_migration(12),
preferred_address(13), preferred_address(13),
active_connection_id_limit(14), active_connection_id_limit(14),
(65535) (65535)
} TransportParameterId; } TransportParameterId;
struct { struct {
TransportParameterId parameter; TransportParameterId parameter;
opaque value<0..2^16-1>; opaque value<0..2^16-1>;
} TransportParameter; } TransportParameter;
skipping to change at page 97, line 41 skipping to change at page 99, line 41
Figure 15: Definition of TransportParameters Figure 15: Definition of TransportParameters
The "extension_data" field of the quic_transport_parameters extension The "extension_data" field of the quic_transport_parameters extension
defined in [QUIC-TLS] contains a TransportParameters value. TLS defined in [QUIC-TLS] contains a TransportParameters value. TLS
encoding rules are therefore used to describe the encoding of encoding rules are therefore used to describe the encoding of
transport parameters. transport parameters.
QUIC encodes transport parameters into a sequence of bytes, which are QUIC encodes transport parameters into a sequence of bytes, which are
then included in the cryptographic handshake. then included in the cryptographic handshake.
18.1. Transport Parameter Definitions 18.1. Reserved Transport Parameters
Transport parameters with an identifier of the form "31 * N + 27" for
integer values of N are reserved to exercise the requirement that
unknown transport parameters be ignored. These transport parameters
have no semantics, and may carry arbitrary values.
18.2. Transport Parameter Definitions
This section details the transport parameters defined in this This section details the transport parameters defined in this
document. document.
Many transport parameters listed here have integer values. Those Many transport parameters listed here have integer values. Those
transport parameters that are identified as integers use a variable- transport parameters that are identified as integers use a variable-
length integer encoding (see Section 16) and have a default value of length integer encoding (see Section 16) and have a default value of
0 if the transport parameter is absent, unless otherwise stated. 0 if the transport parameter is absent, unless otherwise stated.
The following transport parameters are defined: The following transport parameters are defined:
skipping to change at page 99, line 47 skipping to change at page 102, line 5
max_ack_delay (0x000b): The maximum ACK delay is an integer value max_ack_delay (0x000b): The maximum ACK delay is an integer value
indicating the maximum amount of time in milliseconds by which the indicating the maximum amount of time in milliseconds by which the
endpoint will delay sending acknowledgments. This value SHOULD endpoint will delay sending acknowledgments. This value SHOULD
include the receiver's expected delays in alarms firing. For include the receiver's expected delays in alarms firing. For
example, if a receiver sets a timer for 5ms and alarms commonly example, if a receiver sets a timer for 5ms and alarms commonly
fire up to 1ms late, then it should send a max_ack_delay of 6ms. fire up to 1ms late, then it should send a max_ack_delay of 6ms.
If this value is absent, a default of 25 milliseconds is assumed. If this value is absent, a default of 25 milliseconds is assumed.
Values of 2^14 or greater are invalid. Values of 2^14 or greater are invalid.
disable_migration (0x000c): The disable migration transport disable_active_migration (0x000c): The disable active migration
parameter is included if the endpoint does not support connection transport parameter is included if the endpoint does not support
migration (Section 9). Peers of an endpoint that sets this active connection migration (Section 9). Peers of an endpoint
transport parameter MUST NOT send any packets, including probing that sets this transport parameter MUST NOT send any packets,
packets (Section 9.1), from a local address or port other than including probing packets (Section 9.1), from a local address or
that used to perform the handshake. This parameter is a zero- port other than that used to perform the handshake. This
length value. parameter is a zero-length value.
preferred_address (0x000d): The server's preferred address is used preferred_address (0x000d): The server's preferred address is used
to effect a change in server address at the end of the handshake, to effect a change in server address at the end of the handshake,
as described in Section 9.6. The format of this transport as described in Section 9.6. The format of this transport
parameter is the PreferredAddress struct shown in Figure 16. This parameter is the PreferredAddress struct shown in Figure 16. This
transport parameter is only sent by a server. Servers MAY choose transport parameter is only sent by a server. Servers MAY choose
to only send a preferred address of one address family by sending to only send a preferred address of one address family by sending
an all-zero address and port (0.0.0.0:0 or ::.0) for the other an all-zero address and port (0.0.0.0:0 or ::.0) for the other
family. family. IP addresses are encoded in network byte order.
struct { struct {
opaque ipv4Address[4]; opaque ipv4Address[4];
uint16 ipv4Port; uint16 ipv4Port;
opaque ipv6Address[16]; opaque ipv6Address[16];
uint16 ipv6Port; uint16 ipv6Port;
opaque connectionId<0..18>; opaque connectionId<0..20>;
opaque statelessResetToken[16]; opaque statelessResetToken[16];
} PreferredAddress; } PreferredAddress;
Figure 16: Preferred Address format Figure 16: Preferred Address format
active_connection_id_limit (0x000e): The maximum number of active_connection_id_limit (0x000e): The maximum number of
connection IDs from the peer that an endpoint is willing to store. connection IDs from the peer that an endpoint is willing to store.
This value includes only connection IDs sent in NEW_CONNECTION_ID This value includes only connection IDs sent in NEW_CONNECTION_ID
frames. If this parameter is absent, a default of 0 is assumed. frames. If this parameter is absent, a default of 0 is assumed.
skipping to change at page 103, line 4 skipping to change at page 105, line 11
the largest packet number that the peer has received prior to the largest packet number that the peer has received prior to
generating the ACK frame. Unlike the packet number in the QUIC generating the ACK frame. Unlike the packet number in the QUIC
long or short header, the value in an ACK frame is not truncated. long or short header, the value in an ACK frame is not truncated.
ACK Delay: A variable-length integer representing the time delta in ACK Delay: A variable-length integer representing the time delta in
microseconds between when this ACK was sent and when the largest microseconds between when this ACK was sent and when the largest
acknowledged packet, as indicated in the Largest Acknowledged acknowledged packet, as indicated in the Largest Acknowledged
field, was received by this peer. The value of the ACK Delay field, was received by this peer. The value of the ACK Delay
field is scaled by multiplying the encoded value by 2 to the power field is scaled by multiplying the encoded value by 2 to the power
of the value of the "ack_delay_exponent" transport parameter set of the value of the "ack_delay_exponent" transport parameter set
by the sender of the ACK frame (see Section 18.1). Scaling in by the sender of the ACK frame (see Section 18.2). Scaling in
this fashion allows for a larger range of values with a shorter this fashion allows for a larger range of values with a shorter
encoding at the cost of lower resolution. Because the receiver encoding at the cost of lower resolution. Because the receiver
doesn't use the ACK Delay for Initial and Handshake packets, a doesn't use the ACK Delay for Initial and Handshake packets, a
sender SHOULD send a value of 0. sender SHOULD send a value of 0.
ACK Range Count: A variable-length integer specifying the number of ACK Range Count: A variable-length integer specifying the number of
Gap and ACK Range fields in the frame. Gap and ACK Range fields in the frame.
First ACK Range: A variable-length integer indicating the number of First ACK Range: A variable-length integer indicating the number of
contiguous packets preceding the Largest Acknowledged that are contiguous packets preceding the Largest Acknowledged that are
skipping to change at page 105, line 44 skipping to change at page 107, line 44
| ECT(0) Count (i) ... | ECT(0) Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT(1) Count (i) ... | ECT(1) Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Count (i) ... | ECN-CE Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The three ECN Counts are: The three ECN Counts are:
ECT(0) Count: A variable-length integer representing the total ECT(0) Count: A variable-length integer representing the total
number of packets received with the ECT(0) codepoint. number of packets received with the ECT(0) codepoint in the packet
number space of the ACK frame.
ECT(1) Count: A variable-length integer representing the total ECT(1) Count: A variable-length integer representing the total
number of packets received with the ECT(1) codepoint. number of packets received with the ECT(1) codepoint in the packet
number space of the ACK frame.
CE Count: A variable-length integer representing the total number of CE Count: A variable-length integer representing the total number of
packets received with the CE codepoint. packets received with the CE codepoint in the packet number space
of the ACK frame.
ECN counts are maintained separately for each packet number space. ECN counts are maintained separately for each packet number space.
19.4. RESET_STREAM Frame 19.4. RESET_STREAM Frame
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly
terminate the sending part of a stream. terminate the sending part of a stream.
After sending a RESET_STREAM, an endpoint ceases transmission and After sending a RESET_STREAM, an endpoint ceases transmission and
retransmission of STREAM frames on the identified stream. A receiver retransmission of STREAM frames on the identified stream. A receiver
skipping to change at page 107, line 29 skipping to change at page 109, line 34
Stream ID: A variable-length integer carrying the Stream ID of the Stream ID: A variable-length integer carrying the Stream ID of the
stream being ignored. stream being ignored.
Application Error Code: A variable-length integer containing the Application Error Code: A variable-length integer containing the
application-specified reason the sender is ignoring the stream application-specified reason the sender is ignoring the stream
(see Section 20.1). (see Section 20.1).
19.6. CRYPTO Frame 19.6. CRYPTO Frame
The CRYPTO frame (type=0x06) is used to transmit cryptographic The CRYPTO frame (type=0x06) is used to transmit cryptographic
handshake messages. It can be sent in all packet types. The CRYPTO handshake messages. It can be sent in all packet types except 0-RTT.
frame offers the cryptographic protocol an in-order stream of bytes. The CRYPTO frame offers the cryptographic protocol an in-order stream
CRYPTO frames are functionally identical to STREAM frames, except of bytes. CRYPTO frames are functionally identical to STREAM frames,
that they do not bear a stream identifier; they are not flow except that they do not bear a stream identifier; they are not flow
controlled; and they do not carry markers for optional offset, controlled; and they do not carry markers for optional offset,
optional length, and the end of the stream. optional length, and the end of the stream.
The CRYPTO frame is as follows: The CRYPTO frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset (i) ... | Offset (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 120, line 19 skipping to change at page 122, line 43
TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport TRANSPORT_PARAMETER_ERROR (0x8): An endpoint received transport
parameters that were badly formatted, included an invalid value, parameters that were badly formatted, included an invalid value,
was absent even though it is mandatory, was present though it is was absent even though it is mandatory, was present though it is
forbidden, or is otherwise in error. forbidden, or is otherwise in error.
PROTOCOL_VIOLATION (0xA): An endpoint detected an error with PROTOCOL_VIOLATION (0xA): An endpoint detected an error with
protocol compliance that was not covered by more specific error protocol compliance that was not covered by more specific error
codes. codes.
INVALID_MIGRATION (0xC): A peer has migrated to a different network
when the endpoint had disabled migration.
CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in CRYPTO_BUFFER_EXCEEDED (0xD): An endpoint has received more data in
CRYPTO frames than it can buffer. CRYPTO frames than it can buffer.
CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range
of 256 values is reserved for carrying error codes specific to the of 256 values is reserved for carrying error codes specific to the
cryptographic handshake that is used. Codes for errors occurring cryptographic handshake that is used. Codes for errors occurring
when TLS is used for the crypto handshake are described in when TLS is used for the crypto handshake are described in
Section 4.8 of [QUIC-TLS]. Section 4.8 of [QUIC-TLS].
See Section 22.3 for details of registering new error codes. See Section 22.3 for details of registering new error codes.
In defining these error codes, several principles are applied. Error
conditions that might require specific action on the part of a
recipient are given unique codes. Errors that represent common
conditions are given specific codes. Absent either of these
conditions, error codes are used to identify a general function of
the stack, like flow control or transport parameter handling.
Finally, generic errors are provided for conditions where
implementations are unable or unwilling to use more specific codes.
20.1. Application Protocol Error Codes 20.1. Application Protocol Error Codes
Application protocol error codes are 62-bit unsigned integers, but Application protocol error codes are 62-bit unsigned integers, but
the management of application error codes is left to application the management of application error codes is left to application
protocols. Application protocol error codes are used for the protocols. Application protocol error codes are used for the
RESET_STREAM frame (Section 19.4), the STOP_SENDING frame RESET_STREAM frame (Section 19.4), the STOP_SENDING frame
(Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d
(Section 19.19). (Section 19.19).
21. Security Considerations 21. Security Considerations
skipping to change at page 123, line 22 skipping to change at page 126, line 7
21.6. Stream Commitment Attack 21.6. Stream Commitment Attack
An adversarial endpoint can open lots of streams, exhausting state on An adversarial endpoint can open lots of streams, exhausting state on
an endpoint. The adversarial endpoint could repeat the process on a an endpoint. The adversarial endpoint could repeat the process on a
large number of connections, in a manner similar to SYN flooding large number of connections, in a manner similar to SYN flooding
attacks in TCP. attacks in TCP.
Normally, clients will open streams sequentially, as explained in Normally, clients will open streams sequentially, as explained in
Section 2.1. However, when several streams are initiated at short Section 2.1. However, when several streams are initiated at short
intervals, transmission error may cause STREAM DATA frames opening intervals, loss or reordering may cause STREAM frames that open
streams to be received out of sequence. A receiver is obligated to streams to be received out of sequence. On receiving a higher-
open intervening streams if a higher-numbered stream ID is received. numbered stream ID, a receiver is required to open all intervening
Thus, on a new connection, opening stream 2000001 opens 1 million streams of the same type (see Section 3.2). Thus, on a new
streams, as required by the specification. connection, opening stream 4000000 opens 1 million and 1 client-
initiated bidirectional streams.
The number of active streams is limited by the The number of active streams is limited by the
initial_max_streams_bidi and initial_max_streams_uni transport initial_max_streams_bidi and initial_max_streams_uni transport
parameters, as explained in Section 4.5. If chosen judiciously, parameters, as explained in Section 4.5. If chosen judiciously,
these limits mitigate the effect of the stream commitment attack. these limits mitigate the effect of the stream commitment attack.
However, setting the limit too low could affect performance when However, setting the limit too low could affect performance when
applications expect to open large number of streams. applications expect to open large number of streams.
21.7. Explicit Congestion Notification Attacks 21.7. Peer Denial of Service
QUIC and TLS both contain messages that have legitimate uses in some
contexts, but that can be abused to cause a peer to expend processing
resources without having any observable impact on the state of the
connection.
Messages can also be used to change and revert state in small or
inconsequential ways, such as by sending small increments to flow
control limits.
If processing costs are disproportionately large in comparison to
bandwidth consumption or effect on state, then this could allow a
malicious peer to exhaust processing capacity.
While there are legitimate uses for all messages, implementations
SHOULD track cost of processing relative to progress and treat
excessive quantities of any non-productive packets as indicative of
an attack. Endpoints MAY respond to this condition with a connection
error, or by dropping packets.
21.8. Explicit Congestion Notification Attacks
An on-path attacker could manipulate the value of ECN codepoints in An on-path attacker could manipulate the value of ECN codepoints in
the IP header to influence the sender's rate. [RFC3168] discusses the IP header to influence the sender's rate. [RFC3168] discusses
manipulations and their effects in more detail. manipulations and their effects in more detail.
An on-the-side attacker can duplicate and send packets with modified An on-the-side attacker can duplicate and send packets with modified
ECN codepoints to affect the sender's rate. If duplicate packets are ECN codepoints to affect the sender's rate. If duplicate packets are
discarded by a receiver, an off-path attacker will need to race the discarded by a receiver, an off-path attacker will need to race the
duplicate packet against the original to be successful in this duplicate packet against the original to be successful in this
attack. Therefore, QUIC endpoints ignore the ECN codepoint field on attack. Therefore, QUIC endpoints ignore the ECN codepoint field on
an IP packet unless at least one QUIC packet in that IP packet is an IP packet unless at least one QUIC packet in that IP packet is
successfully processed; see Section 13.3. successfully processed; see Section 13.3.
21.8. Stateless Reset Oracle 21.9. Stateless Reset Oracle
Stateless resets create a possible denial of service attack analogous Stateless resets create a possible denial of service attack analogous
to a TCP reset injection. This attack is possible if an attacker is to a TCP reset injection. This attack is possible if an attacker is
able to cause a stateless reset token to be generated for a able to cause a stateless reset token to be generated for a
connection with a selected connection ID. An attacker that can cause connection with a selected connection ID. An attacker that can cause
this token to be generated can reset an active connection with the this token to be generated can reset an active connection with the
same connection ID. same connection ID.
If a packet can be routed to different instances that share a static If a packet can be routed to different instances that share a static
key, for example by changing an IP address or port, then an attacker key, for example by changing an IP address or port, then an attacker
skipping to change at page 124, line 32 skipping to change at page 127, line 34
In the case of a cluster that uses dynamic load balancing, it's In the case of a cluster that uses dynamic load balancing, it's
possible that a change in load balancer configuration could happen possible that a change in load balancer configuration could happen
while an active instance retains connection state; even if an while an active instance retains connection state; even if an
instance retains connection state, the change in routing and instance retains connection state, the change in routing and
resulting stateless reset will result in the connection being resulting stateless reset will result in the connection being
terminated. If there is no chance in the packet being routed to the terminated. If there is no chance in the packet being routed to the
correct instance, it is better to send a stateless reset than wait correct instance, it is better to send a stateless reset than wait
for connections to time out. However, this is acceptable only if the for connections to time out. However, this is acceptable only if the
routing cannot be influenced by an attacker. routing cannot be influenced by an attacker.
21.9. Version Downgrade 21.10. Version Downgrade
This document defines QUIC Version Negotiation packets Section 6, This document defines QUIC Version Negotiation packets Section 6,
which can be used to negotiate the QUIC version used between two which can be used to negotiate the QUIC version used between two
endpoints. However, this document does not specify how this endpoints. However, this document does not specify how this
negotiation will be performed between this version and subsequent negotiation will be performed between this version and subsequent
future versions. In particular, Version Negotiation packets do not future versions. In particular, Version Negotiation packets do not
contain any mechanism to prevent version downgrade attacks. Future contain any mechanism to prevent version downgrade attacks. Future
versions of QUIC that use Version Negotiation packets MUST define a versions of QUIC that use Version Negotiation packets MUST define a
mechanism that is robust against version downgrade attacks. mechanism that is robust against version downgrade attacks.
21.10. Targeted Attacks by Routing 21.11. Targeted Attacks by Routing
Deployments should limit the ability of an attacker to target a new Deployments should limit the ability of an attacker to target a new
connection to a particular server instance. This means that client- connection to a particular server instance. This means that client-
controlled fields, such as the initial Destination Connection ID used controlled fields, such as the initial Destination Connection ID used
on Initial and 0-RTT packets SHOULD NOT be used by themselves to make on Initial and 0-RTT packets SHOULD NOT be used by themselves to make
routing decisions. Ideally, routing decisions are made independently routing decisions. Ideally, routing decisions are made independently
of client-selected values; a Source Connection ID can be selected to of client-selected values; a Source Connection ID can be selected to
route later packets to the same server. route later packets to the same server.
22. IANA Considerations 22. IANA Considerations
skipping to change at page 126, line 8 skipping to change at page 129, line 8
readily accessible. Expert(s) are encouraged to be biased towards readily accessible. Expert(s) are encouraged to be biased towards
approving registrations unless they are abusive, frivolous, or approving registrations unless they are abusive, frivolous, or
actively harmful (not merely aesthetically displeasing, or actively harmful (not merely aesthetically displeasing, or
architecturally dubious). architecturally dubious).
The initial contents of this registry are shown in Table 6. The initial contents of this registry are shown in Table 6.
+--------+-------------------------------------+---------------+ +--------+-------------------------------------+---------------+
| Value | Parameter Name | Specification | | Value | Parameter Name | Specification |
+--------+-------------------------------------+---------------+ +--------+-------------------------------------+---------------+
| 0x0000 | original_connection_id | Section 18.1 | | 0x0000 | original_connection_id | Section 18.2 |
| | | | | | | |
| 0x0001 | idle_timeout | Section 18.1 | | 0x0001 | idle_timeout | Section 18.2 |
| | | | | | | |
| 0x0002 | stateless_reset_token | Section 18.1 | | 0x0002 | stateless_reset_token | Section 18.2 |
| | | | | | | |
| 0x0003 | max_packet_size | Section 18.1 | | 0x0003 | max_packet_size | Section 18.2 |
| | | | | | | |
| 0x0004 | initial_max_data | Section 18.1 | | 0x0004 | initial_max_data | Section 18.2 |
| | | | | | | |
| 0x0005 | initial_max_stream_data_bidi_local | Section 18.1 | | 0x0005 | initial_max_stream_data_bidi_local | Section 18.2 |
| | | | | | | |
| 0x0006 | initial_max_stream_data_bidi_remote | Section 18.1 | | 0x0006 | initial_max_stream_data_bidi_remote | Section 18.2 |
| | | | | | | |
| 0x0007 | initial_max_stream_data_uni | Section 18.1 | | 0x0007 | initial_max_stream_data_uni | Section 18.2 |
| | | | | | | |
| 0x0008 | initial_max_streams_bidi | Section 18.1 | | 0x0008 | initial_max_streams_bidi | Section 18.2 |
| | | | | | | |
| 0x0009 | initial_max_streams_uni | Section 18.1 | | 0x0009 | initial_max_streams_uni | Section 18.2 |
| | | | | | | |
| 0x000a | ack_delay_exponent | Section 18.1 | | 0x000a | ack_delay_exponent | Section 18.2 |
| | | | | | | |
| 0x000b | max_ack_delay | Section 18.1 | | 0x000b | max_ack_delay | Section 18.2 |
| | | | | | | |
| 0x000c | disable_migration | Section 18.1 | | 0x000c | disable_active_migration | Section 18.2 |
| | | | | | | |
| 0x000d | preferred_address | Section 18.1 | | 0x000d | preferred_address | Section 18.2 |
| | | | | | | |
| 0x000e | active_connection_id_limit | Section 18.1 | | 0x000e | active_connection_id_limit | Section 18.2 |
+--------+-------------------------------------+---------------+ +--------+-------------------------------------+---------------+
Table 6: Initial QUIC Transport Parameters Entries Table 6: Initial QUIC Transport Parameters Entries
Additionally, each value of the format "31 * N + 27" for integer
values of N (that is, "27", "58", "89", ...) MUST NOT be assigned by
IANA.
22.2. QUIC Frame Type Registry 22.2. QUIC Frame Type Registry
IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
"QUIC Protocol" heading. "QUIC Protocol" heading.
The "QUIC Frame Types" registry governs a 62-bit space. This space The "QUIC Frame Types" registry governs a 62-bit space. This space
is split into three spaces that are governed by different policies. is split into three spaces that are governed by different policies.
Values between 0x00 and 0x3f (in hexadecimal) are assigned via the Values between 0x00 and 0x3f (in hexadecimal) are assigned via the
Standards Action or IESG Review policies [RFC8126]. Values from 0x40 Standards Action or IESG Review policies [RFC8126]. Values from 0x40
to 0x3fff operate on the Specification Required policy [RFC8126]. to 0x3fff operate on the Specification Required policy [RFC8126].
skipping to change at page 129, line 40 skipping to change at page 132, line 40
| 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 | |
| | | | | | | | | |
| 0xA | PROTOCOL_VIOLATION | Generic | Section 20 | | 0xA | PROTOCOL_VIOLATION | Generic | Section 20 |
| | | protocol | | | | | protocol | |
| | | violation | | | | | violation | |
| | | | |
| 0xC | INVALID_MIGRATION | Violated | Section 20 |
| | | disabled | |
| | | migration | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
Table 7: Initial QUIC Transport Error Codes Entries Table 7: Initial QUIC Transport Error Codes Entries
23. References 23. References
23.1. Normative References 23.1. Normative References
[DPLPMTUD] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08
(work in progress), June 2019. (work in progress), June 2019.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-22 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls-
tls-22 (work in progress). latest (work in progress).
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 131, line 50 skipping to change at page 134, line 41
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-05 (work in progress). draft-ietf-quic-invariants-latest (work in progress).
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-05 Transport Protocol", draft-ietf-quic-manageability-05
(work in progress), July 2019. (work in progress), July 2019.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
skipping to change at page 134, line 31 skipping to change at page 137, line 19
datagram (#2308, #2747) datagram (#2308, #2747)
o More normative language about use of stateless reset (#2471, o More normative language about use of stateless reset (#2471,
#2574) #2574)
o Allow reuse of stateless reset tokens (#2732, #2733) o Allow reuse of stateless reset tokens (#2732, #2733)
o Allow, but not require, enforcing non-duplicate transport o Allow, but not require, enforcing non-duplicate transport
parameters (#2689, #2691) parameters (#2689, #2691)
o Added a active_connection_id_limit transport parameter (#1994, o Added an active_connection_id_limit transport parameter (#1994,
#1998) #1998)
o max_ack_delay transport parameter defaults to 0 (#2638, #2646) o max_ack_delay transport parameter defaults to 0 (#2638, #2646)
o When sending 0-RTT, only remembered transport parameters apply o When sending 0-RTT, only remembered transport parameters apply
(#2458, #2360, #2466, #2461) (#2458, #2360, #2466, #2461)
o Define handshake completion and confirmation; define clearer rules o Define handshake completion and confirmation; define clearer rules
when it encryption keys should be discarded (#2214, #2267, #2673) when it encryption keys should be discarded (#2214, #2267, #2673)
 End of changes. 74 change blocks. 
293 lines changed or deleted 437 lines changed or added

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