draft-ietf-quic-transport-08.txt   draft-ietf-quic-transport-09.txt 
QUIC J. Iyengar, Ed. QUIC J. Iyengar, Ed.
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: June 8, 2018 Mozilla Expires: August 1, 2018 Mozilla
December 5, 2017 January 28, 2018
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-08 draft-ietf-quic-transport-09
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 June 8, 2018. This Internet-Draft will expire on August 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 10 skipping to change at page 3, line 10
7.1. Matching Packets to Connections . . . . . . . . . . . . . 21 7.1. Matching Packets to Connections . . . . . . . . . . . . . 21
7.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 22 7.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 22
7.2.1. Sending Version Negotiation Packets . . . . . . . . . 22 7.2.1. Sending Version Negotiation Packets . . . . . . . . . 22
7.2.2. Handling Version Negotiation Packets . . . . . . . . 23 7.2.2. Handling Version Negotiation Packets . . . . . . . . 23
7.2.3. Using Reserved Versions . . . . . . . . . . . . . . . 23 7.2.3. Using Reserved Versions . . . . . . . . . . . . . . . 23
7.3. Cryptographic and Transport Handshake . . . . . . . . . . 24 7.3. Cryptographic and Transport Handshake . . . . . . . . . . 24
7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 25 7.4. Transport Parameters . . . . . . . . . . . . . . . . . . 25
7.4.1. Transport Parameter Definitions . . . . . . . . . . . 27 7.4.1. Transport Parameter Definitions . . . . . . . . . . . 27
7.4.2. Values of Transport Parameters for 0-RTT . . . . . . 29 7.4.2. Values of Transport Parameters for 0-RTT . . . . . . 29
7.4.3. New Transport Parameters . . . . . . . . . . . . . . 29 7.4.3. New Transport Parameters . . . . . . . . . . . . . . 29
7.4.4. Version Negotiation Validation . . . . . . . . . . . 29 7.4.4. Version Negotiation Validation . . . . . . . . . . . 30
7.5. Stateless Retries . . . . . . . . . . . . . . . . . . . . 31 7.5. Stateless Retries . . . . . . . . . . . . . . . . . . . . 31
7.6. Proof of Source Address Ownership . . . . . . . . . . . . 31 7.6. Proof of Source Address Ownership . . . . . . . . . . . . 32
7.6.1. Client Address Validation Procedure . . . . . . . . . 32 7.6.1. Client Address Validation Procedure . . . . . . . . . 32
7.6.2. Address Validation on Session Resumption . . . . . . 33 7.6.2. Address Validation on Session Resumption . . . . . . 33
7.6.3. Address Validation Token Integrity . . . . . . . . . 34 7.6.3. Address Validation Token Integrity . . . . . . . . . 34
7.7. Connection Migration . . . . . . . . . . . . . . . . . . 34 7.7. Connection Migration . . . . . . . . . . . . . . . . . . 34
7.7.1. Privacy Implications of Connection Migration . . . . 35 7.7.1. Privacy Implications of Connection Migration . . . . 35
7.7.2. Address Validation for Migrated Connections . . . . . 36 7.7.2. Address Validation for Migrated Connections . . . . . 36
7.8. Spurious Connection Migrations . . . . . . . . . . . . . 37 7.8. Spurious Connection Migrations . . . . . . . . . . . . . 37
7.9. Connection Termination . . . . . . . . . . . . . . . . . 38 7.9. Connection Termination . . . . . . . . . . . . . . . . . 38
7.9.1. Closing and Draining Connection States . . . . . . . 38 7.9.1. Closing and Draining Connection States . . . . . . . 38
7.9.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 40 7.9.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 40
7.9.3. Immediate Close . . . . . . . . . . . . . . . . . . . 40 7.9.3. Immediate Close . . . . . . . . . . . . . . . . . . . 40
7.9.4. Stateless Reset . . . . . . . . . . . . . . . . . . . 41 7.9.4. Stateless Reset . . . . . . . . . . . . . . . . . . . 41
8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 43 8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 44
8.1. Variable-Length Integer Encoding . . . . . . . . . . . . 44 8.1. Variable-Length Integer Encoding . . . . . . . . . . . . 44
8.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 44 8.2. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 45
8.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 45 8.3. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 45
8.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 45 8.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 46
8.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 46 8.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 47
8.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 46 8.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 47
8.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 47 8.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 48
8.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 48 8.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 49
8.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 49 8.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 49
8.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 50 8.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 50
8.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 50 8.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 51
8.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 51 8.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 51
8.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 51 8.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 52
8.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 52 8.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 52
8.15. PONG Frame . . . . . . . . . . . . . . . . . . . . . . . 52 8.15. PONG Frame . . . . . . . . . . . . . . . . . . . . . . . 53
8.16. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 53 8.16. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 53
8.16.1. ACK Block Section . . . . . . . . . . . . . . . . . 54 8.16.1. ACK Block Section . . . . . . . . . . . . . . . . . 55
8.16.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 56 8.16.2. Sending ACK Frames . . . . . . . . . . . . . . . . . 56
8.16.3. ACK Frames and Packet Protection . . . . . . . . . . 57 8.16.3. ACK Frames and Packet Protection . . . . . . . . . . 57
8.17. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 58 8.17. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 58
9. Packetization and Reliability . . . . . . . . . . . . . . . . 59 9. Packetization and Reliability . . . . . . . . . . . . . . . . 60
9.1. Special Considerations for PMTU Discovery . . . . . . . . 62 9.1. Packet Size . . . . . . . . . . . . . . . . . . . . . . . 61
10. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 62 9.2. Path Maximum Transmission Unit . . . . . . . . . . . . . 62
10.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 63 9.2.1. Special Considerations for PMTU Discovery . . . . . . 63
10.2. Stream States . . . . . . . . . . . . . . . . . . . . . 64 9.2.2. Special Considerations for Packetization Layer PMTU
10.2.1. Send Stream States . . . . . . . . . . . . . . . . . 65 Discovery . . . . . . . . . . . . . . . . . . . . . . 63
10.2.2. Receive Stream States . . . . . . . . . . . . . . . 67
10.2.3. Permitted Frame Types . . . . . . . . . . . . . . . 70 10. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 64
10.2.4. Bidirectional Stream States . . . . . . . . . . . . 70 10.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 64
10.3. Solicited State Transitions . . . . . . . . . . . . . . 71 10.2. Stream States . . . . . . . . . . . . . . . . . . . . . 65
10.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 72 10.2.1. Send Stream States . . . . . . . . . . . . . . . . . 66
10.5. Sending and Receiving Data . . . . . . . . . . . . . . . 73 10.2.2. Receive Stream States . . . . . . . . . . . . . . . 68
10.6. Stream Prioritization . . . . . . . . . . . . . . . . . 73 10.2.3. Permitted Frame Types . . . . . . . . . . . . . . . 71
11. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 74 10.2.4. Bidirectional Stream States . . . . . . . . . . . . 71
11.1. Edge Cases and Other Considerations . . . . . . . . . . 75 10.3. Solicited State Transitions . . . . . . . . . . . . . . 72
11.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 76 10.4. Stream Concurrency . . . . . . . . . . . . . . . . . . . 73
11.1.2. Data Limit Increments . . . . . . . . . . . . . . . 76 10.5. Sending and Receiving Data . . . . . . . . . . . . . . . 74
11.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 77 10.6. Stream Prioritization . . . . . . . . . . . . . . . . . 74
11.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 77 11. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 75
11.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 77 11.1. Edge Cases and Other Considerations . . . . . . . . . . 76
12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 78 11.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 77
12.1. Connection Errors . . . . . . . . . . . . . . . . . . . 78 11.1.2. Data Limit Increments . . . . . . . . . . . . . . . 77
12.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 79 11.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 78
12.3. Transport Error Codes . . . . . . . . . . . . . . . . . 79 11.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 78
12.4. Application Protocol Error Codes . . . . . . . . . . . . 81 11.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 78
13. Security and Privacy Considerations . . . . . . . . . . . . . 81 12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 79
13.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 81 12.1. Connection Errors . . . . . . . . . . . . . . . . . . . 79
13.2. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 82 12.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 80
13.3. Stream Fragmentation and Reassembly Attacks . . . . . . 82 12.3. Transport Error Codes . . . . . . . . . . . . . . . . . 80
13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 82 12.4. Application Protocol Error Codes . . . . . . . . . . . . 82
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 13. Security and Privacy Considerations . . . . . . . . . . . . . 82
14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 83 13.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 82
14.2. QUIC Transport Error Codes Registry . . . . . . . . . . 84 13.2. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 83
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 87 13.3. Stream Fragmentation and Reassembly Attacks . . . . . . 83
15.1. Normative References . . . . . . . . . . . . . . . . . . 87 13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 83
15.2. Informative References . . . . . . . . . . . . . . . . . 88 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 89 14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 84
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 89 14.2. QUIC Transport Error Codes Registry . . . . . . . . . . 85
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 89 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 88
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 90 15.1. Normative References . . . . . . . . . . . . . . . . . . 88
C.1. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 90 15.2. Informative References . . . . . . . . . . . . . . . . . 89
C.2. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 90 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 90
C.3. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 90 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 90
C.4. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 91 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 90
C.5. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 91 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 91
C.6. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 91 C.1. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 91
C.7. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 92 C.2. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 91
C.8. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 94 C.3. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 92
C.9. Since draft-hamilton-quic-transport-protocol-01 . . . . . 95 C.4. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 95 C.5. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 93
C.6. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 94
C.7. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 94
C.8. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 95
C.9. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 97
C.10. Since draft-hamilton-quic-transport-protocol-01 . . . . . 97
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97
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 transport for multiple applications. it to be a general-purpose transport for multiple applications.
QUIC implements techniques learned from experience with TCP, SCTP and QUIC implements techniques learned from experience with TCP, SCTP and
other transport protocols. QUIC uses UDP as substrate so as to not other transport protocols. QUIC uses UDP as substrate so as to not
require changes to legacy client operating systems and middleboxes to require changes to legacy client operating systems and middleboxes to
skipping to change at page 6, line 6 skipping to change at page 6, line 6
Stream: A logical, bi-directional channel of ordered bytes within a Stream: A logical, bi-directional channel of ordered bytes within a
QUIC connection. QUIC connection.
Connection: A conversation between two QUIC endpoints with a single Connection: A conversation between two QUIC endpoints with a single
encryption context that multiplexes streams within it. encryption context that multiplexes streams within it.
Connection ID: The 64-bit unsigned number used as an identifier for Connection ID: The 64-bit unsigned number used as an identifier for
a QUIC connection. a QUIC connection.
QUIC packet: A well-formed UDP payload that can be parsed by a QUIC QUIC packet: A well-formed UDP payload that can be parsed by a QUIC
receiver. QUIC packet size in this document refers to the UDP receiver.
payload size.
2.1. Notational Conventions 2.1. Notational Conventions
Packet and frame diagrams use the format described in Section 3.1 of Packet and frame diagrams use the format described in Section 3.1 of
[RFC2360], with the following additional conventions: [RFC2360], with the following additional conventions:
[x] Indicates that x is optional [x] Indicates that x is optional
{x} Indicates that x is encrypted
x (A) Indicates that x is A bits long x (A) Indicates that x is A bits long
x (A/B/C) ... Indicates that x is one of A, B, or C bits long x (A/B/C) ... Indicates that x is one of A, B, or C bits long
x (i) ... Indicates that x uses the variable-length encoding in x (i) ... Indicates that x uses the variable-length encoding in
Section 8.1 Section 8.1
x (*) ... Indicates that x is variable-length x (*) ... Indicates that x is variable-length
3. A QUIC Overview 3. A QUIC Overview
skipping to change at page 14, line 31 skipping to change at page 14, line 29
version in the version field. version in the version field.
In order to prevent tampering by version-unaware middleboxes, In order to prevent tampering by version-unaware middleboxes,
handshake packets are protected with a connection- and version- handshake packets are protected with a connection- and version-
specific key, as described in [QUIC-TLS]. This protection does not specific key, 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.
5.4.1. Initial Packet 5.4.1. Initial Packet
The Initial packet uses long headers with a type value of 0x7E. It The Initial packet uses long headers with a type value of 0x7F. It
carries the first cryptographic handshake message sent by the client. carries the first cryptographic handshake message sent by the client.
The client populates the connection ID field with randomly selected The client populates the connection ID field with randomly selected
values, unless it has received a packet from the server. If the values, unless it has received a packet from the server. If the
client has received a packet from the server, the connection ID field client has received a packet from the server, the connection ID field
uses the value provided by the server. uses the value provided by the server.
The first Initial packet that is sent by a client contains a The first Initial packet that is sent by a client contains a
randomized packet number. All subsequent packets contain a packet randomized packet number. All subsequent packets contain a packet
number that is incremented by one, see (Section 5.7). number that is incremented by one, see (Section 5.7).
skipping to change at page 15, line 10 skipping to change at page 15, line 7
handshake message MUST fit in a single packet (see Section 7.3). handshake message MUST fit in a single packet (see Section 7.3).
The client uses the Initial packet type for any packet that contains The client uses the Initial packet type for any packet that contains
an initial cryptographic handshake message. This includes all cases an initial cryptographic handshake message. This includes all cases
where a new packet containing the initial cryptographic message needs where a new packet containing the initial cryptographic message needs
to be created, this includes the packets sent after receiving a to be created, this includes the packets sent after receiving a
Version Negotiation (Section 5.3) or Retry packet (Section 5.4.2). Version Negotiation (Section 5.3) or Retry packet (Section 5.4.2).
5.4.2. Retry Packet 5.4.2. Retry Packet
A Retry packet uses long headers with a type value of 0x7D. It A Retry packet uses long headers with a type value of 0x7E. It
carries cryptographic handshake messages and acknowledgments. It is carries cryptographic handshake messages and acknowledgments. It is
used by a server that wishes to perform a stateless retry (see used by a server that wishes to perform a stateless retry (see
Section 7.5). Section 7.5).
The packet number and connection ID fields echo the corresponding The server includes a connection ID of its choice in the connection
fields from the triggering client packet. This allows a client to ID field. The client MUST use this connection ID for any subsequent
verify that the server received its packet. packets that it sends.
The packet number field echoes the packet number field from the
triggering client packet.
A Retry packet is never explicitly acknowledged in an ACK frame by a A Retry packet is never explicitly acknowledged in an ACK frame by a
client. Receiving another Initial packet implicitly acknowledges a client. Receiving another Initial packet implicitly acknowledges a
Retry packet. Retry packet.
After receiving a Retry packet, the client uses a new Initial packet After receiving a Retry packet, the client uses a new Initial packet
containing the next cryptographic handshake message. The client containing the next cryptographic handshake message. The client
retains the state of its cryptographic handshake, but discards all retains the state of its cryptographic handshake, but discards all
transport state. The Initial packet that is generated in response to transport state. The Initial packet that is generated in response to
a Retry packet includes STREAM frames on stream 0 that start again at a Retry packet includes STREAM frames on stream 0 that start again at
skipping to change at page 15, line 46 skipping to change at page 15, line 46
transport state MUST be discarded. transport state MUST be discarded.
The payload of the Retry packet contains a single STREAM frame on The payload of the Retry packet contains a single STREAM frame on
stream 0 with offset 0 containing the server's cryptographic stream 0 with offset 0 containing the server's cryptographic
stateless retry material. It MUST NOT contain any other frames. The stateless retry material. It MUST NOT contain any other frames. The
next STREAM frame sent by the server will also start at stream offset next STREAM frame sent by the server will also start at stream offset
0. 0.
5.4.3. Handshake Packet 5.4.3. Handshake Packet
A Handshake packet uses long headers with a type value of 0x7C. 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.
The connection ID field in a Handshake packet contains a connection The connection ID field in a Handshake packet contains a connection
ID that is chosen by the server (see Section 5.6). ID that is chosen by the server (see Section 5.6).
The first Handshake packet sent by a server contains a randomized The first Handshake packet sent by a server contains a randomized
packet number. This value is increased for each subsequent packet packet number. This value is increased for each subsequent packet
sent by the server as described in Section 5.7. The client sent by the server as described in Section 5.7. The client
increments the packet number from its previous packet by one for each increments the packet number from its previous packet by one for each
skipping to change at page 16, line 23 skipping to change at page 16, line 23
PADDING and ACK frames. PADDING and ACK frames.
5.5. Protected Packets 5.5. Protected Packets
Packets that are protected with 0-RTT keys are sent with long Packets that are protected with 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. packet protection.
Packets protected with 0-RTT keys use a type value of 0x7B. The Packets protected with 0-RTT keys use a type value of 0x7C. The
connection ID field for a 0-RTT packet is selected by the client. connection ID field for a 0-RTT packet is selected by the client.
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 5.4.3), if that packet does not complete the handshake. (Section 5.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 connection ID selected Handshake packet, it MUST continue to use the connection ID selected
by the client for 0-RTT packets, see Section 5.6. by the client for 0-RTT packets, see Section 5.6.
The version field for protected packets is the current QUIC version. The version field for protected packets is the current QUIC version.
skipping to change at page 17, line 7 skipping to change at page 17, line 7
presence of a Connection ID using the Omit Connection ID flag. When presence of a Connection ID using the Omit Connection ID flag. When
present, the Connection ID is in the same location in all packet present, the Connection ID is in the same location in all packet
headers, making it straightforward for middleboxes, such as load headers, making it straightforward for middleboxes, such as load
balancers, to locate and use it. balancers, to locate and use it.
The client MUST choose a random connection ID and use it in Initial The client MUST choose a random connection ID and use it in Initial
packets (Section 5.4.1) and 0-RTT packets (Section 5.5). packets (Section 5.4.1) and 0-RTT packets (Section 5.5).
When the server receives a Initial packet and decides to proceed with When the server receives a Initial packet and decides to proceed with
the handshake, it chooses a new value for the connection ID and sends the handshake, it chooses a new value for the connection ID and sends
that in a Handshake packet (Section 5.4.3). The server MAY choose to that in a Retry (Section 5.4.2) or Handshake (Section 5.4.3) packet.
use the value that the client initially selects. The server MAY choose to use the value that the client initially
selects.
Once the client receives the connection ID that the server has Once the client receives the connection ID that the server has
chosen, it MUST use it for all subsequent Handshake (Section 5.4.3) chosen, it MUST use it for all subsequent Handshake (Section 5.4.3)
and 1-RTT (Section 5.5) packets but not for 0-RTT packets and 1-RTT (Section 5.5) packets but not for 0-RTT packets
(Section 5.5). (Section 5.5).
Server's Version Negotiation (Section 5.3) and Retry (Section 5.4.2) Server's Version Negotiation (Section 5.3) and Retry (Section 5.4.2)
packets MUST use connection ID selected by the client. packets MUST use connection ID selected by the client.
5.7. Packet Numbers 5.7. Packet Numbers
skipping to change at page 26, line 33 skipping to change at page 26, line 33
} TransportParameter; } TransportParameter;
struct { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: case client_hello:
QuicVersion initial_version; QuicVersion initial_version;
case encrypted_extensions: case encrypted_extensions:
QuicVersion negotiated_version; QuicVersion negotiated_version;
QuicVersion supported_versions<4..2^8-4>; QuicVersion supported_versions<4..2^8-4>;
case new_session_ticket:
struct {};
}; };
TransportParameter parameters<30..2^16-1>; TransportParameter parameters<22..2^16-1>;
} TransportParameters; } TransportParameters;
Figure 6: Definition of TransportParameters Figure 6: 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
skipping to change at page 28, line 46 skipping to change at page 28, line 44
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 5.5). protected packets (Section 5.5).
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 8.16. If this value is absent, a default ACK frame, see Section 8.16. If this value is absent, a default
value of 3 is assumed (indicating a multiplier of 8). Values value of 3 is assumed (indicating a multiplier of 8). The default
above 20 are invalid. value is also used for ACK frames that are sent in Initial,
Handshake, and Retry packets. Values above 20 are invalid.
7.4.2. Values of Transport Parameters for 0-RTT 7.4.2. Values of Transport Parameters for 0-RTT
Transport parameters from the server MUST be remembered by the client A client that attempts to send 0-RTT data MUST remember the transport
for use with 0-RTT data. If the TLS NewSessionTicket message parameters used by the server. The transport parameters that the
includes the quic_transport_parameters extension, then those values server advertises during connection establishment apply to all
are used for the server values when establishing a new connection connections that are resumed using the keying material established
using that ticket. Otherwise, the transport parameters that the during that handshake. Remembered transport parameters apply to the
server advertises during connection establishment are used. new connection until the handshake completes and new transport
parameters from the server can be provided.
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
skipping to change at page 31, line 4 skipping to change at page 31, line 8
MUST be set by the server to the value that is on the Initial packet MUST be set by the server to the value that is on the Initial packet
that it accepts (not an Initial packet that triggers a Retry or that it accepts (not an Initial packet that triggers a Retry or
Version Negotiation packet). A client that receives a Version Negotiation packet). A client that receives a
negotiated_version that does not match the version of QUIC that is in negotiated_version that does not match the version of QUIC that is in
use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR
error code. error code.
The server includes a list of versions that it would send in any The server includes a list of versions that it would send in any
version negotiation packet (Section 5.3) in the supported_versions version negotiation packet (Section 5.3) in the supported_versions
field. The server populates this field even if it did not send a field. The server populates this field even if it did not send a
version negotiation packet. This field is absent if the parameters version negotiation packet.
are included in a NewSessionTicket message.
The client validates that the negotiated_version is included in the The client validates that the negotiated_version is included in the
supported_versions list and - if version negotiation was performed - supported_versions list and - if version negotiation was performed -
that it would have selected the negotiated version. A client MUST that it would have selected the negotiated version. A client MUST
terminate the connection with a VERSION_NEGOTIATION_ERROR error code terminate the connection with a VERSION_NEGOTIATION_ERROR error code
if the current QUIC version is not listed in the supported_versions if the current QUIC version is not listed in the supported_versions
list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error list. A client MUST terminate with a VERSION_NEGOTIATION_ERROR error
code if version negotiation occurred but it would have selected a code if version negotiation occurred but it would have selected a
different version based on the value of the supported_versions list. different version based on the value of the supported_versions list.
skipping to change at page 40, line 5 skipping to change at page 40, line 5
connections SHOULD NOT exit the closing or draining period early. connections SHOULD NOT exit the closing or draining period early.
Once the closing or draining period has ended, an endpoint SHOULD Once the closing or draining period has ended, an endpoint SHOULD
discard all connection state. This results in new packets on the discard all connection state. This results in new packets on the
connection being handled generically. For instance, an endpoint MAY connection being handled generically. For instance, an endpoint MAY
send a stateless reset in response to any further incoming packets. send a stateless reset in response to any further incoming packets.
The draining and closing periods do not apply when a stateless reset The draining and closing periods do not apply when a stateless reset
(Section 7.9.4) is sent. (Section 7.9.4) is sent.
An endpoint is not expected to handle key updates when it is closing
or draining. A key update might prevent the endpoint from moving
from the closing state to draining, but it otherwise has no impact.
An endpoint could receive packets from a new source address,
indicating a connection migration (Section 7.7), while in the closing
period. An endpoint in the closing state MUST strictly limit the
number of packets it sends to this new address as though the address
were not validated (see Section 7.7.2). A server in the closing
state MAY instead choose to discard packets received from a new
source address.
7.9.2. Idle Timeout 7.9.2. Idle Timeout
A connection that remains idle for longer than the idle timeout (see A connection that remains idle for longer than the idle timeout (see
Section 7.4.1) is closed. A connection enters the draining state Section 7.4.1) is closed. A connection enters the draining state
when the idle timeout expires. when the idle timeout expires.
The time at which an idle timeout takes effect won't be perfectly The time at which an idle timeout takes effect won't be perfectly
synchronized on both endpoints. An endpoint that sends packets near synchronized on both endpoints. An endpoint that sends packets near
the end of an idle period could have those packets discarded if its the end of an idle period could have those packets discarded if its
peer enters the draining state before the packet is received. peer enters the draining state before the packet is received.
skipping to change at page 42, line 14 skipping to change at page 42, line 41
The Packet Number field is set to a randomized value. The server The Packet Number field is set to a randomized value. The server
SHOULD send a packet with a short header and a type of 0x1F. This SHOULD send a packet with a short header and a type of 0x1F. This
produces the shortest possible packet number encoding, which produces the shortest possible packet number encoding, which
minimizes the perceived gap between the last packet that the server minimizes the perceived gap between the last packet that the server
sent and this packet. A server MAY use a different short header sent and this packet. A server MAY use a different short header
type, indicating a different packet number length, but a longer type, indicating a different packet number length, but a longer
packet number encoding might allow this message to be identified as a packet number encoding might allow this message to be identified as a
stateless reset more easily using heuristics. stateless reset more easily using heuristics.
After the first short header octet and optional connection ID, the
server includes the value of the Stateless Reset Token that it
included in its transport parameters.
After the Packet Number, the server pads the message with an After the Packet Number, the server pads the message with an
arbitrary number of octets containing random values. 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.
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. possible - indistinguishable from a regular packet.
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 53, line 50 skipping to change at page 54, line 31
| ACK Blocks (*) ... | ACK Blocks (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: ACK Frame Format Figure 7: 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. generating the ACK frame. Unlike the packet number in the QUIC
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 7.4.1). Scaling in this fashion multiplier of 8 (see Section 7.4.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
skipping to change at page 58, line 12 skipping to change at page 58, line 28
protected packets, because it is certain that the server is able to protected packets, because it is certain that the server is able to
decipher the packet. decipher the packet.
8.17. STREAM Frames 8.17. STREAM Frames
STREAM frames implicitly create a stream and carry stream data. The STREAM frames implicitly create a stream and carry stream data. The
STREAM frame takes the form 0b00010XXX (or the set of values from STREAM frame takes the form 0b00010XXX (or the set of values from
0x10 to 0x17). The value of the three low-order bits of the frame 0x10 to 0x17). The value of the three low-order bits of the frame
type determine the fields that are present in the frame. type determine the fields that are present in the frame.
o The FIN bit (0x01) of the frame type is set only on frames that
contain the final offset of the stream. Setting this bit
indicates that the frame marks the end of the stream.
o The LEN bit (0x02) in the frame type is set to indicate that there
is a Length field present. If this bit is set to 0, the Length
field is absent and the Stream Data field extends to the end of
the packet. If this bit is set to 1, the Length field is present.
o The OFF bit (0x04) in the frame type is set to indicate that there o The OFF bit (0x04) in the frame type is set to indicate that there
is an Offset field present. When set to 1, the Offset field is is an Offset field present. When set to 1, the Offset field is
present; when set to 0, the Offset field is absent and the Stream present; when set to 0, the Offset field is absent and the Stream
Data starts at an offset of 0 (that is, the frame contains the Data starts at an offset of 0 (that is, the frame contains the
first octets of the stream, or the end of a stream that includes first octets of the stream, or the end of a stream that includes
no data). no data).
o The LEN bit (0x02) in the frame type is set to indicate that there
is a Length field present. If this bit is set to 0, the Length
field is absent and the Stream Data field extends to the end of
the packet. If this bit is set to 1, the Length field is present.
o The FIN bit (0x01) of the frame type is set only on frames that
contain the final offset of the stream. Setting this bit
indicates that the frame marks the end of the stream.
A STREAM frame is shown below. A STREAM frame is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Offset (i)] ... | [Offset (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Length (i)] ... | [Length (i)] ...
skipping to change at page 59, line 37 skipping to change at page 60, line 12
occurs, only streams with data in that packet are blocked waiting for occurs, only streams with data in that packet are blocked waiting for
a retransmission to be received, while other streams can continue a retransmission to be received, while other streams can continue
making progress. Note that when data from multiple streams is making progress. Note that when data from multiple streams is
bundled into a single QUIC packet, loss of that packet blocks all bundled into a single QUIC packet, loss of that packet blocks all
those streams from making progress. An implementation is therefore those streams from making progress. An implementation is therefore
advised to bundle as few streams as necessary in outgoing packets advised to bundle as few streams as necessary in outgoing packets
without losing transmission efficiency to underfilled packets. without losing transmission efficiency to underfilled packets.
9. Packetization and Reliability 9. Packetization and Reliability
The Path Maximum Transmission Unit (PMTU) is the maximum size of the
entire IP header, UDP header, and UDP payload. The UDP payload
includes the QUIC packet header, protected payload, and any
authentication fields.
All QUIC packets SHOULD be sized to fit within the estimated PMTU to
avoid IP fragmentation or packet drops. To optimize bandwidth
efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery
([PLPMTUD]) and MAY use PMTU Discovery ([PMTUDv4], [PMTUDv6]) for
detecting the PMTU, setting the PMTU appropriately, and storing the
result of previous PMTU determinations.
In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP
packets larger than 1280 octets. Assuming the minimum IP header
size, this results in a QUIC packet size of 1232 octets for IPv6 and
1252 octets for IPv4.
QUIC endpoints that implement any kind of PMTU discovery SHOULD
maintain an estimate for each combination of local and remote IP
addresses (as each pairing could have a different maximum MTU in the
path).
QUIC depends on the network path supporting a MTU of at least 1280
octets. This is the IPv6 minimum and therefore also supported by
most modern IPv4 networks. An endpoint MUST NOT reduce their MTU
below this number, even if it receives signals that indicate a
smaller limit might exist.
Clients MUST ensure that the first packet in a connection, and any
retransmissions of those octets, has a QUIC packet size of least 1200
octets. The packet size for a QUIC packet includes the QUIC header
and integrity check, but not the UDP or IP header.
The initial client packet SHOULD be padded to exactly 1200 octets
unless the client has a reasonable assurance that the PMTU is larger.
Sending a packet of this size ensures that the network path supports
an MTU of this size and helps reduce the amplitude of amplification
attacks caused by server responses toward an unverified client
address.
Servers MUST ignore an initial plaintext packet from a client if its
total size is less than 1200 octets.
If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses has fallen below 1280 octets, it MUST
immediately cease sending QUIC packets on the affected path. This
could result in termination of the connection if an alternative path
cannot be found.
A sender bundles one or more frames in a Regular QUIC packet (see A sender bundles one or more frames in a Regular QUIC packet (see
Section 6). Section 6).
A sender SHOULD minimize per-packet bandwidth and computational costs A sender SHOULD minimize per-packet bandwidth and computational costs
by bundling as many frames as possible within a QUIC packet. A by bundling as many frames as possible within a QUIC packet. A
sender MAY wait for a short period of time to bundle multiple frames sender MAY wait for a short period of time to bundle multiple frames
before sending a packet that is not maximally packed, to avoid before sending a packet that is not maximally packed, to avoid
sending out large numbers of small packets. An implementation may sending out large numbers of small packets. An implementation may
use heuristics about expected application sending behavior to use heuristics about expected application sending behavior to
determine whether and for how long to wait. This waiting period is determine whether and for how long to wait. This waiting period is
skipping to change at page 62, line 16 skipping to change at page 61, line 39
To avoid creating an indefinite feedback loop, an endpoint MUST NOT To avoid creating an indefinite feedback loop, an endpoint MUST NOT
send an ACK frame in response to a packet containing only ACK or send an ACK frame in response to a packet containing only ACK or
PADDING frames, even if there are packet gaps which precede the PADDING frames, even if there are packet gaps which precede the
received packet. The endpoint MUST acknowledge packets containing received packet. The endpoint MUST acknowledge packets containing
only ACK or PADDING frames in the next ACK frame that it sends. only ACK or PADDING frames in the next ACK frame that it sends.
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].
9.1. Special Considerations for PMTU Discovery 9.1. Packet Size
The QUIC packet size includes the QUIC header and integrity check,
but not the UDP or IP header.
Clients MUST pad any Initial packet it sends to have a QUIC packet
size of at least 1200 octets. Sending an Initial packet of this size
ensures that the network path supports a reasonably sized packet, 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
Path Maximum Transmission Unit (PMTU) supports the size that it
chooses.
A server MAY send a CONNECTION_CLOSE frame with error code
PROTOCOL_VIOLATION in response to an Initial packet smaller than 1200
octets. It MUST NOT send any other frame type in response, or
otherwise behave as if any part of the offending packet was processed
as valid.
9.2. Path Maximum Transmission Unit
The Path Maximum Transmission Unit (PMTU) is the maximum size of the
entire IP header, UDP header, and UDP payload. The UDP payload
includes the QUIC packet header, protected payload, and any
authentication fields.
All QUIC packets SHOULD be sized to fit within the estimated PMTU to
avoid IP fragmentation or packet drops. To optimize bandwidth
efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery
([PLPMTUD]). Endpoints MAY use PMTU Discovery ([PMTUDv4], [PMTUDv6])
for detecting the PMTU, setting the PMTU appropriately, and storing
the result of previous PMTU determinations.
In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP
packets larger than 1280 octets. Assuming the minimum IP header
size, this results in a QUIC packet size of 1232 octets for IPv6 and
1252 octets for IPv4. Some QUIC implementations MAY wish to be more
conservative in computing allowed QUIC packet size given unknown
tunneling overheads or IP header options.
QUIC endpoints that implement any kind of PMTU discovery SHOULD
maintain an estimate for each combination of local and remote IP
addresses. Each pairing of local and remote addresses could have a
different maximum MTU in the path.
QUIC depends on the network path supporting a MTU of at least 1280
octets. This is the IPv6 minimum MTU and therefore also supported by
most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below
this number, even if it receives signals that indicate a smaller
limit might exist.
If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses has fallen below 1280 octets, it MUST
immediately cease sending QUIC packets on the affected path. This
could result in termination of the connection if an alternative path
cannot be found.
9.2.1. Special Considerations for PMTU Discovery
Traditional ICMP-based path MTU discovery in IPv4 [RFC1191] is Traditional ICMP-based path MTU discovery in IPv4 [RFC1191] 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 62, line 44 skipping to change at page 63, line 33
spurious. spurious.
o Store additional information from the IP or UDP headers from DF o Store additional information from the IP or UDP headers from DF
packets (for example, the IP ID or UDP checksum) to further packets (for example, the IP ID or UDP checksum) to further
authenticate incoming Datagram Too Big messages. authenticate incoming Datagram Too Big messages.
o Any reduction in PMTU due to a report contained in an ICMP packet o Any reduction in PMTU due to a report contained in an ICMP packet
is provisional until QUIC's loss detection algorithm determines is provisional until QUIC's loss detection algorithm determines
that the packet is actually lost. that the packet is actually lost.
9.2.2. Special Considerations for Packetization Layer PMTU Discovery
The PADDING frame provides a useful option for PMTU probe packets
that does not exist in other transports. PADDING frames generate
acknowledgements, but their content need not be delivered reliably.
PADDING frames may delay the delivery of application data, as they
consume the congestion window. However, by definition their likely
loss in a probe packet does not require delay-inducing retransmission
of application data.
When implementing the algorithm in Section 7.2 of [RFC4821], the
initial value of search_low SHOULD be consistent with the IPv6
minimum packet size. Paths that do not support this size cannot
deliver Initial packets, and therefore are not QUIC-compliant.
Section 7.3 of [RFC4821] discusses tradeoffs between small and large
increases in the size of probe packets. As QUIC probe packets need
not contain application data, aggressive increases in probe size
carry fewer consequences.
10. Streams: QUIC's Data Structuring Abstraction 10. 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
carry data in one direction only; bidirectional streams allow for carry data in one direction only; bidirectional streams allow for
data to be sent in both directions. Different stream identifiers are data to be sent in both directions. Different stream identifiers are
used to distinguish between unidirectional and bidirectional streams, used to distinguish between unidirectional and bidirectional streams,
as well as to create a separation between streams that are initiated as well as to create a separation between streams that are initiated
skipping to change at page 81, line 26 skipping to change at page 82, line 26
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.
13. Security and Privacy Considerations 13. Security and Privacy Considerations
13.1. Spoofed ACK Attack 13.1. Spoofed ACK Attack
An attacker receives an STK from the server and then releases the IP An attacker might be able to receive an address validation token
address on which it received the STK. The attacker may, in the (Section 7.6) from the server and then release the IP address it used
future, spoof this same address (which now presumably addresses a to acquire that token. The attacker may, in the future, spoof this
different endpoint), and initiate a 0-RTT connection with a server on same address (which now presumably addresses a different endpoint),
the victim's behalf. The attacker then spoofs ACK frames to the and initiate a 0-RTT connection with a server on the victim's behalf.
server which cause the server to potentially drown the victim in The attacker can then spoof ACK frames to the server which cause the
data. server to send excessive amounts of data toward the new owner of the
IP address.
There are two possible mitigations to this attack. The simplest one There are two possible mitigations to this attack. The simplest one
is that a server can unilaterally create a gap in packet-number is that a server can unilaterally create a gap in packet-number
space. In the non-attack scenario, the client will send an ACK frame space. In the non-attack scenario, the client will send an ACK frame
with the larger value for largest acknowledged. In the attack with the larger value for largest acknowledged. In the attack
scenario, the attacker could acknowledge a packet in the gap. If the scenario, the attacker could acknowledge a packet in the gap. If the
server sees an acknowledgment for a packet that was never sent, the server sees an acknowledgment for a packet that was never sent, the
connection can be aborted. connection can be aborted.
The second mitigation is that the server can require that The second mitigation is that the server can require that
skipping to change at page 87, line 11 skipping to change at page 88, line 11
+-----------+------------------------+---------------+--------------+ +-----------+------------------------+---------------+--------------+
Table 8: Initial QUIC Transport Error Codes Entries Table 8: Initial QUIC Transport Error Codes Entries
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-22 (work in progress), Version 1.3", draft-ietf-tls-tls13-23 (work in progress),
November 2017. January 2018.
[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-00 (work and Congestion Control", draft-ietf-quic-recovery-09 (work
in progress), December 2017. in progress), January 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-00 (work in progress), December 2017. tls-09 (work in progress), January 2018.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
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>.
15.2. Informative References 15.2. Informative References
skipping to change at page 90, line 12 skipping to change at page 91, line 16
discussions and public ones on the quic@ietf.org and proto- discussions and public ones on the quic@ietf.org and proto-
quic@chromium.org mailing lists. Our thanks to all. quic@chromium.org mailing lists. Our thanks to all.
Appendix C. Change Log Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-transport-07 C.1. Since draft-ietf-quic-transport-08
o Clarified requirements for BLOCKED usage (#65, #924)
o BLOCKED frame now includes reason for blocking (#452, #924, #927,
#928)
o Cleartext integrity as version independent (#568)
o GAP limitation in ACK Frame (#613)
o Improved PMTUD description (#614, #1036)
o Clarified stream state machine (#634, #662, #894)
o Reserved versions don't need to be generated deterministically
(#831, #931)
o You don't always need the draining period (#871)
o Stateless reset clarified as version-specific (#930, #986)
o initial_max_stream_id_x transport parameters are optional (#970,
#971)
o Ack Delay assumes a default value during the handshake (#1007,
#1009)
o Removed transport parameters from NewSessionTicket (#1015)
C.2. Since draft-ietf-quic-transport-07
o The long header now has version before packet number (#926, #939)
o Rename and consolidate packet types (#846, #822, #847)
o Packet types are assigned new codepoints and the Connection ID
Flag is inverted (#426, #956)
o Removed type for Version Negotiation and use Version 0 (#963,
#968)
o Streams are split into unidirectional and bidirectional (#643,
#656, #720, #872, #175, #885)
* Stream limits now have separate uni- and bi-directinal
transport parameters (#909, #958)
* Stream limit transport parameters are now optional and default
to 0 (#970, #971)
o The stream state machine has been split into read and write (#634,
#894)
o Employ variable-length integer encodings throughout (#595) o Employ variable-length integer encodings throughout (#595)
o Draining period can terminate early (#869) o Improvements to connection close
C.2. Since draft-ietf-quic-transport-06 * Added distinct closing and draining states (#899, #871)
* Draining period can terminate early (#869, #870)
* Clarifications about stateless reset (#889, #890)
o Address validation for connection migration (#161, #732, #878)
o Clearly defined retransmission rules for BLOCKED (#452, #65, #924)
o negotiated_version is sent in server transport parameters (#710,
#959)
o Increased the range over which packet numbers are randomized
(#864, #850, #964)
C.3. 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.3. Since draft-ietf-quic-transport-05 C.4. 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.4. Since draft-ietf-quic-transport-04 C.5. 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 91, line 28 skipping to change at page 94, 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.5. Since draft-ietf-quic-transport-03 C.6. 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.6. Since draft-ietf-quic-transport-02 C.7. 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 92, line 29 skipping to change at page 95, 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.7. Since draft-ietf-quic-transport-01 C.8. 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)
o Narrow the packet number encoding range requirement (#67, #286, o Narrow the packet number encoding range requirement (#67, #286,
#299, #323, #356) #299, #323, #356)
o Defined client address validation (#52, #118, #120, #275) o Defined client address validation (#52, #118, #120, #275)
o Define transport parameters as a TLS extension (#49, #122) o Define transport parameters as a TLS extension (#49, #122)
o SCUP and COPT parameters are no longer valid (#116, #117) o SCUP and COPT parameters are no longer valid (#116, #117)
o Transport parameters for 0-RTT are either remembered from before, o Transport parameters for 0-RTT are either remembered from before,
skipping to change at page 94, line 39 skipping to change at page 97, 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.8. Since draft-ietf-quic-transport-00 C.9. 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.9. Since draft-hamilton-quic-transport-protocol-01 C.10. 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
Authors' Addresses Authors' Addresses
 End of changes. 54 change blocks. 
184 lines changed or deleted 299 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/