draft-ietf-quic-transport-18.txt   draft-ietf-quic-transport-19.txt 
QUIC J. Iyengar, Ed. QUIC J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: July 27, 2019 Mozilla Expires: September 12, 2019 Mozilla
January 23, 2019 March 11, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-18 draft-ietf-quic-transport-19
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 July 27, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19 4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20 4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21 4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22 4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22 4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24 5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25 5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25
5.2. Matching Packets to Connections . . . . . . . . . . . . . 25 5.2. Matching Packets to Connections . . . . . . . . . . . . . 26
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 26 5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 26
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 26 5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 27
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 27 5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 27
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 27 6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 28
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28 6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28
6.2. Handling Version Negotiation Packets . . . . . . . . . . 28 6.2. Handling Version Negotiation Packets . . . . . . . . . . 28
6.2.1. Version Negotiation Between Draft Versions . . . . . 29
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29 6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 30 7. Cryptographic and Transport Handshake . . . . . . . . . . . . 29
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 31 7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 31
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32 7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 34 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 33
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34 7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35 7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35
7.3.3. Version Negotiation Validation . . . . . . . . . . . 36 8. Address Validation . . . . . . . . . . . . . . . . . . . . . 35
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 37 8.1. Address Validation During Connection Establishment . . . 35
8.1. Address Validation During Connection Establishment . . . 38 8.1.1. Address Validation using Retry Packets . . . . . . . 36
8.1.1. Address Validation using Retry Packets . . . . . . . 38 8.1.2. Address Validation for Future Connections . . . . . . 37
8.1.2. Address Validation for Future Connections . . . . . . 39 8.1.3. Address Validation Token Integrity . . . . . . . . . 39
8.1.3. Address Validation Token Integrity . . . . . . . . . 41 8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 39
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 41 8.3. Initiating Path Validation . . . . . . . . . . . . . . . 40
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 42 8.4. Path Validation Responses . . . . . . . . . . . . . . . . 40
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 42 8.5. Successful Path Validation . . . . . . . . . . . . . . . 41
8.5. Successful Path Validation . . . . . . . . . . . . . . . 43 8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 41
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 43 9. Connection Migration . . . . . . . . . . . . . . . . . . . . 42
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 44 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 43
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 45 9.2. Initiating Connection Migration . . . . . . . . . . . . . 43
9.2. Initiating Connection Migration . . . . . . . . . . . . . 45 9.3. Responding to Connection Migration . . . . . . . . . . . 44
9.3. Responding to Connection Migration . . . . . . . . . . . 46 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 44
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 46 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 45
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 47 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 45
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 47 9.4. Loss Detection and Congestion Control . . . . . . . . . . 46
9.4. Loss Detection and Congestion Control . . . . . . . . . . 48 9.5. Privacy Implications of Connection Migration . . . . . . 47
9.5. Privacy Implications of Connection Migration . . . . . . 49 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 48
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 50 9.6.1. Communicating A Preferred Address . . . . . . . . . . 48
9.6.1. Communicating A Preferred Address . . . . . . . . . . 50 9.6.2. Responding to Connection Migration . . . . . . . . . 49
9.6.2. Responding to Connection Migration . . . . . . . . . 51 9.6.3. Interaction of Client Migration and Preferred Address 49
9.6.3. Interaction of Client Migration and Preferred Address 51 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 50
10. Connection Termination . . . . . . . . . . . . . . . . . . . 52 10. Connection Termination . . . . . . . . . . . . . . . . . . . 50
10.1. Closing and Draining Connection States . . . . . . . . . 52 10.1. Closing and Draining Connection States . . . . . . . . . 50
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 53 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 52
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 54 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 52
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 55 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 53
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 57 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 56
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 58 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 56
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 59 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 57
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 59 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 58
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 60 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 58
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 60 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 59
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 61 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 59
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 61 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 59
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 62 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 60
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 62 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 61
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 64 12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 62
13. Packetization and Reliability . . . . . . . . . . . . . . . . 66 13. Packetization and Reliability . . . . . . . . . . . . . . . . 65
13.1. Packet Processing and Acknowledgment . . . . . . . . . . 67 13.1. Packet Processing and Acknowledgment . . . . . . . . . . 65
13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 67 13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 66
13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 68 13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 67
13.2. Retransmission of Information . . . . . . . . . . . . . 68 13.2. Retransmission of Information . . . . . . . . . . . . . 67
13.3. Explicit Congestion Notification . . . . . . . . . . . . 71 13.3. Explicit Congestion Notification . . . . . . . . . . . . 69
13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 71 13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 70
13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 72 13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 70
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 73 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 72
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 74 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 73
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 75 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 73
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 76 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 74
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 76 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 75
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 77 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 76
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 78 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 77
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 78 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 77
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 79 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 78
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 82 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 80
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 83 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 82
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 86 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 84
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 87 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 85
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 88 17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 86
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 90 17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 89
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 92 18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 90
18.1. Transport Parameter Definitions . . . . . . . . . . . . 94 18.1. Transport Parameter Definitions . . . . . . . . . . . . 91
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 97 19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 94
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 97 19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 94
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 97 19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 95
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 97 19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 95
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 99 19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 97
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 101 19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 98
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 102 19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 99
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 102 19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 100
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 103 19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 100
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 104 19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 101
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 104 19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 102
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 106 19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 103
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 106 19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 104
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 107 19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 105
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 108 19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 106
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 109 19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 106
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 109 19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 107
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 110 19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 107
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 111 19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 109
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 112 19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 110
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 112 19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 110
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 113 19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 110
19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 114 19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 111
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 114 20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 112
20.1. Application Protocol Error Codes . . . . . . . . . . . . 115 20.1. Application Protocol Error Codes . . . . . . . . . . . . 113
21. Security Considerations . . . . . . . . . . . . . . . . . . . 116 21. Security Considerations . . . . . . . . . . . . . . . . . . . 113
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 116 21.1. Handshake Denial of Service . . . . . . . . . . . . . . 113
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 117 21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 114
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 117 21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 115
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 117 21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 115
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 118 21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 115
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 118 21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 116
21.7. Explicit Congestion Notification Attacks . . . . . . . . 119 21.7. Explicit Congestion Notification Attacks . . . . . . . . 116
21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 119 21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 116
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 119 21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 117
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 119 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117
22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 121 22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 117
22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 122 22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 119
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 125 22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 119
23.1. Normative References . . . . . . . . . . . . . . . . . . 125 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 121
23.2. Informative References . . . . . . . . . . . . . . . . . 126 23.1. Normative References . . . . . . . . . . . . . . . . . . 122
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 128 23.2. Informative References . . . . . . . . . . . . . . . . . 123
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 128 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 125
B.1. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 128 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 125
B.2. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 129 B.1. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 126
B.3. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 130 B.2. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 126
B.4. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 130 B.3. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 127
B.5. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 131 B.4. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 128
B.6. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 132 B.5. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 128
B.7. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 133 B.6. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 128
B.8. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 133 B.7. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 129
B.9. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 134 B.8. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 130
B.10. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 134 B.9. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 130
B.11. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 135 B.10. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 131
B.12. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 136 B.11. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 132
B.13. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 136 B.12. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 132
B.14. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 136 B.13. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 133
B.15. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 137 B.14. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 134
B.16. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 137 B.15. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 134
B.17. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 138 B.16. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 135
B.18. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 140 B.17. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 135
B.19. Since draft-hamilton-quic-transport-protocol-01 . . . . . 140 B.18. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 136
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 141 B.19. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 138
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 141 B.20. Since draft-hamilton-quic-transport-protocol-01 . . . . . 138
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 138
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 139
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
o Low-latency connection establishment o Low-latency connection establishment
o Connection migration and resilience to NAT rebinding o Connection migration and resilience to NAT rebinding
o Authenticated and encrypted header and payload o Authenticated and encrypted header and payload
QUIC uses UDP as a substrate to avoid requiring changes to legacy QUIC uses UDP as a substrate to avoid requiring changes to legacy
client operating systems and middleboxes. QUIC authenticates all of client operating systems and middleboxes. QUIC authenticates all of
its headers and encrypts most of the data it exchanges, including its its headers and encrypts most of the data it exchanges, including its
signaling, to avoid incurring a dependency on middleboxes. signaling, to avoid incurring a dependency on middleboxes.
1.1. Document Structure 1.1. Document Structure
skipping to change at page 8, line 46 skipping to change at page 8, line 50
is as an elastic "message" abstraction. is as an elastic "message" abstraction.
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. Any stream can interleaved with other streams, and can be cancelled. QUIC does not
be initiated by either endpoint. QUIC does not provide any means of provide any means of ensuring ordering between bytes on different
ensuring ordering between bytes on different streams. streams.
QUIC allows for an arbitrary number of streams to operate QUIC allows for an arbitrary number of streams to operate
concurrently and for an arbitrary amount of data to be sent on any concurrently and for an arbitrary amount of data to be sent on any
stream, subject to flow control constraints (see Section 4) and stream, subject to flow control constraints (see Section 4) and
stream limits. stream limits.
2.1. Stream Types and Identifiers 2.1. Stream Types and Identifiers
Streams can be unidirectional or bidirectional. Unidirectional Streams can be unidirectional or bidirectional. Unidirectional
streams carry data in one direction: from the initiator of the stream streams carry data in one direction: from the initiator of the stream
skipping to change at page 25, line 20 skipping to change at page 25, line 20
Endpoints store received connection IDs for future use. An endpoint Endpoints store received connection IDs for future use. An endpoint
that receives excessive connection IDs MAY discard those it cannot that receives excessive connection IDs MAY discard those it cannot
store without sending a RETIRE_CONNECTION_ID frame. An endpoint that store without sending a RETIRE_CONNECTION_ID frame. An endpoint that
issues connection IDs cannot expect its peer to store and use all issues connection IDs cannot expect its peer to store and use all
issued connection IDs. issued connection IDs.
An endpoint SHOULD ensure that its peer has a sufficient number of An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs. While each endpoint available and unused connection IDs. While each endpoint
independently chooses how many connection IDs to issue, endpoints independently chooses how many connection IDs to issue, endpoints
SHOULD provide and maintain at least eight connection IDs. The SHOULD provide and maintain at least eight connection IDs. The
endpoint SHOULD do this by always supplying a new connection ID when endpoint SHOULD do this by supplying a new connection ID when a
a connection ID is retired by its peer or when the endpoint receives connection ID is retired by its peer or when the endpoint receives a
a packet with a previously unused connection ID. Endpoints that packet with a previously unused connection ID. However, it MAY limit
initiate migration and require non-zero-length connection IDs SHOULD the frequency or the total number of connection IDs issued for each
provide their peers with new connection IDs before migration, or risk connection to avoid the risk of running out of connection IDs (see
the peer closing the connection. Section 10.4.2).
An endpoint that initiates migration and requires non-zero-length
connection IDs SHOULD ensure that the pool of connection IDs
available to its peer allows the peer to use a new connection ID on
migration, as the peer will close the connection if the pool is
exhausted.
5.1.2. Consuming and Retiring Connection IDs 5.1.2. Consuming and Retiring Connection IDs
An endpoint can change the connection ID it uses for a peer to An endpoint can change the connection ID it uses for a peer to
another available one at any time during the connection. An endpoint another available one at any time during the connection. An endpoint
consumes connection IDs in response to a migrating peer, see consumes connection IDs in response to a migrating peer, see
Section 9.5 for more. Section 9.5 for more.
An endpoint maintains a set of connection IDs received from its peer, An endpoint maintains a set of connection IDs received from its peer,
any of which it can use when sending packets. When the endpoint any of which it can use when sending packets. When the endpoint
skipping to change at page 26, line 24 skipping to change at page 26, line 30
connection. Endpoints SHOULD either reject connection attempts that connection. Endpoints SHOULD either reject connection attempts that
use the same addresses as existing connections, or use a non-zero- use the same addresses as existing connections, or use a non-zero-
length Destination Connection ID so that packets can be correctly length Destination Connection ID so that packets can be correctly
attributed to connections. attributed to connections.
Endpoints can send a Stateless Reset (Section 10.4) for any packets Endpoints can send a Stateless Reset (Section 10.4) for any packets
that cannot be attributed to an existing connection. A stateless that cannot be attributed to an existing connection. A stateless
reset allows a peer to more quickly identify when a connection reset allows a peer to more quickly identify when a connection
becomes unusable. becomes unusable.
Packets that are matched to an existing connection, but for which the Packets that are matched to an existing connection are discarded if
endpoint cannot remove packet protection, are discarded. the packets are inconsistent with the state of that connection. For
example, packets are discarded if they indicate a different protocol
version than that of the connection, or if the removal of packet
protection is unsuccessful once the expected keys are available.
Invalid packets without packet protection, such as Initial, Retry, or Invalid packets without packet protection, such as Initial, Retry, or
Version Negotiation, MAY be discarded. An endpoint MUST generate a Version Negotiation, MAY be discarded. An endpoint MUST generate a
connection error if it commits changes to state before discovering an connection error if it commits changes to state before discovering an
error. error.
5.2.1. Client Packet Handling 5.2.1. Client Packet Handling
Valid packets sent to clients always include a Destination Connection Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects. Clients that choose to ID that matches a value the client selects. Clients that choose to
skipping to change at page 27, line 50 skipping to change at page 28, line 12
TBD. TBD.
6. Version Negotiation 6. Version Negotiation
Version negotiation ensures that client and server agree to a QUIC Version negotiation ensures that client and server agree to a QUIC
version that is mutually supported. A server sends a Version version that is mutually supported. A server sends a Version
Negotiation packet in response to each packet that might initiate a Negotiation packet in response to each packet that might initiate a
new connection, see Section 5.2 for details. new connection, see Section 5.2 for details.
The first few messages of an exchange between a client attempting to
create a new connection with server is shown in Figure 3. After
version negotiation completes, connection establishment can proceed,
for example as shown in Section 7.1.
Client Server
Packet (v=X) ->
<- Version Negotiation (supported=Y,Z)
Packet (v=Y) ->
<- Packet(s) (v=Y)
Figure 3: Example Version Negotiation Exchange
The size of the first packet sent by a client will determine whether The size of the first packet sent by a client will determine whether
a server sends a Version Negotiation packet. Clients that support a server sends a Version Negotiation packet. Clients that support
multiple QUIC versions SHOULD pad the first packet they send to the multiple QUIC versions SHOULD pad the first packet they send to the
largest of the minimum packet sizes across all versions they support. largest of the minimum packet sizes across all versions they support.
This ensures that the server responds if there is a mutually This ensures that the server responds if there is a mutually
supported version. supported version.
6.1. Sending Version Negotiation Packets 6.1. Sending Version Negotiation Packets
If the version selected by the client is not acceptable to the If the version selected by the client is not acceptable to the
skipping to change at page 28, line 48 skipping to change at page 28, line 41
a response or it abandons the connection attempt. a response or it abandons the connection attempt.
A server MAY limit the number of Version Negotiation packets it A server MAY limit the number of Version Negotiation packets it
sends. For instance, a server that is able to recognize packets as sends. For instance, a server that is able to recognize packets as
0-RTT might choose not to send Version Negotiation packets in 0-RTT might choose not to send Version Negotiation packets in
response to 0-RTT packets with the expectation that it will response to 0-RTT packets with the expectation that it will
eventually receive an Initial packet. eventually receive an Initial packet.
6.2. Handling Version Negotiation Packets 6.2. Handling Version Negotiation Packets
When the client receives a Version Negotiation packet, it first When a client receives a Version Negotiation packet, it MUST abandon
checks that the Destination and Source Connection ID fields match the the current connection attempt. Version Negotiation packets are
Source and Destination Connection ID fields in a packet that the designed to allow future versions of QUIC to negotiate the version in
client sent. If this check fails, the packet MUST be discarded. use between endpoints. Future versions of QUIC might change how
implementations that support multiple versions of QUIC react to
Version Negotiation packets when attempting to establish a connection
using this version. How to perform version negotiation is left as
future work defined by future versions of QUIC. In particular, that
future work will need to ensure robustness against version downgrade
attacks Section 21.9.
Once the Version Negotiation packet is determined to be valid, the 6.2.1. Version Negotiation Between Draft Versions
client then selects an acceptable protocol version from the list
provided by the server. The client then attempts to create a
connection using that version. Though the content of the Initial
packet the client sends might not change in response to version
negotiation, a client MUST increase the packet number it uses on
every packet it sends. Packets MUST continue to use long headers
(Section 17.2) and MUST include the new negotiated protocol version.
The client MUST use the long header format and include its selected [[RFC editor: please remove this section before publication.]]
version on all packets until it has 1-RTT keys and it has received a
packet from the server which is not a Version Negotiation packet.
A client MUST NOT change the version it uses unless it is in response When a draft implementation receives a Version Negotiation packet, it
to a Version Negotiation packet from the server. Once a client MAY use it to attempt a new connection with one of the versions
receives a packet from the server which is not a Version Negotiation listed in the packet, instead of abandoning the current connection
packet, it MUST discard other Version Negotiation packets on the same attempt Section 6.2.
connection. Similarly, a client MUST ignore a Version Negotiation
packet if it has already received and acted on a Version Negotiation
packet.
A client MUST ignore a Version Negotiation packet that lists the The client MUST check that the Destination and Source Connection ID
client's chosen version. If the client does not support any of the fields match the Source and Destination Connection ID fields in a
versions the server offers, it aborts the connection attempt. packet that the client sent. If this check fails, the packet MUST be
discarded.
A client MAY attempt 0-RTT after receiving a Version Negotiation Once the Version Negotiation packet is determined to be valid, the
packet. A client that sends additional 0-RTT packets MUST NOT reset client then selects an acceptable protocol version from the list
the packet number to 0 as a result, see Section 17.2.3. provided by the server. The client then attempts to create a new
connection using that version. The new connection MUST use a new
random Destination Connection ID different from the one it had
previously sent.
Version negotiation packets have no cryptographic protection. The Note that this mechanism does not protect against downgrade attacks
result of the negotiation MUST be revalidated as part of the and MUST NOT be used outside of draft implementations.
cryptographic handshake (see Section 7.3.3).
6.3. Using Reserved Versions 6.3. Using Reserved Versions
For a server to use a new version in the future, clients must For a server to use a new version in the future, clients must
correctly handle unsupported versions. To help ensure this, a server correctly handle unsupported versions. To help ensure this, a server
SHOULD include a reserved version (see Section 15) while generating a SHOULD include a reserved version (see Section 15) while generating a
Version Negotiation packet. Version Negotiation packet.
The design of version negotiation permits a server to avoid The design of version negotiation permits a server to avoid
maintaining state for packets that it rejects in this fashion. The maintaining state for packets that it rejects in this fashion.
validation of version negotiation (see Section 7.3.3) only validates
the result of version negotiation, which is the same no matter which
reserved version was sent. A server MAY therefore send different
reserved version numbers in the Version Negotiation Packet and in its
transport parameters.
A client MAY send a packet using a reserved version number. This can A client MAY send a packet using a reserved version number. This can
be used to solicit a list of supported versions from a server. be used to solicit a list of supported versions from a server.
7. Cryptographic and Transport Handshake 7. Cryptographic and Transport Handshake
QUIC relies on a combined cryptographic and transport handshake to QUIC relies on a combined cryptographic and transport handshake to
minimize connection establishment latency. QUIC uses the CRYPTO minimize connection establishment latency. QUIC uses the CRYPTO
frame Section 19.6 to transmit the cryptographic handshake. Version frame Section 19.6 to transmit the cryptographic handshake. Version
0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different 0x00000001 of QUIC uses TLS as described in [QUIC-TLS]; a different
skipping to change at page 30, line 38 skipping to change at page 30, line 23
* 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 the transport parameters of the peer (see
Section 7.3) Section 7.3)
o authenticated confirmation of version negotiation (see
Section 7.3.3)
o authenticated negotiation of an application protocol (TLS uses o authenticated negotiation of an application protocol (TLS uses
ALPN [RFC7301] for this purpose) ALPN [RFC7301] for this purpose)
The first CRYPTO frame from a client MUST be sent in a single packet. The first CRYPTO frame from a client MUST be sent in a single packet.
Any second attempt that is triggered by address validation (see Any second attempt that is triggered by address validation (see
Section 8.1) MUST also be sent within a single packet. This avoids Section 8.1) MUST also be sent within a single packet. This avoids
having to reassemble a message from multiple packets. having to reassemble a message from multiple packets.
The first client packet of the cryptographic handshake protocol MUST The first client packet of the cryptographic handshake protocol MUST
fit within a 1232 byte QUIC packet payload. This includes overheads fit within a 1232 byte QUIC packet payload. This includes overheads
skipping to change at page 31, line 24 skipping to change at page 31, line 12
avoids situations where there is a disagreement about the protocol avoids situations where there is a disagreement about the protocol
that is in use. that is in use.
7.1. Example Handshake Flows 7.1. Example Handshake Flows
Details of how TLS is integrated with QUIC are provided in Details of how TLS is integrated with QUIC are provided in
[QUIC-TLS], but some examples are provided here. An extension of [QUIC-TLS], but some examples are provided here. An extension of
this exchange to support client address validation is shown in this exchange to support client address validation is shown in
Section 8.1.1. Section 8.1.1.
Once any version negotiation and address validation exchanges are Once any address validation exchanges are complete, the cryptographic
complete, the cryptographic handshake is used to agree on handshake is used to agree on cryptographic keys. The cryptographic
cryptographic keys. The cryptographic handshake is carried in handshake is carried in Initial (Section 17.2.2) and Handshake
Initial (Section 17.2.2) and Handshake (Section 17.2.4) packets. (Section 17.2.4) packets.
Figure 4 provides an overview of the 1-RTT handshake. Each line Figure 3 provides an overview of the 1-RTT handshake. Each line
shows a QUIC packet with the packet type and packet number shown shows a QUIC packet with the packet type and packet number shown
first, followed by the frames that are typically contained in those first, followed by the frames that are typically contained in those
packets. So, for instance the first packet is of type Initial, with packets. So, for instance the first packet is of type Initial, with
packet number 0, and contains a CRYPTO frame carrying the packet number 0, and contains a CRYPTO frame carrying the
ClientHello. ClientHello.
Note that multiple QUIC packets - even of different encryption levels Note that multiple QUIC packets - even of different encryption levels
- may be coalesced into a single UDP datagram (see Section 12.2), and - may be coalesced into a single UDP datagram (see Section 12.2), and
so this handshake may consist of as few as 4 UDP datagrams, or any so this handshake may consist of as few as 4 UDP datagrams, or any
number more. For instance, the server's first flight contains number more. For instance, the server's first flight contains
skipping to change at page 32, line 17 skipping to change at page 31, line 44
Initial[0]: CRYPTO[CH] -> Initial[0]: CRYPTO[CH] ->
Initial[0]: CRYPTO[SH] ACK[0] Initial[0]: CRYPTO[SH] ACK[0]
Handshake[0]: CRYPTO[EE, CERT, CV, FIN] Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
<- 1-RTT[0]: STREAM[1, "..."] <- 1-RTT[0]: STREAM[1, "..."]
Initial[1]: ACK[0] Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0] Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[0]: STREAM[0, "..."], ACK[0] -> 1-RTT[0]: STREAM[0, "..."], ACK[0] ->
1-RTT[1]: STREAM[55, "..."], ACK[0] 1-RTT[1]: STREAM[3, "..."], ACK[0]
<- Handshake[1]: ACK[0] <- Handshake[1]: ACK[0]
Figure 4: Example 1-RTT Handshake Figure 3: Example 1-RTT Handshake
Figure 5 shows an example of a connection with a 0-RTT handshake and Figure 4 shows an example of a connection with a 0-RTT handshake and
a single packet of 0-RTT data. Note that as described in a single packet of 0-RTT data. Note that as described in
Section 12.3, the server acknowledges 0-RTT data at the 1-RTT Section 12.3, the server acknowledges 0-RTT data at the 1-RTT
encryption level, and the client sends 1-RTT packets in the same encryption level, and the client sends 1-RTT packets in the same
packet number space. packet number space.
Client Server Client Server
Initial[0]: CRYPTO[CH] Initial[0]: CRYPTO[CH]
0-RTT[0]: STREAM[0, "..."] -> 0-RTT[0]: STREAM[0, "..."] ->
Initial[0]: CRYPTO[SH] ACK[0] Initial[0]: CRYPTO[SH] ACK[0]
Handshake[0] CRYPTO[EE, CERT, CV, FIN] Handshake[0] CRYPTO[EE, FIN]
<- 1-RTT[0]: STREAM[1, "..."] ACK[0] <- 1-RTT[0]: STREAM[1, "..."] ACK[0]
Initial[1]: ACK[0] Initial[1]: ACK[0]
Handshake[0]: CRYPTO[FIN], ACK[0] Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[2]: STREAM[0, "..."] ACK[0] -> 1-RTT[1]: STREAM[0, "..."] ACK[0] ->
1-RTT[1]: STREAM[55, "..."], ACK[1,2] 1-RTT[1]: STREAM[3, "..."], ACK[1]
<- Handshake[1]: ACK[0] <- Handshake[1]: ACK[0]
Figure 5: Example 0-RTT Handshake Figure 4: Example 0-RTT Handshake
7.2. Negotiating Connection IDs 7.2. Negotiating Connection IDs
A connection ID is used to ensure consistent routing of packets, as A connection ID is used to ensure consistent routing of packets, as
described in Section 5.1. The long header contains two connection described in Section 5.1. The long header contains two connection
IDs: the Destination Connection ID is chosen by the recipient of the IDs: the Destination Connection ID is chosen by the recipient of the
packet and is used to provide consistent routing; the Source packet and is used to provide consistent routing; the Source
Connection ID is used to set the Destination Connection ID used by Connection ID is used to set the Destination Connection ID used by
the peer. the peer.
skipping to change at page 33, line 23 skipping to change at page 32, line 50
Source Connection ID that they receive. Source Connection ID that they receive.
When an Initial packet is sent by a client which has not previously When an Initial packet is sent by a client which has not previously
received a Retry packet from the server, it populates the Destination received a Retry packet from the server, it populates the Destination
Connection ID field with an unpredictable value. This MUST be at Connection ID field with an unpredictable value. This MUST be at
least 8 bytes in length. Until a packet is received from the server, least 8 bytes in length. Until a packet is received from the server,
the client MUST use the same value unless it abandons the connection the client MUST use the same value unless it abandons the connection
attempt and starts a new one. The initial Destination Connection ID attempt and starts a new one. The initial Destination Connection ID
is used to determine packet protection keys for Initial packets. is used to determine packet protection keys for Initial packets.
The final version used for a connection might be different from the
version of the first Initial from the client. To enable consistent
routing through the handshake, a client SHOULD select an initial
Destination Connection ID length long enough to fulfill the minimum
size for every QUIC version it supports.
The client populates the Source Connection ID field with a value of The client populates the Source Connection ID field with a value of
its choosing and sets the SCIL field to match. its choosing and sets the SCIL field to indicate the length.
The first flight of 0-RTT packets use the same Destination and Source
Connection ID values as the client's first Initial.
The Destination Connection ID field in the server's Initial packet The Destination Connection ID field in the server's Initial packet
contains a connection ID that is chosen by the recipient of the contains a connection ID that is chosen by the recipient of the
packet (i.e., the client); the Source Connection ID includes the packet (i.e., the client); the Source Connection ID includes the
connection ID that the sender of the packet wishes to use (see connection ID that the sender of the packet wishes to use (see
Section 5.1). The server MUST use consistent Source Connection IDs Section 5.1). The server MUST use consistent Source Connection IDs
during the handshake. during the handshake.
On first receiving an Initial or Retry packet from the server, the On first receiving an Initial or Retry packet from the server, the
client uses the Source Connection ID supplied by the server as the client uses the Source Connection ID supplied by the server as the
Destination Connection ID for subsequent packets. That means that a Destination Connection ID for subsequent packets, including any
client might change the Destination Connection ID twice during subsequent 0-RTT packets. That means that a client might change the
connection establishment, once in response to a Retry and once in Destination Connection ID twice during connection establishment, once
response to the first Initial packet from the server. Once a client in response to a Retry and once in response to the first Initial
has received an Initial packet from the server, it MUST discard any packet from the server. Once a client has received an Initial packet
packet it receives with a different Source Connection ID. from the server, it MUST discard any packet it receives with a
different Source Connection ID.
A client MUST only change the value it sends in the Destination A client MUST only change the value it sends in the Destination
Connection ID in response to the first packet of each type it Connection ID in response to the first packet of each type it
receives from the server (Retry or Initial); a server MUST set its receives from the server (Retry or Initial); a server MUST set its
value based on the Initial packet. Any additional changes are not value based on the Initial packet. Any additional changes are not
permitted; if subsequent packets of those types include a different permitted; if subsequent packets of those types include a different
Source Connection ID, they MUST be discarded. This avoids problems Source Connection ID, they MUST be discarded. This avoids problems
that might arise from stateless processing of multiple Initial that might arise from stateless processing of multiple Initial
packets producing different connection IDs. packets producing different connection IDs.
skipping to change at page 34, line 26 skipping to change at page 33, line 51
declarations of their transport parameters. These declarations are declarations of their transport parameters. These declarations are
made unilaterally by each endpoint. Endpoints are required to comply made unilaterally by each endpoint. Endpoints are required to comply
with the restrictions implied by these parameters; the description of with the restrictions implied by these parameters; the description of
each parameter includes rules for its handling. each parameter includes rules for its handling.
The encoding of the transport parameters is detailed in Section 18. The encoding of the transport parameters is detailed in Section 18.
QUIC includes the encoded transport parameters in the cryptographic QUIC includes the encoded transport parameters in the cryptographic
handshake. Once the handshake completes, the transport parameters handshake. Once the handshake completes, the transport parameters
declared by the peer are available. Each endpoint validates the declared by the peer are available. Each endpoint validates the
value provided by its peer. In particular, version negotiation MUST value provided by its peer.
be validated (see Section 7.3.3) before the connection establishment
is considered properly complete.
Definitions for each of the defined transport parameters are included Definitions for each of the defined transport parameters are included
in Section 18.1. An endpoint MUST treat receipt of a transport in Section 18.1. An endpoint MUST treat receipt of a transport
parameter with an invalid value as a connection error of type parameter with an invalid value as a connection error of type
TRANSPORT_PARAMETER_ERROR. Any given parameter MUST appear at most TRANSPORT_PARAMETER_ERROR. Any given parameter MUST appear at most
once in a given transport parameters extension. An endpoint MUST once in a given transport parameters extension. An endpoint MUST
treat receipt of duplicate transport parameters as a connection error treat receipt of duplicate transport parameters as a connection error
of type TRANSPORT_PARAMETER_ERROR. of type TRANSPORT_PARAMETER_ERROR.
A server MUST include the original_connection_id transport parameter A server MUST include the original_connection_id transport parameter
skipping to change at page 36, line 8 skipping to change at page 35, line 29
7.3.2. New Transport Parameters 7.3.2. New Transport Parameters
New transport parameters can be used to negotiate new protocol New transport parameters can be used to negotiate new protocol
behavior. An endpoint MUST ignore transport parameters that it does behavior. An endpoint MUST ignore transport parameters that it does
not support. Absence of a transport parameter therefore disables any not support. Absence of a transport parameter therefore disables any
optional protocol feature that is negotiated using the parameter. optional protocol feature that is negotiated using the parameter.
New transport parameters can be registered according to the rules in New transport parameters can be registered according to the rules in
Section 22.1. Section 22.1.
7.3.3. Version Negotiation Validation
Though the cryptographic handshake has integrity protection, two
forms of QUIC version downgrade are possible. In the first, an
attacker replaces the QUIC version in the Initial packet. In the
second, a fake Version Negotiation packet is sent by an attacker. To
protect against these attacks, the transport parameters include three
fields that encode version information. These parameters are used to
retroactively authenticate the choice of version (see Section 6).
The cryptographic handshake provides integrity protection for the
negotiated version as part of the transport parameters (see
Section 18.1). As a result, attacks on version negotiation by an
attacker can be detected.
The client includes the initial_version field in its transport
parameters. The initial_version is the version that the client
initially attempted to use. If the server did not send a Version
Negotiation packet Section 17.2.1, this will be identical to the
negotiated_version field in the server transport parameters.
A server that processes all packets in a stateful fashion can
remember how version negotiation was performed and validate the
initial_version value.
A server that does not maintain state for every packet it receives
(i.e., a stateless server) uses a different process. If the
initial_version matches the version of QUIC that is in use, a
stateless server can accept the value.
If the initial_version is different from the version of QUIC that is
in use, a stateless server MUST check that it would have sent a
Version Negotiation packet if it had received a packet with the
indicated initial_version. If a server would have accepted the
version included in the initial_version and the value differs from
the QUIC version that is in use, the server MUST terminate the
connection with a VERSION_NEGOTIATION_ERROR error.
The server includes both the version of QUIC that is in use and a
list of the QUIC versions that the server supports (see
Section 18.1).
The negotiated_version field is the version that is in use. This
MUST be set by the server to the value that is on the Initial packet
that it accepts (not an Initial packet that triggers a Retry or
Version Negotiation packet). A client that receives a
negotiated_version that does not match the version of QUIC that is in
use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR
error code.
The server includes a list of versions that it would send in any
version negotiation packet (Section 17.2.1) in the supported_versions
field. The server populates this field even if it did not send a
version negotiation packet.
The client validates that the negotiated_version is included in the
supported_versions list and - if version negotiation was performed -
that it would have selected the negotiated version. A client MUST
terminate the connection with a VERSION_NEGOTIATION_ERROR error code
if the current QUIC version is not listed in the supported_versions
list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error
code if version negotiation occurred but it would have selected a
different version based on the value of the supported_versions list.
When an endpoint accepts multiple QUIC versions, it can potentially
interpret transport parameters as they are defined by any of the QUIC
versions it supports. The version field in the QUIC packet header is
authenticated using transport parameters. The position and the
format of the version fields in transport parameters MUST either be
identical across different QUIC versions, or be unambiguously
different to ensure no confusion about their interpretation. One way
that a new format could be introduced is to define a TLS extension
with a different codepoint.
8. Address Validation 8. Address Validation
Address validation is used by QUIC to avoid being used for a traffic Address validation is used by QUIC to avoid being used for a traffic
amplification attack. In such an attack, a packet is sent to a amplification attack. In such an attack, a packet is sent to a
server with spoofed source address information that identifies a server with spoofed source address information that identifies a
victim. If a server generates more or larger packets in response to victim. If a server generates more or larger packets in response to
that packet, the attacker can use the server to send more data toward that packet, the attacker can use the server to send more data toward
the victim than it would be able to send on its own. the victim than it would be able to send on its own.
The primary defense against amplification attack is verifying that an The primary defense against amplification attack is verifying that an
skipping to change at page 38, line 30 skipping to change at page 36, line 21
Clients MUST pad UDP datagrams that contain only Initial packets to Clients MUST pad UDP datagrams that contain only Initial packets to
at least 1200 bytes. Once a client has received an acknowledgment at least 1200 bytes. Once a client has received an acknowledgment
for a Handshake packet it MAY send smaller datagrams. Sending padded for a Handshake packet it MAY send smaller datagrams. Sending padded
datagrams ensures that the server is not overly constrained by the datagrams ensures that the server is not overly constrained by the
amplification restriction. amplification restriction.
Packet loss, in particular loss of a Handshake packet from the Packet loss, in particular loss of a Handshake packet from the
server, can cause a situation in which the server cannot send when server, can cause a situation in which the server cannot send when
the client has no data to send and the anti-amplification limit is the client has no data to send and the anti-amplification limit is
reached. In order to avoid this causing a handshake deadlock, reached. In order to avoid this causing a handshake deadlock,
clients SHOULD send a packet upon a handshake timeout, as described clients SHOULD send a packet upon a crypto retransmission timeout, as
in [QUIC-RECOVERY]. If the client has no data to retransmit and does described in [QUIC-RECOVERY]. If the client has no data to
not have Handshake keys, it SHOULD send an Initial packet in a UDP retransmit and does not have Handshake keys, it SHOULD send an
datagram of at least 1200 bytes. If the client has Handshake keys, Initial packet in a UDP datagram of at least 1200 bytes. If the
it SHOULD send a Handshake packet. client has Handshake keys, it SHOULD send a Handshake packet.
A server might wish to validate the client address before starting A server might wish to validate the client address before starting
the cryptographic handshake. QUIC uses a token in the Initial packet the cryptographic handshake. QUIC uses a token in the Initial packet
to provide address validation prior to completing the handshake. to provide address validation prior to completing the handshake.
This token is delivered to the client during connection establishment This token is delivered to the client during connection establishment
with a Retry packet (see Section 8.1.1) or in a previous connection with a Retry packet (see Section 8.1.1) or in a previous connection
using the NEW_TOKEN frame (see Section 8.1.2). using the NEW_TOKEN frame (see Section 8.1.2).
In addition to sending limits imposed prior to address validation, In addition to sending limits imposed prior to address validation,
servers are also constrained in what they can send by the limits set servers are also constrained in what they can send by the limits set
by the congestion controller. Clients are only constrained by the by the congestion controller. Clients are only constrained by the
congestion controller. congestion controller.
8.1.1. Address Validation using Retry Packets 8.1.1. Address Validation using Retry Packets
Upon receiving the client's Initial packet, the server can request Upon receiving the client's Initial packet, the server can request
address validation by sending a Retry packet (Section 17.2.5) address validation by sending a Retry packet (Section 17.2.5)
containing a token. This token MUST be repeated by the client in all containing a token. This token MUST be repeated by the client in all
Initial packets it sends after it receives the Retry packet. In Initial packets it sends for that connection after it receives the
response to processing an Initial containing a token, a server can Retry packet. In response to processing an Initial containing a
either abort the connection or permit it to proceed. token, a server can either abort the connection or permit it to
proceed.
As long as it is not possible for an attacker to generate a valid As long as it is not possible for an attacker to generate a valid
token for its own address (see Section 8.1.3) and the client is able token for its own address (see Section 8.1.3) and the client is able
to return that token, it proves to the server that it received the to return that token, it proves to the server that it received the
token. token.
A server can also use a Retry packet to defer the state and A server can also use a Retry packet to defer the state and
processing costs of connection establishment. By giving the client a processing costs of connection establishment. By giving the client a
different connection ID to use, a server can cause the connection to different connection ID to use, a server can cause the connection to
be routed to a server instance with more resources available for new be routed to a server instance with more resources available for new
connections. connections.
A flow showing the use of a Retry packet is shown in Figure 6. A flow showing the use of a Retry packet is shown in Figure 5.
Client Server Client Server
Initial[0]: CRYPTO[CH] -> Initial[0]: CRYPTO[CH] ->
<- Retry+Token <- Retry+Token
Initial+Token[0]: CRYPTO[CH] -> Initial+Token[1]: CRYPTO[CH] ->
Initial[0]: CRYPTO[SH] ACK[0] Initial[0]: CRYPTO[SH] ACK[1]
Handshake[0]: CRYPTO[EE, CERT, CV, FIN] Handshake[0]: CRYPTO[EE, CERT, CV, FIN]
<- 1-RTT[0]: STREAM[1, "..."] <- 1-RTT[0]: STREAM[1, "..."]
Figure 6: Example Handshake with Retry Figure 5: Example Handshake with Retry
8.1.2. Address Validation for Future Connections 8.1.2. Address Validation for Future Connections
A server MAY provide clients with an address validation token during A server MAY provide clients with an address validation token during
one connection that can be used on a subsequent connection. Address one connection that can be used on a subsequent connection. Address
validation is especially important with 0-RTT because a server validation is especially important with 0-RTT because a server
potentially sends a significant amount of data to a client in potentially sends a significant amount of data to a client in
response to 0-RTT data. response to 0-RTT data.
The server uses the NEW_TOKEN frame Section 19.7 to provide the The server uses the NEW_TOKEN frame Section 19.7 to provide the
client with an address validation token that can be used to validate client with an address validation token that can be used to validate
future connections. The client includes this token in Initial future connections. The client includes this token in Initial
packets to provide address validation in a future connection. The packets to provide address validation in a future connection. The
client MUST include the token in all Initial packets it sends, unless client MUST include the token in all Initial packets it sends, unless
a Retry replaces the token with a newer token. The client MUST NOT a Retry or NEW_TOKEN frame replaces the token with a newer one. The
use the token provided in a Retry for future connections. Servers client MUST NOT use the token provided in a Retry for future
MAY discard any Initial packet that does not carry the expected connections. Servers MAY discard any Initial packet that does not
token. carry the expected token.
Unlike the token that is created for a Retry packet, there might be Unlike the token that is created for a Retry packet, there might be
some time between when the token is created and when the token is some time between when the token is created and when the token is
subsequently used. Thus, a token SHOULD include an expiration time. subsequently used. Thus, a token SHOULD include an expiration time.
The server MAY include either an explicit expiration time or an The server MAY include either an explicit expiration time or an
issued timestamp and dynamically calculate the expiration time. It issued timestamp and dynamically calculate the expiration time. It
is also unlikely that the client port number is the same on two is also unlikely that the client port number is the same on two
different connections; validating the port is therefore unlikely to different connections; validating the port is therefore unlikely to
be successful. be successful.
A token SHOULD be constructed to be easily distinguishable from A token SHOULD be constructed for the server to easily distinguish it
tokens that are sent in Retry packets as they are carried in the same from tokens that are sent in Retry packets as they are carried in the
field. same field.
If the client has a token received in a NEW_TOKEN frame on a previous If the client has a token received in a NEW_TOKEN frame on a previous
connection to what it believes to be the same server, it can include connection to what it believes to be the same server, it SHOULD
that value in the Token field of its Initial packet. include that value in the Token field of its Initial packet.
Including a token might allow the server to validate the client
address without an additional round trip.
A token allows a server to correlate activity between the connection A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used. where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server MAY Clients that want to break continuity of identity with a server MAY
discard tokens provided using the NEW_TOKEN frame. A token obtained discard tokens provided using the NEW_TOKEN frame. A token obtained
in a Retry packet MUST be used immediately during the connection in a Retry packet MUST be used immediately during the connection
attempt and cannot be used in subsequent connection attempts. attempt and cannot be used in subsequent connection attempts.
A client SHOULD NOT reuse a token in different connections. Reusing A client SHOULD NOT reuse a token in different connections. Reusing
a token allows connections to be linked by entities on the network a token allows connections to be linked by entities on the network
path (see Section 9.5). A client MUST NOT reuse a token if it path (see Section 9.5). A client MUST NOT reuse a token if it
believes that its point of network attachment has changed since the believes that its point of network attachment has changed since the
token was last used; that is, if there is a change in its local IP token was last used; that is, if there is a change in its local IP
address or network interface. A client needs to start the connection address or network interface. A client needs to start the connection
process over if it migrates prior to completing the handshake. process over if it migrates prior to completing the handshake.
When a server receives an Initial packet with an address validation When a server receives an Initial packet with an address validation
token, it SHOULD attempt to validate it, unless it has already token, it MUST attempt to validate the token, unless it has already
completed address validation. If the token is invalid then the completed address validation. If the token is invalid then the
server SHOULD proceed as if the client did not have a validated server SHOULD proceed as if the client did not have a validated
address, including potentially sending a Retry. If the validation address, including potentially sending a Retry. If the validation
succeeds, the server SHOULD then allow the handshake to proceed. succeeds, the server SHOULD then allow the handshake to proceed.
Note: The rationale for treating the client as unvalidated rather Note: The rationale for treating the client as unvalidated rather
than discarding the packet is that the client might have received than discarding the packet is that the client might have received
the token in a previous connection using the NEW_TOKEN frame, and the token in a previous connection using the NEW_TOKEN frame, and
if the server has lost state, it might be unable to validate the if the server has lost state, it might be unable to validate the
token at all, leading to connection failure if the packet is token at all, leading to connection failure if the packet is
discarded. A server MAY encode tokens provided with NEW_TOKEN discarded. A server SHOULD encode tokens provided with NEW_TOKEN
frames and Retry packets differently, and validate the latter more frames and Retry packets differently, and validate the latter more
strictly. strictly.
In a stateless design, a server can use encrypted and authenticated In a stateless design, a server can use encrypted and authenticated
tokens to pass information to clients that the server can later tokens to pass information to clients that the server can later
recover and use to validate a client address. Tokens are not recover and use to validate a client address. Tokens are not
integrated into the cryptographic handshake and so they are not integrated into the cryptographic handshake and so they are not
authenticated. For instance, a client might be able to reuse a authenticated. For instance, a client might be able to reuse a
token. To avoid attacks that exploit this property, a server can token. To avoid attacks that exploit this property, a server can
limit its use of tokens to only the information needed to validate limit its use of tokens to only the information needed to validate
skipping to change at page 44, line 33 skipping to change at page 42, line 27
An endpoint MUST NOT initiate connection migration before the An endpoint MUST NOT initiate connection migration before the
handshake is finished and the endpoint has 1-RTT keys. The design of handshake is finished and the endpoint has 1-RTT keys. The design of
QUIC relies on endpoints retaining a stable address for the duration QUIC relies on endpoints retaining a stable address for the duration
of the handshake. of the handshake.
An endpoint also MUST NOT initiate connection migration if the peer An endpoint also MUST NOT initiate connection migration if the peer
sent the "disable_migration" transport parameter during the sent the "disable_migration" transport parameter during the
handshake. An endpoint which has sent this transport parameter, but handshake. An endpoint which has sent this transport parameter, but
detects that a peer has nonetheless migrated to a different network detects that a peer has nonetheless migrated to a different network
MAY treat this as a connection error of type INVALID_MIGRATION. MAY treat this as a connection error of type INVALID_MIGRATION.
Similarly, an endpoint MUST NOT initiate migration if its peer
supplies a zero-length connection ID as packets without a Destination
Connection ID cannot be attributed to a connection based on address
tuple.
Not all changes of peer address are intentional migrations. The peer Not all changes of peer address are intentional migrations. The peer
could experience NAT rebinding: a change of address due to a could experience NAT rebinding: a change of address due to a
middlebox, usually a NAT, allocating a new outgoing port or even a middlebox, usually a NAT, allocating a new outgoing port or even a
new outgoing IP address for a flow. NAT rebinding is not connection new outgoing IP address for a flow. NAT rebinding is not connection
migration as defined in this section, though an endpoint SHOULD migration as defined in this section, though an endpoint SHOULD
perform path validation (Section 8.2) if it detects a change in the perform path validation (Section 8.2) if it detects a change in the
IP address of its peer. IP address of its peer.
When an endpoint has no validated path on which to send packets, it
MAY discard connection state. An endpoint capable of connection
migration MAY wait for a new path to become available before
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
see a non-probing packet from that address. If a client receives see a non-probing packet from that address. If a client receives
packets from an unknown server address, the client MUST discard these packets from an unknown server address, the client MUST discard these
packets. packets.
9.1. Probing a New Path 9.1. Probing a New Path
skipping to change at page 49, line 40 skipping to change at page 47, line 40
Using a stable connection ID on multiple network paths allows a Using a stable connection ID on multiple network paths allows a
passive observer to correlate activity between those paths. An passive observer to correlate activity between those paths. An
endpoint that moves between networks might not wish to have their endpoint that moves between networks might not wish to have their
activity correlated by any entity other than their peer, so different activity correlated by any entity other than their peer, so different
connection IDs are used when sending from different local addresses, connection IDs are used when sending from different local addresses,
as discussed in Section 5.1. For this to be effective endpoints need as discussed in Section 5.1. For this to be effective endpoints need
to ensure that connections IDs they provide cannot be linked by any to ensure that connections IDs they provide cannot be linked by any
other entity. other entity.
This eliminates the use of the connection ID for linking activity At any time, endpoints MAY change the Destination Connection ID they
from the same connection on different networks. Header protection send to a value that has not been used on another path.
ensures that packet numbers cannot be used to correlate activity.
This does not prevent other properties of packets, such as timing and
size, from being used to correlate activity.
Clients MAY move to a new connection ID at any time based on An endpoint MUST use a new connection ID if it initiates connection
implementation-specific concerns. For example, after a period of migration. Using a new connection ID eliminates the use of the
network inactivity NAT rebinding might occur when the client begins connection ID for linking activity from the same connection on
sending data again. different networks. Header protection ensures that packet numbers
cannot be used to correlate activity. This does not prevent other
properties of packets, such as timing and size, from being used to
correlate activity.
Unintentional changes in path without a change in connection ID are
possible. For example, after a period of network inactivity, NAT
rebinding might cause packets to be sent on a new path when the
client resumes sending.
A client might wish to reduce linkability by employing a new A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period connection ID and source UDP port when sending traffic after a period
of inactivity. Changing the UDP port from which it sends packets at of inactivity. Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection the same time might cause the packet to appear as a connection
migration. This ensures that the mechanisms that support migration migration. This ensures that the mechanisms that support migration
are exercised even for clients that don't experience NAT rebindings are exercised even for clients that don't experience NAT rebindings
or genuine migrations. Changing port number can cause a peer to or genuine migrations. Changing port number can cause a peer to
reset its congestion state (see Section 9.4), so the port SHOULD only reset its congestion state (see Section 9.4), so the port SHOULD only
be changed infrequently. be changed infrequently.
Endpoints that use connection IDs with length greater than zero could An endpoint that exhausts available connection IDs cannot migrate.
have their activity correlated if their peers keep using the same To ensure that migration is possible and packets sent on different
destination connection ID after migration. Endpoints that receive paths cannot be correlated, endpoints SHOULD provide new connection
packets with a previously unused Destination Connection ID SHOULD IDs before peers migrate.
change to sending packets with a connection ID that has not been used
on any other network path. The goal here is to ensure that packets
sent on different paths cannot be correlated. To fulfill this
privacy requirement, endpoints that initiate migration and use
connection IDs with length greater than zero SHOULD provide their
peers with new connection IDs before migration.
Caution: If both endpoints change connection ID in response to
seeing a change in connection ID from their peer, then this can
trigger an infinite sequence of changes.
9.6. Server's Preferred Address 9.6. Server's Preferred Address
QUIC allows servers to accept connections on one IP address and QUIC allows servers to accept connections on one IP address and
attempt to transfer these connections to a more preferred address attempt to transfer these connections to a more preferred address
shortly after the handshake. This is particularly useful when shortly after the handshake. This is particularly useful when
clients initially connect to an address shared by multiple servers clients initially connect to an address shared by multiple servers
but would prefer to use a unicast address to ensure connection but would prefer to use a unicast address to ensure connection
stability. This section describes the protocol for migrating a stability. This section describes the protocol for migrating a
connection to a preferred server address. connection to a preferred server address.
skipping to change at page 52, line 17 skipping to change at page 50, line 13
server's preferred address. server's preferred address.
Servers SHOULD initiate path validation to the client's new address Servers SHOULD initiate path validation to the client's new address
upon receiving a probe packet from a different address. Servers MUST upon receiving a probe packet from a different address. Servers MUST
NOT send more than a minimum congestion window's worth of non-probing NOT send more than a minimum congestion window's worth of non-probing
packets to the new address before path validation is complete. packets to the new address before path validation is complete.
A client that migrates to a new address SHOULD use a preferred A client that migrates to a new address SHOULD use a preferred
address from the same address family for the server. address from the same address family for the server.
9.7. Use of IPv6 Flow-Label and Migration
Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label
in compliance with [RFC6437], unless the local API does not allow
setting IPv6 flow labels.
The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the
destination CID. The flow label generation MUST be designed to
minimize the chances of linkability with a previously used flow
label, as this would enable correlating activity on multiple paths
(see Section 9.5).
A possible implementation is to compute the flow label as a
cryptographic hash function of the source and destination addresses,
source and destination UDP ports, destination CID, and a local
secret.
10. Connection Termination 10. Connection Termination
Connections should remain open until they become idle for a pre- An established QUIC connection can be terminated in one of three
negotiated period of time. A QUIC connection, once established, can ways:
be terminated in one of three ways:
o idle timeout (Section 10.2) o idle timeout (Section 10.2)
o immediate close (Section 10.3) o immediate close (Section 10.3)
o stateless reset (Section 10.4) o stateless reset (Section 10.4)
An endpoint MAY discard connection state if it does not have a
validated path on which it can send packets (see Section 8.2).
10.1. Closing and Draining Connection States 10.1. Closing and Draining Connection States
The closing and draining connection states exist to ensure that The closing and draining connection states exist to ensure that
connections close cleanly and that delayed or reordered packets are connections close cleanly and that delayed or reordered packets are
properly discarded. These states SHOULD persist for three times the properly discarded. These states SHOULD persist for at least three
current Probe Timeout (PTO) interval as defined in [QUIC-RECOVERY]. times the current Probe Timeout (PTO) interval as defined in
[QUIC-RECOVERY].
An endpoint enters a closing period after initiating an immediate An endpoint enters a closing period after initiating an immediate
close (Section 10.3). While closing, an endpoint MUST NOT send close (Section 10.3). While closing, an endpoint MUST NOT send
packets unless they contain a CONNECTION_CLOSE frame (see packets unless they contain a CONNECTION_CLOSE frame (see
Section 10.3 for details). An endpoint retains only enough Section 10.3 for details). An endpoint retains only enough
information to generate a packet containing a CONNECTION_CLOSE frame information to generate a packet containing a CONNECTION_CLOSE frame
and to identify packets as belonging to the connection. The and to identify packets as belonging to the connection. The
connection ID and QUIC version is sufficient information to identify endpoint's selected connection ID and the QUIC version are sufficient
packets for a closing connection; an endpoint can discard all other information to identify packets for a closing connection; an endpoint
connection state. An endpoint MAY retain packet protection keys for can discard all other connection state. An endpoint MAY retain
incoming packets to allow it to read and process a CONNECTION_CLOSE packet protection keys for incoming packets to allow it to read and
frame. process a CONNECTION_CLOSE frame.
The draining state is entered once an endpoint receives a signal that The draining state is entered once an endpoint receives a signal that
its peer is closing or draining. While otherwise identical to the its peer is closing or draining. While otherwise identical to the
closing state, an endpoint in the draining state MUST NOT send any closing state, an endpoint in the draining state MUST NOT send any
packets. Retaining packet protection keys is unnecessary once a packets. Retaining packet protection keys is unnecessary once a
connection is in the draining state. connection is in the draining state.
An endpoint MAY transition from the closing period to the draining An endpoint MAY transition from the closing period to the draining
period if it can confirm that its peer is also closing or draining. period if it receives a CONNECTION_CLOSE frame or stateless reset,
Receiving a CONNECTION_CLOSE frame is sufficient confirmation, as is both of which indicate that the peer is also closing or draining.
receiving a stateless reset. The draining period SHOULD end when the The draining period SHOULD end when the closing period would have
closing period would have ended. In other words, the endpoint can ended. In other words, the endpoint can use the same end time, but
use the same end time, but cease retransmission of the closing cease retransmission of the closing packet.
packet.
Disposing of connection state prior to the end of the closing or Disposing of connection state prior to the end of the closing or
draining period could cause delayed or reordered packets to be draining period could cause delayed or reordered packets to be
handled poorly. Endpoints that have some alternative means to ensure handled poorly. Endpoints that have some alternative means to ensure
that late-arriving packets on the connection do not create QUIC that late-arriving packets on the connection do not create QUIC
state, such as those that are able to close the UDP socket, MAY use state, such as those that are able to close the UDP socket, MAY use
an abbreviated draining period which can allow for faster resource an abbreviated draining period which can allow for faster resource
recovery. Servers that retain an open socket for accepting new recovery. Servers that retain an open socket for accepting new
connections SHOULD NOT exit the closing or draining period early. connections SHOULD NOT exit the closing or draining period early.
skipping to change at page 53, line 37 skipping to change at page 51, line 52
send a stateless reset in response to any further incoming packets. send a stateless reset in response to any further incoming packets.
The draining and closing periods do not apply when a stateless reset The draining and closing periods do not apply when a stateless reset
(Section 10.4) is sent. (Section 10.4) is sent.
An endpoint is not expected to handle key updates when it is closing An endpoint is not expected to handle key updates when it is closing
or draining. A key update might prevent the endpoint from moving or draining. A key update might prevent the endpoint from moving
from the closing state to draining, but it otherwise has no impact. from the closing state to draining, but it otherwise has no impact.
While in the closing period, an endpoint could receive packets from a While in the closing period, an endpoint could receive packets from a
new source address, indicating a client connection migration new source address, indicating a connection migration (Section 9).
(Section 9). An endpoint in the closing state MUST strictly limit
the number of packets it sends to this new address until the address An endpoint in the closing state MUST strictly limit the number of
is validated (see Section 8.2). A server in the closing state MAY packets it sends to this new address until the address is validated
instead choose to discard packets received from a new source address. (see Section 8.2). A server in the closing state MAY instead choose
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 that remains idle for If the idle timeout is enabled, a connection is silently closed and
longer than the advertised idle timeout (see Section 18.1) is closed. the state is discarded when it remains idle for longer than both the
A connection enters the draining state when the idle timeout expires. advertised idle timeout (see Section 18.1) and three times the
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
enpdpoint restarts any timer it maintains when a packet from its peer endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully. The timer is also restarted is received and processed successfully. The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an when sending a packet containing frames other than ACK or PADDING (an
ACK-eliciting packet, see [QUIC-RECOVERY]), but only if no other ACK- ACK-eliciting packet, see [QUIC-RECOVERY]), but only if no other ACK-
eliciting packets have been sent since last receiving a packet. eliciting packets have been sent since last receiving a packet.
Restarting when sending packets ensures that connections do not Restarting when sending packets ensures that connections do not
prematurely time out when initiating new activity. prematurely time out when initiating new activity.
The value for an idle timeout can be asymmetric. The value The value for an idle timeout can be asymmetric. The value
advertised by an endpoint is only used to determine whether the advertised by an endpoint is only used to determine whether the
connection is live at that endpoint. An endpoint that sends packets connection is live at that endpoint. An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the packets discarded if its peer enters the draining state before the
packets arrive. If a peer could timeout within an Probe Timeout packets arrive. If a peer could timeout within an Probe Timeout
(PTO, see Section 6.2.2 of [QUIC-RECOVERY]), it is advisable to test (PTO, see Section 6.2.2 of [QUIC-RECOVERY]), it is advisable to test
for liveness before sending any data that cannot be retried safely. for liveness before sending any data that cannot be retried safely.
Note that it is likely that only applications or application
protocols will know what information can be retried.
10.3. Immediate Close 10.3. Immediate Close
An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to An endpoint sends a CONNECTION_CLOSE frame (Section 19.19) to
terminate the connection immediately. A CONNECTION_CLOSE frame terminate the connection immediately. A CONNECTION_CLOSE frame
causes all streams to immediately become closed; open streams can be causes all streams to immediately become closed; open streams can be
assumed to be implicitly reset. assumed to be implicitly reset.
After sending a CONNECTION_CLOSE frame, endpoints immediately enter After sending a CONNECTION_CLOSE frame, endpoints immediately enter
the closing state. During the closing period, an endpoint that sends the closing state. During the closing period, an endpoint that sends
skipping to change at page 56, line 19 skipping to change at page 54, line 35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Stateless Reset Token (128) + + Stateless Reset Token (128) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Stateless Reset Packet Figure 6: Stateless Reset Packet
This design ensures that a stateless reset packet is - to the extent This design ensures that a stateless reset packet is - to the extent
possible - indistinguishable from a regular packet with a short possible - indistinguishable from a regular packet with a short
header. header.
A stateless reset uses an entire UDP datagram, starting with the A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header. The remainder of the first byte first two bits of the packet header. The remainder of the first byte
and an arbitrary number of bytes following it that are set to and an arbitrary number of bytes following it that are set to
unpredictable values. The last 16 bytes of the datagram contain a unpredictable values. The last 16 bytes of the datagram contain a
Stateless Reset Token. Stateless Reset Token.
A stateless reset will be interpreted by a recipient as a packet with A stateless reset will be interpreted by a recipient as a packet with
a short header. For the packet to appear as valid, the Random Bits a short header. For the packet to appear as valid, the Unpredictable
field needs to include at least 182 bits of data (or 23 bytes, less Bits field needs to include at least 182 bits of data (or 23 bytes,
the two fixed bits). This is intended to allow for a Destination less the two fixed bits). This is intended to allow for a
Connection ID of the maximum length permitted, with a minimal packet Destination Connection ID of the maximum length permitted, with a
number, and payload. The Stateless Reset Token corresponds to the minimal packet number, and payload. The Stateless Reset Token
minimum expansion of the packet protection AEAD. More unpredictable corresponds to the minimum expansion of the packet protection AEAD.
bytes might be necessary if the endpoint could have negotiated a More unpredictable bytes might be necessary if the endpoint could
packet protection scheme with a larger minimum AEAD expansion. have negotiated a packet protection scheme with a larger minimum AEAD
expansion.
An endpoint SHOULD NOT send a stateless reset that is significantly An endpoint SHOULD NOT send a stateless reset that is significantly
larger than the packet it receives. Endpoints MUST discard packets larger than the packet it receives. Endpoints MUST discard packets
that are too small to be valid QUIC packets. With the set of AEAD that are too small to be valid QUIC packets. With the set of AEAD
functions defined in [QUIC-TLS], packets that are smaller than 21 functions defined in [QUIC-TLS], packets that are smaller than 21
bytes are never valid. bytes are never valid.
An endpoint MAY send a stateless reset in response to a packet with a An endpoint MAY send a stateless reset in response to a packet with a
long header. This would not be effective if the stateless reset long header. This would not be effective if the stateless reset
token was not yet available to a peer. In this QUIC version, packets token was not yet available to a peer. In this QUIC version, packets
skipping to change at page 60, line 26 skipping to change at page 58, line 43
connection in this manner even if the error only affects a single connection in this manner even if the error only affects a single
stream. stream.
Application protocols can signal application-specific protocol errors Application protocols can signal application-specific protocol errors
using the application-specific variant of the CONNECTION_CLOSE frame. using the application-specific variant of the CONNECTION_CLOSE frame.
Errors that are specific to the transport, including all those Errors that are specific to the transport, including all those
described in this document, are carried the QUIC-specific variant of described in this document, are carried the QUIC-specific variant of
the CONNECTION_CLOSE frame. the CONNECTION_CLOSE frame.
A CONNECTION_CLOSE frame could be sent in a packet that is lost. An A CONNECTION_CLOSE frame could be sent in a packet that is lost. An
endpoint SHOULD be prepared to retransmit a packet containing endpoint SHOULD be prepared to retransmit a packet containing a
containing a CONNECTION_CLOSE frame if it receives more packets on a CONNECTION_CLOSE frame if it receives more packets on a terminated
terminated connection. Limiting the number of retransmissions and connection. Limiting the number of retransmissions and the time over
the time over which this final packet is sent limits the effort which this final packet is sent limits the effort expended on
expended on terminated connections. terminated connections.
An endpoint that chooses not to retransmit packets containing a An endpoint that chooses not to retransmit packets containing a
CONNECTION_CLOSE frame risks a peer missing the first such packet. CONNECTION_CLOSE frame risks a peer missing the first such packet.
The only mechanism available to an endpoint that continues to receive The only mechanism available to an endpoint that continues to receive
data for a terminated connection is to use the stateless reset data for a terminated connection is to use the stateless reset
process (Section 10.4). process (Section 10.4).
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.
skipping to change at page 62, line 39 skipping to change at page 61, line 9
packets with a different Destination Connection ID than the first packets with a different Destination Connection ID than the first
packet in the datagram. packet in the datagram.
Every QUIC packet that is coalesced into a single UDP datagram is Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete. Though the values of some fields in the separate and complete. Though the values of some fields in the
packet header might be redundant, no fields are omitted. The packet header might be redundant, no fields are omitted. The
receiver of coalesced QUIC packets MUST individually process each receiver of coalesced QUIC packets MUST individually process each
QUIC packet and separately acknowledge them, as if they were received QUIC packet and separately acknowledge them, as if they were received
as the payload of different UDP datagrams. For example, if as the payload of different UDP datagrams. For example, if
decryption fails (because the keys are not available or any other decryption fails (because the keys are not available or any other
reason), the the receiver MAY either discard or buffer the packet for reason), the receiver MAY either discard or buffer the packet for
later processing and MUST attempt to process the remaining packets. later processing and MUST attempt to process the remaining packets.
Retry packets (Section 17.2.5), Version Negotiation packets Retry packets (Section 17.2.5), Version Negotiation packets
(Section 17.2.1), and packets with a short header (Section 17.3) do (Section 17.2.1), and packets with a short header (Section 17.3) do
not contain a Length field and so cannot be followed by other packets not contain a Length field and so cannot be followed by other packets
in the same UDP datagram. in the same UDP datagram.
12.3. Packet Numbers 12.3. Packet Numbers
The packet number is an integer in the range 0 to 2^62-1. This The packet number is an integer in the range 0 to 2^62-1. This
number is used in determining the cryptographic nonce for packet number is used in determining the cryptographic nonce for packet
protection. Each endpoint maintains a separate packet number for protection. Each endpoint maintains a separate packet number for
sending and receiving. sending and receiving.
Packet numbers are limited to this range because they need to be Packet numbers are limited to this range because they need to be
representable in whole in the Largest Acknowledged field of an ACK representable in whole in the Largest Acknowledged field of an ACK
frame (Section 19.3). When present in a long or short header frame (Section 19.3). When present in a long or short header
however, packet numbers are reduced and encoded in 1 to 4 bytes, see however, packet numbers are reduced and encoded in 1 to 4 bytes (see
Section 17.1). Section 17.1).
Version Negotiation (Section 17.2.1) and Retry Section 17.2.5 packets Version Negotiation (Section 17.2.1) and Retry (Section 17.2.5)
do not include a packet number. packets do not include a packet number.
Packet numbers are divided into 3 spaces in QUIC: Packet numbers are divided into 3 spaces in QUIC:
o Initial space: All Initial packets Section 17.2.2 are in this o Initial space: All Initial packets (Section 17.2.2) are in this
space. space.
o Handshake space: All Handshake packets Section 17.2.4 are in this o Handshake space: All Handshake packets (Section 17.2.4) are in
space. this space.
o Application data space: All 0-RTT and 1-RTT encrypted packets o Application data space: All 0-RTT and 1-RTT encrypted packets
Section 12.1 are in this space. (Section 12.1) are in this space.
As described in [QUIC-TLS], each packet type uses different As described in [QUIC-TLS], each packet type uses different
protection keys. protection keys.
Conceptually, a packet number space is the context in which a packet Conceptually, a packet number space is the context in which a packet
can be processed and acknowledged. Initial packets can only be sent can be processed and acknowledged. Initial packets can only be sent
with Initial packet protection keys and acknowledged in packets which with Initial packet protection keys and acknowledged in packets which
are also Initial packets. Similarly, Handshake packets are sent at are also Initial packets. Similarly, Handshake packets are sent at
the Handshake encryption level and can only be acknowledged in the Handshake encryption level and can only be acknowledged in
Handshake packets. Handshake packets.
skipping to change at page 63, line 47 skipping to change at page 62, line 17
This enforces cryptographic separation between the data sent in the This enforces cryptographic separation between the data sent in the
different packet sequence number spaces. Packet numbers in each different packet sequence number spaces. Packet numbers in each
space start at packet number 0. Subsequent packets sent in the same space start at packet number 0. Subsequent packets sent in the same
packet number space MUST increase the packet number by at least one. packet number space MUST increase the packet number by at least one.
0-RTT and 1-RTT data exist in the same packet number space to make 0-RTT and 1-RTT data exist in the same packet number space to make
loss recovery algorithms easier to implement between the two packet loss recovery algorithms easier to implement between the two packet
types. types.
A QUIC endpoint MUST NOT reuse a packet number within the same packet A QUIC endpoint MUST NOT reuse a packet number within the same packet
number space in one connection (that is, under the same cryptographic number space in one connection. If the packet number for sending
keys). If the packet number for sending reaches 2^62 - 1, the sender reaches 2^62 - 1, the sender MUST close the connection without
MUST close the connection without sending a CONNECTION_CLOSE frame or sending a CONNECTION_CLOSE frame or any further packets; an endpoint
any further packets; an endpoint MAY send a Stateless Reset MAY send a Stateless Reset (Section 10.4) in response to further
(Section 10.4) in response to further packets that it receives. packets that it receives.
A receiver MUST discard a newly unprotected packet unless it is A receiver MUST discard a newly unprotected packet unless it is
certain that it has not processed another packet with the same packet certain that it has not processed another packet with the same packet
number from the same packet number space. Duplicate suppression MUST number from the same packet number space. Duplicate suppression MUST
happen after removing packet protection for the reasons described in happen after removing packet protection for the reasons described in
Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate
suppression can be found in Section 3.4.3 of [RFC4303]. suppression can be found in Section 3.4.3 of [RFC4303].
Packet number encoding at a sender and decoding at a receiver are Packet number encoding at a sender and decoding at a receiver are
described in Section 17.1. described in Section 17.1.
12.4. Frames and Frame Types 12.4. Frames and Frame Types
The payload of QUIC packets, after removing packet protection, The payload of QUIC packets, after removing packet protection,
commonly consists of a sequence of frames, as shown in Figure 8. commonly consists of a sequence of frames, as shown in Figure 7.
Version Negotiation, Stateless Reset, and Retry packets do not Version Negotiation, Stateless Reset, and Retry packets do not
contain frames. contain frames.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame 1 (*) ... | Frame 1 (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame 2 (*) ... | Frame 2 (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame N (*) ... | Frame N (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: QUIC Payload Figure 7: QUIC Payload
QUIC payloads MUST contain at least one frame, and MAY contain QUIC payloads MUST contain at least one frame, and MAY contain
multiple frames and multiple frame types. multiple frames and multiple frame types.
Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC
packet boundary. Each frame begins with a Frame Type, indicating its packet boundary. Each frame begins with a Frame Type, indicating its
type, followed by additional type-dependent fields: type, followed by additional type-dependent fields:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Type (i) ... | Frame Type (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-Dependent Fields (*) ... | Type-Dependent Fields (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Generic Frame Layout Figure 8: Generic Frame Layout
The frame types defined in this specification are listed in Table 3. The frame types defined in this specification are listed in Table 3.
The Frame Type in STREAM frames is used to carry other frame-specific The Frame Type in STREAM frames is used to carry other frame-specific
flags. For all other frames, the Frame Type field simply identifies flags. For all other frames, the Frame Type field simply identifies
the frame. These frames are explained in more detail in Section 19. the frame. These frames are explained in more detail in Section 19.
+-------------+----------------------+---------------+ +-------------+----------------------+---------------+
| Type Value | Frame Type Name | Definition | | Type Value | Frame Type Name | Definition |
+-------------+----------------------+---------------+ +-------------+----------------------+---------------+
| 0x00 | PADDING | Section 19.1 | | 0x00 | PADDING | Section 19.1 |
skipping to change at page 79, line 34 skipping to change at page 78, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) | | Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)| |DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ... | Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ... | Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Long Header Packet Format Figure 9: Long Header Packet Format
Long headers are used for packets that are sent prior to the Long headers are used for packets that are sent prior to the
completion of version negotiation and establishment of 1-RTT keys. establishment of 1-RTT keys. Once both conditions are met, a sender
Once both conditions are met, a sender switches to sending packets switches to sending packets using the short header (Section 17.3).
using the short header (Section 17.3). The long form allows for The long form allows for special packets - such as the Version
special packets - such as the Version Negotiation packet - to be Negotiation packet - to be represented in this uniform fixed-length
represented in this uniform fixed-length packet format. Packets that packet format. Packets that use the long header contain the
use the long header contain the following fields: following fields:
Header Form: The most significant bit (0x80) of byte 0 (the first Header Form: The most significant bit (0x80) of byte 0 (the first
byte) is set to 1 for long headers. byte) is set to 1 for long headers.
Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets
containing a zero value for this bit are not valid packets in this containing a zero value for this bit are not valid packets in this
version and MUST be discarded. version and MUST be discarded.
Long Packet Type (T): The next two bits (those with a mask of 0x30) Long Packet Type (T): The next two bits (those with a mask of 0x30)
of byte 0 contain a packet type. Packet types are listed in of byte 0 contain a packet type. Packet types are listed in
skipping to change at page 81, line 35 skipping to change at page 80, line 15
The interpretation of the fields and the payload are specific to a The interpretation of the fields and the payload are specific to a
version and packet type. While type-specific semantics for this version and packet type. While type-specific semantics for this
version are described in the following sections, several long-header version are described in the following sections, several long-header
packets in this version of QUIC contain these additional fields: packets in this version of QUIC contain these additional fields:
Reserved Bits (R): Two bits (those with a mask of 0x0c) of byte 0 Reserved Bits (R): Two bits (those with a mask of 0x0c) of byte 0
are reserved across multiple packet types. These bits are are reserved across multiple packet types. These bits are
protected using header protection (see Section 5.4 of [QUIC-TLS]). protected using header protection (see Section 5.4 of [QUIC-TLS]).
The value included prior to protection MUST be set to 0. An The value included prior to protection MUST be set to 0. An
endpoint MUST treat receipt of a packet that has a non-zero value endpoint MUST treat receipt of a packet that has a non-zero value
for these bits after removing protection as a connection error of for these bits, after removing both packet and header protection,
type PROTOCOL_VIOLATION. as a connection error of type PROTOCOL_VIOLATION. Discarding such
a packet after only removing header protection can expose the
endpoint to attacks (see Section 9.3 of [QUIC-TLS]).
Packet Number Length (P): In packet types which contain a Packet Packet Number Length (P): In packet types which contain a Packet
Number field, the least significant two bits (those with a mask of Number field, the least significant two bits (those with a mask of
0x03) of byte 0 contain the length of the packet number, encoded 0x03) of byte 0 contain the length of the packet number, encoded
as an unsigned, two-bit integer that is one less than the length as an unsigned, two-bit integer that is one less than the length
of the packet number field in bytes. That is, the length of the of the packet number field in bytes. That is, the length of the
packet number field is the value of this field, plus one. These packet number field is the value of this field, plus one. These
bits are protected using header protection (see Section 5.4 of bits are protected using header protection (see Section 5.4 of
[QUIC-TLS]). [QUIC-TLS]).
skipping to change at page 82, line 42 skipping to change at page 81, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version 1 (32) ... | Supported Version 1 (32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Supported Version 2 (32)] ... | [Supported Version 2 (32)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Supported Version N (32)] ... | [Supported Version N (32)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Version Negotiation Packet Figure 10: Version Negotiation Packet
The value in the Unused field is selected randomly by the server. The value in the Unused field is selected randomly by the server.
The Version field of a Version Negotiation packet MUST be set to The Version field of a Version Negotiation packet MUST be set to
0x00000000. 0x00000000.
The server MUST include the value from the Source Connection ID field The server MUST include the value from the Source Connection ID field
of the packet it receives in the Destination Connection ID field. of the packet it receives in the Destination Connection ID field.
The value for Source Connection ID MUST be copied from the The value for Source Connection ID MUST be copied from the
Destination Connection ID of the received packet, which is initially Destination Connection ID of the received packet, which is initially
skipping to change at page 84, line 27 skipping to change at page 82, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (*) ... | Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ... | Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/24/32) ... | Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ... | Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Initial Packet Figure 11: Initial Packet
The Initial packet contains a long header as well as the Length and The Initial packet contains a long header as well as the Length and
Packet Number fields. The first byte contains the Reserved and Packet Number fields. The first byte contains the Reserved and
Packet Number Length bits. Between the SCID and Length fields, there Packet Number Length bits. Between the SCID and Length fields, there
are two additional field specific to the Initial packet. are two additional field specific to the Initial packet.
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
Token field, in bytes. This value is zero if no token is present. Token field, in bytes. This value is zero if no token is present.
Initial packets sent by the server MUST set the Token Length field Initial packets sent by the server MUST set the Token Length field
to zero; clients that receive an Initial packet with a non-zero to zero; clients that receive an Initial packet with a non-zero
skipping to change at page 85, line 9 skipping to change at page 83, line 22
In order to prevent tampering by version-unaware middleboxes, Initial In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys packets are protected with connection- and version-specific keys
(Initial keys) as described in [QUIC-TLS]. This protection does not (Initial keys) as described in [QUIC-TLS]. This protection does not
provide confidentiality or integrity against on-path attackers, but provide confidentiality or integrity against on-path attackers, but
provides some level of protection against off-path attackers. provides some level of protection against off-path attackers.
The client and server use the Initial packet type for any packet that The client and server use the Initial packet type for any packet that
contains an initial cryptographic handshake message. This includes contains an initial cryptographic handshake message. This includes
all cases where a new packet containing the initial cryptographic all cases where a new packet containing the initial cryptographic
message needs to be created, such as the packets sent after receiving message needs to be created, such as the packets sent after receiving
a Version Negotiation (Section 17.2.1) or Retry packet a Retry packet (Section 17.2.5).
(Section 17.2.5).
A server sends its first Initial packet in response to a client A server sends its first Initial packet in response to a client
Initial. A server may send multiple Initial packets. The Initial. A server may send multiple Initial packets. The
cryptographic key exchange could require multiple round trips or cryptographic key exchange could require multiple round trips or
retransmissions of this data. retransmissions of this data.
The payload of an Initial packet includes a CRYPTO frame (or frames) The payload of an Initial packet includes a CRYPTO frame (or frames)
containing a cryptographic handshake message, ACK frames, or both. containing a cryptographic handshake message, ACK frames, or both.
PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint PADDING and CONNECTION_CLOSE frames are also permitted. An endpoint
that receives an Initial packet containing other frames can either that receives an Initial packet containing other frames can either
skipping to change at page 86, line 40 skipping to change at page 85, line 8
| Packet Number (8/16/24/32) ... | Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 or Version Negotiation packet, 0-RTT After a client receives a Retry packet, 0-RTT packets are likely to
packets are likely to have been lost or discarded by the server. A have been lost or discarded by the server. A client MAY attempt to
client MAY attempt to resend data in 0-RTT packets after it sends a resend data in 0-RTT packets after it sends a new Initial packet.
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.
The keys used to protect 0-RTT packets will not change as a result of The keys used to protect 0-RTT packets will not change as a result of
responding to a Retry or Version Negotiation packet unless the client responding to a Retry packet unless the client also regenerates the
also regenerates the cryptographic handshake message. Sending cryptographic handshake message. Sending packets with the same
packets with the same packet number in that case is likely to packet number in that case is likely to compromise the packet
compromise the packet protection for all 0-RTT packets because the protection for all 0-RTT packets because the same key and nonce could
same key and nonce could be used to protect different content. be used to protect different content.
Receiving a Retry or Version Negotiation packet, especially a Retry Receiving a Retry packet, especially a Retry that changes the
that changes the connection ID used for subsequent packets, indicates connection ID used for subsequent packets, indicates a strong
a strong possibility that 0-RTT packets could be lost. A client only possibility that 0-RTT packets could be lost. A client only receives
receives acknowledgments for its 0-RTT packets once the handshake is acknowledgments for its 0-RTT packets once the handshake is complete.
complete. Consequently, a server might expect 0-RTT packets to start Consequently, a server might expect 0-RTT packets to start with a
with a packet number of 0. Therefore, in determining the length of packet number of 0. Therefore, in determining the length of the
the packet number encoding for 0-RTT packets, a client MUST assume packet number encoding for 0-RTT packets, a client MUST assume that
that all packets up to the current packet number are in flight, all packets up to the current packet number are in flight, starting
starting from a packet number of 0. Thus, 0-RTT packets could need from a packet number of 0. Thus, 0-RTT packets could need to use a
to use a longer packet number encoding. longer packet number encoding.
A client SHOULD instead generate a fresh cryptographic handshake A client SHOULD instead generate a fresh cryptographic handshake
message and start packet numbers from 0. This ensures that new 0-RTT message and start packet numbers from 0. This ensures that new 0-RTT
packets will not use the same keys, avoiding any risk of key and packets will not use the same keys, avoiding any risk of key and
nonce reuse; this also prevents 0-RTT packets from previous handshake nonce reuse; this also prevents 0-RTT packets from previous handshake
attempts from being accepted as part of the connection. attempts from being accepted as part of the connection.
17.2.4. Handshake Packet 17.2.4. Handshake Packet
A Handshake packet uses long headers with a type value of 0x2, A Handshake packet uses long headers with a type value of 0x2,
skipping to change at page 87, line 48 skipping to change at page 86, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ... | Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ... | Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/24/32) ... | Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ... | Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Handshake Protected Packet Figure 12: Handshake Protected Packet
Once a client has received a Handshake packet from a server, it uses Once a client has received a Handshake packet from a server, it uses
Handshake packets to send subsequent cryptographic handshake messages Handshake packets to send subsequent cryptographic handshake messages
and acknowledgments to the server. and acknowledgments to the server.
The Destination Connection ID field in a Handshake packet contains a The Destination Connection ID field in a Handshake packet contains a
connection ID that is chosen by the recipient of the packet; the connection ID that is chosen by the recipient of the packet; the
Source Connection ID includes the connection ID that the sender of Source Connection ID includes the connection ID that the sender of
the packet wishes to use (see Section 7.2). the packet wishes to use (see Section 7.2).
skipping to change at page 88, line 48 skipping to change at page 87, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ... | Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ... | Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Connection ID (0/32..144) ... | Original Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Token (*) ... | Retry Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Retry Packet Figure 13: Retry Packet
A Retry packet (shown in Figure 14) does not contain any protected A Retry packet (shown in Figure 13) does not contain any protected
fields. In addition to the long header, it contains these additional fields. In addition to the long header, it contains these additional
fields: fields:
ODCIL: The four least-significant bits of the first byte of a Retry ODCIL: The four least-significant bits of the first byte of a Retry
packet are not protected as they are for other packets with the packet are not protected as they are for other packets with the
long header, because Retry packets don't contain a protected long header, because Retry packets don't contain a protected
payload. These bits instead encode the length of the Original payload. These bits instead encode the length of the Original
Destination Connection ID field. The length uses the same Destination Connection ID field. The length uses the same
encoding as the DCIL and SCIL fields. encoding as the DCIL and SCIL fields.
skipping to change at page 90, line 8 skipping to change at page 88, line 32
includes the provided Retry Token to continue connection includes the provided Retry Token to continue connection
establishment. establishment.
A client sets the Destination Connection ID field of this Initial A client sets the Destination Connection ID field of this Initial
packet to the value from the Source Connection ID in the Retry packet to the value from the Source Connection ID in the Retry
packet. Changing Destination Connection ID also results in a change packet. Changing Destination Connection ID also results in a change
to the keys used to protect the Initial packet. It also sets the to the keys used to protect the Initial packet. It also sets the
Token field to the token provided in the Retry. The client MUST NOT Token field to the token provided in the Retry. The client MUST NOT
change the Source Connection ID because the server could include the change the Source Connection ID because the server could include the
connection ID as part of its token validation logic (see connection ID as part of its token validation logic (see
Section 8.1.2). Section 8.1.3).
The next Initial packet from the client uses the connection ID and The next Initial packet from the client uses the connection ID and
token values from the Retry packet (see Section 7.2). Aside from token values from the Retry packet (see Section 7.2). Aside from
this, the Initial packet sent by the client is subject to the same this, the Initial packet sent by the client is subject to the same
restrictions as the first Initial packet. A client can either reuse restrictions as the first Initial packet. A client can either reuse
the cryptographic handshake message or construct a new one at its the cryptographic handshake message or construct a new one at its
discretion. discretion.
A client MAY attempt 0-RTT after receiving a Retry packet by sending A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server. A client 0-RTT packets to the connection ID provided by the server. A client
skipping to change at page 91, line 17 skipping to change at page 89, line 31
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|1|S|R|R|K|P P| |0|1|S|R|R|K|P P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0..144) ... | Destination Connection ID (0..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/24/32) ... | Packet Number (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Payload (*) ... | Protected Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Short Header Packet Format Figure 14: Short Header Packet Format
The short header can be used after the version and 1-RTT keys are The short header can be used after the version and 1-RTT keys are
negotiated. Packets that use the short header contain the following negotiated. Packets that use the short header contain the following
fields: fields:
Header Form: The most significant bit (0x80) of byte 0 is set to 0 Header Form: The most significant bit (0x80) of byte 0 is set to 0
for the short header. for the short header.
Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets Fixed Bit: The next bit (0x40) of byte 0 is set to 1. Packets
containing a zero value for this bit are not valid packets in this containing a zero value for this bit are not valid packets in this
version and MUST be discarded. version and MUST be discarded.
Spin Bit (S): The sixth bit (0x20) of byte 0 is the Latency Spin Spin Bit (S): The sixth bit (0x20) of byte 0 is the Latency Spin
Bit, set as described in [SPIN]. Bit, set as described in [SPIN].
Reserved Bits (R): The next two bits (those with a mask of 0x18) of Reserved Bits (R): The next two bits (those with a mask of 0x18) of
byte 0 are reserved. These bits are protected using header byte 0 are reserved. These bits are protected using header
protection (see Section 5.4 of [QUIC-TLS]). The value included protection (see Section 5.4 of [QUIC-TLS]). The value included
prior to protection MUST be set to 0. An endpoint MUST treat prior to protection MUST be set to 0. An endpoint MUST treat
receipt of a packet that has a non-zero value for these bits after receipt of a packet that has a non-zero value for these bits,
removing protection as a connection error of type after removing both packet and header protection, as a connection
PROTOCOL_VIOLATION. error of type PROTOCOL_VIOLATION. Discarding such a packet after
only removing header protection can expose the endpoint to attacks
(see Section 9.3 of [QUIC-TLS]).
Key Phase (K): The next bit (0x04) of byte 0 indicates the key Key Phase (K): The next bit (0x04) of byte 0 indicates the key
phase, which allows a recipient of a packet to identify the packet phase, which allows a recipient of a packet to identify the packet
protection keys that are used to protect the packet. See protection keys that are used to protect the packet. See
[QUIC-TLS] for details. This bit is protected using header [QUIC-TLS] for details. This bit is protected using header
protection (see Section 5.4 of [QUIC-TLS]). protection (see Section 5.4 of [QUIC-TLS]).
Packet Number Length (P): The least significant two bits (those with Packet Number Length (P): The least significant two bits (those with
a mask of 0x03) of byte 0 contain the length of the packet number, a mask of 0x03) of byte 0 contain the length of the packet number,
encoded as an unsigned, two-bit integer that is one less than the encoded as an unsigned, two-bit integer that is one less than the
skipping to change at page 92, line 29 skipping to change at page 90, line 43
1-RTT protected payload. 1-RTT protected payload.
The header form bit and the connection ID field of a short header The header form bit and the connection ID field of a short header
packet are version-independent. The remaining fields are specific to packet are version-independent. The remaining fields are specific to
the selected QUIC version. See [QUIC-INVARIANTS] for details on how the selected QUIC version. See [QUIC-INVARIANTS] for details on how
packets from different versions of QUIC are interpreted. packets from different versions of QUIC are interpreted.
18. Transport Parameter Encoding 18. Transport Parameter Encoding
The format of the transport parameters is the TransportParameters The format of the transport parameters is the TransportParameters
struct from Figure 16. This is described using the presentation struct from Figure 15. This is described using the presentation
language from Section 3 of [TLS13]. language from Section 3 of [TLS13].
uint32 QuicVersion;
enum { enum {
original_connection_id(0), original_connection_id(0),
idle_timeout(1), idle_timeout(1),
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),
skipping to change at page 93, line 30 skipping to change at page 91, line 28
disable_migration(12), disable_migration(12),
preferred_address(13), preferred_address(13),
(65535) (65535)
} TransportParameterId; } TransportParameterId;
struct { struct {
TransportParameterId parameter; TransportParameterId parameter;
opaque value<0..2^16-1>; opaque value<0..2^16-1>;
} TransportParameter; } TransportParameter;
struct { TransportParameter TransportParameters<0..2^16-1>;
select (Handshake.msg_type) {
case client_hello:
QuicVersion initial_version;
case encrypted_extensions:
QuicVersion negotiated_version;
QuicVersion supported_versions<4..2^8-4>;
};
TransportParameter parameters<0..2^16-1>;
} TransportParameters;
Figure 16: 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. Transport Parameter Definitions
skipping to change at page 94, line 23 skipping to change at page 92, line 11
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:
original_connection_id (0x0000): The value of the Destination original_connection_id (0x0000): The value of the Destination
Connection ID field from the first Initial packet sent by the Connection ID field from the first Initial packet sent by the
client. This transport parameter is only sent by a server. A client. This transport parameter is only sent by a server. A
server MUST include the original_connection_id transport parameter server MUST include the original_connection_id transport parameter
if it sent a Retry packet. if it sent a Retry packet.
idle_timeout (0x0001): The idle timeout is a value in seconds that idle_timeout (0x0001): The idle timeout is a value in milliseconds
is encoded as an integer, see (Section 10.2). If this parameter that is encoded as an integer, see (Section 10.2). If this
is absent or zero then the idle timeout is disabled. parameter is absent or zero then the idle timeout is disabled.
stateless_reset_token (0x0002): A stateless reset token is used in stateless_reset_token (0x0002): A stateless reset token is used in
verifying a stateless reset, see Section 10.4. This parameter is verifying a stateless reset, see Section 10.4. This parameter is
a sequence of 16 bytes. This transport parameter is only sent by a sequence of 16 bytes. This transport parameter is only sent by
a server. a server.
max_packet_size (0x0003): The maximum packet size parameter is an max_packet_size (0x0003): The maximum packet size parameter is an
integer value that limits the size of packets that the endpoint is integer value that limits the size of packets that the endpoint is
willing to receive. This indicates that packets larger than this willing to receive. This indicates that packets larger than this
limit will be dropped. The default for this parameter is the limit will be dropped. The default for this parameter is the
skipping to change at page 96, line 19 skipping to change at page 94, line 8
disable_migration (0x000c): The disable migration transport disable_migration (0x000c): The disable migration transport
parameter is included if the endpoint does not support connection parameter is included if the endpoint does not support connection
migration (Section 9). Peers of an endpoint that sets this migration (Section 9). Peers of an endpoint that sets this
transport parameter MUST NOT send any packets, including probing transport parameter MUST NOT send any packets, including probing
packets (Section 9.1), from a local address other than that used packets (Section 9.1), from a local address other than that used
to perform the handshake. This parameter is a zero-length value. to perform the handshake. This 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 17. 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.
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..18>;
opaque statelessResetToken[16]; opaque statelessResetToken[16];
} PreferredAddress; } PreferredAddress;
Figure 17: Preferred Address format Figure 16: Preferred Address format
If present, transport parameters that set initial flow control limits If present, transport parameters that set initial flow control limits
(initial_max_stream_data_bidi_local, (initial_max_stream_data_bidi_local,
initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni) initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni)
are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on are equivalent to sending a MAX_STREAM_DATA frame (Section 19.10) on
every stream of the corresponding type immediately after opening. If every stream of the corresponding type immediately after opening. If
the transport parameter is absent, streams of that type start with a the transport parameter is absent, streams of that type start with a
flow control limit of 0. flow control limit of 0.
A client MUST NOT include an original connection ID, a stateless A client MUST NOT include an original connection ID, a stateless
skipping to change at page 98, line 41 skipping to change at page 96, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Range Count (i) ... | ACK Range Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First ACK Range (i) ... | First ACK Range (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Ranges (*) ... | ACK Ranges (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ECN Counts] ... | [ECN Counts] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: ACK Frame Format Figure 17: ACK Frame Format
ACK frames contain the following fields: ACK frames contain the following fields:
Largest Acknowledged: A variable-length integer representing the Largest Acknowledged: A variable-length integer representing the
largest packet number the peer is acknowledging; this is usually largest packet number the peer is acknowledging; this is usually
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 including the time in ACK Delay: A variable-length integer including the time in
skipping to change at page 100, line 23 skipping to change at page 97, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ACK Range (i)] ... | [ACK Range (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Gap (i)] ... | [Gap (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ACK Range (i)] ... | [ACK Range (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: ACK Ranges Figure 18: ACK Ranges
The fields that form the ACK Ranges are: The fields that form the ACK Ranges are:
Gap (repeated): A variable-length integer indicating the number of Gap (repeated): A variable-length integer indicating the number of
contiguous unacknowledged packets preceding the packet number one contiguous unacknowledged packets preceding the packet number one
lower than the smallest in the preceding ACK Range. lower than the smallest in the preceding ACK Range.
ACK Range (repeated): A variable-length integer indicating the ACK Range (repeated): A variable-length integer indicating the
number of contiguous acknowledged packets preceding the largest number of contiguous acknowledged packets preceding the largest
packet number, as determined by the preceding Gap. packet number, as determined by the preceding Gap.
skipping to change at page 103, line 30 skipping to change at page 101, line 4
stream being ignored. stream being ignored.
Application Error Code: A 16-bit, application-specified reason the Application Error Code: A 16-bit, application-specified reason the
sender is ignoring the stream (see Section 20.1). sender is ignoring the stream (see Section 20.1).
19.6. CRYPTO Frame 19.6. CRYPTO Frame
The CRYPTO frame (type=0x06) is used to transmit cryptographic The CRYPTO frame (type=0x06) is used to transmit cryptographic
handshake messages. It can be sent in all packet types. The CRYPTO handshake messages. It can be sent in all packet types. The CRYPTO
frame offers the cryptographic protocol an in-order stream of bytes. frame offers the cryptographic protocol an in-order stream of bytes.
CRYPTO frames are functionally identical to STREAM frames, except CRYPTO frames are functionally identical to STREAM frames, except
that they do not bear a stream identifier; they are not flow that they do not bear a stream identifier; they are not flow
controlled; and they do not carry markers for optional offset, controlled; and they do not carry markers for optional offset,
optional length, and the end of the stream. optional length, and the end of the stream.
The CRYPTO frame is as follows: The CRYPTO frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset (i) ... | Offset (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ... | Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto Data (*) ... | Crypto Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: CRYPTO Frame Format Figure 19: CRYPTO Frame Format
CRYPTO frames contain the following fields: CRYPTO frames contain the following fields:
Offset: A variable-length integer specifying the byte offset in the Offset: A variable-length integer specifying the byte offset in the
stream for the data in this CRYPTO frame. stream for the data in this CRYPTO frame.
Length: A variable-length integer specifying the length of the Length: A variable-length integer specifying the length of the
Crypto Data field in this CRYPTO frame. Crypto Data field in this CRYPTO frame.
Crypto Data: The cryptographic message data. Crypto Data: The cryptographic message data.
skipping to change at page 105, line 38 skipping to change at page 103, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Offset (i)] ... | [Offset (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Length (i)] ... | [Length (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Data (*) ... | Stream Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: STREAM Frame Format Figure 20: STREAM Frame Format
STREAM frames contain the following fields: STREAM frames contain the following fields:
Stream ID: A variable-length integer indicating the stream ID of the Stream ID: A variable-length integer indicating the stream ID of the
stream (see Section 2.1). stream (see Section 2.1).
Offset: A variable-length integer specifying the byte offset in the Offset: A variable-length integer specifying the byte offset in the
stream for the data in this STREAM frame. This field is present stream for the data in this STREAM frame. This field is present
when the OFF bit is set to 1. When the Offset field is absent, when the OFF bit is set to 1. When the Offset field is absent,
the offset is 0. the offset is 0.
skipping to change at page 112, line 9 skipping to change at page 109, line 41
RETIRE_CONNECTION_ID frames contain the following fields: RETIRE_CONNECTION_ID frames contain the following fields:
Sequence Number: The sequence number of the connection ID being Sequence Number: The sequence number of the connection ID being
retired. See Section 5.1.2. retired. See Section 5.1.2.
Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number
greater than any previously sent to the peer MAY be treated as a greater than any previously sent to the peer MAY be treated as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
The sequence number specified in a RETIRE_CONNECTION_ID frame MUST
NOT refer to the Destination Connection ID field of the packet in
which the frame is contained. The peer MAY treat this as a
connection error of type PROTOCOL_VIOLATION.
An endpoint cannot send this frame if it was provided with a zero- An endpoint cannot send this frame if it was provided with a zero-
length connection ID by its peer. An endpoint that provides a zero- length connection ID by its peer. An endpoint that provides a zero-
length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID
frame as a connection error of type PROTOCOL_VIOLATION. frame as a connection error of type PROTOCOL_VIOLATION.
19.17. PATH_CHALLENGE Frame 19.17. PATH_CHALLENGE Frame
Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check
reachability to the peer and for path validation during connection reachability to the peer and for path validation during connection
migration. migration.
skipping to change at page 115, line 26 skipping to change at page 113, line 15
FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was FRAME_ENCODING_ERROR (0x7): An endpoint received a frame that was
badly formatted. For instance, a frame of an unknown type, or an badly formatted. For instance, a frame of an unknown type, or an
ACK frame that has more acknowledgment ranges than the remainder ACK frame that has more acknowledgment ranges than the remainder
of the packet could carry. of the packet could carry.
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.
VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport
parameters that contained version negotiation parameters that
disagreed with the version negotiation that it performed. This
error code indicates a potential version downgrade attack.
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 INVALID_MIGRATION (0xC): A peer has migrated to a different network
when the endpoint had disabled migration. when the endpoint had disabled migration.
CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range CRYPTO_ERROR (0x1XX): The cryptographic handshake failed. A range
of 256 values is reserved for carrying error codes specific to the of 256 values is reserved for carrying error codes specific to the
cryptographic handshake that is used. Codes for errors occurring cryptographic handshake that is used. Codes for errors occurring
when TLS is used for the crypto handshake are described in when TLS is used for the crypto handshake are described in
Section 4.8 of [QUIC-TLS]. Section 4.8 of [QUIC-TLS].
See Section 22.3 for details of registering new error codes. See Section 22.3 for details of registering new error codes.
20.1. Application Protocol Error Codes 20.1. Application Protocol Error Codes
Application protocol error codes are 16-bit unsigned integers, but Application protocol error codes are 16-bit unsigned integers, but
the management of application error codes are left to application the management of application error codes are left to application
protocols. Application protocol error codes are used for the protocols. Application protocol error codes are used for the
RESET_STREAM frame (Section 19.4) and the CONNECTION_CLOSE frame with RESET_STREAM frame (Section 19.4), the STOP_SENDING frame
a type of 0x1d (Section 19.19). (Section 19.5), and the CONNECTION_CLOSE frame with a type of 0x1d
(Section 19.19).
21. Security Considerations 21. Security Considerations
21.1. Handshake Denial of Service 21.1. Handshake Denial of Service
As an encrypted and authenticated transport QUIC provides a range of As an encrypted and authenticated transport QUIC provides a range of
protections against denial of service. Once the cryptographic protections against denial of service. Once the cryptographic
handshake is complete, QUIC endpoints discard most packets that are handshake is complete, QUIC endpoints discard most packets that are
not authenticated, greatly limiting the ability of an attacker to not authenticated, greatly limiting the ability of an attacker to
interfere with existing connections. interfere with existing connections.
skipping to change at page 116, line 50 skipping to change at page 114, line 36
provides a strong assurance that the sender of the packet saw the provides a strong assurance that the sender of the packet saw the
Initial packet and understood it. Initial packet and understood it.
These protections are not intended to be effective against an These protections are not intended to be effective against an
attacker that is able to receive QUIC packets prior to the connection attacker that is able to receive QUIC packets prior to the connection
being established. Such an attacker can potentially send packets being established. Such an attacker can potentially send packets
that will be accepted by QUIC endpoints. This version of QUIC that will be accepted by QUIC endpoints. This version of QUIC
attempts to detect this sort of attack, but it expects that endpoints attempts to detect this sort of attack, but it expects that endpoints
will fail to establish a connection rather than recovering. For the will fail to establish a connection rather than recovering. For the
most part, the cryptographic handshake protocol [QUIC-TLS] is most part, the cryptographic handshake protocol [QUIC-TLS] is
responsible for detecting tampering during the handshake, though responsible for detecting tampering during the handshake.
additional validation is required for version negotiation (see
Section 7.3.3).
Endpoints are permitted to use other methods to detect and attempt to Endpoints are permitted to use other methods to detect and attempt to
recover from interference with the handshake. Invalid packets may be recover from interference with the handshake. Invalid packets may be
identified and discarded using other methods, but no specific method identified and discarded using other methods, but no specific method
is mandated in this document. is mandated in this document.
21.2. Amplification Attack 21.2. Amplification Attack
An attacker might be able to receive an address validation token An attacker might be able to receive an address validation token
(Section 8) from a server and then release the IP address it used to (Section 8) from a server and then release the IP address it used to
skipping to change at page 119, line 45 skipping to change at page 117, line 23
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
This document defines QUIC Version Negotiation packets Section 6,
which can be used to negotiate the QUIC version used between two
endpoints. However, this document does not specify how this
negotiation will be performed between this version and subsequent
future versions. In particular, Version Negotiation packets do not
contain any mechanism to prevent version downgrade attacks. Future
versions of QUIC that use Version Negotiation packets MUST define a
mechanism that is robust against version downgrade attacks.
22. IANA Considerations 22. IANA Considerations
22.1. QUIC Transport Parameter Registry 22.1. QUIC Transport Parameter Registry
IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" IANA [SHALL add/has added] a registry for "QUIC Transport Parameters"
under a "QUIC Protocol" heading. under a "QUIC Protocol" heading.
The "QUIC Transport Parameters" registry governs a 16-bit space. The "QUIC Transport Parameters" registry governs a 16-bit space.
This space is split into two spaces that are governed by different This space is split into two spaces that are governed by different
policies. Values with the first byte in the range 0x00 to 0xfe (in policies. Values with the first byte in the range 0x00 to 0xfe (in
skipping to change at page 124, line 37 skipping to change at page 121, line 37
| 0x6 | FINAL_SIZE_ERROR | Change to | Section 20 | | 0x6 | FINAL_SIZE_ERROR | Change to | Section 20 |
| | | final size | | | | | final size | |
| | | | | | | | | |
| 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 | | 0x7 | FRAME_ENCODING_ERROR | Frame encoding | Section 20 |
| | | error | | | | | error | |
| | | | | | | | | |
| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 | | 0x8 | TRANSPORT_PARAMETER_ERROR | Error in | Section 20 |
| | | transport | | | | | transport | |
| | | parameters | | | | | parameters | |
| | | | | | | | | |
| 0x9 | VERSION_NEGOTIATION_ERROR | Version | Section 20 |
| | | negotiation | |
| | | failure | |
| | | | |
| 0xA | PROTOCOL_VIOLATION | Generic | Section 20 | | 0xA | PROTOCOL_VIOLATION | Generic | Section 20 |
| | | protocol | | | | | protocol | |
| | | violation | | | | | violation | |
| | | | | | | | | |
| 0xC | INVALID_MIGRATION | Violated | Section 20 | | 0xC | INVALID_MIGRATION | Violated | Section 20 |
| | | disabled | | | | | disabled | |
| | | migration | | | | | migration | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
Table 7: Initial QUIC Transport Error Codes Entries Table 7: Initial QUIC Transport Error Codes Entries
skipping to change at page 125, line 6 skipping to change at page 122, line 4
| | | violation | | | | | violation | |
| | | | | | | | | |
| 0xC | INVALID_MIGRATION | Violated | Section 20 | | 0xC | INVALID_MIGRATION | Violated | Section 20 |
| | | disabled | | | | | disabled | |
| | | migration | | | | | migration | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
Table 7: Initial QUIC Transport Error Codes Entries Table 7: Initial QUIC Transport Error Codes Entries
23. References 23. References
23.1. Normative References 23.1. Normative References
[DPLPMTUD] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler, Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
"Packetization Layer Path MTU Discovery for Datagram T. Voelker, "Packetization Layer Path MTU Discovery for
Transports", draft-ietf-tsvwg-datagram-plpmtud-06 (work in Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-07
progress), November 2018. (work in progress), February 2019.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-18 (work and Congestion Control", draft-ietf-quic-recovery-19 (work
in progress), January 2019. in progress), March 2019.
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-
tls-18 (work in progress), January 2019. tls-19 (work in progress), March 2019.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 126, line 5 skipping to change at page 123, line 5
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 126, line 49 skipping to change at page 124, line 7
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-03 (work in progress), January draft-ietf-quic-invariants-03 (work in progress), March
2019. 2019.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
skipping to change at page 128, line 47 skipping to change at page 126, line 5
return candidate_pn - pn_win return candidate_pn - pn_win
return candidate_pn return candidate_pn
Appendix B. Change Log Appendix B. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
B.1. Since draft-ietf-quic-transport-17 B.1. Since draft-ietf-quic-transport-18
o Removed version negotation; version negotiation, including
authentication of the result, will be addressed in the next
version of QUIC (#1773, #2313)
o Added discussion of the use of IPv6 flow labels (#2348, #2399)
o A connection ID can't be retired in a packet that uses that
connection ID (#2101, #2420)
o Idle timeout transport parameter is in milliseconds (from seconds)
(#2453, #2454)
o Endpoints are required to use new connnection IDs when they use
new network paths (#2413, #2414)
o Increased the set of permissible frames in 0-RTT (#2344, #2355)
B.2. Since draft-ietf-quic-transport-17
o Stream-related errors now use STREAM_STATE_ERROR (#2305) o Stream-related errors now use STREAM_STATE_ERROR (#2305)
o Endpoints discard initial keys as soon as handshake keys are o Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
o Expanded conditions for ignoring ICMP packet too big messages o Expanded conditions for ignoring ICMP packet too big messages
(#2108, #2161) (#2108, #2161)
o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129, o Remove rate control from PATH_CHALLENGE/PATH_RESPONSE (#2129,
skipping to change at page 129, line 35 skipping to change at page 127, line 14
o Set a maximum value for max_ack_delay transport parameter (#2282, o Set a maximum value for max_ack_delay transport parameter (#2282,
#2301) #2301)
o Allow server preferred address for both IPv4 and IPv6 (#2122, o Allow server preferred address for both IPv4 and IPv6 (#2122,
#2296) #2296)
o Corrected requirements for migration to a preferred address o Corrected requirements for migration to a preferred address
(#2146, #2349) (#2146, #2349)
B.2. Since draft-ietf-quic-transport-16 o ACK of non-existent packet is illegal (#2298, #2302)
B.3. Since draft-ietf-quic-transport-16
o Stream limits are defined as counts, not maximums (#1850, #1906) o Stream limits are defined as counts, not maximums (#1850, #1906)
o Require amplification attack defense after closing (#1905, #1911) o Require amplification attack defense after closing (#1905, #1911)
o Remove reservation of application error code 0 for STOPPING o Remove reservation of application error code 0 for STOPPING
(#1804, #1922) (#1804, #1922)
o Renumbered frames (#1945) o Renumbered frames (#1945)
skipping to change at page 130, line 41 skipping to change at page 128, line 23
o Tokens are repeated in all Initial packets (#2089) o Tokens are repeated in all Initial packets (#2089)
o Clarified how PING frames are sent after loss (#2094) o Clarified how PING frames are sent after loss (#2094)
o Initial keys are discarded once Handshake are available (#1951, o Initial keys are discarded once Handshake are available (#1951,
#2045) #2045)
o ICMP PTB validation clarifications (#2161, #2109, #2108) o ICMP PTB validation clarifications (#2161, #2109, #2108)
B.3. Since draft-ietf-quic-transport-15 B.4. Since draft-ietf-quic-transport-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
B.4. Since draft-ietf-quic-transport-14 B.5. Since draft-ietf-quic-transport-14
o Merge ACK and ACK_ECN (#1778, #1801) o Merge ACK and ACK_ECN (#1778, #1801)
o Explicitly communicate max_ack_delay (#981, #1781) o Explicitly communicate max_ack_delay (#981, #1781)
o Validate original connection ID after Retry packets (#1710, #1486, o Validate original connection ID after Retry packets (#1710, #1486,
#1793) #1793)
o Idle timeout is optional and has no specified maximum (#1765) o Idle timeout is optional and has no specified maximum (#1765)
o Update connection ID handling; add RETIRE_CONNECTION_ID type o Update connection ID handling; add RETIRE_CONNECTION_ID type
(#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799,
#1821) #1821)
o Include a Token in all Initial packets (#1649, #1794) o Include a Token in all Initial packets (#1649, #1794)
o Prevent handshake deadlock (#1764, #1824) o Prevent handshake deadlock (#1764, #1824)
B.5. Since draft-ietf-quic-transport-13 B.6. Since draft-ietf-quic-transport-13
o Streams open when higher-numbered streams of the same type open o Streams open when higher-numbered streams of the same type open
(#1342, #1549) (#1342, #1549)
o Split initial stream flow control limit into 3 transport o Split initial stream flow control limit into 3 transport
parameters (#1016, #1542) parameters (#1016, #1542)
o All flow control transport parameters are optional (#1610) o All flow control transport parameters are optional (#1610)
o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539) o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
skipping to change at page 132, line 7 skipping to change at page 129, line 35
o Permit 0-RTT after receiving Version Negotiation or Retry (#1507, o Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621) #1514, #1621)
o Permit Retry in response to 0-RTT (#1547, #1552) o Permit Retry in response to 0-RTT (#1547, #1552)
o Looser verification of ECN counters to account for ACK loss o Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565) (#1555, #1481, #1565)
o Remove frame type field from APPLICATION_CLOSE (#1508, #1528) o Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
B.6. Since draft-ietf-quic-transport-12 B.7. Since draft-ietf-quic-transport-12
o Changes to integration of the TLS handshake (#829, #1018, #1094, o Changes to integration of the TLS handshake (#829, #1018, #1094,
#1165, #1190, #1233, #1242, #1252, #1450, #1458) #1165, #1190, #1233, #1242, #1252, #1450, #1458)
* The cryptographic handshake uses CRYPTO frames, not stream 0 * The cryptographic handshake uses CRYPTO frames, not stream 0
* QUIC packet protection is used in place of TLS record * QUIC packet protection is used in place of TLS record
protection protection
* Separate QUIC packet number spaces are used for the handshake * Separate QUIC packet number spaces are used for the handshake
skipping to change at page 133, line 5 skipping to change at page 130, line 29
o Fixed sampling method for packet number encryption; the length o Fixed sampling method for packet number encryption; the length
field in long headers includes the packet number field in addition field in long headers includes the packet number field in addition
to the packet payload (#1387, #1389) to the packet payload (#1387, #1389)
o Stateless Reset is now symmetric and subject to size constraints o Stateless Reset is now symmetric and subject to size constraints
(#466, #1346) (#466, #1346)
o Added frame type extension mechanism (#58, #1473) o Added frame type extension mechanism (#58, #1473)
B.7. Since draft-ietf-quic-transport-11 B.8. Since draft-ietf-quic-transport-11
o Enable server to transition connections to a preferred address o Enable server to transition connections to a preferred address
(#560, #1251) (#560, #1251)
o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850, o Packet numbers are encrypted (#1174, #1043, #1048, #1034, #850,
#990, #734, #1317, #1267, #1079) #990, #734, #1317, #1267, #1079)
o Packet numbers use a variable-length encoding (#989, #1334) o Packet numbers use a variable-length encoding (#989, #1334)
o STREAM frames can now be empty (#1350) o STREAM frames can now be empty (#1350)
B.8. Since draft-ietf-quic-transport-10 B.9. Since draft-ietf-quic-transport-10
o Swap payload length and packed number fields in long header o Swap payload length and packed number fields in long header
(#1294) (#1294)
o Clarified that CONNECTION_CLOSE is allowed in Handshake packet o Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
o Spin bit reserved (#1283) o Spin bit reserved (#1283)
o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
skipping to change at page 134, line 5 skipping to change at page 131, line 28
o STOP_SENDING is now prohibited before streams are used (#1050) o STOP_SENDING is now prohibited before streams are used (#1050)
o Recommend including ACK in Retry packets and allow PADDING (#1067, o Recommend including ACK in Retry packets and allow PADDING (#1067,
#882) #882)
o Endpoints now become closing after an idle timeout (#1178, #1179) o Endpoints now become closing after an idle timeout (#1178, #1179)
o Remove implication that Version Negotiation is sent when a packet o Remove implication that Version Negotiation is sent when a packet
of the wrong version is received (#1197) of the wrong version is received (#1197)
B.9. Since draft-ietf-quic-transport-09 B.10. Since draft-ietf-quic-transport-09
o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with o Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with
Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d. Data and PONG frame. Changed ACK frame type from 0x0e to 0x0d.
(#1091, #725, #1086) (#1091, #725, #1086)
o A server can now only send 3 packets without validating the client o A server can now only send 3 packets without validating the client
address (#38, #1090) address (#38, #1090)
o Delivery order of stream data is no longer strongly specified o Delivery order of stream data is no longer strongly specified
(#252, #1070) (#252, #1070)
skipping to change at page 134, line 32 skipping to change at page 132, line 7
o Improved retransmission rules for all frame types: information is o Improved retransmission rules for all frame types: information is
retransmitted, not packets or frames (#463, #765, #1095, #1053) retransmitted, not packets or frames (#463, #765, #1095, #1053)
o Added an error code for server busy signals (#1137) o Added an error code for server busy signals (#1137)
o Endpoints now set the connection ID that their peer uses. o Endpoints now set the connection ID that their peer uses.
Connection IDs are variable length. Removed the Connection IDs are variable length. Removed the
omit_connection_id transport parameter and the corresponding short omit_connection_id transport parameter and the corresponding short
header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151) header flag. (#1089, #1052, #1146, #821, #745, #821, #1166, #1151)
B.10. Since draft-ietf-quic-transport-08 B.11. Since draft-ietf-quic-transport-08
o Clarified requirements for BLOCKED usage (#65, #924) o Clarified requirements for BLOCKED usage (#65, #924)
o BLOCKED frame now includes reason for blocking (#452, #924, #927, o BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
o GAP limitation in ACK Frame (#613) o GAP limitation in ACK Frame (#613)
o Improved PMTUD description (#614, #1036) o Improved PMTUD description (#614, #1036)
skipping to change at page 135, line 4 skipping to change at page 132, line 26
o Improved PMTUD description (#614, #1036) o Improved PMTUD description (#614, #1036)
o Clarified stream state machine (#634, #662, #743, #894) o Clarified stream state machine (#634, #662, #743, #894)
o Reserved versions don't need to be generated deterministically o Reserved versions don't need to be generated deterministically
(#831, #931) (#831, #931)
o You don't always need the draining period (#871) o You don't always need the draining period (#871)
o Stateless reset clarified as version-specific (#930, #986) o Stateless reset clarified as version-specific (#930, #986)
o initial_max_stream_id_x transport parameters are optional (#970, o initial_max_stream_id_x transport parameters are optional (#970,
#971) #971)
o Ack Delay assumes a default value during the handshake (#1007, o Ack Delay assumes a default value during the handshake (#1007,
#1009) #1009)
o Removed transport parameters from NewSessionTicket (#1015) o Removed transport parameters from NewSessionTicket (#1015)
B.11. Since draft-ietf-quic-transport-07 B.12. Since draft-ietf-quic-transport-07
o The long header now has version before packet number (#926, #939) o The long header now has version before packet number (#926, #939)
o Rename and consolidate packet types (#846, #822, #847) o Rename and consolidate packet types (#846, #822, #847)
o Packet types are assigned new codepoints and the Connection ID o Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956) Flag is inverted (#426, #956)
o Removed type for Version Negotiation and use Version 0 (#963, o Removed type for Version Negotiation and use Version 0 (#963,
#968) #968)
skipping to change at page 136, line 8 skipping to change at page 133, line 31
o Address validation for connection migration (#161, #732, #878) o Address validation for connection migration (#161, #732, #878)
o Clearly defined retransmission rules for BLOCKED (#452, #65, #924) o Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
o negotiated_version is sent in server transport parameters (#710, o negotiated_version is sent in server transport parameters (#710,
#959) #959)
o Increased the range over which packet numbers are randomized o Increased the range over which packet numbers are randomized
(#864, #850, #964) (#864, #850, #964)
B.12. Since draft-ietf-quic-transport-06 B.13. Since draft-ietf-quic-transport-06
o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554) o Replaced FNV-1a with AES-GCM for all "Cleartext" packets (#554)
o Split error code space between application and transport (#485) o Split error code space between application and transport (#485)
o Stateless reset token moved to end (#820) o Stateless reset token moved to end (#820)
o 1-RTT-protected long header types removed (#848) o 1-RTT-protected long header types removed (#848)
o No acknowledgments during draining period (#852) o No acknowledgments during draining period (#852)
o Remove "application close" as a separate close type (#854) o Remove "application close" as a separate close type (#854)
o Remove timestamps from the ACK frame (#841) o Remove timestamps from the ACK frame (#841)
o Require transport parameters to only appear once (#792) o Require transport parameters to only appear once (#792)
B.13. Since draft-ietf-quic-transport-05 B.14. Since draft-ietf-quic-transport-05
o Stateless token is server-only (#726) o Stateless token is server-only (#726)
o Refactor section on connection termination (#733, #748, #328, o Refactor section on connection termination (#733, #748, #328,
#177) #177)
o Limit size of Version Negotiation packet (#585) o Limit size of Version Negotiation packet (#585)
o Clarify when and what to ack (#736) o Clarify when and what to ack (#736)
o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED o Renamed STREAM_ID_NEEDED to STREAM_ID_BLOCKED
o Clarify Keep-alive requirements (#729) o Clarify Keep-alive requirements (#729)
B.14. Since draft-ietf-quic-transport-04 B.15. Since draft-ietf-quic-transport-04
o Introduce STOP_SENDING frame, RESET_STREAM only resets in one o Introduce STOP_SENDING frame, RESET_STREAM only resets in one
direction (#165) direction (#165)
o Removed GOAWAY; application protocols are responsible for graceful o Removed GOAWAY; application protocols are responsible for graceful
shutdown (#696) shutdown (#696)
o Reduced the number of error codes (#96, #177, #184, #211) o Reduced the number of error codes (#96, #177, #184, #211)
o Version validation fields can't move or change (#121) o Version validation fields can't move or change (#121)
skipping to change at page 137, line 26 skipping to change at page 135, line 5
o Increased the maximum length of the Largest Acknowledged field in o Increased the maximum length of the Largest Acknowledged field in
ACK frames to 64 bits (#629) ACK frames to 64 bits (#629)
o truncate_connection_id is renamed to omit_connection_id (#659) o truncate_connection_id is renamed to omit_connection_id (#659)
o CONNECTION_CLOSE terminates the connection like TCP RST (#330, o CONNECTION_CLOSE terminates the connection like TCP RST (#330,
#328) #328)
o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642) o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
B.15. Since draft-ietf-quic-transport-03 B.16. Since draft-ietf-quic-transport-03
o Change STREAM and RESET_STREAM layout o Change STREAM and RESET_STREAM layout
o Add MAX_STREAM_ID settings o Add MAX_STREAM_ID settings
B.16. Since draft-ietf-quic-transport-02 B.17. Since draft-ietf-quic-transport-02
o The size of the initial packet payload has a fixed minimum (#267, o The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
o Define when Version Negotiation packets are ignored (#284, #294, o Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
o The 64-bit FNV-1a algorithm is used for integrity protection of o The 64-bit FNV-1a algorithm is used for integrity protection of
unprotected packets (#167, #480, #481, #517) unprotected packets (#167, #480, #481, #517)
skipping to change at page 138, line 24 skipping to change at page 136, line 4
* BLOCKED split to match WINDOW_UPDATE split (#454) * BLOCKED split to match WINDOW_UPDATE split (#454)
* Define STREAM_ID_NEEDED frame (#455) * Define STREAM_ID_NEEDED frame (#455)
o A NEW_CONNECTION_ID frame supports connection migration without o A NEW_CONNECTION_ID frame supports connection migration without
linkability (#232, #491, #496) linkability (#232, #491, #496)
o Transport parameters for 0-RTT are retained from a previous o Transport parameters for 0-RTT are retained from a previous
connection (#405, #513, #512) connection (#405, #513, #512)
* A client in 0-RTT no longer required to reset excess streams * A client in 0-RTT no longer required to reset excess streams
(#425, #479) (#425, #479)
o Expanded security considerations (#440, #444, #445, #448) o Expanded security considerations (#440, #444, #445, #448)
B.17. Since draft-ietf-quic-transport-01 B.18. Since draft-ietf-quic-transport-01
o Defined short and long packet headers (#40, #148, #361) o Defined short and long packet headers (#40, #148, #361)
o Defined a versioning scheme and stable fields (#51, #361) o Defined a versioning scheme and stable fields (#51, #361)
o Define reserved version values for "greasing" negotiation (#112, o Define reserved version values for "greasing" negotiation (#112,
#278) #278)
o The initial packet number is randomized (#35, #283) o The initial packet number is randomized (#35, #283)
skipping to change at page 140, line 28 skipping to change at page 138, line 8
o Remove error code and reason phrase from GOAWAY (#352, #355) o Remove error code and reason phrase from GOAWAY (#352, #355)
o GOAWAY includes a final stream number for both directions (#347) o GOAWAY includes a final stream number for both directions (#347)
o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a o Error codes for RESET_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
o Defined priority as the responsibility of the application protocol o Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
B.18. Since draft-ietf-quic-transport-00 B.19. Since draft-ietf-quic-transport-00
o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
o Defined versioning o Defined versioning
o Reworked description of packet and frame layout o Reworked description of packet and frame layout
o Error code space is divided into regions for each component o Error code space is divided into regions for each component
o Use big endian for all numeric values o Use big endian for all numeric values
B.19. Since draft-hamilton-quic-transport-protocol-01 B.20. Since draft-hamilton-quic-transport-protocol-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added IANA Considerations section o Added IANA Considerations section
o Moved Contributors and Acknowledgments to appendices o Moved Contributors and Acknowledgments to appendices
Acknowledgments Acknowledgments
 End of changes. 139 change blocks. 
518 lines changed or deleted 479 lines changed or added

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