draft-ietf-quic-transport-13.txt   draft-ietf-quic-transport-14.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: December 30, 2018 Mozilla Expires: February 16, 2019 Mozilla
June 28, 2018 August 15, 2018
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-13 draft-ietf-quic-transport-14
Abstract Abstract
This document defines the core of the QUIC transport protocol. This This document defines the core of the QUIC transport protocol. This
document describes connection establishment, packet format, document describes connection establishment, packet format,
multiplexing and reliability. Accompanying documents describe the multiplexing and reliability. Accompanying documents describe the
cryptographic handshake and loss detection. cryptographic handshake and loss detection.
Note to Readers Note to Readers
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 December 30, 2018. This Internet-Draft will expire on February 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
2.1. Notational Conventions . . . . . . . . . . . . . . . . . 7 2.1. Notational Conventions . . . . . . . . . . . . . . . . . 7
3. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Packet Types and Formats . . . . . . . . . . . . . . . . . . 8 4. Packet Types and Formats . . . . . . . . . . . . . . . . . . 8
4.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Long Header . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Version Negotiation Packet . . . . . . . . . . . . . . . 12 4.3. Version Negotiation Packet . . . . . . . . . . . . . . . 12
4.4. Cryptographic Handshake Packets . . . . . . . . . . . . . 14 4.4. Retry Packet . . . . . . . . . . . . . . . . . . . . . . 14
4.4.1. Initial Packet . . . . . . . . . . . . . . . . . . . 14 4.5. Cryptographic Handshake Packets . . . . . . . . . . . . . 16
4.4.2. Retry Packet . . . . . . . . . . . . . . . . . . . . 17 4.6. Initial Packet . . . . . . . . . . . . . . . . . . . . . 16
4.4.3. Handshake Packet . . . . . . . . . . . . . . . . . . 18 4.6.1. Connection IDs . . . . . . . . . . . . . . . . . . . 18
4.5. Protected Packets . . . . . . . . . . . . . . . . . . . . 18 4.6.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 19
4.6. Coalescing Packets . . . . . . . . . . . . . . . . . . . 19 4.6.3. Starting Packet Numbers . . . . . . . . . . . . . . . 20
4.7. Connection ID Encoding . . . . . . . . . . . . . . . . . 20 4.6.4. 0-RTT Packet Numbers . . . . . . . . . . . . . . . . 20
4.8. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 21 4.6.5. Minimum Packet Size . . . . . . . . . . . . . . . . . 20
5. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 23 4.7. Handshake Packet . . . . . . . . . . . . . . . . . . . . 21
5.1. Extension Frames . . . . . . . . . . . . . . . . . . . . 26 4.8. Protected Packets . . . . . . . . . . . . . . . . . . . . 21
6. Life of a Connection . . . . . . . . . . . . . . . . . . . . 26 4.9. Coalescing Packets . . . . . . . . . . . . . . . . . . . 22
6.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 27 4.10. Connection ID Encoding . . . . . . . . . . . . . . . . . 23
6.2. Matching Packets to Connections . . . . . . . . . . . . . 28 4.11. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 24
6.2.1. Client Packet Handling . . . . . . . . . . . . . . . 28 5. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 26
6.2.2. Server Packet Handling . . . . . . . . . . . . . . . 29 5.1. Extension Frames . . . . . . . . . . . . . . . . . . . . 29
6.3. Version Negotiation . . . . . . . . . . . . . . . . . . . 29 6. Life of a Connection . . . . . . . . . . . . . . . . . . . . 29
6.3.1. Sending Version Negotiation Packets . . . . . . . . . 30 6.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 30
6.3.2. Handling Version Negotiation Packets . . . . . . . . 30 6.2. Matching Packets to Connections . . . . . . . . . . . . . 31
6.3.3. Using Reserved Versions . . . . . . . . . . . . . . . 31 6.2.1. Client Packet Handling . . . . . . . . . . . . . . . 31
6.4. Cryptographic and Transport Handshake . . . . . . . . . . 31 6.2.2. Server Packet Handling . . . . . . . . . . . . . . . 32
6.5. Example Handshake Flows . . . . . . . . . . . . . . . . . 32 6.3. Version Negotiation . . . . . . . . . . . . . . . . . . . 32
6.6. Transport Parameters . . . . . . . . . . . . . . . . . . 34 6.3.1. Sending Version Negotiation Packets . . . . . . . . . 33
6.6.1. Transport Parameter Definitions . . . . . . . . . . . 36 6.3.2. Handling Version Negotiation Packets . . . . . . . . 33
6.6.2. Values of Transport Parameters for 0-RTT . . . . . . 38 6.3.3. Using Reserved Versions . . . . . . . . . . . . . . . 34
6.6.3. New Transport Parameters . . . . . . . . . . . . . . 38 6.4. Cryptographic and Transport Handshake . . . . . . . . . . 34
6.6.4. Version Negotiation Validation . . . . . . . . . . . 39 6.5. Example Handshake Flows . . . . . . . . . . . . . . . . . 35
6.7. Stateless Retries . . . . . . . . . . . . . . . . . . . . 40 6.6. Transport Parameters . . . . . . . . . . . . . . . . . . 37
6.8. Using Explicit Congestion Notification . . . . . . . . . 40 6.6.1. Transport Parameter Definitions . . . . . . . . . . . 39
6.9. Proof of Source Address Ownership . . . . . . . . . . . . 42 6.6.2. Values of Transport Parameters for 0-RTT . . . . . . 41
6.9.1. Client Address Validation Procedure . . . . . . . . . 43 6.6.3. New Transport Parameters . . . . . . . . . . . . . . 42
6.9.2. Address Validation for Future Connections . . . . . . 44 6.6.4. Version Negotiation Validation . . . . . . . . . . . 42
6.9.3. Address Validation Token Integrity . . . . . . . . . 44 6.7. Stateless Retries . . . . . . . . . . . . . . . . . . . . 44
6.10. Path Validation . . . . . . . . . . . . . . . . . . . . . 44 6.8. Using Explicit Congestion Notification . . . . . . . . . 44
6.10.1. Initiation . . . . . . . . . . . . . . . . . . . . . 45 6.9. Proof of Source Address Ownership . . . . . . . . . . . . 46
6.10.2. Response . . . . . . . . . . . . . . . . . . . . . . 45 6.9.1. Client Address Validation Procedure . . . . . . . . . 47
6.10.3. Completion . . . . . . . . . . . . . . . . . . . . . 46 6.9.2. Address Validation for Future Connections . . . . . . 47
6.10.4. Abandonment . . . . . . . . . . . . . . . . . . . . 46 6.9.3. Address Validation Token Integrity . . . . . . . . . 48
6.11. Connection Migration . . . . . . . . . . . . . . . . . . 47 6.10. Path Validation . . . . . . . . . . . . . . . . . . . . . 48
6.11.1. Probing a New Path . . . . . . . . . . . . . . . . . 47 6.10.1. Initiation . . . . . . . . . . . . . . . . . . . . . 49
6.11.2. Initiating Connection Migration . . . . . . . . . . 48 6.10.2. Response . . . . . . . . . . . . . . . . . . . . . . 49
6.11.3. Responding to Connection Migration . . . . . . . . . 48 6.10.3. Completion . . . . . . . . . . . . . . . . . . . . . 50
6.11.4. Loss Detection and Congestion Control . . . . . . . 50 6.10.4. Abandonment . . . . . . . . . . . . . . . . . . . . 50
6.11.5. Privacy Implications of Connection Migration . . . . 51 6.11. Connection Migration . . . . . . . . . . . . . . . . . . 51
6.12. Server's Preferred Address . . . . . . . . . . . . . . . 51 6.11.1. Probing a New Path . . . . . . . . . . . . . . . . . 51
6.12.1. Communicating A Preferred Address . . . . . . . . . 52 6.11.2. Initiating Connection Migration . . . . . . . . . . 52
6.12.2. Responding to Connection Migration . . . . . . . . . 52 6.11.3. Responding to Connection Migration . . . . . . . . . 52
6.11.4. Loss Detection and Congestion Control . . . . . . . 54
6.11.5. Privacy Implications of Connection Migration . . . . 55
6.12. Server's Preferred Address . . . . . . . . . . . . . . . 55
6.12.1. Communicating A Preferred Address . . . . . . . . . 56
6.12.2. Responding to Connection Migration . . . . . . . . . 56
6.12.3. Interaction of Client Migration and Preferred 6.12.3. Interaction of Client Migration and Preferred
Address . . . . . . . . . . . . . . . . . . . . . . 52 Address . . . . . . . . . . . . . . . . . . . . . . 56
6.13. Connection Termination . . . . . . . . . . . . . . . . . 53 6.13. Connection Termination . . . . . . . . . . . . . . . . . 57
6.13.1. Closing and Draining Connection States . . . . . . . 53 6.13.1. Closing and Draining Connection States . . . . . . . 57
6.13.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 54 6.13.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 58
6.13.3. Immediate Close . . . . . . . . . . . . . . . . . . 55 6.13.3. Immediate Close . . . . . . . . . . . . . . . . . . 59
6.13.4. Stateless Reset . . . . . . . . . . . . . . . . . . 56 6.13.4. Stateless Reset . . . . . . . . . . . . . . . . . . 60
7. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 59 7. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 64
7.1. Variable-Length Integer Encoding . . . . . . . . . . . . 59 7.1. Variable-Length Integer Encoding . . . . . . . . . . . . 64
7.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 60 7.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 65
7.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 60 7.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 65
7.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 61 7.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 66
7.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 62 7.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 67
7.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 62 7.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 68
7.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 62 7.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 69
7.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 63 7.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 70
7.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 64 7.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 70
7.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 65 7.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 71
7.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 65 7.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 71
7.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 66 7.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 72
7.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 66 7.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 72
7.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 68 7.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 74
7.15. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 68 7.15. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 74
7.15.1. ACK Block Section . . . . . . . . . . . . . . . . . 70 7.15.1. ACK Block Section . . . . . . . . . . . . . . . . . 76
7.15.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 71 7.15.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 77
7.15.3. ACK Frames and Packet Protection . . . . . . . . . . 72 7.15.3. ACK Frames and Packet Protection . . . . . . . . . . 78
7.16. ACK_ECN Frame . . . . . . . . . . . . . . . . . . . . . . 72 7.16. ACK_ECN Frame . . . . . . . . . . . . . . . . . . . . . . 78
7.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 73 7.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 79
7.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . . 74 7.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . . 80
7.19. NEW_TOKEN frame . . . . . . . . . . . . . . . . . . . . . 74 7.19. NEW_TOKEN frame . . . . . . . . . . . . . . . . . . . . . 80
7.20. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 74 7.20. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 80
7.21. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 76 7.21. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 82
8. Packetization and Reliability . . . . . . . . . . . . . . . . 77 8. Packetization and Reliability . . . . . . . . . . . . . . . . 83
8.1. Packet Processing and Acknowledgment . . . . . . . . . . 78 8.1. Packet Processing and Acknowledgment . . . . . . . . . . 84
8.2. Retransmission of Information . . . . . . . . . . . . . . 78 8.2. Retransmission of Information . . . . . . . . . . . . . . 84
8.3. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 80 8.3. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 86
8.4. Path Maximum Transmission Unit . . . . . . . . . . . . . 80 8.4. Path Maximum Transmission Unit . . . . . . . . . . . . . 87
8.4.1. IPv4 PMTU Discovery . . . . . . . . . . . . . . . . . 81 8.4.1. IPv4 PMTU Discovery . . . . . . . . . . . . . . . . . 87
8.4.2. Special Considerations for Packetization Layer PMTU 8.4.2. Special Considerations for Packetization Layer PMTU
Discovery . . . . . . . . . . . . . . . . . . . . . . 82 Discovery . . . . . . . . . . . . . . . . . . . . . . 88
9. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 82 9. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 88
9.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 83 9.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 89
9.2. Stream States . . . . . . . . . . . . . . . . . . . . . . 84 9.2. Stream States . . . . . . . . . . . . . . . . . . . . . . 90
9.2.1. Send Stream States . . . . . . . . . . . . . . . . . 85 9.2.1. Send Stream States . . . . . . . . . . . . . . . . . 91
9.2.2. Receive Stream States . . . . . . . . . . . . . . . . 86 9.2.2. Receive Stream States . . . . . . . . . . . . . . . . 93
9.2.3. Permitted Frame Types . . . . . . . . . . . . . . . . 89 9.2.3. Permitted Frame Types . . . . . . . . . . . . . . . . 96
9.2.4. Bidirectional Stream States . . . . . . . . . . . . . 89 9.2.4. Bidirectional Stream States . . . . . . . . . . . . . 96
9.3. Solicited State Transitions . . . . . . . . . . . . . . . 90 9.3. Solicited State Transitions . . . . . . . . . . . . . . . 97
9.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 91 9.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 98
9.5. Sending and Receiving Data . . . . . . . . . . . . . . . 92 9.5. Sending and Receiving Data . . . . . . . . . . . . . . . 99
9.6. Stream Prioritization . . . . . . . . . . . . . . . . . . 92 9.6. Stream Prioritization . . . . . . . . . . . . . . . . . . 99
10. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 93 10. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 100
10.1. Edge Cases and Other Considerations . . . . . . . . . . 94 10.1. Edge Cases and Other Considerations . . . . . . . . . . 101
10.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 95 10.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 102
10.1.2. Data Limit Increments . . . . . . . . . . . . . . . 95 10.1.2. Data Limit Increments . . . . . . . . . . . . . . . 102
10.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 96 10.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 103
10.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 96 10.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 103
10.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 96 10.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 103
10.4. Flow Control for Crytographic Handshake . . . . . . . . 97 10.4. Flow Control for Cryptographic Handshake . . . . . . . . 104
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 97 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 104
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 97 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 104
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 98 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 105
11.3. Transport Error Codes . . . . . . . . . . . . . . . . . 98 11.3. Transport Error Codes . . . . . . . . . . . . . . . . . 105
11.4. Application Protocol Error Codes . . . . . . . . . . . . 100 11.4. Application Protocol Error Codes . . . . . . . . . . . . 107
12. Security Considerations . . . . . . . . . . . . . . . . . . . 100 12. Security Considerations . . . . . . . . . . . . . . . . . . . 107
12.1. Handshake Denial of Service . . . . . . . . . . . . . . 100 12.1. Handshake Denial of Service . . . . . . . . . . . . . . 107
12.2. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 101 12.2. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 108
12.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 102 12.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 109
12.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 102 12.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 109
12.5. Stream Fragmentation and Reassembly Attacks . . . . . . 102 12.5. Stream Fragmentation and Reassembly Attacks . . . . . . 109
12.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 103 12.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 110
12.7. Explicit Congestion Notification Attacks . . . . . . . . 103 12.7. Explicit Congestion Notification Attacks . . . . . . . . 110
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 12.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 110
13.1. QUIC Transport Parameter Registry . . . . . . . . . . . 104 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111
13.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 105 13.1. QUIC Transport Parameter Registry . . . . . . . . . . . 111
13.3. QUIC Transport Error Codes Registry . . . . . . . . . . 106 13.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 112
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 108 13.3. QUIC Transport Error Codes Registry . . . . . . . . . . 113
14.1. Normative References . . . . . . . . . . . . . . . . . . 108 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 115
14.2. Informative References . . . . . . . . . . . . . . . . . 109 14.1. Normative References . . . . . . . . . . . . . . . . . . 115
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 110 14.2. Informative References . . . . . . . . . . . . . . . . . 116
A.1. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 110 Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 117
A.2. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 111 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 118
A.3. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 111 B.1. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 118
A.4. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 112 B.2. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 119
A.5. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 113 B.3. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 120
A.6. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 113 B.4. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 120
A.7. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 114 B.5. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 121
A.8. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 115 B.6. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 121
A.9. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 115 B.7. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 122
A.10. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 116 B.8. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 123
A.11. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 116 B.9. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 123
A.12. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 117 B.10. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 124
A.13. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 119 B.11. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 124
A.14. Since draft-hamilton-quic-transport-protocol-01 . . . . . 119 B.12. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 125
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 119 B.13. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 126
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 119 B.14. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 128
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120 B.15. Since draft-hamilton-quic-transport-protocol-01 . . . . . 128
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 128
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 129
1. Introduction 1. Introduction
QUIC is a multiplexed and secure transport protocol that runs on top QUIC is a multiplexed and secure transport protocol that runs on top
of UDP. QUIC aims to provide a flexible set of features that allow of UDP. QUIC aims to provide a flexible set of features that allow
it to be a general-purpose secure transport for multiple it to be a general-purpose secure transport for multiple
applications. applications.
o Version negotiation o Version negotiation
skipping to change at page 9, line 24 skipping to change at page 9, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ... | Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ... | Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/32) | | Packet Number (8/16/32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ... | Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Long Header Format Figure 1: 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. completion of version negotiation and establishment of 1-RTT keys.
Once both conditions are met, a sender switches to sending packets Once both conditions are met, a sender switches to sending packets
using the short header (Section 4.2). The long form allows for using the short header (Section 4.2). The long form allows for
special packets - such as the Version Negotiation packet - to be special packets - such as the Version Negotiation packet - to be
represented in this uniform fixed-length packet format. A long represented in this uniform fixed-length packet format. Packets that
header contains the following fields: use the long header contain the following fields:
Header Form: The most significant bit (0x80) of octet 0 (the first Header Form: The most significant bit (0x80) of octet 0 (the first
octet) is set to 1 for long headers. octet) is set to 1 for long headers.
Long Packet Type: The remaining seven bits of octet 0 contain the Long Packet Type: The remaining seven bits of octet 0 contain the
packet type. This field can indicate one of 128 packet types. packet type. This field can indicate one of 128 packet types.
The types specified for this version are listed in Table 1. The types specified for this version are listed in Table 1.
Version: The QUIC Version is a 32-bit field that follows the Type. Version: The QUIC Version is a 32-bit field that follows the Type.
This field indicates which version of QUIC is in use and This field indicates which version of QUIC is in use and
skipping to change at page 10, line 12 skipping to change at page 10, line 12
the 4 low bits of the octet. An encoded length of 0 indicates the 4 low bits of the octet. An encoded length of 0 indicates
that the connection ID is also 0 octets in length. Non-zero that the connection ID is also 0 octets in length. Non-zero
encoded lengths are increased by 3 to get the full length of the encoded lengths are increased by 3 to get the full length of the
connection ID, producing a length between 4 and 18 octets connection ID, producing a length between 4 and 18 octets
inclusive. For example, an octet with the value 0x50 describes an inclusive. For example, an octet with the value 0x50 describes an
8-octet Destination Connection ID and a zero-length Source 8-octet Destination Connection ID and a zero-length Source
Connection ID. Connection ID.
Destination Connection ID: The Destination Connection ID field Destination Connection ID: The Destination Connection ID field
follows the connection ID lengths and is either 0 octets in length follows the connection ID lengths and is either 0 octets in length
or between 4 and 18 octets. Section 4.7 describes the use of this or between 4 and 18 octets. Section 4.10 describes the use of
field in more detail. this field in more detail.
Source Connection ID: The Source Connection ID field follows the Source Connection ID: The Source Connection ID field follows the
Destination Connection ID and is either 0 octets in length or Destination Connection ID and is either 0 octets in length or
between 4 and 18 octets. Section 4.7 describes the use of this between 4 and 18 octets. Section 4.10 describes the use of this
field in more detail. field in more detail.
Length: The length of the remainder of the packet (that is, the Length: The length of the remainder of the packet (that is, the
Packet Number and Payload fields) in octets, encoded as a Packet Number and Payload fields) in octets, encoded as a
variable-length integer (Section 7.1). variable-length integer (Section 7.1).
Packet Number: The packet number field is 1, 2, or 4 octets long. Packet Number: The packet number field is 1, 2, or 4 octets long.
The packet number has confidentiality protection separate from The packet number has confidentiality protection separate from
packet protection, as described in Section 5.6 of [QUIC-TLS]. The packet protection, as described in Section 5.3 of [QUIC-TLS]. The
length of the packet number field is encoded in the plaintext length of the packet number field is encoded in the plaintext
packet number. See Section 4.8 for details. packet number. See Section 4.11 for details.
Payload: The payload of the packet. Payload: The payload of the packet.
The following packet types are defined: The following packet types are defined:
+------+-----------------+---------------+ +------+-----------------+-------------+
| Type | Name | Section | | Type | Name | Section |
+------+-----------------+---------------+ +------+-----------------+-------------+
| 0x7F | Initial | Section 4.4.1 | | 0x7F | Initial | Section 4.6 |
| | | | | | | |
| 0x7E | Retry | Section 4.4.2 | | 0x7E | Retry | Section 4.4 |
| | | | | | | |
| 0x7D | Handshake | Section 4.4.3 | | 0x7D | Handshake | Section 4.7 |
| | | | | | | |
| 0x7C | 0-RTT Protected | Section 4.5 | | 0x7C | 0-RTT Protected | Section 4.8 |
+------+-----------------+---------------+ +------+-----------------+-------------+
Table 1: Long Header Packet Types Table 1: Long Header Packet Types
The header form, type, connection ID lengths octet, destination and The header form, type, connection ID lengths octet, destination and
source connection IDs, and version fields of a long header packet are source connection IDs, and version fields of a long header packet are
version-independent. The packet number and values for packet types version-independent. The packet number and values for packet types
defined in Table 1 are version-specific. See [QUIC-INVARIANTS] for defined in Table 1 are version-specific. See [QUIC-INVARIANTS] for
details on how packets from different versions of QUIC are details on how packets from different versions of QUIC are
interpreted. interpreted.
skipping to change at page 11, line 18 skipping to change at page 11, line 18
version and packet type. Type-specific semantics for this version version and packet type. Type-specific semantics for this version
are described in the following sections. are described in the following sections.
The end of the packet is determined by the Length field. The Length The end of the packet is determined by the Length field. The Length
field covers the both the Packet Number and Payload fields, both of field covers the both the Packet Number and Payload fields, both of
which are confidentiality protected and initially of unknown length. which are confidentiality protected and initially of unknown length.
The size of the Payload field is learned once the packet number The size of the Payload field is learned once the packet number
protection is removed. protection is removed.
Senders can sometimes coalesce multiple packets into one UDP Senders can sometimes coalesce multiple packets into one UDP
datagram. See Section 4.6 for more details. datagram. See Section 4.9 for more details.
4.2. Short Header 4.2. Short Header
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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|K|1|1|0|R R R| |0|K|1|1|0|R R R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0..144) ... | Destination Connection ID (0..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/32) ... | Packet Number (8/16/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Payload (*) ... | Protected Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Short Header Format Figure 2: 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. This header form has the following fields: negotiated. Packets that use the short header contain the following
fields:
Header Form: The most significant bit (0x80) of octet 0 is set to 0 Header Form: The most significant bit (0x80) of octet 0 is set to 0
for the short header. for the short header.
Key Phase Bit: The second bit (0x40) of octet 0 indicates the key Key Phase Bit: The second bit (0x40) of octet 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. [QUIC-TLS] for details.
[[Editor's Note: this section should be removed and the bit [[Editor's Note: this section should be removed and the bit
skipping to change at page 12, line 22 skipping to change at page 12, line 22
Google QUIC Demultipexing Bit: The fifth bit (0x8) of octet 0 is set Google QUIC Demultipexing Bit: The fifth bit (0x8) of octet 0 is set
to 0. This allows implementations of Google QUIC to distinguish to 0. This allows implementations of Google QUIC to distinguish
Google QUIC packets from short header packets sent by a client Google QUIC packets from short header packets sent by a client
because Google QUIC servers expect the connection ID to always be because Google QUIC servers expect the connection ID to always be
present. The special interpretation of this bit SHOULD be removed present. The special interpretation of this bit SHOULD be removed
from this specification when Google QUIC has finished from this specification when Google QUIC has finished
transitioning to the new header format. transitioning to the new header format.
Reserved: The sixth, seventh, and eighth bits (0x7) of octet 0 are Reserved: The sixth, seventh, and eighth bits (0x7) of octet 0 are
reserved for experimentation. reserved for experimentation. Endpoints MUST ignore these bits on
packets they receive unless they are participating in an
experiment that uses these bits. An endpoint not actively using
these bits SHOULD set the value randomly on packets they send to
protect against unwanted inference about particular values.
Destination Connection ID: The Destination Connection ID is a Destination Connection ID: The Destination Connection ID is a
connection ID that is chosen by the intended recipient of the connection ID that is chosen by the intended recipient of the
packet. See Section 6.1 for more details. packet. See Section 6.1 for more details.
Packet Number: The packet number field is 1, 2, or 4 octets long. Packet Number: The packet number field is 1, 2, or 4 octets long.
The packet number has confidentiality protection separate from The packet number has confidentiality protection separate from
packet protection, as described in Section 5.6 of [QUIC-TLS]. The packet protection, as described in Section 5.3 of [QUIC-TLS]. The
length of the packet number field is encoded in the plaintext length of the packet number field is encoded in the plaintext
packet number. See Section 4.8 for details. packet number. See Section 4.11 for details.
Protected Payload: Packets with a short header always include a Protected Payload: Packets with a short header always include a
1-RTT protected payload. 1-RTT protected payload.
The header form and connection ID field of a short header packet are The header form and connection ID field of a short header packet are
version-independent. The remaining fields are specific to the version-independent. The remaining fields are specific to the
selected QUIC version. See [QUIC-INVARIANTS] for details on how 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.
4.3. Version Negotiation Packet 4.3. Version Negotiation Packet
skipping to change at page 14, line 12 skipping to change at page 14, line 16
ACK frame by a client. Receiving another Initial packet implicitly ACK frame by a client. Receiving another Initial packet implicitly
acknowledges a Version Negotiation packet. acknowledges a Version Negotiation packet.
The Version Negotiation packet does not include the Packet Number and The Version Negotiation packet does not include the Packet Number and
Length fields present in other packets that use the long header form. Length fields present in other packets that use the long header form.
Consequently, a Version Negotiation packet consumes an entire UDP Consequently, a Version Negotiation packet consumes an entire UDP
datagram. datagram.
See Section 6.3 for a description of the version negotiation process. See Section 6.3 for a description of the version negotiation process.
4.4. Cryptographic Handshake Packets 4.4. Retry Packet
A Retry packet uses a long packet header with a type value of 0x7E.
It carries an address validation token created by the server. It is
used by a server that wishes to perform a stateless retry (see
Section 6.7).
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
+-+-+-+-+-+-+-+-+
|1| 0x7e |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ODCIL(8) | Original Destination Connection ID (*) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Retry Packet
A Retry packet (shown in Figure 4) only uses the invariant portion of
the long packet header [QUIC-INVARIANTS]; that is, the fields up to
and including the Destination and Source Connection ID fields. The
contents of the Retry packet are not protected. Like Version
Negotiation, a Retry packet contains the long header including the
connection IDs, but omits the Length, Packet Number, and Payload
fields. These are replaced with:
ODCIL: The length of the Original Destination Connection ID field.
The length is encoded in the least significant 4 bits of the
octet, using the same encoding as the DCIL and SCIL fields. The
most significant 4 bits of this octet are reserved. Unless a use
for these bits has been negotiated, endpoints SHOULD send
randomized values and MUST ignore any value that it receives.
Original Destination Connection ID: The Original Destination
Connection ID contains the value of the Destination Connection ID
from the Initial packet that this Retry is in response to. The
length of this field is given in ODCIL.
Retry Token: An opaque token that the server can use to validate the
client's address.
The server populates the Destination Connection ID with the
connection ID that the client included in the Source Connection ID of
the Initial packet.
The server includes a connection ID of its choice in the Source
Connection ID field. The client MUST use this connection ID in the
Destination Connection ID of subsequent packets that it sends.
A Retry packet does not include a packet number and cannot be
explicitly acknowledged by a client.
A server MUST NOT send a Retry in response to packets other than
Initial or 0-RTT packets. A server MAY choose to only send Retry in
response to Initial packets and discard or buffer 0-RTT packets
corresponding to unvalidated client addresses.
If the Original Destination Connection ID field does not match the
Destination Connection ID from the most recent Initial packet it
sent, clients MUST discard the packet. This prevents an off-path
attacker from injecting a Retry packet.
The client responds to a Retry packet with an Initial packet that
includes the provided Retry Token to continue connection
establishment.
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
that sends additional 0-RTT packets MUST NOT reset the packet number
to 0 after a Retry packet, see Section 4.6.4.
A server that might send another Retry packet in response to a
subsequent Initial packet MUST set the Source Connection ID to a new
value of at least 8 octets in length. This allows clients to
distinguish between Retry packets when the server sends multiple
rounds of Retry packets. Consequently, a valid Retry packet will
always have an Original Destination Connection ID that is at least 8
octets long; clients MUST discard Retry packets that include a
shorter value. A server that will not send additional Retry packets
can set the Source Connection ID to any value.
4.5. Cryptographic Handshake Packets
Once version negotiation is complete, the cryptographic handshake is Once version negotiation is complete, the cryptographic handshake is
used to agree on cryptographic keys. The cryptographic handshake is used to agree on cryptographic keys. The cryptographic handshake is
carried in Initial (Section 4.4.1) and Handshake (Section 4.4.3) carried in Initial (Section 4.6) and Handshake (Section 4.7) packets.
packets.
All these packets use the long header and contain the current QUIC All these packets use the long header and contain the current QUIC
version in the version field. version in the version field.
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.
4.4.1. Initial Packet 4.6. Initial Packet
The Initial packet uses long headers with a type value of 0x7F. It The Initial packet uses long headers with a type value of 0x7F. It
carries the first CRYPTO frames sent by the client and server to carries the first CRYPTO frames sent by the client and server to
perform key exchange, and may carry ACKs in either direction. The perform key exchange, and carries ACKs in either direction. The
Initial packet is protected by Initial keys as described in Initial packet is protected by Initial keys as described in
[QUIC-TLS]. [QUIC-TLS].
The Initial packet has two additional header fields that follow the The Initial packet (shown in Figure 5) has two additional header
normal Long Header. fields that are added to the Long Header before the Length field.
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 |1| 0x7f |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Length (i) ... | Version (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DCIL(4)|SCIL(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection ID (0/32..144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (*) ... | Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Initial Packet
These fields include the token that was previously provided in a
Retry packet or NEW_TOKEN frame:
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. It may be 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 include a zero-length Initial packets sent by the server MUST set the Token Length field
token. to zero; clients that receive an Initial packet with a non-zero
Token Length field MUST either discard the packet or generate a
connection error of type PROTOCOL_VIOLATION.
Token: An optional token blob previously received in either a Retry Token: The value of the token.
packet or NEW_TOKEN frame.
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. In addition to contains an initial cryptographic handshake message. This includes
the first packet(s). This includes all cases where a new packet all cases where a new packet containing the initial cryptographic
containing the initial cryptographic message needs to be created, message needs to be created, such as the packets sent after receiving
such as the packets sent after receiving a Version Negotiation a Version Negotiation (Section 4.3) or Retry packet (Section 4.4).
(Section 4.3) or Retry packet (Section 4.4.2).
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.
The first CRYPTO frame sent always begins at an offset of 0 (see PADDING frames are also permitted. The first CRYPTO frame sent
Section 6.4). The client's complete first message MUST fit in a always begins at an offset of 0 (see Section 6.4).
single packet (see Section 6.4). Note that if the server sends a
HelloRetryRequest, the client will send a second Initial packet with
a CRYPTO frame with an offset starting at the end of the CRYPTO
stream in the first Initial.
4.4.1.1. Connection IDs The first packet sent by a client always includes a CRYPTO frame that
contains the entirety of the first cryptographic handshake message.
This packet, and the cryptographic handshake message, MUST fit in a
single UDP datagram (see Section 6.4).
Note that if the server sends a HelloRetryRequest, the client will
send a second Initial packet. This Initial packet will continue the
cryptographic handshake and will contain a CRYPTO frame with an
offset matching the size of the CRYPTO frame sent in the first
Initial packet. Cryptographic handshake messages subsequent to the
first do not need to fit within a single UDP datagram.
4.6.1. Connection IDs
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 octets in length. Until a packet is received from the least 8 octets in length. Until a packet is received from the
server, the client MUST use the same value unless it abandons the server, the client MUST use the same value unless it abandons the
connection attempt and starts a new one. The initial Destination connection attempt and starts a new one. The initial Destination
Connection ID is used to determine packet protection keys for Initial Connection ID is used to determine packet protection keys for Initial
packets. packets.
skipping to change at page 16, line 7 skipping to change at page 19, line 5
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 6.1). The server MUST use consistent Source Connection IDs Section 6.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. Once a client has Destination Connection ID for subsequent packets. Once a client has
received an Initial packet from the server, it MUST discard any received an Initial packet from the server, it MUST discard any
packet it receives with a different Source Connection ID. packet it receives with a different Source Connection ID.
4.4.1.2. Tokens 4.6.2. Tokens
If the client has a suitable token available from a previous If the client has a token received in a NEW_TOKEN frame on a previous
connection, it SHOULD populate the Token field. connection to what it believes to be the same server, it can include
that value in the Token field of its Initial packet.
A token allows a server to correlate activity between connections.
Specifically, the connection where the token was issued, and any
connection where it is used. Clients that want to break continuity
of identity with a server MAY discard tokens provided using the
NEW_TOKEN frame. Tokens obtained in Retry packets MUST NOT be
discarded.
A client SHOULD NOT reuse a token. Reusing a token allows
connections to be linked by entities on the network path (see
Section 6.11.5). A client MUST NOT reuse a token if it 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 address or
network interface. A client needs to start the connection process
over if it migrates prior to completing the handshake.
If the client received a Retry packet from the server and sends an If the client received a Retry packet from the server and sends an
Initial packet in response, then it sets the Destination Connection Initial packet in response, then it sets the Destination Connection
ID to the value from the Source Connection ID in the Retry packet. ID to the value from the Source Connection ID in the Retry packet.
Changing Destination Connection ID also results in a change to the Changing Destination Connection ID also results in a change to the
keys used to protect the Initial packet. It also sets the Token keys used to protect the Initial packet. It also sets the Token
field to the token provided in the Retry. The client MUST NOT change field to the token provided in the Retry. The client MUST NOT change
the Source Connection ID because the server could include the the Source Connection ID because the server could include the
connection ID as part of its token validation logic. connection ID as part of its token validation logic.
skipping to change at page 16, line 33 skipping to change at page 19, line 47
then the server SHOULD proceed as if the client did not have a then the server SHOULD proceed as if the client did not have a
validated address, including potentially sending a Retry. If the validated address, including potentially sending a Retry. If the
validation succeeds, the server SHOULD then allow the handshake to validation succeeds, the server SHOULD then allow the handshake to
proceed (see Section 6.7). proceed (see Section 6.7).
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. discarded. A server MAY encode tokens provided with NEW_TOKEN
frames and Retry packets differently, and validate the latter more
4.4.1.3. Starting Packet Numbers strictly.
The first Initial packet contains a packet number of 0. Each packet
sent after the Initial packet is associated with a packet number
space and its packet number increases monotonically in that space
(see Section 4.8).
4.4.1.4. Minimum Packet Size
The payload of a UDP datagram carrying the Initial packet MUST be
expanded to at least 1200 octets (see Section 8), by adding PADDING
frames to the Initial packet and/or by combining the Initial packet
with a 0-RTT packet (see Section 4.6).
4.4.2. Retry Packet
A Retry packet uses long headers with a type value of 0x7E. It
carries an address validation token created by the server. It is
used by a server that wishes to perform a stateless retry (see
Section 6.7).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ODCIL(8 | Original Destination Connection ID (*) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Retry packet is not encrypted at all. Instead, the payload of a
Retry packet contains two values in the clear.
ODCIL: The length of the Original Destination Connection ID. 4.6.3. Starting Packet Numbers
Original Destination Connection ID: The Destination Connection ID The first Initial packet sent by either endpoint contains a packet
from the Initial packet that this Retry is in response to. The number of 0. The packet number MUST increase monotonically
length of this field is given in DCIL. thereafter. Initial packets are in a different packet number space
to other packets (see Section 4.11).
Retry Token: An opaque token that the server can use to validate the 4.6.4. 0-RTT Packet Numbers
client's address.
The server populates the Destination Connection ID with the Packet numbers for 0-RTT protected packets use the same space as
connection ID that the client included in the Source Connection ID of 1-RTT protected packets.
the Initial packet. This might be a zero-length value.
The server includes a connection ID of its choice in the Source After a client receives a Retry or Version Negotiation packet, 0-RTT
Connection ID field. The client MUST use this connection ID in the packets are likely to have been lost or discarded by the server. A
Destination Connection ID of subsequent packets that it sends. client MAY attempt to resend data in 0-RTT packets after it sends a
new Initial packet.
The Packet Number field of a Retry packet MUST be set to 0. This A client MUST NOT reset the packet number it uses for 0-RTT packets.
value is subsequently protected as normal. [[Editor's Note: This The keys used to protect 0-RTT packets will not change as a result of
isn't ideal, because it creates a "cheat" where the client assumes a responding to a Retry or Version Negotiation packet unless the client
value. That's a problem, so I'm tempted to suggest that this include also regenerates the cryptographic handshake message. Sending
any value less than 2^30 so that normal processing works - and can be packets with the same packet number in that case is likely to
properly exercised.]] compromise the packet protection for all 0-RTT packets because the
same key and nonce could be used to protect different content.
A Retry packet is never explicitly acknowledged in an ACK frame by a Receiving a Retry or Version Negotiation packet, especially a Retry
client. that changes the connection ID used for subsequent packets, indicates
a strong possibility that 0-RTT packets could be lost. A client only
receives acknowledgments for its 0-RTT packets once the handshake is
complete. Consequently, a server might expect 0-RTT packets to start
with a packet number of 0. Therefore, in determining the length of
the packet number encoding for 0-RTT packets, a client MUST assume
that all packets up to the current packet number are in flight,
starting from a packet number of 0. Thus, 0-RTT packets could need
to use a longer packet number encoding.
A server MUST only send a Retry in response to a client Initial A client MAY instead generate a fresh cryptographic handshake message
packet. 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 nonce reuse;
this also prevents 0-RTT packets from previous handshake attempts
from being accepted as part of the connection.
If the Original Destination Connection ID field does not match the 4.6.5. Minimum Packet Size
Destination Connection ID from most recent the Initial packet it
sent, clients MUST discard the packet. This prevents an off-path
attacker from injecting a Retry packet with a bogus new Source
Connection ID.
Otherwise, the client SHOULD respond with a new Initial packet with The payload of a UDP datagram carrying the Initial packet MUST be
the Token field set to the token received in the Retry packet. expanded to at least 1200 octets (see Section 8), by adding PADDING
frames to the Initial packet and/or by combining the Initial packet
with a 0-RTT packet (see Section 4.9).
4.4.3. Handshake Packet 4.7. Handshake Packet
A Handshake packet uses long headers with a type value of 0x7D. It A Handshake packet uses long headers with a type value of 0x7D. It
is used to carry acknowledgments and cryptographic handshake messages is used to carry acknowledgments and cryptographic handshake messages
from the server and client. from the server and client.
A server sends its cryptographic handshake in one or more Handshake A server sends its cryptographic handshake in one or more Handshake
packets in response to an Initial packet if it does not send a Retry packets in response to an Initial packet if it does not send a Retry
packet. Once a client has received a Handshake packet from a server, packet. Once a client has received a Handshake packet from a server,
it uses Handshake packets to send subsequent cryptographic handshake it uses Handshake packets to send subsequent cryptographic handshake
messages and acknowledgments to the server. messages 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 4.7). the packet wishes to use (see Section 4.10).
The first Handshake packet sent by a server contains a packet number The first Handshake packet sent by a server contains a packet number
of 0. Handshake packets are their own packet number space. Packet of 0. Handshake packets are their own packet number space. Packet
numbers are incremented normally for other Handshake packets. numbers are incremented normally for other Handshake packets.
Servers MUST NOT send more than three datagrams including Initial and Servers MUST NOT send more than three datagrams including Initial and
Handshake packets without receiving a packet from a verified source Handshake packets without receiving a packet from a verified source
address. Source addresses can be verified through an address address. Source addresses can be verified through an address
validation token (delivered via a Retry packet or a NEW_TOKEN frame) validation token (delivered via a Retry packet or a NEW_TOKEN frame)
or by receiving any message from the client encrypted using the or by receiving any message from the client encrypted using the
Handshake keys. Handshake keys.
The payload of this packet contains CRYPTO frames and could contain The payload of this packet contains CRYPTO frames and could contain
PADDING, or ACK frames. Handshake packets MAY contain PADDING, or ACK frames. Handshake packets MAY contain
CONNECTION_CLOSE frames if the handshake is unsuccessful. CONNECTION_CLOSE frames if the handshake is unsuccessful.
4.5. Protected Packets 4.8. Protected Packets
All QUIC packets use packet protection. Packets that are protected All QUIC packets use packet protection. Packets that are protected
with the static handshake keys or the 0-RTT keys are sent with long with the static handshake keys or the 0-RTT keys are sent with long
headers; all packets protected with 1-RTT keys are sent with short headers; all packets protected with 1-RTT keys are sent with short
headers. The different packet types explicitly indicate the headers. The different packet types explicitly indicate the
encryption level and therefore the keys that are used to remove encryption level and therefore the keys that are used to remove
packet protection. 0-RTT and 1-RTT protected packets share a single packet protection. 0-RTT and 1-RTT protected packets share a single
packet number space. packet number space.
Packets protected with handshake keys only use packet protection to Packets protected with handshake keys only use packet protection to
skipping to change at page 19, line 21 skipping to change at page 22, line 12
keys necessary to remove packet protection or to generate packets keys necessary to remove packet protection or to generate packets
that will be successfully authenticated. that will be successfully authenticated.
Packets protected with 0-RTT and 1-RTT keys are expected to have Packets protected with 0-RTT and 1-RTT keys are expected to have
confidentiality and data origin authentication; the cryptographic confidentiality and data origin authentication; the cryptographic
handshake ensures that only the communicating endpoints receive the handshake ensures that only the communicating endpoints receive the
corresponding keys. corresponding keys.
Packets protected with 0-RTT keys use a type value of 0x7C. The Packets protected with 0-RTT keys use a type value of 0x7C. The
connection ID fields for a 0-RTT packet MUST match the values used in connection ID fields for a 0-RTT packet MUST match the values used in
the Initial packet (Section 4.4.1). the Initial packet (Section 4.6).
The client can send 0-RTT packets after receiving an Initial The client can send 0-RTT packets after receiving an Initial
Section 4.4.1 or Handshake (Section 4.4.3) packet, if that packet Section 4.6 or Handshake (Section 4.7) packet, if that packet does
does not complete the handshake. Even if the client receives a not complete the handshake. Even if the client receives a different
different connection ID in the Handshake packet, it MUST continue to connection ID in the Handshake packet, it MUST continue to use the
use the same Destination Connection ID for 0-RTT packets, see same Destination Connection ID for 0-RTT packets, see Section 4.10.
Section 4.7.
The version field for protected packets is the current QUIC version. The version field for protected packets is the current QUIC version.
The packet number field contains a packet number, which has The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet additional confidentiality protection that is applied after packet
protection is applied (see [QUIC-TLS] for details). The underlying protection is applied (see [QUIC-TLS] for details). The underlying
packet number increases with each packet sent, see Section 4.8 for packet number increases with each packet sent, see Section 4.11 for
details. details.
The payload is protected using authenticated encryption. [QUIC-TLS] The payload is protected using authenticated encryption. [QUIC-TLS]
describes packet protection in detail. After decryption, the describes packet protection in detail. After decryption, the
plaintext consists of a sequence of frames, as described in plaintext consists of a sequence of frames, as described in
Section 5. Section 5.
4.6. Coalescing Packets 4.9. Coalescing Packets
A sender can coalesce multiple QUIC packets (typically a A sender can coalesce multiple QUIC packets (typically a
Cryptographic Handshake packet and a Protected packet) into one UDP Cryptographic Handshake packet and a Protected packet) into one UDP
datagram. This can reduce the number of UDP datagrams needed to send datagram. This can reduce the number of UDP datagrams needed to send
application data during the handshake and immediately afterwards. It application data during the handshake and immediately afterwards. It
is not necessary for senders to coalesce packets, though failing to is not necessary for senders to coalesce packets, though failing to
do so will require sending a significantly larger number of datagrams do so will require sending a significantly larger number of datagrams
during the handshake. Receivers MUST be able to process coalesced during the handshake. Receivers MUST be able to process coalesced
packets. packets.
skipping to change at page 20, line 31 skipping to change at page 23, line 20
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. If one or more packets in as the payload of different UDP datagrams. If one or more packets in
a datagram cannot be processed yet (because the keys are not yet a datagram cannot be processed yet (because the keys are not yet
available) or processing fails (decryption failure, unknown type, available) or processing fails (decryption failure, unknown type,
etc.), the receiver MUST still attempt to process the remaining etc.), the receiver MUST still attempt to process the remaining
packets. The skipped packets MAY either be discarded or buffered for packets. The skipped packets MAY either be discarded or buffered for
later processing, just as if the packets were received out-of-order later processing, just as if the packets were received out-of-order
in separate datagrams. in separate datagrams.
4.7. Connection ID Encoding Retry (Section 4.4) and Version Negotiation (Section 4.3) packets
cannot be coalesced.
4.10. Connection ID Encoding
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 6.1. The long header contains two connection described in Section 6.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.
During the handshake, packets with the long header are used to During the handshake, packets with the long header are used to
establish the connection ID that each endpoint uses. Each endpoint establish the connection ID that each endpoint uses. Each endpoint
skipping to change at page 21, line 24 skipping to change at page 24, line 17
is expected to be known to endpoints. is expected to be known to endpoints.
Endpoints using a connection-ID based load balancer could agree with Endpoints using a connection-ID based load balancer could agree with
the load balancer on a fixed or minimum length and on an encoding for the load balancer on a fixed or minimum length and on an encoding for
connection IDs. This fixed portion could encode an explicit length, connection IDs. This fixed portion could encode an explicit length,
which allows the entire connection ID to vary in length and still be which allows the entire connection ID to vary in length and still be
used by the load balancer. used by the load balancer.
The very first packet sent by a client includes a random value for The very first packet sent by a client includes a random value for
Destination Connection ID. The same value MUST be used for all 0-RTT Destination Connection ID. The same value MUST be used for all 0-RTT
packets sent on that connection (Section 4.5). This randomized value packets sent on that connection (Section 4.8). This randomized value
is used to determine the handshake packet protection keys (see is used to determine the packet protection keys for Initial packets
Section 5.3.2 of [QUIC-TLS]). (see Section 5.1.1 of [QUIC-TLS]).
A Version Negotiation (Section 4.3) packet MUST use both connection A Version Negotiation (Section 4.3) packet MUST use both connection
IDs selected by the client, swapped to ensure correct routing toward IDs selected by the client, swapped to ensure correct routing toward
the client. the client.
The connection ID can change over the lifetime of a connection, The connection ID can change over the lifetime of a connection,
especially in response to connection migration (Section 6.11). especially in response to connection migration (Section 6.11).
NEW_CONNECTION_ID frames (Section 7.13) are used to provide new NEW_CONNECTION_ID frames (Section 7.13) are used to provide new
connection ID values. connection ID values.
4.8. Packet Numbers 4.11. Packet Numbers
The packet number is an integer in the range 0 to 2^62-1. The value The packet number is an integer in the range 0 to 2^62-1. The value
is used in determining the cryptographic nonce for packet encryption. is used in determining the cryptographic nonce for packet encryption.
Each endpoint maintains a separate packet number for sending and Each endpoint maintains a separate packet number for sending and
receiving. receiving.
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 4.4.1 are in this o Initial space: All Initial packets Section 4.6 are in this space.
space.
o Handshake space: All Handshake packets Section 4.4.3 are in this o Handshake space: All Handshake packets Section 4.7 are in this
space. 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 4.5 are in this space. Section 4.8 are in this space.
As described in [QUIC-TLS], each packet type uses different As described in [QUIC-TLS], each packet type uses different
encryption keys. encryption keys.
Conceptually, a packet number space is the encryption context in Conceptually, a packet number space is the encryption context in
which a packet can be processed and ACKed. Initial packets can only which a packet can be processed and ACKed. Initial packets can only
be sent with Initial encryption keys and ACKed in packets which are be sent with Initial encryption keys and ACKed in packets which are
also Initial packets. Similarly, Handshake packets can only be sent also Initial packets. Similarly, Handshake packets can only be sent
and acknowledged in Handshake packets. and acknowledged in Handshake packets.
skipping to change at page 22, line 34 skipping to change at page 25, line 24
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 (that is, under the same cryptographic
keys). If the packet number for sending reaches 2^62 - 1, the sender keys). If the packet number for sending reaches 2^62 - 1, the sender
MUST close the connection without sending a CONNECTION_CLOSE frame or MUST close the connection without sending a CONNECTION_CLOSE frame or
any further packets; an endpoint MAY send a Stateless Reset any further packets; an endpoint MAY send a Stateless Reset
(Section 6.13.4) in response to further packets that it receives. (Section 6.13.4) in response to further packets that it receives.
In the QUIC long and short packet headers, the number of bits In the QUIC long and short packet headers, the number of bits
required to represent the packet number are reduced by including only required to represent the packet number is reduced by including only
a variable number of the least significant bits of the packet number. a variable number of the least significant bits of the packet number.
One or two of the most significant bits of the first octet determine One or two of the most significant bits of the first octet determine
how many bits of the packet number are provided, as shown in Table 2. how many bits of the packet number are provided, as shown in Table 2.
+---------------------+----------------+--------------+ +---------------------+----------------+--------------+
| First octet pattern | Encoded Length | Bits Present | | First octet pattern | Encoded Length | Bits Present |
+---------------------+----------------+--------------+ +---------------------+----------------+--------------+
| 0b0xxxxxxx | 1 octet | 7 | | 0b0xxxxxxx | 1 octet | 7 |
| | | | | | | |
| 0b10xxxxxx | 2 | 14 | | 0b10xxxxxx | 2 | 14 |
| | | | | | | |
| 0b11xxxxxx | 4 | 30 | | 0b11xxxxxx | 4 | 30 |
+---------------------+----------------+--------------+ +---------------------+----------------+--------------+
Table 2: Packet Number Encodings for Packet Headers Table 2: Packet Number Encodings for Packet Headers
Note that these encodings are similar to those in Section 7.1, but Note that these encodings are similar to those in Section 7.1, but
use different values. use different values.
The encoded packet number is protected as described in Section 5.6 The encoded packet number is protected as described in Section 5.3
[QUIC-TLS]. Protection of the packet number is removed prior to [QUIC-TLS]. Protection of the packet number is removed prior to
recovering the full packet number. The full packet number is recovering the full packet number. The full packet number is
reconstructed at the receiver based on the number of significant bits reconstructed at the receiver based on the number of significant bits
present, the content of those bits, and the largest packet number present, the content of those bits, and the largest packet number
received on a successfully authenticated packet. Recovering the full received on a successfully authenticated packet. Recovering the full
packet number is necessary to successfully remove packet protection. packet number is necessary to successfully remove packet protection.
Once packet number protection is removed, the packet number is Once packet number protection is removed, the packet number is
decoded by finding the packet number value that is closest to the decoded by finding the packet number value that is closest to the
next expected packet. The next expected packet is the highest next expected packet. The next expected packet is the highest
received packet number plus one. For example, if the highest received packet number plus one. For example, if the highest
successfully authenticated packet had a packet number of 0xaa82f30e, successfully authenticated packet had a packet number of 0xaa82f30e,
then a packet containing a 14-bit value of 0x9b3 will be decoded as then a packet containing a 14-bit value of 0x9b3 will be decoded as
0xaa8309b3. 0xaa8309b3. Example pseudo-code for packet number decoding can be
found in Appendix A.
The sender MUST use a packet number size able to represent more than The sender MUST use a packet number size able to represent more than
twice as large a range than the difference between the largest twice as large a range than the difference between the largest
acknowledged packet and packet number being sent. A peer receiving acknowledged packet and packet number being sent. A peer receiving
the packet will then correctly decode the packet number, unless the the packet will then correctly decode the packet number, unless the
packet is delayed in transit such that it arrives after many higher- packet is delayed in transit such that it arrives after many higher-
numbered packets have been received. An endpoint SHOULD use a large numbered packets have been received. An endpoint SHOULD use a large
enough packet number encoding to allow the packet number to be enough packet number encoding to allow the packet number to be
recovered even if the packet arrives after packets that are sent recovered even if the packet arrives after packets that are sent
afterwards. afterwards.
skipping to change at page 23, line 41 skipping to change at page 26, line 34
As a result, the size of the packet number encoding is at least one As a result, the size of the packet number encoding is at least one
more than the base 2 logarithm of the number of contiguous more than the base 2 logarithm of the number of contiguous
unacknowledged packet numbers, including the new packet. unacknowledged packet numbers, including the new packet.
For example, if an endpoint has received an acknowledgment for packet For example, if an endpoint has received an acknowledgment for packet
0x6afa2f, sending a packet with a number of 0x6b2d79 requires a 0x6afa2f, sending a packet with a number of 0x6b2d79 requires a
packet number encoding with 14 bits or more; whereas the 30-bit packet number encoding with 14 bits or more; whereas the 30-bit
packet number encoding is needed to send a packet with a number of packet number encoding is needed to send a packet with a number of
0x6bc107. 0x6bc107.
A receiver MUST discard a newly unprotected packet unless it is
certain that it has not processed another packet with the same packet
number from the same packet number space. Duplicate suppression MUST
happen after removing packet protection for the reasons described in
Section 9.3 of [QUIC-TLS]. An efficient algorithm for duplicate
suppression can be found in Section 3.4.3 of [RFC2406].
A Version Negotiation packet (Section 4.3) does not include a packet A Version Negotiation packet (Section 4.3) does not include a packet
number. The Retry packet (Section 4.4.2) has special rules for number. The Retry packet (Section 4.4) has special rules for
populating the packet number field. populating the packet number field.
5. Frames and Frame Types 5. Frames and Frame Types
The payload of all packets, after removing packet protection, The payload of all packets, after removing packet protection,
consists of a sequence of frames, as shown in Figure 4. Version consists of a sequence of frames, as shown in Figure 6. Version
Negotiation and Stateless Reset do not contain frames. Negotiation and Stateless Reset do not 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 4: Contents of Protected Payload Figure 6: Contents of Protected Payload
Protected payloads MUST contain at least one frame, and MAY contain Protected 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (i) ... | Frame Type (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-Dependent Fields (*) ... | Type-Dependent Fields (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Generic Frame Layout Figure 7: 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 as they are the frame. These frames are explained in more detail as they are
referenced later in the document. referenced later in the document.
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
| Type Value | Frame Type Name | Definition | | Type Value | Frame Type Name | Definition |
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
skipping to change at page 25, line 46 skipping to change at page 28, line 46
| 0x0e | PATH_CHALLENGE | Section 7.17 | | 0x0e | PATH_CHALLENGE | Section 7.17 |
| | | | | | | |
| 0x0f | PATH_RESPONSE | Section 7.18 | | 0x0f | PATH_RESPONSE | Section 7.18 |
| | | | | | | |
| 0x10 - 0x17 | STREAM | Section 7.20 | | 0x10 - 0x17 | STREAM | Section 7.20 |
| | | | | | | |
| 0x18 | CRYPTO | Section 7.21 | | 0x18 | CRYPTO | Section 7.21 |
| | | | | | | |
| 0x19 | NEW_TOKEN | Section 7.19 | | 0x19 | NEW_TOKEN | Section 7.19 |
| | | | | | | |
| 0x20 | ACK_ECN | Section 7.16 | | 0x1a | ACK_ECN | Section 7.16 |
+-------------+-------------------+--------------+ +-------------+-------------------+--------------+
Table 3: Frame Types Table 3: Frame Types
All QUIC frames are idempotent. That is, a valid frame does not All QUIC frames are idempotent. That is, a valid frame does not
cause undesirable side effects or errors when received more than cause undesirable side effects or errors when received more than
once. once.
The Frame Type field uses a variable length integer encoding (see The Frame Type field uses a variable length integer encoding (see
Section 7.1) with one exception. To ensure simple and efficient Section 7.1) with one exception. To ensure simple and efficient
skipping to change at page 27, line 7 skipping to change at page 30, line 7
endpoints. QUIC's connection establishment intertwines version endpoints. QUIC's connection establishment intertwines version
negotiation with the cryptographic and transport handshakes to reduce negotiation with the cryptographic and transport handshakes to reduce
connection establishment latency, as described in Section 6.4. Once connection establishment latency, as described in Section 6.4. Once
established, a connection may migrate to a different IP or port at established, a connection may migrate to a different IP or port at
either endpoint, due to NAT rebinding or mobility, as described in either endpoint, due to NAT rebinding or mobility, as described in
Section 6.11. Finally a connection may be terminated by either Section 6.11. Finally a connection may be terminated by either
endpoint, as described in Section 6.13. endpoint, as described in Section 6.13.
6.1. Connection ID 6.1. Connection ID
Each connection is identified by a collection of identifiers assigned Each connection possesses a set of identifiers, any of which could be
to it. A connection ID can be 0 octets in length (and thus unlikely used to distinguish it from other connections. A connection ID can
to be unique), or between 4 and 18 octets (inclusive). Connection be either 0 octets in length, or between 4 and 18 octets (inclusive).
IDs are selected independently in each direction. Connection IDs are selected independently in each direction.
The primary function of a connection ID is to ensure that changes in The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP, and below) don't cause addressing at lower protocol layers (UDP, IP, and below) don't cause
packets for a QUIC connection to be delivered to the wrong endpoint. packets for a QUIC connection to be delivered to the wrong endpoint.
Each endpoint selects connection IDs using an implementation-specific Each endpoint selects connection IDs using an implementation-specific
(and perhaps deployment-specific) method which will allow packets (and perhaps deployment-specific) method which will allow packets
with that connection ID to be routed back to the endpoint and with that connection ID to be routed back to the endpoint and
identified by the endpoint upon receipt. identified by the endpoint upon receipt.
A zero-length connection ID MAY be used when the connection ID is not A zero-length connection ID MAY be used when the connection ID is not
skipping to change at page 28, line 12 skipping to change at page 31, line 12
Implementations SHOULD ensure that peers have a connection ID with a Implementations SHOULD ensure that peers have a connection ID with a
matching sequence number available when changing to a new connection matching sequence number available when changing to a new connection
ID. An implementation could do this by always supplying a ID. An implementation could do this by always supplying a
corresponding connection ID to a peer for each connection ID received corresponding connection ID to a peer for each connection ID received
from that peer. from that peer.
While endpoints select connection IDs as appropriate for their While endpoints select connection IDs as appropriate for their
implementation, the connection ID MUST NOT include the unprotected implementation, the connection ID MUST NOT include the unprotected
sequence number. Endpoints need to be able to recover the sequence sequence number. Endpoints need to be able to recover the sequence
number associated with each connection ID they generate without number associated with each connection ID they generate without
relying on information available to unaffiliate parties. A relying on information available to unaffiliated parties. A
connection ID that encodes an unencrypted sequence number could be connection ID that encodes an unencrypted sequence number could be
used to correlate connection IDs across network paths. used to correlate connection IDs across network paths.
6.2. Matching Packets to Connections 6.2. Matching Packets to Connections
Incoming packets are classified on receipt. Packets can either be Incoming packets are classified on receipt. Packets can either be
associated with an existing connection, or - for servers - associated with an existing connection, or - for servers -
potentially create a new connection. potentially create a new connection.
Hosts try to associate a packet with an existing connection. If the Hosts try to associate a packet with an existing connection. If the
skipping to change at page 31, line 8 skipping to change at page 34, line 8
to a Version Negotiation packet from the server. Once a client to a Version Negotiation packet from the server. Once a client
receives a packet from the server which is not a Version Negotiation receives a packet from the server which is not a Version Negotiation
packet, it MUST discard other Version Negotiation packets on the same packet, it MUST discard other Version Negotiation packets on the same
connection. Similarly, a client MUST ignore a Version Negotiation connection. Similarly, a client MUST ignore a Version Negotiation
packet if it has already received and acted on a Version Negotiation packet if it has already received and acted on a Version Negotiation
packet. packet.
A client MUST ignore a Version Negotiation packet that lists the A client MUST ignore a Version Negotiation packet that lists the
client's chosen version. client's chosen version.
A client MAY attempt 0-RTT after receiving a Version Negotiation
packet. A client that sends additional 0-RTT packets MUST NOT reset
the packet number to 0 as a result, see Section 4.6.4.
Version negotiation packets have no cryptographic protection. The Version negotiation packets have no cryptographic protection. The
result of the negotiation MUST be revalidated as part of the result of the negotiation MUST be revalidated as part of the
cryptographic handshake (see Section 6.6.4). cryptographic handshake (see Section 6.6.4).
6.3.3. Using Reserved Versions 6.3.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 3) while generating a SHOULD include a reserved version (see Section 3) while generating a
Version Negotiation packet. Version Negotiation packet.
skipping to change at page 32, line 41 skipping to change at page 35, line 43
The CRYPTO frame can be sent in different packet number spaces. The CRYPTO frame can be sent in different packet number spaces.
CRYPTO frames in each packet number space carry a separate sequence CRYPTO frames in each packet number space carry a separate sequence
of handshake data starting from an offset of 0. of handshake data starting from an offset of 0.
6.5. Example Handshake Flows 6.5. 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. [QUIC-TLS], but some examples are provided here.
Figure 6 provides an overview of the 1-RTT handshake. Each line Figure 8 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 contents. So, for instance the first packet first, followed by the contents. So, for instance the first packet
is of type Initial, with packet number 0, and contains a CRYPTO frame is of type Initial, with packet number 0, and contains a CRYPTO frame
carrying the ClientHello. carrying the 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 4.6, and - may be coalesced into a single UDP datagram (see Section 4.9), 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
packets from the Initial encryption level (obfuscation), the packets from the Initial encryption level (obfuscation), the
Handshake level, and "0.5-RTT data" from the server at the 1-RTT Handshake level, and "0.5-RTT data" from the server at the 1-RTT
encryption level. encryption level.
Client Server Client Server
Initial[0]: CRYPTO[CH] -> Initial[0]: CRYPTO[CH] ->
skipping to change at page 33, line 22 skipping to change at page 36, line 24
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[55, "..."], ACK[0]
<- Handshake[1]: ACK[0] <- Handshake[1]: ACK[0]
Figure 6: Example 1-RTT Handshake Figure 8: Example 1-RTT Handshake
Figure 7 shows an example of a connection with a 0-RTT handshake and Figure 9 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 4.8, the server ACKs the 0-RTT data at the 1-RTT encryption Section 4.11, the server ACKs the 0-RTT data at the 1-RTT encryption
level, and the client's sequence numbers at the 1-RTT encryption level, and the client's sequence numbers at the 1-RTT encryption
level continue to increment from its 0-RTT packets. level continue to increment from its 0-RTT packets.
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, CERT, CV, FIN]
<- 1-RTT[0]: STREAM[1, "..."] ACK[0] <- 1-RTT[0]: STREAM[1, "..."] ACK[0]
Initial[1]: ACK[0] Initial[1]: ACK[0]
0-RTT[1]: CRYPTO[EOED] 0-RTT[1]: CRYPTO[EOED]
Handshake[0]: CRYPTO[FIN], ACK[0] Handshake[0]: CRYPTO[FIN], ACK[0]
1-RTT[2]: STREAM[0, "..."] ACK[0] -> 1-RTT[2]: STREAM[0, "..."] ACK[0] ->
1-RTT[1]: STREAM[55, "..."], ACK[1,2] 1-RTT[1]: STREAM[55, "..."], ACK[1,2]
<- Handshake[1]: ACK[0] <- Handshake[1]: ACK[0]
Figure 7: Example 1-RTT Handshake Figure 9: Example 1-RTT Handshake
6.6. Transport Parameters 6.6. Transport Parameters
During connection establishment, both endpoints make authenticated During connection establishment, both endpoints make authenticated
declarations of their transport parameters. These declarations are declarations of their transport parameters. These declarations are
made unilaterally by each endpoint. Endpoints are required to comply made unilaterally by each endpoint. Endpoints are required to comply
with the restrictions implied by these parameters; the description of with the restrictions implied by these parameters; the description of
each parameter includes rules for its handling. each parameter includes rules for its handling.
The format of the transport parameters is the TransportParameters The format of the transport parameters is the TransportParameters
struct from Figure 8. This is described using the presentation struct from Figure 10. This is described using the presentation
language from Section 3 of [I-D.ietf-tls-tls13]. language from Section 3 of [TLS13].
uint32 QuicVersion; uint32 QuicVersion;
enum { enum {
initial_max_stream_data(0), initial_max_stream_data_bidi_local(0),
initial_max_data(1), initial_max_data(1),
initial_max_bidi_streams(2), initial_max_bidi_streams(2),
idle_timeout(3), idle_timeout(3),
preferred_address(4), preferred_address(4),
max_packet_size(5), max_packet_size(5),
stateless_reset_token(6), stateless_reset_token(6),
ack_delay_exponent(7), ack_delay_exponent(7),
initial_max_uni_streams(8), initial_max_uni_streams(8),
disable_migration(9), disable_migration(9),
initial_max_stream_data_bidi_remote(10),
initial_max_stream_data_uni(11),
(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 { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
skipping to change at page 35, line 46 skipping to change at page 38, line 48
} TransportParameters; } TransportParameters;
struct { struct {
enum { IPv4(4), IPv6(6), (15) } ipVersion; enum { IPv4(4), IPv6(6), (15) } ipVersion;
opaque ipAddress<4..2^8-1>; opaque ipAddress<4..2^8-1>;
uint16 port; uint16 port;
opaque connectionId<0..18>; opaque connectionId<0..18>;
opaque statelessResetToken[16]; opaque statelessResetToken[16];
} PreferredAddress; } PreferredAddress;
Figure 8: Definition of TransportParameters Figure 10: 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 encode the transport parameters. encoding rules are therefore used to encode the transport parameters.
QUIC encodes transport parameters into a sequence of octets, which QUIC encodes transport parameters into a sequence of octets, which
are then included in the cryptographic handshake. Once the handshake are then included in the cryptographic handshake. Once the handshake
completes, the transport parameters declared by the peer are completes, the transport parameters declared by the peer are
available. Each endpoint validates the value provided by its peer. available. Each endpoint validates the value provided by its peer.
In particular, version negotiation MUST be validated (see In particular, version negotiation MUST be validated (see
skipping to change at page 36, line 24 skipping to change at page 39, line 24
in Section 6.6.1. Any given parameter MUST appear at most once in a in Section 6.6.1. Any given parameter MUST appear at most once in a
given transport parameters extension. An endpoint MUST treat receipt given transport parameters extension. An endpoint MUST treat receipt
of duplicate transport parameters as a connection error of type of duplicate transport parameters as a connection error of type
TRANSPORT_PARAMETER_ERROR. TRANSPORT_PARAMETER_ERROR.
6.6.1. Transport Parameter Definitions 6.6.1. Transport Parameter Definitions
An endpoint MUST include the following parameters in its encoded An endpoint MUST include the following parameters in its encoded
TransportParameters: TransportParameters:
initial_max_stream_data (0x0000): The initial stream maximum data idle_timeout (0x0003): The idle timeout is a value in seconds that
parameter contains the initial value for the maximum data that can is encoded as an unsigned 16-bit integer. The maximum value is
be sent on any newly created stream. This parameter is encoded as 600 seconds (10 minutes).
an unsigned 32-bit integer in units of octets. This is equivalent
to an implicit MAX_STREAM_DATA frame (Section 7.7) being sent on An endpoint MAY use the following transport parameters:
all streams immediately after opening.
initial_max_data (0x0001): The initial maximum data parameter initial_max_data (0x0001): The initial maximum data parameter
contains the initial value for the maximum amount of data that can contains the initial value for the maximum amount of data that can
be sent on the connection. This parameter is encoded as an be sent on the connection. This parameter is encoded as an
unsigned 32-bit integer in units of octets. This is equivalent to unsigned 32-bit integer in units of octets. This is equivalent to
sending a MAX_DATA (Section 7.6) for the connection immediately sending a MAX_DATA (Section 7.6) for the connection immediately
after completing the handshake. after completing the handshake. If the transport parameter is
absent, the connection starts with a flow control limit of 0.
idle_timeout (0x0003): The idle timeout is a value in seconds that
is encoded as an unsigned 16-bit integer. The maximum value is
600 seconds (10 minutes).
An endpoint MAY use the following transport parameters:
initial_max_bidi_streams (0x0002): The initial maximum bidirectional initial_max_bidi_streams (0x0002): The initial maximum bidirectional
streams parameter contains the initial maximum number of streams parameter contains the initial maximum number of
application-owned bidirectional streams the peer may initiate, bidirectional streams the peer may initiate, encoded as an
encoded as an unsigned 16-bit integer. If this parameter is unsigned 16-bit integer. If this parameter is absent or zero,
absent or zero, application-owned bidirectional streams cannot be bidirectional streams cannot be created until a MAX_STREAM_ID
created until a MAX_STREAM_ID frame is sent. Setting this frame is sent. Setting this parameter is equivalent to sending a
parameter is equivalent to sending a MAX_STREAM_ID (Section 7.8) MAX_STREAM_ID (Section 7.8) immediately after completing the
immediately after completing the handshake containing the handshake containing the corresponding Stream ID. For example, a
corresponding Stream ID. For example, a value of 0x05 would be value of 0x05 would be equivalent to receiving a MAX_STREAM_ID
equivalent to receiving a MAX_STREAM_ID containing 16 when containing 16 when received by a client or 17 when received by a
received by a client or 17 when received by a server. server.
initial_max_uni_streams (0x0008): The initial maximum unidirectional initial_max_uni_streams (0x0008): The initial maximum unidirectional
streams parameter contains the initial maximum number of streams parameter contains the initial maximum number of
application-owned unidirectional streams the peer may initiate, unidirectional streams the peer may initiate, encoded as an
encoded as an unsigned 16-bit integer. If this parameter is unsigned 16-bit integer. If this parameter is absent or zero,
absent or zero, unidirectional streams cannot be created until a unidirectional streams cannot be created until a MAX_STREAM_ID
MAX_STREAM_ID frame is sent. Setting this parameter is equivalent frame is sent. Setting this parameter is equivalent to sending a
to sending a MAX_STREAM_ID (Section 7.8) immediately after MAX_STREAM_ID (Section 7.8) immediately after completing the
completing the handshake containing the corresponding Stream ID. handshake containing the corresponding Stream ID. For example, a
For example, a value of 0x05 would be equivalent to receiving a value of 0x05 would be equivalent to receiving a MAX_STREAM_ID
MAX_STREAM_ID containing 18 when received by a client or 19 when containing 18 when received by a client or 19 when received by a
received by a server. server.
max_packet_size (0x0005): The maximum packet size parameter places a max_packet_size (0x0005): The maximum packet size parameter places a
limit on the size of packets that the endpoint is willing to limit on the size of packets that the endpoint is willing to
receive, encoded as an unsigned 16-bit integer. This indicates receive, encoded as an unsigned 16-bit integer. This indicates
that packets larger than this limit will be dropped. The default that packets larger than this limit will be dropped. The default
for this parameter is the maximum permitted UDP payload of 65527. for this parameter is the maximum permitted UDP payload of 65527.
Values below 1200 are invalid. This limit only applies to Values below 1200 are invalid. This limit only applies to
protected packets (Section 4.5). protected packets (Section 4.8).
ack_delay_exponent (0x0007): An 8-bit unsigned integer value ack_delay_exponent (0x0007): An 8-bit unsigned integer value
indicating an exponent used to decode the ACK Delay field in the indicating an exponent used to decode the ACK Delay field in the
ACK frame, see Section 7.15. If this value is absent, a default ACK frame, see Section 7.15. If this value is absent, a default
value of 3 is assumed (indicating a multiplier of 8). The default value of 3 is assumed (indicating a multiplier of 8). The default
value is also used for ACK frames that are sent in Initial and value is also used for ACK frames that are sent in Initial and
Handshake packets. Values above 20 are invalid. Handshake packets. Values above 20 are invalid.
disable_migration (0x0009): The endpoint does not support connection disable_migration (0x0009): The endpoint does not support connection
migration (Section 6.11). Peers MUST NOT send any packets, migration (Section 6.11). Peers MUST NOT send any packets,
including probing packets (Section 6.11.1), from a local address including probing packets (Section 6.11.1), from a local address
other than that used to perform the handshake. This parameter is other than that used to perform the handshake. This parameter is
a zero-length value. a zero-length value.
Either peer MAY advertise an initial value for the flow control on
each type of stream on which they might receive data. Each of the
following transport parameters is encoded as an unsigned 32-bit
integer in units of octets:
initial_max_stream_data_bidi_local (0x0000): The initial stream
maximum data for bidirectional, locally-initiated streams
parameter contains the initial flow control limit for newly
created bidirectional streams opened by the endpoint that sets the
transport parameter. In client transport parameters, this applies
to streams with an identifier ending in 0x0; in server transport
parameters, this applies to streams ending in 0x1.
initial_max_stream_data_bidi_remote (0x000a): The initial stream
maximum data for bidirectional, peer-initiated streams parameter
contains the initial flow control limit for newly created
bidirectional streams opened by the endpoint that receives the
transport parameter. In client transport parameters, this applies
to streams with an identifier ending in 0x1; in server transport
parameters, this applies to streams ending in 0x0.
initial_max_stream_data_uni (0x000b): The initial stream maximum
data for unidirectional streams parameter contains the initial
flow control limit for newly created unidirectional streams opened
by the endpoint that receives the transport parameter. In client
transport parameters, this applies to streams with an identifier
ending in 0x3; in server transport parameters, this applies to
streams ending in 0x2.
If present, transport parameters that set initial stream flow control
limits are equivalent to sending a MAX_STREAM_DATA frame
(Section 7.7) on every stream of the corresponding type immediately
after opening. If the transport parameter is absent, streams of that
type start with a flow control limit of 0.
A server MAY include the following transport parameters: A server MAY include the following transport parameters:
stateless_reset_token (0x0006): The Stateless Reset Token is used in stateless_reset_token (0x0006): The Stateless Reset Token is used in
verifying a stateless reset, see Section 6.13.4. This parameter verifying a stateless reset, see Section 6.13.4. This parameter
is a sequence of 16 octets. is a sequence of 16 octets.
preferred_address (0x0004): The server's Preferred Address is used preferred_address (0x0004): 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 6.12. as described in Section 6.12.
skipping to change at page 38, line 29 skipping to change at page 42, line 7
A server can remember the transport parameters that it advertised, or A server can remember the transport parameters that it advertised, or
store an integrity-protected copy of the values in the ticket and store an integrity-protected copy of the values in the ticket and
recover the information when accepting 0-RTT data. A server uses the recover the information when accepting 0-RTT data. A server uses the
transport parameters in determining whether to accept 0-RTT data. transport parameters in determining whether to accept 0-RTT data.
A server MAY accept 0-RTT and subsequently provide different values A server MAY accept 0-RTT and subsequently provide different values
for transport parameters for use in the new connection. If 0-RTT for transport parameters for use in the new connection. If 0-RTT
data is accepted by the server, the server MUST NOT reduce any limits data is accepted by the server, the server MUST NOT reduce any limits
or alter any values that might be violated by the client with its or alter any values that might be violated by the client with its
0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT
set values for initial_max_data or initial_max_stream_data that are set values for initial_max_data, initial_max_stream_data_bidi_local,
smaller than the remembered value of those parameters. Similarly, a initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni
server MUST NOT reduce the value of initial_max_bidi_streams or that are smaller than the remembered value of those parameters.
initial_max_uni_streams. Similarly, a server MUST NOT reduce the value of
initial_max_bidi_streams or initial_max_uni_streams.
Omitting or setting a zero value for certain transport parameters can Omitting or setting a zero value for certain transport parameters can
result in 0-RTT data being enabled, but not usable. The following result in 0-RTT data being enabled, but not usable. The applicable
transport parameters SHOULD be set to non-zero values for 0-RTT: subset of transport parameters that permit sending of application
initial_max_bidi_streams, initial_max_uni_streams, initial_max_data, data SHOULD be set to non-zero values for 0-RTT. This includes
initial_max_stream_data. initial_max_data and either initial_max_bidi_streams and
initial_max_stream_data_bidi_remote, or initial_max_uni_streams and
initial_max_stream_data_uni.
The value of the server's previous preferred_address MUST NOT be used The value of the server's previous preferred_address MUST NOT be used
when establishing a new connection; rather, the client should wait to when establishing a new connection; rather, the client should wait to
observe the server's new preferred_address value in the handshake. observe the server's new preferred_address value in the handshake.
A server MUST reject 0-RTT data or even abort a handshake if the A server MUST reject 0-RTT data or even abort a handshake if the
implied values for transport parameters cannot be supported. implied values for transport parameters cannot be supported.
6.6.3. New Transport Parameters 6.6.3. New Transport Parameters
skipping to change at page 40, line 40 skipping to change at page 44, line 23
with a different codepoint. with a different codepoint.
6.7. Stateless Retries 6.7. Stateless Retries
A server can process an initial cryptographic handshake messages from A server can process an initial cryptographic handshake messages from
a client without committing any state. This allows a server to a client without committing any state. This allows a server to
perform address validation (Section 6.9), or to defer connection perform address validation (Section 6.9), or to defer connection
establishment costs. establishment costs.
A server that generates a response to an Initial packet without A server that generates a response to an Initial packet without
retaining connection state MUST use the Retry packet (Section 4.4.2). retaining connection state MUST use the Retry packet (Section 4.4).
This packet causes a client to restart the connection attempt and This packet causes a client to restart the connection attempt and
includes the token in the new Initial packet (Section 4.4.1) to prove includes the token in the new Initial packet (Section 4.6) to prove
source address ownership. source address ownership.
6.8. Using Explicit Congestion Notification 6.8. Using Explicit Congestion Notification
QUIC endpoints use Explicit Congestion Notification (ECN) [RFC3168] QUIC endpoints use Explicit Congestion Notification (ECN) [RFC3168]
to detect and respond to network congestion. ECN allows a network to detect and respond to network congestion. ECN allows a network
node to indicate congestion in the network by setting a codepoint in node to indicate congestion in the network by setting a codepoint in
the IP header of a packet instead of dropping it. Endpoints react to the IP header of a packet instead of dropping it. Endpoints react to
congestion by reducing their sending rate in response, as described congestion by reducing their sending rate in response, as described
in [QUIC-RECOVERY]. in [QUIC-RECOVERY].
skipping to change at page 41, line 30 skipping to change at page 45, line 11
network device, then a received packet contains either the codepoint network device, then a received packet contains either the codepoint
sent by the peer or the Congestion Experienced (CE) codepoint set by sent by the peer or the Congestion Experienced (CE) codepoint set by
a network device that is experiencing congestion. a network device that is experiencing congestion.
On receiving a packet with an ECT or CE codepoint, an endpoint that On receiving a packet with an ECT or CE codepoint, an endpoint that
supports ECN increases the corresponding ECT(0), ECT(1), or CE count, supports ECN increases the corresponding ECT(0), ECT(1), or CE count,
and includes these counters in subsequent (see Section 8.1) ACK_ECN and includes these counters in subsequent (see Section 8.1) ACK_ECN
frames (see Section 7.16). frames (see Section 7.16).
A packet detected by a receiver as a duplicate does not affect the A packet detected by a receiver as a duplicate does not affect the
receiver's local ECN codepoint counts to mitigate security concerns receiver's local ECN codepoint counts; see (Section 12.7) for
(Section 12.7). relevant security concerns.
If an endpoint receives a packet without an ECT or CE codepoint, it If an endpoint receives a packet without an ECT or CE codepoint, it
responds per Section 8.1 with an ACK frame. responds per Section 8.1 with an ACK frame.
If an endpoint does not support ECN or does not have access to If an endpoint does not support ECN or does not have access to
received ECN codepoints, it acknowledges received packets per received ECN codepoints, it acknowledges received packets per
Section 8.1 with an ACK frame. Section 8.1 with an ACK frame.
If a packet sent with an ECT codepoint is newly acknowledged by the If a packet sent with an ECT codepoint is newly acknowledged by the
peer in an ACK frame, the endpoint stops setting ECT codepoints in peer in an ACK frame, the endpoint stops setting ECT codepoints in
subsequent packets, with the expectation that either the network or subsequent packets, with the expectation that either the network or
the peer no longer supports ECN. the peer no longer supports ECN.
To protect the connection from arbitrary corruption of ECN codepoints To protect the connection from arbitrary corruption of ECN codepoints
by the network, an endpoint verifies the following when an ACK_ECN by the network, an endpoint verifies the following when an ACK_ECN
frame is received: frame is received:
o The increase in ECT(0) and ECT(1) counters MUST be at least the
number of packets newly acknowledged that were sent with the
corresponding codepoint.
o The total increase in ECT(0), ECT(1), and CE counters reported in o The total increase in ECT(0), ECT(1), and CE counters reported in
the ACK_ECN frame MUST be equal to the total number of packets the ACK_ECN frame MUST be at least the total number of packets
newly acknowledged in this ACK_ECN frame. newly acknowledged in this ACK_ECN frame.
o The increase in ECT(0) and ECT(1) counters MUST be no greater than An endpoint could miss acknowledgements for a packet when ACK frames
the number of packets newly acknowledged that were sent with the are lost. It is therefore possible for the total increase in ECT(0),
corresponding codepoint. ECT(1), and CE counters to be greater than the number of packets
acknowledged in an ACK frame. When this happens, the local reference
counts MUST be increased to match the counters in the ACK frame.
Upon successful verification, an endpoint continues to set ECT Upon successful verification, an endpoint continues to set ECT
codepoints in subsequent packets with the expectation that the path codepoints in subsequent packets with the expectation that the path
is ECN-capable. is ECN-capable.
If verification fails, then the endpoint ceases setting ECT If verification fails, then the endpoint ceases setting ECT
codepoints in subsequent packets with the expectation that either the codepoints in subsequent packets with the expectation that either the
network or the peer does not support ECN. network or the peer does not support ECN.
If an endpoint sets ECT codepoints on outgoing packets and encounters If an endpoint sets ECT codepoints on outgoing packets and encounters
a retransmission timeout due to the absence of acknowledgments from a retransmission timeout due to the absence of acknowledgments from
the peer (see [QUIC-RECOVERY]), the endpoint MAY cease setting ECT the peer (see [QUIC-RECOVERY]), or if an endpoint has reason to
codepoints in subsequent packets. Doing so allows the connection to believe that a network element might be corrupting ECN codepoints,
traverse network elements that drop packets carrying ECT or CE the endpoint MAY cease setting ECT codepoints in subsequent packets.
codepoints in the IP header. Doing so allows the connection to traverse network elements that drop
or corrupt ECN codepoints in the IP header.
6.9. Proof of Source Address Ownership 6.9. Proof of Source Address Ownership
Transport protocols commonly spend a round trip checking that a Transport protocols commonly spend a round trip checking that a
client owns the transport address (IP and port) that it claims. client owns the transport address (IP and port) that it claims.
Verifying that a client can receive packets sent to its claimed Verifying that a client can receive packets sent to its claimed
transport address protects against spoofing of this information by transport address protects against spoofing of this information by
malicious clients. malicious clients.
This technique is used primarily to avoid QUIC from being used for This technique is used primarily to avoid QUIC from being used for
traffic amplification attack. In such an attack, a packet is sent to traffic amplification attack. In such an attack, a packet is sent to
a server with spoofed source address information that identifies a 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.
Several methods are used in QUIC to mitigate this attack. Firstly, Several methods are used in QUIC to mitigate this attack. Firstly,
the initial handshake packet is padded to at least 1200 octets. This the initial handshake packet is sent in a UDP datagram that contains
allows a server to send a similar amount of data without risking at least 1200 octets of UDP payload. This allows a server to send a
causing an amplification attack toward an unproven remote address. similar amount of data without risking causing an amplification
attack toward an unproven remote address.
A server eventually confirms that a client has received its messages A server eventually confirms that a client has received its messages
when the first Handshake-level message is received. This might be when the first Handshake-level message is received. This might be
insufficient, either because the server wishes to avoid the insufficient, either because the server wishes to avoid the
computational cost of completing the handshake, or it might be that computational cost of completing the handshake, or it might be that
the size of the packets that are sent during the handshake is too the size of the packets that are sent during the handshake is too
large. This is especially important for 0-RTT, where the server large. This is especially important for 0-RTT, where the server
might wish to provide application data traffic - such as a response might wish to provide application data traffic - such as a response
to a request - in response to the data carried in the early data from to a request - in response to the data carried in the early data from
the client. the client.
skipping to change at page 47, line 18 skipping to change at page 51, line 13
progress. progress.
6.11. Connection Migration 6.11. Connection Migration
QUIC allows connections to survive changes to endpoint addresses QUIC allows connections to survive changes to endpoint addresses
(that is, IP address and/or port), such as those caused by a endpoint (that is, IP address and/or port), such as those caused by a endpoint
migrating to a new network. This section describes the process by migrating to a new network. This section describes the process by
which an endpoint migrates to a new address. which an endpoint migrates to a new address.
An endpoint MUST NOT initiate connection migration before the An endpoint MUST NOT initiate connection migration before the
handshake is finished and the endpoint has 1-RTT keys. An endpoint handshake is finished and the endpoint has 1-RTT keys. The design of
also MUST NOT initiate connection migration if the peer sent the QUIC relies on endpoints retaining a stable address for the duration
"disable_migration" transport parameter during the handshake. An of the handshake.
endpoint which has sent this transport parameter, but detects that a
peer has nonetheless migrated to a different network MAY treat this An endpoint also MUST NOT initiate connection migration if the peer
as a connection error of type INVALID_MIGRATION. However, note that sent the "disable_migration" transport parameter during the
not all changes of peer address are intentional migrations. The peer handshake. An endpoint which has sent this transport parameter, but
could experience an unintended change of address due to NAT detects that a peer has nonetheless migrated to a different network
rebinding; endpoints SHOULD perform path validation (Section 6.10) if MAY treat this as a connection error of type INVALID_MIGRATION.
the rebinding does not cause the connection to fail.
Not all changes of peer address are intentional migrations. The peer
could experience NAT rebinding: a change of address due to a
middlebox, usually a NAT, allocating a new outgoing port or even a
new outgoing IP address for a flow. Endpoints SHOULD perform path
validation (Section 6.10) if a NAT rebinding does not cause the
connection to fail.
This document limits migration of connections to new client This document limits migration of connections to new client
addresses, except as described in Section 6.12. Clients are addresses, except as described in Section 6.12. 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 6.11.1) toward a client address until it probing packets (see Section 6.11.1) toward a client address until it
sees a non-probing packet from that address. If a client receives sees a non-probing packet from that address. If a client receives
packets from an unknown server address, the client MAY discard these packets from an unknown server address, the client MAY discard these
packets. packets.
6.11.1. Probing a New Path 6.11.1. Probing a New Path
skipping to change at page 50, line 51 skipping to change at page 54, line 51
sends data and probes from/to multiple addresses during the migration sends data and probes from/to multiple addresses during the migration
period, since the two resulting paths may have different round-trip period, since the two resulting paths may have different round-trip
times. A receiver of packets on multiple paths will still send ACK times. A receiver of packets on multiple paths will still send ACK
frames covering all received packets. frames covering all received packets.
While multiple paths might be used during connection migration, a While multiple paths might be used during connection migration, a
single congestion control context and a single loss recovery context single congestion control context and a single loss recovery context
(as described in [QUIC-RECOVERY]) may be adequate. A sender can make (as described in [QUIC-RECOVERY]) may be adequate. A sender can make
exceptions for probe packets so that their loss detection is exceptions for probe packets so that their loss detection is
independent and does not unduly cause the congestion controller to independent and does not unduly cause the congestion controller to
reduce its sending rate. An endpoint might arm a separate alarm when reduce its sending rate. An endpoint might set a separate timer when
a PATH_CHALLENGE is sent, which is disarmed when the corresponding a PATH_CHALLENGE is sent, which is cancelled when the corresponding
PATH_RESPONSE is received. If the alarm fires before the PATH_RESPONSE is received. If the timer fires before the
PATH_RESPONSE is received, the endpoint might send a new PATH_RESPONSE is received, the endpoint might send a new
PATH_CHALLENGE, and restart the alarm for a longer period of time. PATH_CHALLENGE, and restart the timer for a longer period of time.
6.11.5. Privacy Implications of Connection Migration 6.11.5. Privacy Implications of Connection Migration
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 6.1. as discussed in Section 6.1.
skipping to change at page 54, line 48 skipping to change at page 58, line 48
An endpoint could receive packets from a new source address, An endpoint could receive packets from a new source address,
indicating a client connection migration (Section 6.11), while in the indicating a client connection migration (Section 6.11), while in the
closing period. An endpoint in the closing state MUST strictly limit closing period. An endpoint in the closing state MUST strictly limit
the number of packets it sends to this new address until the address the number of packets it sends to this new address until the address
is validated (see Section 6.10). A server in the closing state MAY is validated (see Section 6.10). A server in the closing state MAY
instead choose to discard packets received from a new source address. instead choose to discard packets received from a new source address.
6.13.2. Idle Timeout 6.13.2. Idle Timeout
A connection that remains idle for longer than the idle timeout (see A connection that remains idle for longer than the advertised idle
Section 6.6.1) is closed. A connection enters the draining state timeout (see Section 6.6.1) is closed. A connection enters the
when the idle timeout expires. draining state when the idle timeout expires.
The time at which an idle timeout takes effect won't be perfectly Each endpoint advertises their own idle timeout to their peer. The
synchronized on both endpoints. An endpoint that sends packets near idle timeout starts from the last packet received. In order to
the end of an idle period could have those packets discarded if its ensure that initiating new activity postpones an idle timeout, an
peer enters the draining state before the packet is received. endpoint restarts this timer when sending a packet. An endpoint does
not postpone the idle timeout if another packet has been sent
containing frames other than ACK or PADDING, and that other packet
has not been acknowledged or declared lost. Packets that contain
only ACK or PADDING frames are not acknowledged until an endpoint has
other frames to send, so they could prevent the timeout from being
refreshed.
The value for an idle timeout can be asymmetric. The value
advertised by an endpoint is only used to determine whether the
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
packets discarded if its peer enters the draining state before the
packets arrive. If a peer could timeout within an RTO (see
Section 4.3.3 of [QUIC-RECOVERY]), it is advisable to test for
liveness before sending any data that cannot be retried safely.
6.13.3. Immediate Close 6.13.3. Immediate Close
An endpoint sends a closing frame (CONNECTION_CLOSE or An endpoint sends a closing frame (CONNECTION_CLOSE or
APPLICATION_CLOSE) to terminate the connection immediately. Any APPLICATION_CLOSE) to terminate the connection immediately. Any
closing frame causes all streams to immediately become closed; open closing frame causes all streams to immediately become closed; open
streams can be assumed to be implicitly reset. streams can be assumed to be implicitly reset.
After sending a closing frame, endpoints immediately enter the After sending a closing frame, endpoints immediately enter the
closing state. During the closing period, an endpoint that sends a closing state. During the closing period, an endpoint that sends a
skipping to change at page 56, line 40 skipping to change at page 61, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Stateless Reset Token (128) + + Stateless Reset Token (128) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: 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.
The message consists of a header octet, followed by random octets of The message consists of a header octet, followed by an arbitrary
arbitrary length, followed by a Stateless Reset Token. number of random octets, followed by a 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 Octets a short header. For the packet to appear as valid, the Random Octets
field needs to include at least 20 octets of random or unpredictable field needs to include at least 20 octets of random or unpredictable
values. This is intended to allow for a destination connection ID of values. This is intended to allow for a destination connection ID of
the maximum length permitted, a packet number, and minimal payload. the maximum length permitted, a packet number, and minimal payload.
The Stateless Reset Token corresponds to the minimum expansion of the The Stateless Reset Token corresponds to the minimum expansion of the
packet protection AEAD. More random octets might be necessary if the packet protection AEAD. More random octets might be necessary if the
endpoint could have negotiated a packet protection scheme with a endpoint could have negotiated a packet protection scheme with a
larger minimum AEAD expansion. 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 less than 19 octets long are functions defined in [QUIC-TLS], packets less than 19 octets long are
never valid. never valid.
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
token was not yet available to a peer. In this QUIC version, packets
with a long header are only used during connection establishment.
Because the stateless reset token is not available until connection
establishment is complete or near completion, ignoring an unknown
packet with a long header might be more effective.
An endpoint cannot determine the Source Connection ID from a packet An endpoint cannot determine the Source Connection ID from a packet
with a short header, therefore it cannot set the Destination with a short header, therefore it cannot set the Destination
Connection ID in the stateless reset packet. The destination Connection ID in the stateless reset packet. The destination
connection ID will therefore differ from the value used in previous connection ID will therefore differ from the value used in previous
packets. A random Destination Connection ID makes the connection ID packets. A random Destination Connection ID makes the connection ID
appear to be the result of moving to a new connection ID that was appear to be the result of moving to a new connection ID that was
provided using a NEW_CONNECTION_ID frame (Section 7.13). provided using a NEW_CONNECTION_ID frame (Section 7.13).
Using a randomized connection ID results in two problems: Using a randomized connection ID results in two problems:
o The packet might not reach the peer. If the Destination o The packet might not reach the peer. If the Destination
Connection ID is critical for routing toward the peer, then this Connection ID is critical for routing toward the peer, then this
packet could be incorrectly routed. This causes the stateless packet could be incorrectly routed. This might also trigger
reset to be ineffective in causing errors to be quickly detected another Stateless Reset in response, see Section 6.13.4.3. A
and recovered. In this case, endpoints will need to rely on other Stateless Reset that is not correctly routed is ineffective in
methods - such as timers - to detect that the connection has causing errors to be quickly detected and recovered. In this
failed. case, endpoints will need to rely on other methods - such as
timers - to detect that the connection has failed.
o The randomly generated connection ID can be used by entities other o The randomly generated connection ID can be used by entities other
than the peer to identify this as a potential stateless reset. An than the peer to identify this as a potential stateless reset. An
endpoint that occasionally uses different connection IDs might endpoint that occasionally uses different connection IDs might
introduce some uncertainty about this. introduce some uncertainty about this.
Finally, the last 16 octets of the packet are set to the value of the Finally, the last 16 octets of the packet are set to the value of the
Stateless Reset Token. Stateless Reset Token.
A stateless reset is not appropriate for signaling error conditions. A stateless reset is not appropriate for signaling error conditions.
skipping to change at page 58, line 28 skipping to change at page 63, line 19
The stateless reset token MUST be difficult to guess. In order to The stateless reset token MUST be difficult to guess. In order to
create a Stateless Reset Token, an endpoint could randomly generate create a Stateless Reset Token, an endpoint could randomly generate
[RFC4086] a secret for every connection that it creates. However, [RFC4086] a secret for every connection that it creates. However,
this presents a coordination problem when there are multiple this presents a coordination problem when there are multiple
instances in a cluster or a storage problem for a endpoint that might instances in a cluster or a storage problem for a endpoint that might
lose state. Stateless reset specifically exists to handle the case lose state. Stateless reset specifically exists to handle the case
where state is lost, so this approach is suboptimal. where state is lost, so this approach is suboptimal.
A single static key can be used across all connections to the same A single static key can be used across all connections to the same
endpoint by generating the proof using a second iteration of a endpoint by generating the proof using a second iteration of a
preimage-resistant function that takes three inputs: the static key, preimage-resistant function that takes a static key and the
the connection ID chosen by the endpoint (see Section 6.1), and an connection ID chosen by the endpoint (see Section 6.1) as input. An
instance identifier. An endpoint could use HMAC [RFC2104] (for endpoint could use HMAC [RFC2104] (for example, HMAC(static_key,
example, HMAC(static_key, instance_id || connection_id)) or HKDF connection_id)) or HKDF [RFC5869] (for example, using the static key
[RFC5869] (for example, using the static key as input keying as input keying material, with the connection ID as salt). The
material, with instance and connection identifiers as salt). The
output of this function is truncated to 16 octets to produce the output of this function is truncated to 16 octets to produce the
Stateless Reset Token for that connection. Stateless Reset Token for that connection.
An endpoint that loses state can use the same method to generate a An endpoint that loses state can use the same method to generate a
valid Stateless Reset Token. The connection ID comes from the packet valid Stateless Reset Token. The connection ID comes from the packet
that the endpoint receives. An instance that receives a packet for that the endpoint receives.
another instance might be able to recover the instance identifier
using the connection ID. Alternatively, the instance identifier
might be omitted from the calculation of the Stateless Reset Token so
that all instances are equally able to generate a stateless reset.
This design relies on the peer always sending a connection ID in its This design relies on the peer always sending a connection ID in its
packets so that the endpoint can use the connection ID from a packet packets so that the endpoint can use the connection ID from a packet
to reset the connection. An endpoint that uses this design cannot to reset the connection. An endpoint that uses this design MUST
allow its peers to send packets with a zero-length destination either use the same connection ID length for all connections or
encode the length of the connection ID such that it can be recovered
without state. In addition, it MUST NOT provide a zero-length
connection ID. connection ID.
Revealing the Stateless Reset Token allows any entity to terminate Revealing the Stateless Reset Token allows any entity to terminate
the connection, so a value can only be used once. This method for the connection, so a value can only be used once. This method for
choosing the Stateless Reset Token means that the combination of choosing the Stateless Reset Token means that the combination of
instance, connection ID, and static key cannot occur for another connection ID and static key cannot occur for another connection. A
connection. A connection ID from a connection that is reset by denial of service attack is possible if the same connection ID is
revealing the Stateless Reset Token cannot be reused for new used by instances that share a static key, or if an attacker can
connections at the same instance without first changing to use a cause a packet to be routed to an instance that has no state but the
different static key or instance identifier. same static key (see Section 12.8). A connection ID from a
connection that is reset by revealing the Stateless Reset Token
cannot be reused for new connections at nodes that share a static
key.
Note that Stateless Reset messages do not have any cryptographic Note that Stateless Reset packets do not have any cryptographic
protection. protection.
6.13.4.3. Looping
The design of a Stateless Reset is such that it is indistinguishable
from a valid packet. This means that a Stateless Reset might trigger
the sending of a Stateless Reset in response, which could lead to
infinite exchanges.
An endpoint MUST ensure that every Stateless Reset that it sends is
smaller than the packet triggered it, unless it maintains state
sufficient to prevent looping. In the event of a loop, this results
in packets eventually being too small to trigger a response.
An endpoint can remember the number of Stateless Reset packets that
it has sent and stop generating new Stateless Reset packets once a
limit is reached. Using separate limits for different remote
addresses will ensure that Stateless Reset packets can be used to
close connections when other peers or connections have exhausted
limits.
Reducing the size of a Stateless Reset below the recommended minimum
size of 37 octets could mean that the packet could reveal to an
observer that it is a Stateless Reset. Conversely, refusing to send
a Stateless Reset in response to a small packet might result in
Stateless Reset not being useful in detecting cases of broken
connections where only very small packets are sent; such failures
might only be detected by other means, such as timers.
7. Frame Types and Formats 7. Frame Types and Formats
As described in Section 5, packets contain one or more frames. This As described in Section 5, packets contain one or more frames. This
section describes the format and semantics of the core QUIC frame section describes the format and semantics of the core QUIC frame
types. types.
7.1. Variable-Length Integer Encoding 7.1. Variable-Length Integer Encoding
QUIC frames commonly use a variable-length encoding for non-negative QUIC frames commonly use a variable-length encoding for non-negative
integer values. This encoding ensures that smaller integer values integer values. This encoding ensures that smaller integer values
skipping to change at page 61, line 41 skipping to change at page 67, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase Length (i) ... | Reason Phrase Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (*) ... | Reason Phrase (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of a CONNECTION_CLOSE frame are as follows: The fields of a CONNECTION_CLOSE frame are as follows:
Error Code: A 16-bit error code which indicates the reason for Error Code: A 16-bit error code which indicates the reason for
closing this connection. CONNECTION_CLOSE uses codes from the closing this connection. CONNECTION_CLOSE uses codes from the
space defined in Section 11.3 (APPLICATION_CLOSE uses codes from space defined in Section 11.3.
the application protocol error code space, see Section 11.4).
Frame Type: The type of frame that triggered the error. A value of Frame Type: A variable-length integer encoding the type of frame
0 (equivalent to the mention of the PADDING frame) is used when that triggered the error. A value of 0 (equivalent to the mention
the frame type is unknown. of the PADDING frame) is used when the frame type is unknown.
Reason Phrase Length: A variable-length integer specifying the Reason Phrase Length: A variable-length integer specifying the
length of the reason phrase in bytes. Note that a length of the reason phrase in bytes. Note that a
CONNECTION_CLOSE frame cannot be split between packets, so in CONNECTION_CLOSE frame cannot be split between packets, so in
practice any limits on packet size will also limit the space practice any limits on packet size will also limit the space
available for a reason phrase. available for a reason phrase.
Reason Phrase: A human-readable explanation for why the connection Reason Phrase: A human-readable explanation for why the connection
was closed. This can be zero length if the sender chooses to not was closed. This can be zero length if the sender chooses to not
give details beyond the Error Code. This SHOULD be a UTF-8 give details beyond the Error Code. This SHOULD be a UTF-8
encoded string [RFC3629]. encoded string [RFC3629].
7.5. APPLICATION_CLOSE frame 7.5. APPLICATION_CLOSE frame
An APPLICATION_CLOSE frame (type=0x03) uses the same format as the An APPLICATION_CLOSE frame (type=0x03) is used to signal an error
CONNECTION_CLOSE frame (Section 7.4), except that it uses error codes with the protocol that uses QUIC.
from the application protocol error code space (Section 11.4) instead
of the transport error code space.
Other than the error code space, the format and semantics of the The APPLICATION_CLOSE frame is as follows:
APPLICATION_CLOSE frame are identical to the CONNECTION_CLOSE frame.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of a APPLICATION_CLOSE frame are as follows:
Error Code: A 16-bit error code which indicates the reason for
closing this connection. APPLICATION_CLOSE uses codes from the
application protocol error code space, see Section 11.4.
Reason Phrase Length: This field is identical in format and
semantics to the Reason Phrase Length field from CONNECTION_CLOSE.
Reason Phrase: This field is identical in format and semantics to
the Reason Phrase field from CONNECTION_CLOSE.
APPLICATION_CLOSE has similar format and semantics to the
CONNECTION_CLOSE frame (Section 7.4). Aside from the semantics of
the Error Code field and the omission of the Frame Type field, both
frames are used to close the connection.
7.6. MAX_DATA Frame 7.6. MAX_DATA Frame
The MAX_DATA frame (type=0x04) is used in flow control to inform the The MAX_DATA frame (type=0x04) is used in flow control to inform the
peer of the maximum amount of data that can be sent on the connection peer of the maximum amount of data that can be sent on the connection
as a whole. as a whole.
The frame is as follows: The frame is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 69, line 26 skipping to change at page 75, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Largest Acknowledged (i) ... | Largest Acknowledged (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Delay (i) ... | ACK Delay (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Block Count (i) ... | ACK Block Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Blocks (*) ... | ACK Blocks (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: ACK Frame Format Figure 12: ACK Frame Format
The fields in the ACK frame are as follows: The fields in the ACK frame are as follows:
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
microseconds that the largest acknowledged packet, as indicated in microseconds that the largest acknowledged packet, as indicated in
the Largest Acknowledged field, was received by this peer to when the Largest Acknowledged field, was received by this peer to when
this ACK was sent. The value of the ACK Delay field is scaled by this ACK was sent. The value of the ACK Delay field is scaled by
multiplying the encoded value by the 2 to the power of the value multiplying the encoded value by the 2 to the power of the value
of the "ack_delay_exponent" transport parameter set by the sender of the "ack_delay_exponent" transport parameter set by the sender
of the ACK frame. The "ack_delay_exponent" defaults to 3, or a of the ACK frame. The "ack_delay_exponent" defaults to 3, or a
multiplier of 8 (see Section 6.6.1). Scaling in this fashion multiplier of 8 (see Section 6.6.1). Scaling in this fashion
allows for a larger range of values with a shorter encoding at the allows for a larger range of values with a shorter encoding at the
cost of lower resolution. cost of lower resolution.
ACK Block Count: The number of Additional ACK Block (and Gap) fields ACK Block Count: A variable-length integer specifying the number of
after the First ACK Block. Additional ACK Block (and Gap) fields after the First ACK Block.
ACK Blocks: Contains one or more blocks of packet numbers which have ACK Blocks: Contains one or more blocks of packet numbers which have
been successfully received, see Section 7.15.1. been successfully received, see Section 7.15.1.
7.15.1. ACK Block Section 7.15.1. ACK Block Section
The ACK Block Section consists of alternating Gap and ACK Block The ACK Block Section consists of alternating Gap and ACK Block
fields in descending packet number order. A First Ack Block field is fields in descending packet number order. A First Ack Block field is
followed by a variable number of alternating Gap and Additional ACK followed by a variable number of alternating Gap and Additional ACK
Blocks. The number of Gap and Additional ACK Block fields is Blocks. The number of Gap and Additional ACK Block fields is
skipping to change at page 70, line 40 skipping to change at page 76, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional ACK Block (i) ... | Additional ACK Block (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gap (i) ... | Gap (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional ACK Block (i) ... | Additional ACK Block (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: ACK Block Section Figure 13: ACK Block Section
Each ACK Block acknowledges a contiguous range of packets by Each ACK Block acknowledges a contiguous range of packets by
indicating the number of acknowledged packets that precede the indicating the number of acknowledged packets that precede the
largest packet number in that block. A value of zero indicates that largest packet number in that block. A value of zero indicates that
only the largest packet number is acknowledged. Larger ACK Block only the largest packet number is acknowledged. Larger ACK Block
values indicate a larger range, with corresponding lower values for values indicate a larger range, with corresponding lower values for
the smallest packet number in the range. Thus, given a largest the smallest packet number in the range. Thus, given a largest
packet number for the ACK, the smallest value is determined by the packet number for the ACK, the smallest value is determined by the
formula: formula:
skipping to change at page 72, line 32 skipping to change at page 78, line 32
without receiving acknowledgment of its ACK frames, with the without receiving acknowledgment of its ACK frames, with the
knowledge this could cause the sender to unnecessarily retransmit knowledge this could cause the sender to unnecessarily retransmit
some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets some data. Standard QUIC [QUIC-RECOVERY] algorithms declare packets
lost after sufficiently newer packets are acknowledged. Therefore, lost after sufficiently newer packets are acknowledged. Therefore,
the receiver SHOULD repeatedly acknowledge newly received packets in the receiver SHOULD repeatedly acknowledge newly received packets in
preference to packets received in the past. preference to packets received in the past.
7.15.3. ACK Frames and Packet Protection 7.15.3. ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed (see Section 4.5). For number space as the packet being ACKed (see Section 4.8). For
instance, packets that are protected with 1-RTT keys MUST be instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys. acknowledged in packets that are also protected with 1-RTT keys.
Packets that a client sends with 0-RTT packet protection MUST be Packets that a client sends with 0-RTT packet protection MUST be
acknowledged by the server in packets protected by 1-RTT keys. This acknowledged by the server in packets protected by 1-RTT keys. This
can mean that the client is unable to use these acknowledgments if can mean that the client is unable to use these acknowledgments if
the server cryptographic handshake messages are delayed or lost. the server cryptographic handshake messages are delayed or lost.
Note that the same limitation applies to other data sent by the Note that the same limitation applies to other data sent by the
server protected by the 1-RTT keys. server protected by the 1-RTT keys.
Endpoints SHOULD send acknowledgments for packets containing CRYPTO Endpoints SHOULD send acknowledgments for packets containing CRYPTO
frames with a reduced delay; see Section 3.5.1 of [QUIC-RECOVERY]. frames with a reduced delay; see Section 4.3.1 of [QUIC-RECOVERY].
7.16. ACK_ECN Frame 7.16. ACK_ECN Frame
The ACK_ECN frame (type=0x20) is used by an endpoint that supports The ACK_ECN frame (type=0x1a) is used by an endpoint that supports
ECN to acknowledge packets received with ECN codepoints of ECT(0), ECN to acknowledge packets received with ECN codepoints of ECT(0),
ECT(1), or CE in the packet's IP header. ECT(1), or CE in the packet's IP header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Largest Acknowledged (i) ... | Largest Acknowledged (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Delay (i) ... | ACK Delay (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 73, line 23 skipping to change at page 79, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT(1) Count (i) ... | ECT(1) Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Count (i) ... | ECN-CE Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Block Count (i) ... | ACK Block Count (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Blocks (*) ... | ACK Blocks (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ACK_ECN Frame Format Figure 14: ACK_ECN Frame Format
An ACK_ECN frame contains all the elements of the ACK frame An ACK_ECN frame contains all the elements of the ACK frame
(Section 7.15) with the addition of three counts following the ACK (Section 7.15) with the addition of three counts following the ACK
Delay field. Delay field.
ECT(0) Count: A variable-length integer representing the total ECT(0) Count: A variable-length integer representing the total
number packets received with the ECT(0) codepoint. number packets received with the ECT(0) codepoint.
ECT(1) Count: A variable-length integer representing the total ECT(1) Count: A variable-length integer representing the total
number packets received with the ECT(1) codepoint. number packets received with the ECT(1) codepoint.
skipping to change at page 74, line 21 skipping to change at page 80, line 21
(Section 7.18) containing the same Data. (Section 7.18) containing the same Data.
7.18. PATH_RESPONSE Frame 7.18. PATH_RESPONSE Frame
The PATH_RESPONSE frame (type=0x0f) is sent in response to a The PATH_RESPONSE frame (type=0x0f) is sent in response to a
PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE PATH_CHALLENGE frame. Its format is identical to the PATH_CHALLENGE
frame (Section 7.17). frame (Section 7.17).
If the content of a PATH_RESPONSE frame does not match the content of If the content of a PATH_RESPONSE frame does not match the content of
a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint
MAY generate a connection error of type UNSOLICITED_PATH_RESPONSE. MAY generate a connection error of type PROTOCOL_VIOLATION.
7.19. NEW_TOKEN frame 7.19. NEW_TOKEN frame
A server sends a NEW_TOKEN frame (type=0x19) to provide the client a A server sends a NEW_TOKEN frame (type=0x19) to provide the client a
token to send in a the header of an Initial packet for a future token to send in the header of an Initial packet for a future
connection. connection.
The NEW_TOKEN frame is as follows: The NEW_TOKEN frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Length (i) ... | Token Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (*) ... | Token (*) ...
skipping to change at page 75, line 40 skipping to change at page 81, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Offset (i)] ... | [Offset (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Length (i)] ... | [Length (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Data (*) ... | Stream Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: STREAM Frame Format Figure 15: STREAM Frame Format
The STREAM frame contains the following fields: The STREAM frame contains 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 9.1). stream (see Section 9.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 77, line 15 skipping to change at page 83, line 15
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 13: CRYPTO Frame Format Figure 16: CRYPTO Frame Format
The CRYPTO frame contains the following fields: The CRYPTO frame contains 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 78, line 23 skipping to change at page 84, line 23
Once the packet has been fully processed, a receiver acknowledges Once the packet has been fully processed, a receiver acknowledges
receipt by sending one or more ACK frames containing the packet receipt by sending one or more ACK frames containing the packet
number of the received packet. To avoid creating an indefinite number of the received packet. To avoid creating an indefinite
feedback loop, an endpoint MUST NOT send an ACK frame in response to feedback loop, an endpoint MUST NOT send an ACK frame in response to
a packet containing only ACK or PADDING frames, even if there are a packet containing only ACK or PADDING frames, even if there are
packet gaps which precede the received packet. The endpoint MUST packet gaps which precede the received packet. The endpoint MUST
acknowledge packets containing only ACK or PADDING frames in the next acknowledge packets containing only ACK or PADDING frames in the next
ACK frame that it sends. ACK frame that it sends.
While PADDING frames do not elicit an ACK frame from a receiver, they
are considered to be in flight for congestion control purposes
[QUIC-RECOVERY]. Sending only PADDING frames might cause the sender
to become limited by the congestion controller (as described in
[QUIC-RECOVERY]) with no acknowledgments forthcoming from the
receiver. Therefore, a sender should ensure that other frames are
sent in addition to PADDING frames to elicit acknowledgments from the
receiver.
Strategies and implications of the frequency of generating Strategies and implications of the frequency of generating
acknowledgments are discussed in more detail in [QUIC-RECOVERY]. acknowledgments are discussed in more detail in [QUIC-RECOVERY].
8.2. Retransmission of Information 8.2. Retransmission of Information
QUIC packets that are determined to be lost are not retransmitted QUIC packets that are determined to be lost are not retransmitted
whole. The same applies to the frames that are contained within lost whole. The same applies to the frames that are contained within lost
packets. Instead, the information that might be carried in frames is packets. Instead, the information that might be carried in frames is
sent again in new frames as needed. sent again in new frames as needed.
skipping to change at page 80, line 26 skipping to change at page 86, line 35
Upon detecting losses, a sender MUST take appropriate congestion Upon detecting losses, a sender MUST take appropriate congestion
control action. The details of loss detection and congestion control control action. The details of loss detection and congestion control
are described in [QUIC-RECOVERY]. are described in [QUIC-RECOVERY].
8.3. Packet Size 8.3. Packet Size
The QUIC packet size includes the QUIC header and integrity check, The QUIC packet size includes the QUIC header and integrity check,
but not the UDP or IP header. but not the UDP or IP header.
Clients MUST pad any Initial packet it sends to have a QUIC packet Clients MUST ensure that the first Initial packet it sends is sent in
size of at least 1200 octets. Sending an Initial packet of this size a UDP datagram that is at least 1200 octets. Padding the Initial
ensures that the network path supports a reasonably sized packet, and packet or including a 0-RTT packet in the same datagram are ways to
helps reduce the amplitude of amplification attacks caused by server meet this requirement. Sending a UDP datagram of this size ensures
responses toward an unverified client address. that the network path supports a reasonable Maximum Transmission Unit
(MTU), and helps reduce the amplitude of amplification attacks caused
by server responses toward an unverified client address.
An Initial packet MAY exceed 1200 octets if the client knows that the The datagram containing the first Initial packet from a client MAY
Path Maximum Transmission Unit (PMTU) supports the size that it exceed 1200 octets if the client believes that the Path Maximum
chooses. Transmission Unit (PMTU) supports the size that it chooses.
A server MAY send a CONNECTION_CLOSE frame with error code A server MAY send a CONNECTION_CLOSE frame with error code
PROTOCOL_VIOLATION in response to an Initial packet smaller than 1200 PROTOCOL_VIOLATION in response to the first Initial packet it
receives from a client if the UDP datagram is smaller than 1200
octets. It MUST NOT send any other frame type in response, or octets. It MUST NOT send any other frame type in response, or
otherwise behave as if any part of the offending packet was processed otherwise behave as if any part of the offending packet was processed
as valid. as valid.
8.4. Path Maximum Transmission Unit 8.4. Path Maximum Transmission Unit
The Path Maximum Transmission Unit (PMTU) is the maximum size of the The Path Maximum Transmission Unit (PMTU) is the maximum size of the
entire IP header, UDP header, and UDP payload. The UDP payload entire IP header, UDP header, and UDP payload. The UDP payload
includes the QUIC packet header, protected payload, and any includes the QUIC packet header, protected payload, and any
authentication fields. authentication fields.
skipping to change at page 82, line 27 skipping to change at page 88, line 39
delivered reliably. As a result, the loss of PADDING frames in probe delivered reliably. As a result, the loss of PADDING frames in probe
packets does not require delay-inducing retransmission. However, packets does not require delay-inducing retransmission. However,
PADDING frames do consume congestion window, which may delay the PADDING frames do consume congestion window, which may delay the
transmission of subsequent application data. transmission of subsequent application data.
When implementing the algorithm in Section 7.2 of [PLPMTUD], the When implementing the algorithm in Section 7.2 of [PLPMTUD], the
initial value of search_low SHOULD be consistent with the IPv6 initial value of search_low SHOULD be consistent with the IPv6
minimum packet size. Paths that do not support this size cannot minimum packet size. Paths that do not support this size cannot
deliver Initial packets, and therefore are not QUIC-compliant. deliver Initial packets, and therefore are not QUIC-compliant.
Section 7.3 of [PLPMTUD] discusses tradeoffs between small and large Section 7.3 of [PLPMTUD] discusses trade-offs between small and large
increases in the size of probe packets. As QUIC probe packets need increases in the size of probe packets. As QUIC probe packets need
not contain application data, aggressive increases in probe size not contain application data, aggressive increases in probe size
carry fewer consequences. carry fewer consequences.
9. Streams: QUIC's Data Structuring Abstraction 9. Streams: QUIC's Data Structuring Abstraction
Streams in QUIC provide a lightweight, ordered byte-stream Streams in QUIC provide a lightweight, ordered byte-stream
abstraction. abstraction.
There are two basic types of stream in QUIC. Unidirectional streams There are two basic types of stream in QUIC. Unidirectional streams
skipping to change at page 84, line 21 skipping to change at page 90, line 29
| | | | | |
| 0x2 | Client-Initiated, Unidirectional | | 0x2 | Client-Initiated, Unidirectional |
| | | | | |
| 0x3 | Server-Initiated, Unidirectional | | 0x3 | Server-Initiated, Unidirectional |
+----------+----------------------------------+ +----------+----------------------------------+
Table 5: Stream ID Types Table 5: Stream ID Types
The first bi-directional stream opened by the client is stream 0. The first bi-directional stream opened by the client is stream 0.
A QUIC endpoint MUST NOT reuse a Stream ID. Streams can be used in A QUIC endpoint MUST NOT reuse a Stream ID. Streams of each type are
any order. Streams that are used out of order result in opening all created in numeric order. Streams that are used out of order result
lower-numbered streams of the same type in the same direction. in opening all lower-numbered streams of the same type in the same
direction.
Stream IDs are encoded as a variable-length integer (see Stream IDs are encoded as a variable-length integer (see
Section 7.1). Section 7.1).
9.2. Stream States 9.2. Stream States
This section describes the two types of QUIC stream in terms of the This section describes the two types of QUIC stream in terms of the
states of their send or receive components. Two state machines are states of their send or receive components. Two state machines are
described: one for streams on which an endpoint transmits data described: one for streams on which an endpoint transmits data
(Section 9.2.1); another for streams from which an endpoint receives (Section 9.2.1); another for streams from which an endpoint receives
skipping to change at page 85, line 11 skipping to change at page 91, line 21
of frames can be sent and the reactions that are expected when of frames can be sent and the reactions that are expected when
different types of frames are received. Though these state different types of frames are received. Though these state
machines are intended to be useful in implementing QUIC, these machines are intended to be useful in implementing QUIC, these
states aren't intended to constrain implementations. An states aren't intended to constrain implementations. An
implementation can define a different state machine as long as its implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements behavior is consistent with an implementation that implements
these states. these states.
9.2.1. Send Stream States 9.2.1. Send Stream States
Figure 14 shows the states for the part of a stream that sends data Figure 17 shows the states for the part of a stream that sends data
to a peer. to a peer.
o o
| Create Stream (Sending) | Create Stream (Sending)
| Create Bidirectional Stream (Receiving) | Create Bidirectional Stream (Receiving)
v v
+-------+ +-------+
| Ready | Send RST_STREAM | Ready | Send RST_STREAM
| |-----------------------. | |-----------------------.
+-------+ | +-------+ |
skipping to change at page 85, line 45 skipping to change at page 92, line 36
| Sent +------------------>| Sent | | Sent +------------------>| Sent |
+-------+ +-------+ +-------+ +-------+
| | | |
| Recv All ACKs | Recv ACK | Recv All ACKs | Recv ACK
v v v v
+-------+ +-------+ +-------+ +-------+
| Data | | Reset | | Data | | Reset |
| Recvd | | Recvd | | Recvd | | Recvd |
+-------+ +-------+ +-------+ +-------+
Figure 14: States for Send Streams Figure 17: States for Send Streams
The sending part of stream that the endpoint initiates (types 0 and 2 The sending part of stream that the endpoint initiates (types 0 and 2
for clients, 1 and 3 for servers) is opened by the application or for clients, 1 and 3 for servers) is opened by the application or
application protocol. The "Ready" state represents a newly created application protocol. The "Ready" state represents a newly created
stream that is able to accept data from the application. Stream data stream that is able to accept data from the application. Stream data
might be buffered in this state in preparation for sending. might be buffered in this state in preparation for sending.
The sending part of a bidirectional stream initiated by a peer (type The sending part of a bidirectional stream initiated by a peer (type
0 for a server, type 1 for a client) enters the "Ready" state if the 0 for a server, type 1 for a client) enters the "Ready" state if the
receiving part enters the "Recv" state. receiving part enters the "Recv" state.
skipping to change at page 86, line 49 skipping to change at page 93, line 39
An endpoint MAY send a RST_STREAM as the first frame on a send An endpoint MAY send a RST_STREAM as the first frame on a send
stream; this causes the send stream to open and then immediately stream; this causes the send stream to open and then immediately
transition to the "Reset Sent" state. transition to the "Reset Sent" state.
Once a packet containing a RST_STREAM has been acknowledged, the send Once a packet containing a RST_STREAM has been acknowledged, the send
stream enters the "Reset Recvd" state, which is a terminal state. stream enters the "Reset Recvd" state, which is a terminal state.
9.2.2. Receive Stream States 9.2.2. Receive Stream States
Figure 15 shows the states for the part of a stream that receives Figure 18 shows the states for the part of a stream that receives
data from a peer. The states for a receive stream mirror only some data from a peer. The states for a receive stream mirror only some
of the states of the send stream at the peer. A receive stream of the states of the send stream at the peer. A receive stream
doesn't track states on the send stream that cannot be observed, such doesn't track states on the send stream that cannot be observed, such
as the "Ready" state; instead, receive streams track the delivery of as the "Ready" state; instead, receive streams track the delivery of
data to the application or application protocol some of which cannot data to the application or application protocol some of which cannot
be observed by the sender. be observed by the sender.
o o
| Recv STREAM / STREAM_BLOCKED / RST_STREAM | Recv STREAM / STREAM_BLOCKED / RST_STREAM
| Create Bidirectional Stream (Sending) | Create Bidirectional Stream (Sending)
| Recv MAX_STREAM_DATA | Recv MAX_STREAM_DATA
| Create Higher-Numbered Stream
v v
+-------+ +-------+
| Recv | Recv RST_STREAM | Recv | Recv RST_STREAM
| |-----------------------. | |-----------------------.
+-------+ | +-------+ |
| | | |
| Recv STREAM + FIN | | Recv STREAM + FIN |
v | v |
+-------+ | +-------+ |
| Size | Recv RST_STREAM | | Size | Recv RST_STREAM |
skipping to change at page 87, line 39 skipping to change at page 94, line 37
| Recvd +<-- (optional) --->| Recvd | | Recvd +<-- (optional) --->| Recvd |
+-------+ +-------+ +-------+ +-------+
| | | |
| App Read All Data | App Read RST | App Read All Data | App Read RST
v v v v
+-------+ +-------+ +-------+ +-------+
| Data | | Reset | | Data | | Reset |
| Read | | Read | | Read | | Read |
+-------+ +-------+ +-------+ +-------+
Figure 15: States for Receive Streams Figure 18: States for Receive Streams
The receiving part of a stream initiated by a peer (types 1 and 3 for The receiving part of a stream initiated by a peer (types 1 and 3 for
a client, or 0 and 2 for a server) are created when the first STREAM, a client, or 0 and 2 for a server) are created when the first STREAM,
STREAM_BLOCKED, RST_STREAM, or MAX_STREAM_DATA (bidirectional only, STREAM_BLOCKED, RST_STREAM, or MAX_STREAM_DATA (bidirectional only,
see below) is received for that stream. The initial state for a see below) is received for that stream. The initial state for a
receive stream is "Recv". Receiving a RST_STREAM frame causes the receive stream is "Recv". Receiving a RST_STREAM frame causes the
receive stream to immediately transition to the "Reset Recvd". receive stream to immediately transition to the "Reset Recvd".
The receive stream enters the "Recv" state when the sending part of a The receive stream enters the "Recv" state when the sending part of a
bidirectional stream initiated by the endpoint (type 0 for a client, bidirectional stream initiated by the endpoint (type 0 for a client,
type 1 for a server) enters the "Ready" state. type 1 for a server) enters the "Ready" state.
A bidirectional stream also opens when a MAX_STREAM_DATA frame is A bidirectional stream also opens when a MAX_STREAM_DATA frame is
received. Receiving a MAX_STREAM_DATA frame implies that the remote received. Receiving a MAX_STREAM_DATA frame implies that the remote
peer has opened the stream and is providing flow control credit. A peer has opened the stream and is providing flow control credit. A
MAX_STREAM_DATA frame might arrive before a STREAM or STREAM_BLOCKED MAX_STREAM_DATA frame might arrive before a STREAM or STREAM_BLOCKED
frame if packets are lost or reordered. frame if packets are lost or reordered.
Before creating a stream, all lower-numbered streams of the same type
MUST be created. That means that receipt of a frame that would open
a stream causes all lower-numbered streams of the same type to be
opened in numeric order. This ensures that the creation order for
streams is consistent on both endpoints.
In the "Recv" state, the endpoint receives STREAM and STREAM_BLOCKED In the "Recv" state, the endpoint receives STREAM and STREAM_BLOCKED
frames. Incoming data is buffered and can be reassembled into the frames. Incoming data is buffered and can be reassembled into the
correct order for delivery to the application. As data is consumed correct order for delivery to the application. As data is consumed
by the application and buffer space becomes available, the endpoint by the application and buffer space becomes available, the endpoint
sends MAX_STREAM_DATA frames to allow the peer to send more data. sends MAX_STREAM_DATA frames to allow the peer to send more data.
When a STREAM frame with a FIN bit is received, the final offset (see When a STREAM frame with a FIN bit is received, the final offset (see
Section 10.3) is known. The receive stream enters the "Size Known" Section 10.3) is known. The receive stream enters the "Size Known"
state. In this state, the endpoint no longer needs to send state. In this state, the endpoint no longer needs to send
MAX_STREAM_DATA frames, it only receives any retransmissions of MAX_STREAM_DATA frames, it only receives any retransmissions of
skipping to change at page 91, line 46 skipping to change at page 98, line 46
to the peer that receives the setting. That is, clients specify the to the peer that receives the setting. That is, clients specify the
maximum stream ID the server can initiate, and servers specify the maximum stream ID the server can initiate, and servers specify the
maximum stream ID the client can initiate. Each endpoint may respond maximum stream ID the client can initiate. Each endpoint may respond
on streams initiated by the other peer, regardless of whether it is on streams initiated by the other peer, regardless of whether it is
permitted to initiated new streams. permitted to initiated new streams.
Endpoints MUST NOT exceed the limit set by their peer. An endpoint Endpoints MUST NOT exceed the limit set by their peer. An endpoint
that receives a STREAM frame with an ID greater than the limit it has that receives a STREAM frame with an ID greater than the limit it has
sent MUST treat this as a stream error of type STREAM_ID_ERROR sent MUST treat this as a stream error of type STREAM_ID_ERROR
(Section 11), unless this is a result of a change in the initial (Section 11), unless this is a result of a change in the initial
offsets (see Section 6.6.2). limits (see Section 6.6.2).
A receiver MUST NOT renege on an advertisement; that is, once a A receiver cannot renege on an advertisement; that is, once a
receiver advertises a stream ID via a MAX_STREAM_ID frame, it MUST receiver advertises a stream ID via a MAX_STREAM_ID frame,
NOT subsequently advertise a smaller maximum ID. A sender may advertising a smaller maximum ID has no effect. A sender MUST ignore
receive MAX_STREAM_ID frames out of order; a sender MUST therefore any MAX_STREAM_ID frame that does not increase the maximum stream ID.
ignore any MAX_STREAM_ID that does not increase the maximum.
9.5. Sending and Receiving Data 9.5. Sending and Receiving Data
Once a stream is created, endpoints may use the stream to send and Once a stream is created, endpoints may use the stream to send and
receive data. Each endpoint may send a series of STREAM frames receive data. Each endpoint may send a series of STREAM frames
encapsulating data on a stream until the stream is terminated in that encapsulating data on a stream until the stream is terminated in that
direction. Streams are an ordered byte-stream abstraction, and they direction. Streams are an ordered byte-stream abstraction, and they
have no other structure within them. STREAM frame boundaries are not have no other structure within them. STREAM frame boundaries are not
expected to be preserved in retransmissions from the sender or during expected to be preserved in retransmissions from the sender or during
delivery to the application at the receiver. delivery to the application at the receiver.
skipping to change at page 94, line 11 skipping to change at page 101, line 11
receiver's buffer capacity for the connection, and (ii) Stream flow receiver's buffer capacity for the connection, and (ii) Stream flow
control, which prevents a single stream from consuming the entire control, which prevents a single stream from consuming the entire
receive buffer for a connection. receive buffer for a connection.
A data receiver sends MAX_STREAM_DATA or MAX_DATA frames to the A data receiver sends MAX_STREAM_DATA or MAX_DATA frames to the
sender to advertise additional credit. MAX_STREAM_DATA frames send sender to advertise additional credit. MAX_STREAM_DATA frames send
the maximum absolute byte offset of a stream, while MAX_DATA sends the maximum absolute byte offset of a stream, while MAX_DATA sends
the maximum of the sum of the absolute byte offsets of all streams. the maximum of the sum of the absolute byte offsets of all streams.
A receiver MAY advertise a larger offset at any point by sending A receiver MAY advertise a larger offset at any point by sending
MAX_DATA or MAX_STREAM_DATA frames. A receiver MUST NOT renege on an MAX_DATA or MAX_STREAM_DATA frames. A receiver cannot renege on an
advertisement; that is, once a receiver advertises an offset, it MUST advertisement; that is, once a receiver advertises an offset,
NOT subsequently advertise a smaller offset. A sender could receive advertising a smaller offset has no effect. A sender MUST therefore
MAX_DATA or MAX_STREAM_DATA frames out of order; a sender MUST ignore any MAX_DATA or MAX_STREAM_DATA frames that do not increase
therefore ignore any flow control offset that does not move the flow control limits.
window forward.
A receiver MUST close the connection with a FLOW_CONTROL_ERROR error A receiver MUST close the connection with a FLOW_CONTROL_ERROR error
(Section 11) if the peer violates the advertised connection or stream (Section 11) if the peer violates the advertised connection or stream
data limits. data limits.
A sender SHOULD send BLOCKED or STREAM_BLOCKED frames to indicate it A sender SHOULD send BLOCKED or STREAM_BLOCKED frames to indicate it
has data to write but is blocked by flow control limits. These has data to write but is blocked by flow control limits. These
frames are expected to be sent infrequently in common cases, but they frames are expected to be sent infrequently in common cases, but they
are considered useful for debugging and monitoring purposes. are considered useful for debugging and monitoring purposes.
skipping to change at page 95, line 45 skipping to change at page 102, line 45
10.1.2. Data Limit Increments 10.1.2. Data Limit Increments
This document leaves when and how many bytes to advertise in a This document leaves when and how many bytes to advertise in a
MAX_DATA or MAX_STREAM_DATA to implementations, but offers a few MAX_DATA or MAX_STREAM_DATA to implementations, but offers a few
considerations. These frames contribute to connection overhead. considerations. These frames contribute to connection overhead.
Therefore frequently sending frames with small changes is Therefore frequently sending frames with small changes is
undesirable. At the same time, infrequent updates require larger undesirable. At the same time, infrequent updates require larger
increments to limits if blocking is to be avoided. Thus, larger increments to limits if blocking is to be avoided. Thus, larger
updates require a receiver to commit to larger resource commitments. updates require a receiver to commit to larger resource commitments.
Thus there is a tradeoff between resource commitment and overhead Thus there is a trade-off between resource commitment and overhead
when determining how large a limit is advertised. when determining how large a limit is advertised.
A receiver MAY use an autotuning mechanism to tune the frequency and A receiver MAY use an autotuning mechanism to tune the frequency and
amount that it increases data limits based on a round-trip time amount that it increases data limits based on a round-trip time
estimate and the rate at which the receiving application consumes estimate and the rate at which the receiving application consumes
data, similar to common TCP implementations. data, similar to common TCP implementations.
10.2. Stream Limit Increment 10.2. Stream Limit Increment
As with flow control, this document leaves when and how many streams As with flow control, this document leaves when and how many streams
skipping to change at page 96, line 32 skipping to change at page 103, line 32
SHOULD send a BLOCKED or STREAM_BLOCKED frame. These frames are SHOULD send a BLOCKED or STREAM_BLOCKED frame. These frames are
expected to be useful for debugging at the receiver; they do not expected to be useful for debugging at the receiver; they do not
require any other action. A receiver SHOULD NOT wait for a BLOCKED require any other action. A receiver SHOULD NOT wait for a BLOCKED
or STREAM_BLOCKED frame before sending MAX_DATA or MAX_STREAM_DATA, or STREAM_BLOCKED frame before sending MAX_DATA or MAX_STREAM_DATA,
since doing so will mean that a sender is unable to send for an since doing so will mean that a sender is unable to send for an
entire round trip. entire round trip.
For smooth operation of the congestion controller, it is generally For smooth operation of the congestion controller, it is generally
considered best to not let the sender go into quiescence if considered best to not let the sender go into quiescence if
avoidable. To avoid blocking a sender, and to reasonably account for avoidable. To avoid blocking a sender, and to reasonably account for
the possibiity of loss, a receiver should send a MAX_DATA or the possibility of loss, a receiver should send a MAX_DATA or
MAX_STREAM_DATA frame at least two round trips before it expects the MAX_STREAM_DATA frame at least two round trips before it expects the
sender to get blocked. sender to get blocked.
A sender sends a single BLOCKED or STREAM_BLOCKED frame only once A sender sends a single BLOCKED or STREAM_BLOCKED frame only once
when it reaches a data limit. A sender SHOULD NOT send multiple when it reaches a data limit. A sender SHOULD NOT send multiple
BLOCKED or STREAM_BLOCKED frames for the same data limit, unless the BLOCKED or STREAM_BLOCKED frames for the same data limit, unless the
original frame is determined to be lost. Another BLOCKED or original frame is determined to be lost. Another BLOCKED or
STREAM_BLOCKED frame can be sent after the data limit is increased. STREAM_BLOCKED frame can be sent after the data limit is increased.
10.3. Stream Final Offset 10.3. Stream Final Offset
skipping to change at page 97, line 18 skipping to change at page 104, line 18
Once a final offset for a stream is known, it cannot change. If a Once a final offset for a stream is known, it cannot change. If a
RST_STREAM or STREAM frame causes the final offset to change for a RST_STREAM or STREAM frame causes the final offset to change for a
stream, an endpoint SHOULD respond with a FINAL_OFFSET_ERROR error stream, an endpoint SHOULD respond with a FINAL_OFFSET_ERROR error
(see Section 11). A receiver SHOULD treat receipt of data at or (see Section 11). A receiver SHOULD treat receipt of data at or
beyond the final offset as a FINAL_OFFSET_ERROR error, even after a beyond the final offset as a FINAL_OFFSET_ERROR error, even after a
stream is closed. Generating these errors is not mandatory, but only stream is closed. Generating these errors is not mandatory, but only
because requiring that an endpoint generate these errors also means because requiring that an endpoint generate these errors also means
that the endpoint needs to maintain the final offset state for closed that the endpoint needs to maintain the final offset state for closed
streams, which could mean a significant state commitment. streams, which could mean a significant state commitment.
10.4. Flow Control for Crytographic Handshake 10.4. Flow Control for Cryptographic Handshake
Data sent in CRYPTO frames is not flow controlled in the same way as Data sent in CRYPTO frames is not flow controlled in the same way as
STREAM frames. QUIC relies on the cryptographic protocol STREAM frames. QUIC relies on the cryptographic protocol
implementation to avoid excessive buffering of data, see [QUIC-TLS]. implementation to avoid excessive buffering of data, see [QUIC-TLS].
The implementation SHOULD provide an interface to QUIC to tell it The implementation SHOULD provide an interface to QUIC to tell it
about its buffering limits so that there is not excessive buffering about its buffering limits so that there is not excessive buffering
at multiple layers. at multiple layers.
11. Error Handling 11. Error Handling
skipping to change at page 99, line 48 skipping to change at page 106, line 48
VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport VERSION_NEGOTIATION_ERROR (0x9): An endpoint received transport
parameters that contained version negotiation parameters that parameters that contained version negotiation parameters that
disagreed with the version negotiation that it performed. This disagreed with the version negotiation that it performed. This
error code indicates a potential version downgrade attack. 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.
UNSOLICITED_PATH_RESPONSE (0xB): An endpoint received a
PATH_RESPONSE frame that did not correspond to any PATH_CHALLENGE
frame that it previously sent.
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 occuring cryptographic handshake that is used. Codes for errors occurring
when TLS is used for the crypto handshake are defined in when TLS is used for the crypto handshake are described in
Section 11 of [QUIC-TLS]. Section 4.8 of [QUIC-TLS].
See Section 13.3 for details of registering new error codes. See Section 13.3 for details of registering new error codes.
11.4. Application Protocol Error Codes 11.4. 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
RST_STREAM (Section 7.3) and APPLICATION_CLOSE (Section 7.5) frames. RST_STREAM (Section 7.3) and APPLICATION_CLOSE (Section 7.5) frames.
skipping to change at page 103, line 30 skipping to change at page 110, line 28
Normally, clients will open streams sequentially, as explained in Normally, clients will open streams sequentially, as explained in
Section 9.1. However, when several streams are initiated at short Section 9.1. However, when several streams are initiated at short
intervals, transmission error may cause STREAM DATA frames opening intervals, transmission error may cause STREAM DATA frames opening
streams to be received out of sequence. A receiver is obligated to streams to be received out of sequence. A receiver is obligated to
open intervening streams if a higher-numbered stream ID is received. open intervening streams if a higher-numbered stream ID is received.
Thus, on a new connection, opening stream 2000001 opens 1 million Thus, on a new connection, opening stream 2000001 opens 1 million
streams, as required by the specification. streams, as required by the specification.
The number of active streams is limited by the concurrent stream The number of active streams is limited by the concurrent stream
limit transport parameter, as explained in Section 9.4. If chosen limit transport parameter, as explained in Section 9.4. If chosen
judisciously, this limit mitigates the effect of the stream judiciously, this limit mitigates the effect of the stream commitment
commitment attack. However, setting the limit too low could affect attack. However, setting the limit too low could affect performance
performance when applications expect to open large number of streams. when applications expect to open large number of streams.
12.7. Explicit Congestion Notification Attacks 12.7. Explicit Congestion Notification Attacks
An on-path attacker could manipulate the value of ECN codepoints in An on-path attacker could manipulate the value of ECN codepoints in
the IP header to influence the sender's rate. [RFC3168] discusses the IP header to influence the sender's rate. [RFC3168] discusses
manipulations and their effects in more detail. manipulations and their effects in more detail.
An on-the-side attacker can duplicate and send packets with modified An on-the-side attacker can duplicate and send packets with modified
ECN codepoints to affect the sender's rate. If duplicate packets are ECN codepoints to affect the sender's rate. If duplicate packets are
discarded by a receiver, an off-path attacker will need to race the discarded by a receiver, an off-path attacker will need to race the
duplicate packet against the original to be successful in this duplicate packet against the original to be successful in this
attack. Therefore, QUIC receivers ignore ECN codepoints set in attack. Therefore, QUIC receivers ignore ECN codepoints set in
duplicate packets (see Section 6.8). duplicate packets (see Section 6.8).
12.8. Stateless Reset Oracle
Stateless resets create a possible denial of service attack analogous
to a TCP reset injection. This attack is possible if an attacker is
able to cause a stateless reset token to be generated for a
connection with a selected connection ID. An attacker that can cause
this token to be generated can reset an active connection with the
same connection ID.
If a packet can be routed to different instances that share a static
key, for example by changing an IP address or port, then an attacker
can cause the server to send a stateless reset. To defend against
this style of denial service, endpoints that share a static key for
stateless reset (see Section 6.13.4.2) MUST be arranged so that
packets with a given connection ID always arrive at an instance that
has connection state, unless that connection is no longer active.
In the case of a cluster that uses dynamic load balancing, it's
possible that a change in load balancer configuration could happen
while an active instance retains connection state; even if an
instance retains connection state, the change in routing and
resulting stateless reset will result in the connection being
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
for connections to time out. However, this is acceptable only if the
routing cannot be influenced by an attacker.
13. IANA Considerations 13. IANA Considerations
13.1. QUIC Transport Parameter Registry 13.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
hexadecimal) are assigned via the Specification Required policy hexadecimal) are assigned via the Specification Required policy
[RFC8126]. Values with the first byte 0xff are reserved for Private [RFC8126]. Values with the first byte 0xff are reserved for Private
skipping to change at page 105, line 5 skipping to change at page 112, line 7
the value. the value.
The nominated expert(s) verify that a specification exists and is The nominated expert(s) verify that a specification exists and is
readily accessible. Expert(s) are encouraged to be biased towards readily accessible. Expert(s) are encouraged to be biased towards
approving registrations unless they are abusive, frivolous, or approving registrations unless they are abusive, frivolous, or
actively harmful (not merely aesthetically displeasing, or actively harmful (not merely aesthetically displeasing, or
architecturally dubious). architecturally dubious).
The initial contents of this registry are shown in Table 7. The initial contents of this registry are shown in Table 7.
+--------+--------------------------+---------------+ +--------+-------------------------------------+---------------+
| Value | Parameter Name | Specification | | Value | Parameter Name | Specification |
+--------+--------------------------+---------------+ +--------+-------------------------------------+---------------+
| 0x0000 | initial_max_stream_data | Section 6.6.1 | | 0x0000 | initial_max_stream_data_bidi_local | Section 6.6.1 |
| | | | | | | |
| 0x0001 | initial_max_data | Section 6.6.1 | | 0x0001 | initial_max_data | Section 6.6.1 |
| | | | | | | |
| 0x0002 | initial_max_bidi_streams | Section 6.6.1 | | 0x0002 | initial_max_bidi_streams | Section 6.6.1 |
| | | | | | | |
| 0x0003 | idle_timeout | Section 6.6.1 | | 0x0003 | idle_timeout | Section 6.6.1 |
| | | | | | | |
| 0x0004 | preferred_address | Section 6.6.1 | | 0x0004 | preferred_address | Section 6.6.1 |
| | | | | | | |
| 0x0005 | max_packet_size | Section 6.6.1 | | 0x0005 | max_packet_size | Section 6.6.1 |
| | | | | | | |
| 0x0006 | stateless_reset_token | Section 6.6.1 | | 0x0006 | stateless_reset_token | Section 6.6.1 |
| | | | | | | |
| 0x0007 | ack_delay_exponent | Section 6.6.1 | | 0x0007 | ack_delay_exponent | Section 6.6.1 |
| | | | | | | |
| 0x0008 | initial_max_uni_streams | Section 6.6.1 | | 0x0008 | initial_max_uni_streams | Section 6.6.1 |
+--------+--------------------------+---------------+ | | | |
| 0x0009 | disable_migration | Section 6.6.1 |
| | | |
| 0x000a | initial_max_stream_data_bidi_remote | Section 6.6.1 |
| | | |
| 0x000b | initial_max_stream_data_uni | Section 6.6.1 |
+--------+-------------------------------------+---------------+
Table 7: Initial QUIC Transport Parameters Entries Table 7: Initial QUIC Transport Parameters Entries
13.2. QUIC Frame Type Registry 13.2. QUIC Frame Type Registry
IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a
"QUIC Protocol" heading. "QUIC Protocol" heading.
The "QUIC Frame Types" registry governs a 62-bit space. This space The "QUIC Frame Types" registry governs a 62-bit space. This space
is split into three spaces that are governed by different policies. is split into three spaces that are governed by different policies.
skipping to change at page 107, line 37 skipping to change at page 114, line 46
| | | parameters | | | | | parameters | |
| | | | | | | | | |
| 0x9 | VERSION_NEGOTIATION_ERROR | Version | Section 11.3 | | 0x9 | VERSION_NEGOTIATION_ERROR | Version | Section 11.3 |
| | | negotiation | | | | | negotiation | |
| | | failure | | | | | failure | |
| | | | | | | | | |
| 0xA | PROTOCOL_VIOLATION | Generic | Section 11.3 | | 0xA | PROTOCOL_VIOLATION | Generic | Section 11.3 |
| | | protocol | | | | | protocol | |
| | | violation | | | | | violation | |
| | | | | | | | | |
| 0xB | UNSOLICITED_PATH_RESPONSE | Unsolicited | Section 11.3 |
| | | PATH_RESPONSE | |
| | | frame | |
| | | | |
| 0xC | INVALID_MIGRATION | Violated | Section 11.3 | | 0xC | INVALID_MIGRATION | Violated | Section 11.3 |
| | | disabled | | | | | disabled | |
| | | migration | | | | | migration | |
+------+---------------------------+----------------+---------------+ +------+---------------------------+----------------+---------------+
Table 8: Initial QUIC Transport Error Codes Entries Table 8: Initial QUIC Transport Error Codes Entries
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
July 2017.
[PLPMTUD] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [PLPMTUD] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[PMTUDv4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [PMTUDv4] 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>.
[PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[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-13 (work and Congestion Control", draft-ietf-quic-recovery-14 (work
in progress), June 2018. in progress), August 2018.
[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-13 (work in progress), June 2018. tls-14 (work in progress), August 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 109, line 24 skipping to change at page 116, line 19
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311, Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018, DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>. <https://www.rfc-editor.org/info/rfc8311>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
14.2. Informative References 14.2. Informative References
[EARLY-DESIGN] [EARLY-DESIGN]
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-01 (work in progress), June draft-ietf-quic-invariants-01 (work in progress), August
2018. 2018.
[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>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22,
RFC 2360, DOI 10.17487/RFC2360, June 1998, RFC 2360, DOI 10.17487/RFC2360, June 1998,
<https://www.rfc-editor.org/info/rfc2360>. <https://www.rfc-editor.org/info/rfc2360>.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, DOI 10.17487/RFC2406, November
1998, <https://www.rfc-editor.org/info/rfc2406>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>. 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
skipping to change at page 110, line 29 skipping to change at page 117, line 33
[SLOWLORIS] [SLOWLORIS]
RSnake Hansen, R., "Welcome to Slowloris...", June 2009, RSnake Hansen, R., "Welcome to Slowloris...", June 2009,
<https://web.archive.org/web/20150315054838/ <https://web.archive.org/web/20150315054838/
http://ha.ckers.org/slowloris/>. http://ha.ckers.org/slowloris/>.
[SST] Ford, B., "Structured streams", ACM SIGCOMM Computer [SST] Ford, B., "Structured streams", ACM SIGCOMM Computer
Communication Review Vol. 37, pp. 361, Communication Review Vol. 37, pp. 361,
DOI 10.1145/1282427.1282421, October 2007. DOI 10.1145/1282427.1282421, October 2007.
Appendix A. Change Log Appendix A. Sample Packet Number Decoding Algorithm
The following pseudo-code shows how an implementation can decode
packet numbers after packet number protection has been removed.
DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
expected_pn = largest_pn + 1
pn_win = 1 << pn_nbits
pn_hwin = pn_win / 2
pn_mask = pn_win - 1
// The incoming packet number should be greater than
// expected_pn - pn_hwin and less than or equal to
// expected_pn + pn_hwin
//
// This means we can't just strip the trailing bits from
// expected_pn and add the truncated_pn because that might
// yield a value outside the window.
//
// The following code calculates a candidate value and
// makes sure it's within the packet number window.
candidate_pn = (expected_pn & ~pn_mask) | truncated_pn
if candidate_pn <= expected_pn - pn_hwin:
return candidate_pn + pn_win
// Note the extra check for underflow when candidate_pn
// is near zero.
if candidate_pn > expected_pn + pn_hwin and
candidate_pn > pn_win:
return candidate_pn - pn_win
return candidate_pn
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.
A.1. Since draft-ietf-quic-transport-12 B.1. Since draft-ietf-quic-transport-13
o Streams open when higher-numbered streams of the same type open
(#1342, #1549)
o Split initial stream flow control limit into 3 transport
parameters (#1016, #1542)
o All flow control transport parameters are optional (#1610)
o Removed UNSOLICITED_PATH_RESPONSE error code (#1265, #1539)
o Permit stateless reset in response to any packet (#1348, #1553)
o Recommended defense against stateless reset spoofing (#1386,
#1554)
o Prevent infinite stateless reset exchanges (#1443, #1627)
o Forbid processing of the same packet number twice (#1405, #1624)
o Added a packet number decoding example (#1493)
o More precisely define idle timeout (#1429, #1614, #1652)
o Corrected format of Retry packet and prevented looping (#1492,
#1451, #1448, #1498)
o Permit 0-RTT after receiving Version Negotiation or Retry (#1507,
#1514, #1621)
o Permit Retry in response to 0-RTT (#1547, #1552)
o Looser verification of ECN counters to account for ACK loss
(#1555, #1481, #1565)
o Remove frame type field from APPLICATION_CLOSE (#1508, #1528)
B.2. 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) #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
* Changed Retry to be independent of the cryptographic handshake * Changed Retry to be independent of the cryptographic handshake
skipping to change at page 111, line 31 skipping to change at page 120, line 20
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)
A.2. Since draft-ietf-quic-transport-11 B.3. 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)
A.3. Since draft-ietf-quic-transport-10 B.4. 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)
o A more complete connection migration (#1249) o A more complete connection migration (#1249)
o Refine opportunistic ACK defense text (#305, #1030, #1185) o Refine opportunistic ACK defense text (#305, #1030, #1185)
o A Stateless Reset Token isn't mandatory (#818, #1191) o A Stateless Reset Token isn't mandatory (#818, #1191)
o Removed implicit stream opening (#896, #1193) o Removed implicit stream opening (#896, #1193)
o An empty STREAM frame can be used to open a stream without sending o An empty STREAM frame can be used to open a stream without sending
data (#901, #1194) data (#901, #1194)
o Define stream counts in transport parameters rather than a maximum o Define stream counts in transport parameters rather than a maximum
stream ID (#1023, #1065) stream ID (#1023, #1065)
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)
A.4. Since draft-ietf-quic-transport-09 B.5. 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 113, line 4 skipping to change at page 121, line 41
o Rework of packet handling and version negotiation (#1038) o Rework of packet handling and version negotiation (#1038)
o Stream 0 is now exempt from flow control until the handshake o Stream 0 is now exempt from flow control until the handshake
completes (#1074, #725, #825, #1082) completes (#1074, #725, #825, #1082)
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)
A.5. Since draft-ietf-quic-transport-08 B.6. 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)
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
skipping to change at page 113, line 37 skipping to change at page 122, line 28
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)
A.6. Since draft-ietf-quic-transport-07 B.7. 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)
o Streams are split into unidirectional and bidirectional (#643, o Streams are split into unidirectional and bidirectional (#643,
#656, #720, #872, #175, #885) #656, #720, #872, #175, #885)
* Stream limits now have separate uni- and bi-directinal
* Stream limits now have separate uni- and bi-directional
transport parameters (#909, #958) transport parameters (#909, #958)
* Stream limit transport parameters are now optional and default * Stream limit transport parameters are now optional and default
to 0 (#970, #971) to 0 (#970, #971)
o The stream state machine has been split into read and write (#634, o The stream state machine has been split into read and write (#634,
#894) #894)
o Employ variable-length integer encodings throughout (#595) o Employ variable-length integer encodings throughout (#595)
skipping to change at page 114, line 33 skipping to change at page 123, line 25
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)
A.7. Since draft-ietf-quic-transport-06 B.8. 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)
A.8. Since draft-ietf-quic-transport-05 B.9. 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)
A.9. Since draft-ietf-quic-transport-04 B.10. Since draft-ietf-quic-transport-04
o Introduce STOP_SENDING frame, RST_STREAM only resets in one o Introduce STOP_SENDING frame, RST_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 116, line 5 skipping to change at page 124, line 42
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)
A.10. Since draft-ietf-quic-transport-03 B.11. Since draft-ietf-quic-transport-03
o Change STREAM and RST_STREAM layout o Change STREAM and RST_STREAM layout
o Add MAX_STREAM_ID settings o Add MAX_STREAM_ID settings
A.11. Since draft-ietf-quic-transport-02 B.12. 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 117, line 4 skipping to change at page 125, line 45
* 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)
A.12. Since draft-ietf-quic-transport-01 B.13. 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 119, line 8 skipping to change at page 128, line 5
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 RST_STREAM and CONNECTION_CLOSE are now at a o Error codes for RST_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)
A.13. Since draft-ietf-quic-transport-00 B.14. 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
A.14. Since draft-hamilton-quic-transport-protocol-01 B.15. 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. 181 change blocks. 
527 lines changed or deleted 905 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/