draft-ietf-quic-transport-12.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: November 23, 2018 Mozilla Expires: November 25, 2018 Mozilla
May 22, 2018 May 24, 2018
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-12 draft-ietf-quic-transport-latest
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 November 23, 2018. This Internet-Draft will expire on November 25, 2018.
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 36 skipping to change at page 2, line 36
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 . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Short Header . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Version Negotiation Packet . . . . . . . . . . . . . . . 12 4.3. Version Negotiation Packet . . . . . . . . . . . . . . . 12
4.4. Cryptographic Handshake Packets . . . . . . . . . . . . . 13 4.4. Cryptographic Handshake Packets . . . . . . . . . . . . . 13
4.4.1. Initial Packet . . . . . . . . . . . . . . . . . . . 13 4.4.1. Initial Packet . . . . . . . . . . . . . . . . . . . 13
4.4.2. Retry Packet . . . . . . . . . . . . . . . . . . . . 14 4.4.2. Retry Packet . . . . . . . . . . . . . . . . . . . . 14
4.4.3. Handshake Packet . . . . . . . . . . . . . . . . . . 15 4.4.3. Handshake Packet . . . . . . . . . . . . . . . . . . 15
4.5. Protected Packets . . . . . . . . . . . . . . . . . . . . 16 4.5. Protected Packets . . . . . . . . . . . . . . . . . . . . 16
4.6. Coalescing Packets . . . . . . . . . . . . . . . . . . . 17 4.6. Coalescing Packets . . . . . . . . . . . . . . . . . . . 17
4.7. Connection ID . . . . . . . . . . . . . . . . . . . . . . 17 4.7. Connection ID . . . . . . . . . . . . . . . . . . . . . . 18
4.8. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 18 4.8. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 19
5. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 20 5. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 20
6. Life of a Connection . . . . . . . . . . . . . . . . . . . . 22 6. Life of a Connection . . . . . . . . . . . . . . . . . . . . 22
6.1. Matching Packets to Connections . . . . . . . . . . . . . 23 6.1. Matching Packets to Connections . . . . . . . . . . . . . 23
6.1.1. Client Packet Handling . . . . . . . . . . . . . . . 23 6.1.1. Client Packet Handling . . . . . . . . . . . . . . . 23
6.1.2. Server Packet Handling . . . . . . . . . . . . . . . 23 6.1.2. Server Packet Handling . . . . . . . . . . . . . . . 23
6.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 24 6.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 24
6.2.1. Sending Version Negotiation Packets . . . . . . . . . 25 6.2.1. Sending Version Negotiation Packets . . . . . . . . . 25
6.2.2. Handling Version Negotiation Packets . . . . . . . . 25 6.2.2. Handling Version Negotiation Packets . . . . . . . . 25
6.2.3. Using Reserved Versions . . . . . . . . . . . . . . . 26 6.2.3. Using Reserved Versions . . . . . . . . . . . . . . . 26
6.3. Cryptographic and Transport Handshake . . . . . . . . . . 26 6.3. Cryptographic and Transport Handshake . . . . . . . . . . 26
skipping to change at page 3, line 35 skipping to change at page 3, line 35
6.10. Connection Termination . . . . . . . . . . . . . . . . . 45 6.10. Connection Termination . . . . . . . . . . . . . . . . . 45
6.10.1. Closing and Draining Connection States . . . . . . . 45 6.10.1. Closing and Draining Connection States . . . . . . . 45
6.10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 47 6.10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 47
6.10.3. Immediate Close . . . . . . . . . . . . . . . . . . 47 6.10.3. Immediate Close . . . . . . . . . . . . . . . . . . 47
6.10.4. Stateless Reset . . . . . . . . . . . . . . . . . . 48 6.10.4. Stateless Reset . . . . . . . . . . . . . . . . . . 48
7. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 51 7. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 51
7.1. Variable-Length Integer Encoding . . . . . . . . . . . . 51 7.1. Variable-Length Integer Encoding . . . . . . . . . . . . 51
7.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 52 7.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 52
7.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 52 7.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 52
7.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 53 7.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 53
7.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 53 7.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 54
7.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 54 7.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 54
7.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 54 7.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 55
7.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 55 7.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 56
7.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 56 7.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 56
7.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 57 7.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 57
7.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 57 7.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 57
7.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 58 7.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 58
7.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 58 7.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 58
7.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 59 7.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 60
7.15. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 60 7.15. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 60
7.15.1. ACK Block Section . . . . . . . . . . . . . . . . . 61 7.15.1. ACK Block Section . . . . . . . . . . . . . . . . . 62
7.15.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 63 7.15.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 63
7.15.3. ACK Frames and Packet Protection . . . . . . . . . . 64 7.15.3. ACK Frames and Packet Protection . . . . . . . . . . 64
7.16. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 65 7.16. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 65
7.17. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . . 65 7.17. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . . 65
7.18. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 65 7.18. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 66
8. Packetization and Reliability . . . . . . . . . . . . . . . . 67 8. Packetization and Reliability . . . . . . . . . . . . . . . . 67
8.1. Packet Processing and Acknowledgment . . . . . . . . . . 67 8.1. Packet Processing and Acknowledgment . . . . . . . . . . 68
8.2. Retransmission of Information . . . . . . . . . . . . . . 68 8.2. Retransmission of Information . . . . . . . . . . . . . . 68
8.3. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 70 8.3. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 70
8.4. Path Maximum Transmission Unit . . . . . . . . . . . . . 70 8.4. Path Maximum Transmission Unit . . . . . . . . . . . . . 70
8.4.1. Special Considerations for PMTU Discovery . . . . . . 71 8.4.1. IPv4 PMTU Discovery . . . . . . . . . . . . . . . . . 71
8.4.2. Special Considerations for Packetization Layer PMTU 8.4.2. Special Considerations for Packetization Layer PMTU
Discovery . . . . . . . . . . . . . . . . . . . . . . 71 Discovery . . . . . . . . . . . . . . . . . . . . . . 72
9. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 72 9. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 72
9.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 73 9.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 73
9.2. Stream States . . . . . . . . . . . . . . . . . . . . . . 74 9.2. Stream States . . . . . . . . . . . . . . . . . . . . . . 74
9.2.1. Send Stream States . . . . . . . . . . . . . . . . . 74 9.2.1. Send Stream States . . . . . . . . . . . . . . . . . 75
9.2.2. Receive Stream States . . . . . . . . . . . . . . . . 76 9.2.2. Receive Stream States . . . . . . . . . . . . . . . . 77
9.2.3. Permitted Frame Types . . . . . . . . . . . . . . . . 79 9.2.3. Permitted Frame Types . . . . . . . . . . . . . . . . 79
9.2.4. Bidirectional Stream States . . . . . . . . . . . . . 79 9.2.4. Bidirectional Stream States . . . . . . . . . . . . . 79
9.3. Solicited State Transitions . . . . . . . . . . . . . . . 80 9.3. Solicited State Transitions . . . . . . . . . . . . . . . 80
9.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 81 9.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 81
9.5. Sending and Receiving Data . . . . . . . . . . . . . . . 82 9.5. Sending and Receiving Data . . . . . . . . . . . . . . . 82
9.6. Stream Prioritization . . . . . . . . . . . . . . . . . . 82 9.6. Stream Prioritization . . . . . . . . . . . . . . . . . . 83
10. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 83 10. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 84
10.1. Edge Cases and Other Considerations . . . . . . . . . . 85 10.1. Edge Cases and Other Considerations . . . . . . . . . . 85
10.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 85 10.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 85
10.1.2. Data Limit Increments . . . . . . . . . . . . . . . 85 10.1.2. Data Limit Increments . . . . . . . . . . . . . . . 86
10.1.3. Handshake Exemption . . . . . . . . . . . . . . . . 86 10.1.3. Handshake Exemption . . . . . . . . . . . . . . . . 86
10.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 86 10.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 86
10.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 86 10.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 87
10.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 87 10.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 87
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 87 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 88
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 88 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 88
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 89 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 89
11.3. Transport Error Codes . . . . . . . . . . . . . . . . . 89 11.3. Transport Error Codes . . . . . . . . . . . . . . . . . 89
11.4. Application Protocol Error Codes . . . . . . . . . . . . 90 11.4. Application Protocol Error Codes . . . . . . . . . . . . 91
12. Security Considerations . . . . . . . . . . . . . . . . . . . 91 12. Security Considerations . . . . . . . . . . . . . . . . . . . 91
12.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 91 12.1. Handshake Denial of Service . . . . . . . . . . . . . . 91
12.2. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 91 12.2. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 92
12.3. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 92 12.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 93
12.4. Stream Fragmentation and Reassembly Attacks . . . . . . 92 12.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 93
12.5. Stream Commitment Attack . . . . . . . . . . . . . . . . 92 12.5. Stream Fragmentation and Reassembly Attacks . . . . . . 93
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93 12.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 94
13.1. QUIC Transport Parameter Registry . . . . . . . . . . . 93 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94
13.2. QUIC Transport Error Codes Registry . . . . . . . . . . 94 13.1. QUIC Transport Parameter Registry . . . . . . . . . . . 94
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 13.2. QUIC Transport Error Codes Registry . . . . . . . . . . 95
14.1. Normative References . . . . . . . . . . . . . . . . . . 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 97
14.2. Informative References . . . . . . . . . . . . . . . . . 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 97
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 98 14.2. Informative References . . . . . . . . . . . . . . . . . 98
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 98 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 99
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 99 A.1. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 99
C.1. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 99 A.2. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 100
C.2. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 99 A.3. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 100
C.3. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 100 A.4. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 101
C.4. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 100 A.5. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 101
C.5. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 101 A.6. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 102
C.6. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 102 A.7. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 103
C.7. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 102 A.8. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 103
C.8. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 102 A.9. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 104
C.9. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 103 A.10. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 104
C.10. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 103 A.11. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 105
C.11. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 104 A.12. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 107
C.12. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 106 A.13. Since draft-hamilton-quic-transport-protocol-01 . . . . . 107
C.13. Since draft-hamilton-quic-transport-protocol-01 . . . . . 106 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 107
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 107 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108
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 16, line 36 skipping to change at page 16, line 36
server, but could involve additional computational effort depending server, but could involve additional computational effort depending
on implementation choices. on implementation choices.
The payload of this packet contains STREAM frames and could contain The payload of this packet contains STREAM frames and could contain
PADDING, ACK, PATH_CHALLENGE, or PATH_RESPONSE frames. Handshake PADDING, ACK, PATH_CHALLENGE, or PATH_RESPONSE frames. Handshake
packets MAY contain CONNECTION_CLOSE frames if the handshake is packets MAY contain CONNECTION_CLOSE frames if the handshake is
unsuccessful. unsuccessful.
4.5. Protected Packets 4.5. Protected Packets
All QUIC packets are protected. Packets that are protected with the All QUIC packets use packet protection. Packets that are protected
static handshake keys or the 0-RTT keys are sent with long headers; with the static handshake keys or the 0-RTT keys are sent with long
all packets protected with 1-RTT keys are sent with short headers. headers; all packets protected with 1-RTT keys are sent with short
The different packet types explicitly indicate the encryption level headers. The different packet types explicitly indicate the
and therefore the keys that are used to remove packet protection. encryption level and therefore the keys that are used to remove
packet protection.
Packets protected with handshake keys only use packet protection to
ensure that the sender of the packet is on the network path. This
packet protection is not effective confidentiality protection; any
entity that receives the Initial packet from a client can recover the
keys necessary to remove packet protection or to generate packets
that will be successfully authenticated.
Packets protected with 0-RTT and 1-RTT keys are expected to have
confidentiality and data origin authentication; the cryptographic
handshake ensures that only the communicating endpoints receive the
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.4.1).
The client can send 0-RTT packets after receiving a Handshake packet The client can send 0-RTT packets after receiving a Handshake packet
(Section 4.4.3), if that packet does not complete the handshake. (Section 4.4.3), if that packet does not complete the handshake.
Even if the client receives a different connection ID in the Even if the client receives a different connection ID in the
Handshake packet, it MUST continue to use the same Destination Handshake packet, it MUST continue to use the same Destination
Connection ID for 0-RTT packets, see Section 4.7. Connection ID for 0-RTT packets, see Section 4.7.
skipping to change at page 19, line 4 skipping to change at page 19, line 23
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. The packet number for sending MUST start at zero for the receiving. The packet number for sending MUST start at zero for the
first packet sent and MUST increase by at least one after sending a first packet sent and MUST increase by at least one after sending a
packet. packet.
A QUIC endpoint MUST NOT reuse a packet number within the same A QUIC endpoint MUST NOT reuse a packet number within the same
connection (that is, under the same cryptographic keys). If the connection (that is, under the same cryptographic keys). If the
packet number for sending reaches 2^62 - 1, the sender MUST close the packet number for sending reaches 2^62 - 1, the sender MUST close the
connection without sending a CONNECTION_CLOSE frame or any further connection without sending a CONNECTION_CLOSE frame or any further
packets; a server MAY send a Stateless Reset (Section 6.10.4) in packets; an endpoint MAY send a Stateless Reset (Section 6.10.4) in
response to further packets that it receives. 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 are 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 |
skipping to change at page 43, line 18 skipping to change at page 43, line 18
frame. frame.
An endpoint might need to send packets on multiple networks without An endpoint might need to send packets on multiple networks without
receiving any response from its peer. To ensure that the endpoint is receiving any response from its peer. To ensure that the endpoint is
not linkable across each of these changes, a new connection ID is not linkable across each of these changes, a new connection ID is
needed for each network. To support this, multiple NEW_CONNECTION_ID needed for each network. To support this, multiple NEW_CONNECTION_ID
messages are needed. Each NEW_CONNECTION_ID is marked with a messages are needed. Each NEW_CONNECTION_ID is marked with a
sequence number. Connection IDs MUST be used in the order in which sequence number. Connection IDs MUST be used in the order in which
they are numbered. they are numbered.
An endpoint that to break linkability upon changing networks MUST use Upon changing networks an endpoint MUST use a previously unused
a previously unused connection ID provided by its peer. Protection connection ID provided by its peer. This eliminates the use of the
of packet numbers ensures that packet numbers cannot be used to connection ID for linking activity from the same connection on
correlate connections. Other properties of packets, such as timing different networks. Protection of packet numbers ensures that packet
and size, might be used to correlate activity, but no explicit numbers cannot be used to correlate activity. This does not prevent
correlation can be used to link activity across paths. other properties of packets, such as timing and size, from being used
to correlate activity.
Clients MAY change connection ID at any time based on implementation- Clients MAY change connection ID at any time based on implementation-
specific concerns. For example, after a period of network inactivity specific concerns. For example, after a period of network inactivity
NAT rebinding might occur when the client begins sending data again. NAT rebinding might occur when the client begins sending data again.
A client might wish to reduce linkability by employing a new A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period connection ID and source UDP port when sending traffic after a period
of inactivity. Changing the UDP port from which it sends packets at of inactivity. Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection the same time might cause the packet to appear as a connection
migration. This ensures that the mechanisms that support migration migration. This ensures that the mechanisms that support migration
skipping to change at page 48, line 18 skipping to change at page 48, line 18
arranged to close a connection. This might be after the application arranged to close a connection. This might be after the application
protocols negotiates a graceful shutdown. The application protocol protocols negotiates a graceful shutdown. The application protocol
exchanges whatever messages that are needed to cause both endpoints exchanges whatever messages that are needed to cause both endpoints
to agree to close the connection, after which the application to agree to close the connection, after which the application
requests that the connection be closed. The application protocol can requests that the connection be closed. The application protocol can
use an APPLICATION_CLOSE message with an appropriate error code to use an APPLICATION_CLOSE message with an appropriate error code to
signal closure. signal closure.
6.10.4. Stateless Reset 6.10.4. Stateless Reset
A stateless reset is provided as an option of last resort for a A stateless reset is provided as an option of last resort for an
server that does not have access to the state of a connection. A endpoint that does not have access to the state of a connection. A
server crash or outage might result in clients continuing to send crash or outage might result in peers continuing to send data to an
data to a server that is unable to properly continue the connection. endpoint that is unable to properly continue the connection. An
A server that wishes to communicate a fatal connection error MUST use endpoint that wishes to communicate a fatal connection error MUST use
a closing frame if it has sufficient state to do so. a closing frame if it has sufficient state to do so.
To support this process, the server sends a stateless_reset_token To support this process, a token is sent by endpoints. The token is
value during the handshake in the transport parameters. This value carried in the NEW_CONNECTION_ID frame sent by either peer, and
is protected by encryption, so only client and server know this servers can specify the stateless_reset_token transport parameter
value. during the handshake (clients cannot because their transport
parameters don't have confidentiality protection). This value is
protected by encryption, so only client and server know this value.
A server that receives packets that it cannot process sends a packet An endpoint that receives packets that it cannot process sends a
in the following layout: packet in the following layout:
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| Type (6) | |0|K|1|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection ID (144) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Number (8/16/32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octets (*) ... | Random Octets (160..) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Stateless Reset Token (128) + + Stateless Reset Token (128) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This design ensures that a stateless reset packet is - to the extent This design ensures that a stateless reset packet is - to the extent
possible - indistinguishable from a regular packet with a short possible - indistinguishable from a regular packet with a short
header. header.
A server generates a random 18-octet Destination Connection ID field. The message consists of a header octet, followed by random octets of
For a client that depends on the server including a connection ID, arbitrary length, followed by a Stateless Reset Token.
this will mean that this value differs from previous packets. Ths
results in two problems:
o The packet might not reach the client. If the Destination A stateless reset will be interpreted by a recipient as a packet with
Connection ID is critical for routing toward the client, then this 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
values. This is intended to allow for a destination connection ID of
the maximum length permitted, a packet number, and minimal payload.
The Stateless Reset Token corresponds to the minimum expansion of the
packet protection AEAD. More random octets might be necessary if the
endpoint could have negotiated a packet protection scheme with a
larger minimum AEAD expansion.
An endpoint SHOULD NOT send a stateless reset that is significantly
larger than the packet it receives. Endpoints MUST discard packets
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
never valid.
An endpoint cannot determine the Source Connection ID from a packet
with a short header, therefore it cannot set the Destination
Connection ID in the stateless reset packet. The destination
connection ID will therefore differ from the value used in previous
packets. A random Destination Connection ID makes the connection ID
appear to be the result of moving to a new connection ID that was
provided using a NEW_CONNECTION_ID frame (Section 7.13).
Using a randomized connection ID results in two problems:
o The packet might not reach the peer. If the Destination
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 causes the stateless
reset to be ineffective in causing errors to be quickly detected reset to be ineffective in causing errors to be quickly detected
and recovered. In this case, clients will need to rely on other and recovered. In this case, endpoints will need to rely on other
methods - such as timers - to detect that the connection has methods - such as timers - to detect that the connection has
failed. 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 client to identify this as a potential stateless reset. than the peer to identify this as a potential stateless reset. An
A server 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.
The Packet Number field is set to a randomized value. The server
SHOULD send a packet with a short header and a packet number length
of 1 octet. Using the shortest possible packet number encoding
minimizes the perceived gap between the last packet that the server
sent and this packet. A server MAY indicate a different packet
number length, but a longer packet number encoding might allow this
message to be identified as a stateless reset more easily using
heuristics.
After the Packet Number, the server pads the message with an
arbitrary number of octets containing random values.
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.
An endpoint that wishes to communicate a fatal connection error MUST An endpoint that wishes to communicate a fatal connection error MUST
use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has
sufficient state to do so. sufficient state to do so.
This stateless reset design is specific to QUIC version 1. A server This stateless reset design is specific to QUIC version 1. An
that supports multiple versions of QUIC needs to generate a stateless endpoint that supports multiple versions of QUIC needs to generate a
reset that will be accepted by clients that support any version that stateless reset that will be accepted by peers that support any
the server might support (or might have supported prior to losing version that the endpoint might support (or might have supported
state). Designers of new versions of QUIC need to be aware of this prior to losing state). Designers of new versions of QUIC need to be
and either reuse this design, or use a portion of the packet other aware of this and either reuse this design, or use a portion of the
than the last 16 octets for carrying data. packet other than the last 16 octets for carrying data.
6.10.4.1. Detecting a Stateless Reset 6.10.4.1. Detecting a Stateless Reset
A client detects a potential stateless reset when a packet with a An endpoint detects a potential stateless reset when a packet with a
short header either cannot be decrypted or is marked as a duplicate short header either cannot be decrypted or is marked as a duplicate
packet. The client then compares the last 16 octets of the packet packet. The endpoint then compares the last 16 octets of the packet
with the Stateless Reset Token provided by the server in its with the Stateless Reset Token provided by its peer, either in a
transport parameters. If these values are identical, the client MUST NEW_CONNECTION_ID frame or the server's transport parameters. If
enter the draining period and not send any further packets on this these values are identical, the endpoint MUST enter the draining
connection. If the comparison fails, the packet can be discarded. period and not send any further packets on this connection. If the
comparison fails, the packet can be discarded.
6.10.4.2. Calculating a Stateless Reset Token 6.10.4.2. Calculating a Stateless Reset Token
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, a server 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 servers this presents a coordination problem when there are multiple
in a cluster or a storage problem for a server that might lose state. instances in a cluster or a storage problem for a endpoint that might
Stateless reset specifically exists to handle the case where state is lose state. Stateless reset specifically exists to handle the case
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 three inputs: the static key,
the server's connection ID (see Section 4.7), and an identifier for the connection ID chosen by the endpoint (see Section 4.7), and an
the server instance. A server could use HMAC [RFC2104] (for example, instance identifier. An endpoint could use HMAC [RFC2104] (for
HMAC(static_key, server_id || connection_id)) or HKDF [RFC5869] (for example, HMAC(static_key, instance_id || connection_id)) or HKDF
example, using the static key as input keying material, with server [RFC5869] (for example, using the static key as input keying
and connection identifiers as salt). The output of this function is material, with instance and connection identifiers as salt). The
truncated to 16 octets to produce the Stateless Reset Token for that output of this function is truncated to 16 octets to produce the
connection. Stateless Reset Token for that connection.
A server that loses state can use the same method to generate a valid An endpoint that loses state can use the same method to generate a
Stateless Reset Secret. The connection ID comes from the packet that valid Stateless Reset Token. The connection ID comes from the packet
the server receives. that the endpoint receives. An instance that receives a packet for
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 client always sending a connection ID in This design relies on the peer always sending a connection ID in its
its packets so that the server can use the connection ID from a packets so that the endpoint can use the connection ID from a packet
packet to reset the connection. A server that uses this design to reset the connection. An endpoint that uses this design cannot
cannot allow clients to use a zero-length connection ID. allow its peers to send packets with a zero-length destination
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
server instance, connection ID, and static key cannot occur for instance, connection ID, and static key cannot occur for another
another connection. A connection ID from a connection that is reset connection. A connection ID from a connection that is reset by
by revealing the Stateless Reset Token cannot be reused for new revealing the Stateless Reset Token cannot be reused for new
connections at the same server without first changing to use a connections at the same instance without first changing to use a
different static key or server identifier. different static key or instance identifier.
Note that Stateless Reset messages do not have any cryptographic Note that Stateless Reset messages do not have any cryptographic
protection. protection.
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.
skipping to change at page 71, line 17 skipping to change at page 71, line 29
most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below
this number, even if it receives signals that indicate a smaller this number, even if it receives signals that indicate a smaller
limit might exist. limit might exist.
If a QUIC endpoint determines that the PMTU between any pair of local If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses has fallen below 1280 octets, it MUST and remote IP addresses has fallen below 1280 octets, it MUST
immediately cease sending QUIC packets on the affected path. This immediately cease sending QUIC packets on the affected path. This
could result in termination of the connection if an alternative path could result in termination of the connection if an alternative path
cannot be found. cannot be found.
8.4.1. Special Considerations for PMTU Discovery 8.4.1. IPv4 PMTU Discovery
Traditional ICMP-based path MTU discovery in IPv4 [PMTUDv4] is Traditional ICMP-based path MTU discovery in IPv4 [PMTUDv4] is
potentially vulnerable to off-path attacks that successfully guess potentially vulnerable to off-path attacks that successfully guess
the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient the IP/port 4-tuple and reduce the MTU to a bandwidth-inefficient
value. TCP connections mitigate this risk by using the (at minimum) value. TCP connections mitigate this risk by using the (at minimum)
8 bytes of transport header echoed in the ICMP message to validate 8 bytes of transport header echoed in the ICMP message to validate
the TCP sequence number as valid for the current connection. the TCP sequence number as valid for the current connection.
However, as QUIC operates over UDP, in IPv4 the echoed information However, as QUIC operates over UDP, in IPv4 the echoed information
could consist only of the IP and UDP headers, which usually has could consist only of the IP and UDP headers, which usually has
insufficient entropy to mitigate off-path attacks. insufficient entropy to mitigate off-path attacks.
skipping to change at page 91, line 13 skipping to change at page 91, line 20
RST_STREAM (Section 7.3) and APPLICATION_CLOSE (Section 7.5) frames. RST_STREAM (Section 7.3) and APPLICATION_CLOSE (Section 7.5) frames.
There is no restriction on the use of the 16-bit error code space for There is no restriction on the use of the 16-bit error code space for
application protocols. However, QUIC reserves the error code with a application protocols. However, QUIC reserves the error code with a
value of 0 to mean STOPPING. The application error code of STOPPING value of 0 to mean STOPPING. The application error code of STOPPING
(0) is used by the transport to cancel a stream in response to (0) is used by the transport to cancel a stream in response to
receipt of a STOP_SENDING frame. receipt of a STOP_SENDING frame.
12. Security Considerations 12. Security Considerations
12.1. Spoofed ACK Attack 12.1. Handshake Denial of Service
As an encrypted and authenticated transport QUIC provides a range of
protections against denial of service. Once the cryptographic
handshake is complete, QUIC endpoints discard most packets that are
not authenticated, greatly limiting the ability of an attacker to
interfere with existing connections.
Once a connection is established QUIC endpoints might accept some
unauthenticated ICMP packets (see Section 8.4.1), but the use of
these packets is extremely limited. The only other type of packet
that an endpoint might accept is a stateless reset (Section 6.10.4)
which relies on the token being kept secret until it is used.
During the creation of a connection, QUIC only provides protection
against attack from off the network path. All QUIC packets contain
proof that the recipient saw a preceding packet from its peer.
The first mechanism used is the source and destination connection
IDs, which are required to match those set by a peer. Except for an
Initial and stateless reset packets, an endpoint only accepts packets
that include a destination connection that matches a connection ID
the endpoint previously chose. This is the only protection offered
for Version Negotiation packets.
The destination connection ID in an Initial packet is selected by a
client to be unpredictable, which serves an additional purpose. The
packets that carry the cryptographic handshake are protected with a
key that is derived from this connection ID and salt specific to the
QUIC version. This allows endpoints to use the same process for
authenticating packets that they receive as they use after the
cryptographic handshake completes. Packets that cannot be
authenticated are discarded. Protecting packets in this fashion
provides a strong assurance that the sender of the packet saw the
Initial packet and understood it.
These protections are not intended to be effective against an
attacker that is able to receive QUIC packets prior to the connection
being established. Such an attacker can potentially send packets
that will be accepted by QUIC endpoints. This version of QUIC
attempts to detect this sort of attack, but it expects that endpoints
will fail to establish a connection rather than recovering. For the
most part, the cryptographic handshake protocol [QUIC-TLS] is
responsible for detecting tampering during the handshake, though
additional validation is required for version negotiation (see
Section 6.4.4).
Endpoints are permitted to use other methods to detect and attempt to
recover from interference with the handshake. Invalid packets may be
identified and discarded using other methods, but no specific method
is mandated in this document.
12.2. Spoofed ACK Attack
An attacker might be able to receive an address validation token An attacker might be able to receive an address validation token
(Section 6.6) from the server and then release the IP address it used (Section 6.6) from the server and then release the IP address it used
to acquire that token. The attacker may, in the future, spoof this to acquire that token. The attacker may, in the future, spoof this
same address (which now presumably addresses a different endpoint), same address (which now presumably addresses a different endpoint),
and initiate a 0-RTT connection with a server on the victim's behalf. and initiate a 0-RTT connection with a server on the victim's behalf.
The attacker can then spoof ACK frames to the server which cause the The attacker can then spoof ACK frames to the server which cause the
server to send excessive amounts of data toward the new owner of the server to send excessive amounts of data toward the new owner of the
IP address. IP address.
skipping to change at page 91, line 42 skipping to change at page 93, line 5
The second mitigation is that the server can require that The second mitigation is that the server can require that
acknowledgments for sent packets match the encryption level of the acknowledgments for sent packets match the encryption level of the
sent packet. This mitigation is useful if the connection has an sent packet. This mitigation is useful if the connection has an
ephemeral forward-secure key that is generated and used for every new ephemeral forward-secure key that is generated and used for every new
connection. If a packet sent is protected with a forward-secure key, connection. If a packet sent is protected with a forward-secure key,
then any acknowledgments that are received for them MUST also be then any acknowledgments that are received for them MUST also be
forward-secure protected. Since the attacker will not have the forward-secure protected. Since the attacker will not have the
forward secure key, the attacker will not be able to generate forward secure key, the attacker will not be able to generate
forward-secure protected packets with ACK frames. forward-secure protected packets with ACK frames.
12.2. Optimistic ACK Attack 12.3. Optimistic ACK Attack
An endpoint that acknowledges packets it has not received might cause An endpoint that acknowledges packets it has not received might cause
a congestion controller to permit sending at rates beyond what the a congestion controller to permit sending at rates beyond what the
network supports. An endpoint MAY skip packet numbers when sending network supports. An endpoint MAY skip packet numbers when sending
packets to detect this behavior. An endpoint can then immediately packets to detect this behavior. An endpoint can then immediately
close the connection with a connection error of type close the connection with a connection error of type
PROTOCOL_VIOLATION (see Section 6.10.3). PROTOCOL_VIOLATION (see Section 6.10.3).
12.3. Slowloris Attacks 12.4. Slowloris Attacks
The attacks commonly known as Slowloris [SLOWLORIS] try to keep many The attacks commonly known as Slowloris [SLOWLORIS] try to keep many
connections to the target endpoint open and hold them open as long as connections to the target endpoint open and hold them open as long as
possible. These attacks can be executed against a QUIC endpoint by possible. These attacks can be executed against a QUIC endpoint by
generating the minimum amount of activity necessary to avoid being generating the minimum amount of activity necessary to avoid being
closed for inactivity. This might involve sending small amounts of closed for inactivity. This might involve sending small amounts of
data, gradually opening flow control windows in order to control the data, gradually opening flow control windows in order to control the
sender rate, or manufacturing ACK frames that simulate a high loss sender rate, or manufacturing ACK frames that simulate a high loss
rate. rate.
QUIC deployments SHOULD provide mitigations for the Slowloris QUIC deployments SHOULD provide mitigations for the Slowloris
attacks, such as increasing the maximum number of clients the server attacks, such as increasing the maximum number of clients the server
will allow, limiting the number of connections a single IP address is will allow, limiting the number of connections a single IP address is
allowed to make, imposing restrictions on the minimum transfer speed allowed to make, imposing restrictions on the minimum transfer speed
a connection is allowed to have, and restricting the length of time a connection is allowed to have, and restricting the length of time
an endpoint is allowed to stay connected. an endpoint is allowed to stay connected.
12.4. Stream Fragmentation and Reassembly Attacks 12.5. Stream Fragmentation and Reassembly Attacks
An adversarial endpoint might intentionally fragment the data on An adversarial endpoint might intentionally fragment the data on
stream buffers in order to cause disproportionate memory commitment. stream buffers in order to cause disproportionate memory commitment.
An adversarial endpoint could open a stream and send some STREAM An adversarial endpoint could open a stream and send some STREAM
frames containing arbitrary fragments of the stream content. frames containing arbitrary fragments of the stream content.
The attack is mitigated if flow control windows correspond to The attack is mitigated if flow control windows correspond to
available memory. However, some receivers will over-commit memory available memory. However, some receivers will over-commit memory
and advertise flow control offsets in the aggregate that exceed and advertise flow control offsets in the aggregate that exceed
actual available memory. The over-commitment strategy can lead to actual available memory. The over-commitment strategy can lead to
better performance when endpoints are well behaved, but renders better performance when endpoints are well behaved, but renders
endpoints vulnerable to the stream fragmentation attack. endpoints vulnerable to the stream fragmentation attack.
QUIC deployments SHOULD provide mitigations against the stream QUIC deployments SHOULD provide mitigations against the stream
fragmentation attack. Mitigations could consist of avoiding over- fragmentation attack. Mitigations could consist of avoiding over-
committing memory, delaying reassembly of STREAM frames, implementing committing memory, delaying reassembly of STREAM frames, implementing
heuristics based on the age and duration of reassembly holes, or some heuristics based on the age and duration of reassembly holes, or some
combination. combination.
12.5. Stream Commitment Attack 12.6. Stream Commitment Attack
An adversarial endpoint can open lots of streams, exhausting state on An adversarial endpoint can open lots of streams, exhausting state on
an endpoint. The adversarial endpoint could repeat the process on a an endpoint. The adversarial endpoint could repeat the process on a
large number of connections, in a manner similar to SYN flooding large number of connections, in a manner similar to SYN flooding
attacks in TCP. attacks in TCP.
Normally, clients will open streams sequentially, as explained in Normally, clients will open streams sequentially, as explained in
Section 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
skipping to change at page 96, line 38 skipping to change at page 97, line 44
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-12 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls-
tls-12 (work in progress). latest (work in progress).
[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>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
skipping to change at page 97, line 36 skipping to change at page 98, line 41
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-12 (work in progress). draft-ietf-quic-invariants-latest (work in progress).
[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>.
skipping to change at page 98, line 29 skipping to change at page 99, 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. Contributors Appendix A. Change Log
The original authors of this specification were Ryan Hamilton, Jana
Iyengar, Ian Swett, and Alyssa Wilk.
The original design and rationale behind this protocol draw
significantly from work by Jim Roskind [EARLY-DESIGN]. In
alphabetical order, the contributors to the pre-IETF QUIC project at
Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar,
Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind,
Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti,
Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale
Worley, Fan Yang, Dan Zhang, Daniel Ziegler.
Appendix B. Acknowledgments
Special thanks are due to the following for helping shape pre-IETF
QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon,
Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund.
This document has benefited immensely from various private
discussions and public ones on the quic@ietf.org and proto-
quic@chromium.org mailing lists. Our thanks to all.
Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-transport-11 A.1. 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, #1079) #990, #734, #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)
C.2. Since draft-ietf-quic-transport-10 A.2. Since draft-ietf-quic-transport-10
o Swap payload length and packed number fields in long header o Swap payload length and packed number fields in long header
(#1294) (#1294)
o Clarified that CONNECTION_CLOSE is allowed in Handshake packet o Clarified that CONNECTION_CLOSE is allowed in Handshake packet
(#1274) (#1274)
o Spin bit reserved (#1283) o Spin bit reserved (#1283)
o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285) o Coalescing multiple QUIC packets in a UDP datagram (#1262, #1285)
skipping to change at page 100, line 4 skipping to change at page 100, line 32
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)
C.3. Since draft-ietf-quic-transport-09 A.3. 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 100, line 39 skipping to change at page 101, line 20
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)
C.4. Since draft-ietf-quic-transport-08 A.4. Since draft-ietf-quic-transport-08
o Clarified requirements for BLOCKED usage (#65, #924) o Clarified requirements for BLOCKED usage (#65, #924)
o BLOCKED frame now includes reason for blocking (#452, #924, #927, o BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928) #928)
o GAP limitation in ACK Frame (#613) o GAP limitation in ACK Frame (#613)
o Improved PMTUD description (#614, #1036) o Improved PMTUD description (#614, #1036)
skipping to change at page 101, line 4 skipping to change at page 101, line 32
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
(#831, #931) (#831, #931)
o You don't always need the draining period (#871) o You don't always need the draining period (#871)
o Stateless reset clarified as version-specific (#930, #986) o Stateless reset clarified as version-specific (#930, #986)
o initial_max_stream_id_x transport parameters are optional (#970, o initial_max_stream_id_x transport parameters are optional (#970,
#971) #971)
o Ack Delay assumes a default value during the handshake (#1007, o Ack Delay assumes a default value during the handshake (#1007,
#1009) #1009)
o Removed transport parameters from NewSessionTicket (#1015) o Removed transport parameters from NewSessionTicket (#1015)
C.5. Since draft-ietf-quic-transport-07 A.5. 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-directinal
skipping to change at page 102, line 15 skipping to change at page 102, line 42
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)
C.6. Since draft-ietf-quic-transport-06 A.6. 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)
C.7. Since draft-ietf-quic-transport-05 A.7. 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)
C.8. Since draft-ietf-quic-transport-04 A.8. 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 103, line 23 skipping to change at page 104, line 4
NewSessionTicket message (#547) NewSessionTicket message (#547)
o Clarify the meaning of "bytes in flight" (#550) o Clarify the meaning of "bytes in flight" (#550)
o Public reset is now stateless reset and not visible to the path o Public reset is now stateless reset and not visible to the path
(#215) (#215)
o Reordered bits and fields in STREAM frame (#620) o Reordered bits and fields in STREAM frame (#620)
o Clarifications to the stream state machine (#572, #571) o Clarifications to the stream state machine (#572, #571)
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)
C.9. Since draft-ietf-quic-transport-03 A.9. 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
C.10. Since draft-ietf-quic-transport-02 A.10. 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 104, line 23 skipping to change at page 105, line 4
different handshake protocol (#516) different handshake protocol (#516)
o STREAM frames have a reduced number of offset lengths (#543, #430) o STREAM frames have a reduced number of offset lengths (#543, #430)
o Split some frames into separate connection- and stream- level o Split some frames into separate connection- and stream- level
frames (#443) frames (#443)
* WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450)
* 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)
C.11. Since draft-ietf-quic-transport-01 A.11. 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 106, line 36 skipping to change at page 107, line 17
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)
C.12. Since draft-ietf-quic-transport-00 A.12. 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
C.13. Since draft-hamilton-quic-transport-protocol-01 A.13. 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
Special thanks are due to the following for helping shape pre-IETF
QUIC and its deployment: Chris Bentzel, Misha Efimov, Roberto Peon,
Alistair Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund.
This document has benefited immensely from various private
discussions and public ones on the quic@ietf.org and proto-
quic@chromium.org mailing lists. Our thanks to all.
Contributors
The original authors of this specification were Ryan Hamilton, Jana
Iyengar, Ian Swett, and Alyssa Wilk.
The original design and rationale behind this protocol draw
significantly from work by Jim Roskind [EARLY-DESIGN]. In
alphabetical order, the contributors to the pre-IETF QUIC project at
Google are: Britt Cyr, Jeremy Dorfman, Ryan Hamilton, Jana Iyengar,
Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim Roskind,
Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman Tenneti,
Victor Vasiliev, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale
Worley, Fan Yang, Dan Zhang, Daniel Ziegler.
Authors' Addresses Authors' Addresses
Jana Iyengar (editor) Jana Iyengar (editor)
Fastly Fastly
Email: jri.ietf@gmail.com Email: jri.ietf@gmail.com
Martin Thomson (editor) Martin Thomson (editor)
Mozilla Mozilla
 End of changes. 72 change blocks. 
191 lines changed or deleted 273 lines changed or added

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