draft-ietf-quic-transport-23.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: March 15, 2020 Mozilla Expires: April 20, 2020 Mozilla
September 12, 2019 October 18, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-23 draft-ietf-quic-transport-latest
Abstract Abstract
This document defines the core of the QUIC transport protocol. This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation. control and the use of TLS for key negotiation.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 15, 2020. This Internet-Draft will expire on April 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 31 skipping to change at page 3, line 31
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 46 9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 46
9.2. Initiating Connection Migration . . . . . . . . . . . . . 47 9.2. Initiating Connection Migration . . . . . . . . . . . . . 47
9.3. Responding to Connection Migration . . . . . . . . . . . 47 9.3. Responding to Connection Migration . . . . . . . . . . . 47
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 48 9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 48
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 48 9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 48
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 49 9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 49
9.4. Loss Detection and Congestion Control . . . . . . . . . . 50 9.4. Loss Detection and Congestion Control . . . . . . . . . . 50
9.5. Privacy Implications of Connection Migration . . . . . . 51 9.5. Privacy Implications of Connection Migration . . . . . . 51
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 52 9.6. Server's Preferred Address . . . . . . . . . . . . . . . 52
9.6.1. Communicating a Preferred Address . . . . . . . . . . 52 9.6.1. Communicating a Preferred Address . . . . . . . . . . 52
9.6.2. Responding to Connection Migration . . . . . . . . . 52 9.6.2. Responding to Connection Migration . . . . . . . . . 53
9.6.3. Interaction of Client Migration and Preferred Address 53 9.6.3. Interaction of Client Migration and Preferred Address 53
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 53 9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 54
10. Connection Termination . . . . . . . . . . . . . . . . . . . 54 10. Connection Termination . . . . . . . . . . . . . . . . . . . 54
10.1. Closing and Draining Connection States . . . . . . . . . 54 10.1. Closing and Draining Connection States . . . . . . . . . 54
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 55 10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 56
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 56 10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 56
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 57 10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 58
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 60 10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 60
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 61 10.4.2. Calculating a Stateless Reset Token . . . . . . . . 61
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 62 10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 62
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 62 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 62
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 63 11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 63
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 64 11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 64
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 64 12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 64
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 64 12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 64
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 65 12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 65
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 66 12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 66
skipping to change at page 4, line 17 skipping to change at page 4, line 17
13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 73 13.2.3. Receiver Tracking of ACK Frames . . . . . . . . . . 73
13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 73 13.2.4. Limiting ACK Ranges . . . . . . . . . . . . . . . . 73
13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 74 13.2.5. Measuring and Reporting Host Delay . . . . . . . . . 74
13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 74 13.2.6. ACK Frames and Packet Protection . . . . . . . . . . 74
13.3. Retransmission of Information . . . . . . . . . . . . . 75 13.3. Retransmission of Information . . . . . . . . . . . . . 75
13.4. Explicit Congestion Notification . . . . . . . . . . . . 77 13.4. Explicit Congestion Notification . . . . . . . . . . . . 77
13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 77 13.4.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 77
13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 78 13.4.2. ECN Validation . . . . . . . . . . . . . . . . . . . 78
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 80 14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 80
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 81 14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 81
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 82 14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 81
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 83 14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 82
14.3.1. PMTU Probes Containing Source Connection ID . . . . 83 14.3.1. PMTU Probes Containing Source Connection ID . . . . 83
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 83 15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 83
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 84 16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 84
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 85 17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 85
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 85 17.1. Packet Number Encoding and Decoding . . . . . . . . . . 85
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 86 17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 86
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 89 17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 89
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 91 17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 91
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 93 17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 93
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 95 17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 95
skipping to change at page 5, line 47 skipping to change at page 5, line 47
B.5. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 142 B.5. Since draft-ietf-quic-transport-18 . . . . . . . . . . . 142
B.6. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 143 B.6. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 143
B.7. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 144 B.7. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 144
B.8. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 145 B.8. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 145
B.9. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 145 B.9. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 145
B.10. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 145 B.10. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 145
B.11. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 146 B.11. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 146
B.12. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 147 B.12. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 147
B.13. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 147 B.13. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 147
B.14. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 148 B.14. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 148
B.15. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 148 B.15. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 149
B.16. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 149 B.16. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 149
B.17. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 150 B.17. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 150
B.18. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 150 B.18. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 150
B.19. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 151 B.19. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 151
B.20. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 151 B.20. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 151
B.21. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 152 B.21. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 152
B.22. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 153 B.22. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 153
B.23. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 155 B.23. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 155
B.24. Since draft-hamilton-quic-transport-protocol-01 . . . . . 155 B.24. Since draft-hamilton-quic-transport-protocol-01 . . . . . 155
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 155 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 155
skipping to change at page 8, line 22 skipping to change at page 8, line 22
Commonly used terms in the document are described below. Commonly used terms in the document are described below.
QUIC: The transport protocol described by this document. QUIC is a QUIC: The transport protocol described by this document. QUIC is a
name, not an acronym. name, not an acronym.
QUIC packet: A complete processable unit of QUIC that can be QUIC packet: A complete processable unit of QUIC that can be
encapsulated in a UDP datagram. Multiple QUIC packets can be encapsulated in a UDP datagram. Multiple QUIC packets can be
encapsulated in a single UDP datagram. encapsulated in a single UDP datagram.
Ack-eliciting Packet: A QUIC packet that contains frames other than
ACK and PADDING. These cause a recipient to send an
acknowledgment (see Section 13.2.1).
Endpoint: An entity that can participate in a QUIC connection by Endpoint: An entity that can participate in a QUIC connection by
generating, receiving, and processing QUIC packets. There are generating, receiving, and processing QUIC packets. There are
only two types of endpoint in QUIC: client and server. only two types of endpoint in QUIC: client and server.
Client: The endpoint initiating a QUIC connection. Client: The endpoint initiating a QUIC connection.
Server: The endpoint accepting incoming QUIC connections. Server: The endpoint accepting incoming QUIC connections.
Connection ID: An opaque identifier that is used to identify a QUIC Connection ID: An opaque identifier that is used to identify a QUIC
connection at an endpoint. Each endpoint sets a value for its connection at an endpoint. Each endpoint sets a value for its
skipping to change at page 25, line 29 skipping to change at page 25, line 29
connection ID could agree with the load balancer on a fixed length connection ID could agree with the load balancer on a fixed length
for connection IDs, or agree on an encoding scheme. A fixed portion for connection IDs, or agree on an encoding scheme. A fixed portion
could encode an explicit length, which allows the entire connection could encode an explicit length, which allows the entire connection
ID to vary in length and still be used by the load balancer. ID to vary in length and still be used by the load balancer.
A Version Negotiation (Section 17.2.1) packet echoes the connection A Version Negotiation (Section 17.2.1) packet echoes the connection
IDs selected by the client, both to ensure correct routing toward the IDs selected by the client, both to ensure correct routing toward the
client and to allow the client to validate that the packet is in client and to allow the client to validate that the packet is in
response to an Initial packet. response to an Initial packet.
A zero-length connection ID MAY be used when the connection ID is not A zero-length connection ID can be used when a connection ID is not
needed for routing and the address/port tuple of packets is needed to route to the correct endpoint. However, multiplexing
sufficient to identify a connection. An endpoint whose peer has connections on the same local IP address and port while using zero-
selected a zero-length connection ID MUST continue to use a zero- length connection IDs will cause failures in the presence of peer
length connection ID for the lifetime of the connection and MUST NOT connection migration, NAT rebinding, and client port reuse; and
send packets from any other local address. therefore MUST NOT be done unless an endpoint is certain that those
protocol features are not in use.
When an endpoint has requested a non-zero-length connection ID, it When an endpoint has requested a non-zero-length connection ID, it
needs to ensure that the peer has a supply of connection IDs from needs to ensure that the peer has a supply of connection IDs from
which to choose for packets sent to the endpoint. These connection which to choose for packets sent to the endpoint. These connection
IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame IDs are supplied by the endpoint using the NEW_CONNECTION_ID frame
(Section 19.15). (Section 19.15).
5.1.1. Issuing Connection IDs 5.1.1. Issuing Connection IDs
Each Connection ID has an associated sequence number to assist in Each Connection ID has an associated sequence number to assist in
skipping to change at page 26, line 16 skipping to change at page 26, line 16
NEW_CONNECTION_ID frames (Section 19.15). The sequence number on NEW_CONNECTION_ID frames (Section 19.15). The sequence number on
each newly-issued connection ID MUST increase by 1. The connection each newly-issued connection ID MUST increase by 1. The connection
ID randomly selected by the client in the Initial packet and any ID randomly selected by the client in the Initial packet and any
connection ID provided by a Retry packet are not assigned sequence connection ID provided by a Retry packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection numbers unless a server opts to retain them as its initial connection
ID. ID.
When an endpoint issues a connection ID, it MUST accept packets that When an endpoint issues a connection ID, it MUST accept packets that
carry this connection ID for the duration of the connection or until carry this connection ID for the duration of the connection or until
its peer invalidates the connection ID via a RETIRE_CONNECTION_ID its peer invalidates the connection ID via a RETIRE_CONNECTION_ID
frame (Section 19.16). frame (Section 19.16). Connection IDs that are issued and not
retired are considered active; any active connection ID can be used.
An endpoint SHOULD ensure that its peer has a sufficient number of An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs. Endpoints store received available and unused connection IDs. Endpoints store received
connection IDs for future use and advertise the number of connection connection IDs for future use and advertise the number of connection
IDs they are willing to store with the active_connection_id_limit IDs they are willing to store with the active_connection_id_limit
transport parameter. An endpoint SHOULD NOT provide more connection transport parameter. An endpoint SHOULD NOT provide more connection
IDs than the peer's limit. IDs than the peer's limit.
An endpoint SHOULD supply a new connection ID when it receives a An endpoint SHOULD supply a new connection ID when it receives a
packet with a previously unused connection ID or when the peer packet with a previously unused connection ID or when the peer
skipping to change at page 27, line 33 skipping to change at page 27, line 33
connection ID could elicit a response with the corresponding connection ID could elicit a response with the corresponding
stateless reset token. stateless reset token.
5.2. Matching Packets to Connections 5.2. Matching Packets to Connections
Incoming packets are classified on receipt. Packets can either be Incoming packets are classified on receipt. Packets can either be
associated with an existing connection, or - for servers - associated with an existing connection, or - for servers -
potentially create a new connection. potentially create a new connection.
Hosts try to associate a packet with an existing connection. If the Hosts try to associate a packet with an existing connection. If the
packet has a Destination Connection ID corresponding to an existing packet has a non-zero-length Destination Connection ID corresponding
connection, QUIC processes that packet accordingly. Note that more to an existing connection, QUIC processes that packet accordingly.
than one connection ID can be associated with a connection; see Note that more than one connection ID can be associated with a
Section 5.1. connection; see Section 5.1.
If the Destination Connection ID is zero length and the packet If the Destination Connection ID is zero length and the packet
matches the address/port tuple of a connection where the host did not matches the local address and port of a connection where the host
require connection IDs, QUIC processes the packet as part of that used zero-length connection IDs, QUIC processes the packet as part of
connection. Endpoints SHOULD either reject connection attempts that that connection.
use the same addresses as existing connections, or use a non-zero-
length Destination Connection ID so that packets can be correctly
attributed to connections.
Endpoints can send a Stateless Reset (Section 10.4) for any packets Endpoints can send a Stateless Reset (Section 10.4) for any packets
that cannot be attributed to an existing connection. A stateless that cannot be attributed to an existing connection. A stateless
reset allows a peer to more quickly identify when a connection reset allows a peer to more quickly identify when a connection
becomes unusable. becomes unusable.
Packets that are matched to an existing connection are discarded if Packets that are matched to an existing connection are discarded if
the packets are inconsistent with the state of that connection. For the packets are inconsistent with the state of that connection. For
example, packets are discarded if they indicate a different protocol example, packets are discarded if they indicate a different protocol
version than that of the connection, or if the removal of packet version than that of the connection, or if the removal of packet
skipping to change at page 28, line 17 skipping to change at page 28, line 14
Invalid packets without packet protection, such as Initial, Retry, or Invalid packets without packet protection, such as Initial, Retry, or
Version Negotiation, MAY be discarded. An endpoint MUST generate a Version Negotiation, MAY be discarded. An endpoint MUST generate a
connection error if it commits changes to state before discovering an connection error if it commits changes to state before discovering an
error. error.
5.2.1. Client Packet Handling 5.2.1. Client Packet Handling
Valid packets sent to clients always include a Destination Connection Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects. Clients that choose to ID that matches a value the client selects. Clients that choose to
receive zero-length connection IDs can use the address/port tuple to receive zero-length connection IDs can use the local address and port
identify a connection. Packets that don't match an existing to identify a connection. Packets that don't match an existing
connection are discarded. connection are discarded.
Due to packet reordering or loss, a client might receive packets for Due to packet reordering or loss, a client might receive packets for
a connection that are encrypted with a key it has not yet computed. a connection that are encrypted with a key it has not yet computed.
The client MAY drop these packets, or MAY buffer them in anticipation The client MAY drop these packets, or MAY buffer them in anticipation
of later packets that allow it to compute the key. of later packets that allow it to compute the key.
If a client receives a packet that has an unsupported version, it If a client receives a packet that has an unsupported version, it
MUST discard that packet. MUST discard that packet.
skipping to change at page 28, line 49 skipping to change at page 28, line 46
semantics and encodings for any version-specific field. In semantics and encodings for any version-specific field. In
particular, different packet protection keys might be used for particular, different packet protection keys might be used for
different versions. Servers that do not support a particular version different versions. Servers that do not support a particular version
are unlikely to be able to decrypt the payload of the packet. are unlikely to be able to decrypt the payload of the packet.
Servers SHOULD NOT attempt to decode or decrypt a packet from an Servers SHOULD NOT attempt to decode or decrypt a packet from an
unknown version, but instead send a Version Negotiation packet, unknown version, but instead send a Version Negotiation packet,
provided that the packet is sufficiently long. provided that the packet is sufficiently long.
Packets with a supported version, or no version field, are matched to Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero- a connection using the connection ID or - for packets with zero-
length connection IDs - the address tuple. If the packet doesn't length connection IDs - the local address and port. If the packet
match an existing connection, the server continues below. doesn't match an existing connection, the server continues below.
If the packet is an Initial packet fully conforming with the If the packet is an Initial packet fully conforming with the
specification, the server proceeds with the handshake (Section 7). specification, the server proceeds with the handshake (Section 7).
This commits the server to the version that the client selected. This commits the server to the version that the client selected.
If a server isn't currently accepting any new connections, it SHOULD If a server isn't currently accepting any new connections, it SHOULD
send an Initial packet containing a CONNECTION_CLOSE frame with error send an Initial packet containing a CONNECTION_CLOSE frame with error
code SERVER_BUSY. code SERVER_BUSY.
If the packet is a 0-RTT packet, the server MAY buffer a limited If the packet is a 0-RTT packet, the server MAY buffer a limited
skipping to change at page 51, line 21 skipping to change at page 51, line 21
PATH_CHALLENGE, and restart the timer for a longer period of time. PATH_CHALLENGE, and restart the timer for a longer period of time.
9.5. Privacy Implications of Connection Migration 9.5. Privacy Implications of Connection Migration
Using a stable connection ID on multiple network paths allows a Using a stable connection ID on multiple network paths allows a
passive observer to correlate activity between those paths. An passive observer to correlate activity between those paths. An
endpoint that moves between networks might not wish to have their endpoint that moves between networks might not wish to have their
activity correlated by any entity other than their peer, so different activity correlated by any entity other than their peer, so different
connection IDs are used when sending from different local addresses, connection IDs are used when sending from different local addresses,
as discussed in Section 5.1. For this to be effective endpoints need as discussed in Section 5.1. For this to be effective endpoints need
to ensure that connections IDs they provide cannot be linked by any to ensure that connection IDs they provide cannot be linked by any
other entity. other entity.
At any time, endpoints MAY change the Destination Connection ID they At any time, endpoints MAY change the Destination Connection ID they
send to a value that has not been used on another path. send to a value that has not been used on another path.
An endpoint MUST use a new connection ID if it initiates connection An endpoint MUST use a new connection ID if it initiates connection
migration. Using a new connection ID eliminates the use of the migration as described in Section 9.2 or probes a new network path as
connection ID for linking activity from the same connection on described in Section 9.1. An endpoint MUST use a new connection ID
different networks. Header protection ensures that packet numbers in response to a change in the address of a peer if the packet with
cannot be used to correlate activity. This does not prevent other the new peer address uses an active connection ID that has not been
properties of packets, such as timing and size, from being used to previously used by the peer.
correlate activity.
Using different connection IDs for packets sent in both directions on
each new network path eliminates the use of the connection ID for
linking packets from the same connection across different network
paths. Header protection ensures that packet numbers cannot be used
to correlate activity. This does not prevent other properties of
packets, such as timing and size, from being used to correlate
activity.
Unintentional changes in path without a change in connection ID are Unintentional changes in path without a change in connection ID are
possible. For example, after a period of network inactivity, NAT possible. For example, after a period of network inactivity, NAT
rebinding might cause packets to be sent on a new path when the rebinding might cause packets to be sent on a new path when the
client resumes sending. client resumes sending.
A client might wish to reduce linkability by employing a new A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period connection ID and source UDP port when sending traffic after a period
of inactivity. Changing the UDP port from which it sends packets at of inactivity. Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection the same time might cause the packet to appear as a connection
migration. This ensures that the mechanisms that support migration migration. This ensures that the mechanisms that support migration
are exercised even for clients that don't experience NAT rebindings are exercised even for clients that don't experience NAT rebindings
or genuine migrations. Changing port number can cause a peer to or genuine migrations. Changing port number can cause a peer to
reset its congestion state (see Section 9.4), so the port SHOULD only reset its congestion state (see Section 9.4), so the port SHOULD only
be changed infrequently. be changed infrequently.
An endpoint that exhausts available connection IDs cannot migrate. An endpoint that exhausts available connection IDs cannot probe new
To ensure that migration is possible and packets sent on different paths or initiate migration, nor can it respond to probes or attempts
paths cannot be correlated, endpoints SHOULD provide new connection by its peer to migrate. To ensure that migration is possible and
IDs before peers migrate. packets sent on different paths cannot be correlated, endpoints
SHOULD provide new connection IDs before peers migrate; see
Section 5.1.1. If a peer might have exhausted available connection
IDs, a migrating endpoint could include a NEW_CONNECTION_ID frame in
all packets sent on a new network path.
9.6. Server's Preferred Address 9.6. Server's Preferred Address
QUIC allows servers to accept connections on one IP address and QUIC allows servers to accept connections on one IP address and
attempt to transfer these connections to a more preferred address attempt to transfer these connections to a more preferred address
shortly after the handshake. This is particularly useful when shortly after the handshake. This is particularly useful when
clients initially connect to an address shared by multiple servers clients initially connect to an address shared by multiple servers
but would prefer to use a unicast address to ensure connection but would prefer to use a unicast address to ensure connection
stability. This section describes the protocol for migrating a stability. This section describes the protocol for migrating a
connection to a preferred server address. connection to a preferred server address.
skipping to change at page 56, line 6 skipping to change at page 56, line 16
If the idle timeout is enabled, a connection is silently closed and If the idle timeout is enabled, a connection is silently closed and
the state is discarded when it remains idle for longer than both the the state is discarded when it remains idle for longer than both the
advertised idle timeout (see Section 18.2) and three times the advertised idle timeout (see Section 18.2) and three times the
current Probe Timeout (PTO). current Probe Timeout (PTO).
Each endpoint advertises its own idle timeout to its peer. An Each endpoint advertises its own idle timeout to its peer. An
endpoint restarts any timer it maintains when a packet from its peer endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully. The timer is also restarted is received and processed successfully. The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an when sending a packet containing frames other than ACK or PADDING (an
ACK-eliciting packet; see [QUIC-RECOVERY]), but only if no other ACK- ack-eliciting packet; see [QUIC-RECOVERY]), but only if no other ack-
eliciting packets have been sent since last receiving a packet. eliciting packets have been sent since last receiving a packet.
Restarting when sending packets ensures that connections do not Restarting when sending packets ensures that connections do not
prematurely time out when initiating new activity. prematurely time out when initiating new activity.
The value for an idle timeout can be asymmetric. The value The value for an idle timeout can be asymmetric. The value
advertised by an endpoint is only used to determine whether the advertised by an endpoint is only used to determine whether the
connection is live at that endpoint. An endpoint that sends packets connection is live at that endpoint. An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the packets discarded if its peer enters the draining state before the
packets arrive. If a peer could timeout within a Probe Timeout (PTO; packets arrive. If a peer could timeout within a Probe Timeout (PTO;
skipping to change at page 58, line 12 skipping to change at page 58, line 21
crash or outage might result in peers continuing to send data to an crash or outage might result in peers continuing to send data to an
endpoint that is unable to properly continue the connection. An endpoint that is unable to properly continue the connection. An
endpoint MAY send a stateless reset in response to receiving a packet endpoint MAY send a stateless reset in response to receiving a packet
that it cannot associate with an active connection. that it cannot associate with an active connection.
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 frame if it has sufficient state to do so. use a CONNECTION_CLOSE frame if it has sufficient state to do so.
To support this process, a token is sent by endpoints. The token is To support this process, a token is sent by endpoints. The token is
carried in the NEW_CONNECTION_ID frame sent by either peer, and carried in the Stateless Reset Token field of a NEW_CONNECTION_ID
servers can specify the stateless_reset_token transport parameter frame. Servers can also specify a stateless_reset_token transport
during the handshake (clients cannot because their transport parameter during the handshake that applies to the connection ID that
parameters don't have confidentiality protection). This value is it selected during the handshake; clients cannot use this transport
protected by encryption, so only client and server know this value. parameter because their transport parameters don't have
Tokens are invalidated when their associated connection ID is retired confidentiality protection. These tokens are protected by
via a RETIRE_CONNECTION_ID frame (Section 19.16). encryption, so only client and server know their value. Tokens are
invalidated when their associated connection ID is retired via a
RETIRE_CONNECTION_ID frame (Section 19.16).
An endpoint that receives packets that it cannot process sends a An endpoint that receives packets that it cannot process sends a
packet 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|1| Unpredictable Bits (38 ..) ... |0|1| Unpredictable Bits (38 ..) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 60, line 37 skipping to change at page 60, line 49
prior to losing state). Designers of new versions of QUIC need to be prior to losing state). Designers of new versions of QUIC need to be
aware of this and either reuse this design, or use a portion of the aware of this and either reuse this design, or use a portion of the
packet other than the last 16 bytes for carrying data. packet other than the last 16 bytes for carrying data.
10.4.1. Detecting a Stateless Reset 10.4.1. Detecting a Stateless Reset
An endpoint detects a potential stateless reset when an incoming An endpoint detects a potential stateless reset when an incoming
packet either cannot be associated with a connection, cannot be packet either cannot be associated with a connection, cannot be
decrypted, or is marked as a duplicate packet. The endpoint MUST decrypted, or is marked as a duplicate packet. The endpoint MUST
then compare the last 16 bytes of the packet with all Stateless Reset then compare the last 16 bytes of the packet with all Stateless Reset
Tokens that are associated with connection IDs that the endpoint Tokens corresponding to active connection IDs that the endpoint has
recently used to send packets from the IP address and port on which used for sending packets to the IP address and port on which the
the datagram is received. This includes Stateless Reset Tokens from datagram is received. This includes Stateless Reset Tokens from
NEW_CONNECTION_ID frames and the server's transport parameters. An NEW_CONNECTION_ID frames and the server's transport parameters. An
endpoint MUST NOT check for any Stateless Reset Tokens associated endpoint MUST NOT check for any Stateless Reset Tokens associated
with connection IDs it has not used or for connection IDs that have with connection IDs it has not used or for connection IDs that have
been retired. been retired.
If the last 16 bytes of the packet values are identical to a If the last 16 bytes of the packet values are identical to a
Stateless Reset Token, the endpoint MUST enter the draining period Stateless Reset Token, the endpoint MUST enter the draining period
and not send any further packets on this connection. If the and not send any further packets on this connection. If the
comparison fails, the packet can be discarded. comparison fails, the packet can be discarded.
skipping to change at page 61, line 48 skipping to change at page 62, line 9
the connection, so a value can only be used once. This method for the connection, so a value can only be used once. This method for
choosing the Stateless Reset Token means that the combination of choosing the Stateless Reset Token means that the combination of
connection ID and static key MUST NOT be used for another connection. connection ID and static key MUST NOT be used for another connection.
A denial of service attack is possible if the same connection ID is A denial of service attack is possible if the same connection ID is
used by instances that share a static key, or if an attacker can used by instances that share a static key, or if an attacker can
cause a packet to be routed to an instance that has no state but the cause a packet to be routed to an instance that has no state but the
same static key; see Section 21.9. A connection ID from a connection same static key; see Section 21.9. A connection ID from a connection
that is reset by revealing the Stateless Reset Token MUST NOT be that is reset by revealing the Stateless Reset Token MUST NOT be
reused for new connections at nodes that share a static key. reused for new connections at nodes that share a static key.
The same Stateless Reset Token MAY be used for multiple connection The same Stateless Reset Token MUST NOT be used for multiple
IDs on the same connection. However, reuse of a Stateless Reset connection IDs. Endpoints are not required to compare new values
Token might expose an endpoint to denial of service if associated against all previous values, but a duplicate value MAY be treated as
connection IDs are forgotten while the associated token is still a connection error of type PROTOCOL_VIOLATION.
active at a peer. An endpoint MUST ensure that packets with
Destination Connection ID field values that correspond to a reused
Stateless Reset Token are attributed to the same connection as long
as the Stateless Reset Token is still usable, even when the
connection ID has been retired. Otherwise, an attacker might be able
to send a packet with a retired connection ID and cause the endpoint
to produce a Stateless Reset that it can use to disrupt the
connection, just as with the attacks in Section 21.9.
Note that Stateless Reset packets do not have any cryptographic Note that Stateless Reset packets do not have any cryptographic
protection. protection.
10.4.3. Looping 10.4.3. Looping
The design of a Stateless Reset is such that without knowing the The design of a Stateless Reset is such that without knowing the
stateless reset token it is indistinguishable from a valid packet. stateless reset token it is indistinguishable from a valid packet.
For instance, if a server sends a Stateless Reset to another server For instance, if a server sends a Stateless Reset to another server
it might receive another Stateless Reset in response, which could it might receive another Stateless Reset in response, which could
skipping to change at page 66, line 6 skipping to change at page 66, line 6
short header does not include a length, so it can only be the last short header does not include a length, so it can only be the last
packet included in a UDP datagram. An endpoint SHOULD NOT coalesce packet included in a UDP datagram. An endpoint SHOULD NOT coalesce
multiple packets at the same encryption level. multiple packets at the same encryption level.
Senders MUST NOT coalesce QUIC packets for different connections into Senders MUST NOT coalesce QUIC packets for different connections into
a single UDP datagram. Receivers SHOULD ignore any subsequent a single UDP datagram. Receivers SHOULD ignore any subsequent
packets with a different Destination Connection ID than the first packets with a different Destination Connection ID than the first
packet in the datagram. packet in the datagram.
Every QUIC packet that is coalesced into a single UDP datagram is Every QUIC packet that is coalesced into a single UDP datagram is
separate and complete. Though the values of some fields in the separate and complete. The receiver of coalesced QUIC packets MUST
packet header might be redundant, no fields are omitted. The individually process each QUIC packet and separately acknowledge
receiver of coalesced QUIC packets MUST individually process each them, as if they were received as the payload of different UDP
QUIC packet and separately acknowledge them, as if they were received datagrams. For example, if decryption fails (because the keys are
as the payload of different UDP datagrams. For example, if not available or any other reason), the receiver MAY either discard
decryption fails (because the keys are not available or any other or buffer the packet for later processing and MUST attempt to process
reason), the receiver MAY either discard or buffer the packet for the remaining packets.
later processing and MUST attempt to process the remaining packets.
Retry packets (Section 17.2.5), Version Negotiation packets Retry packets (Section 17.2.5), Version Negotiation packets
(Section 17.2.1), and packets with a short header (Section 17.3) do (Section 17.2.1), and packets with a short header (Section 17.3) do
not contain a Length field and so cannot be followed by other packets not contain a Length field and so cannot be followed by other packets
in the same UDP datagram. Note also that there is no situation where in the same UDP datagram. Note also that there is no situation where
a Retry or Version Negotiation packet is coalesced with another a Retry or Version Negotiation packet is coalesced with another
packet. packet.
12.3. Packet Numbers 12.3. Packet Numbers
skipping to change at page 71, line 40 skipping to change at page 71, line 40
load generated by a receiver that sends an ACK frame in response to load generated by a receiver that sends an ACK frame in response to
every ack-eliciting packet. The guidance offered below seeks to every ack-eliciting packet. The guidance offered below seeks to
strike this balance. strike this balance.
13.2.1. Sending ACK Frames 13.2.1. Sending ACK Frames
An ACK frame SHOULD be generated for at least every second ack- An ACK frame SHOULD be generated for at least every second ack-
eliciting packet. This recommendation is in keeping with standard eliciting packet. This recommendation is in keeping with standard
practice for TCP [RFC5681]. practice for TCP [RFC5681].
A receiver's delayed acknowledgment timer SHOULD NOT exceed the An endpoint MUST NOT excessively delay acknowledgements of ack-
current RTT estimate or the value it indicates in the "max_ack_delay" eliciting packets. An endpoint commits to a maximum delay using the
transport parameter. This ensures an acknowledgment is sent at least max_ack_delay transport parameter; see Section 18.2. max_ack_delay
once per RTT when packets needing acknowledgement are received. The declares an explicit contract: an endpoint promises to never delay
sender can use the receiver's "max_ack_delay" value in determining acknowledgments of an ack-eliciting packet by more than the indicated
timeouts for timer-based retransmission. value. If it does, any excess accrues to the RTT estimate and could
result in delayed retransmissions from the peer. For Initial and
Handshake packets, a max_ack_delay of 0 is used. The sender uses the
receiver's "max_ack_delay" value in determining timeouts for timer-
based retransmission, as detailed in Section 5.2.1 of
[QUIC-RECOVERY].
In order to assist loss detection at the sender, an endpoint SHOULD In order to assist loss detection at the sender, an endpoint SHOULD
send an ACK frame immediately on receiving an ack-eliciting packet send an ACK frame immediately on receiving an ack-eliciting packet
that is out of order. The endpoint MAY continue sending ACK frames that is out of order. The endpoint MAY continue sending ACK frames
immediately on each subsequently received packet, but the endpoint immediately on each subsequently received packet, but the endpoint
SHOULD return to acknowledging every other packet after a period of SHOULD return to acknowledging every other packet after a period of
1/8 x RTT, unless more ACK-eliciting packets are received out of 1/8 x RTT, unless more ack-eliciting packets are received out of
order. If every subsequent ACK-eliciting packet arrives out of order. If every subsequent ack-eliciting packet arrives out of
order, then an ACK frame SHOULD be sent immediately for every order, then an ACK frame SHOULD be sent immediately for every
received ACK-eliciting packet. received ack-eliciting packet.
Similarly, packets marked with the ECN Congestion Experienced (CE) Similarly, packets marked with the ECN Congestion Experienced (CE)
codepoint in the IP header SHOULD be acknowledged immediately, to codepoint in the IP header SHOULD be acknowledged immediately, to
reduce the peer's response time to congestion events. reduce the peer's response time to congestion events.
As an optimization, a receiver MAY process multiple packets before As an optimization, a receiver MAY process multiple packets before
sending any ACK frames in response. In this case the receiver can sending any ACK frames in response. In this case the receiver can
determine whether an immediate or delayed acknowledgement should be determine whether an immediate or delayed acknowledgement should be
generated after processing incoming packets. generated after processing incoming packets.
Acknowledgements of packets carrying CRYPTO frames SHOULD be
minimally delayed, to complete the handshake with minimal latency.
Delaying them by a small amount, such as the local timer granularity,
allows the endpoint to bundle any data sent in response with the ACK
frame. ACK frames SHOULD be sent immediately when the crypto stack
indicates all data for that packet number space has been received.
Packets containing PADDING frames are considered to be in flight for Packets containing PADDING frames are considered to be in flight for
congestion control purposes [QUIC-RECOVERY]. Sending only PADDING congestion control purposes [QUIC-RECOVERY]. Sending only PADDING
frames might cause the sender to become limited by the congestion frames might cause the sender to become limited by the congestion
controller (as described in [QUIC-RECOVERY]) with no acknowledgments controller (as described in [QUIC-RECOVERY]) with no acknowledgments
forthcoming from the receiver. Therefore, a sender SHOULD ensure forthcoming from the receiver. Therefore, a sender SHOULD ensure
that other frames are sent in addition to PADDING frames to elicit that other frames are sent in addition to PADDING frames to elicit
acknowledgments from the receiver. acknowledgments from the receiver.
An endpoint that is only sending ACK frames will not receive An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are acknowledgments from its peer unless those acknowledgements are
included in packets with ACK-eliciting frames. An endpoint SHOULD included in packets with ack-eliciting frames. An endpoint SHOULD
bundle ACK frames with other frames when there are new ACK-eliciting bundle ACK frames with other frames when there are new ack-eliciting
packets to acknowledge. When only non-ACK-eliciting packets need to packets to acknowledge. When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ACK-eliciting packet be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to bundle an ACK frame with outgoing frames. has been received to bundle an ACK frame with outgoing frames.
The algorithms in [QUIC-RECOVERY] are resilient to receivers that do The algorithms in [QUIC-RECOVERY] are resilient to receivers that do
not follow guidance offered above. However, an implementor should not follow guidance offered above. However, an implementor should
only deviate from these requirements after careful consideration of only deviate from these requirements after careful consideration of
the performance implications of doing so. the performance implications of doing so.
Packets containing only ACK frames are not congestion controlled, so Packets containing only ACK frames are not congestion controlled, so
there are limits on how frequently they can be sent. An endpoint there are limits on how frequently they can be sent. An endpoint
MUST NOT send more than one ACK-frame-only packet in response to MUST NOT send more than one ACK-frame-only packet in response to
receiving an ACK-eliciting packet (one containing frames other than receiving an ack-eliciting packet (one containing frames other than
ACK and/or PADDING). An endpoint MUST NOT send a packet containing ACK and/or PADDING). An endpoint MUST NOT send a packet containing
only an ACK frame in response to a non-ACK-eliciting packet (one only an ACK frame in response to a non-ack-eliciting packet (one
containing only ACK and/or PADDING frames), even if there are packet containing only ACK and/or PADDING frames), even if there are packet
gaps which precede the received packet. Limiting ACK frames avoids gaps which precede the received packet. Limiting ACK frames avoids
an infinite feedback loop of acknowledgements, which could prevent an infinite feedback loop of acknowledgements, which could prevent
the connection from ever becoming idle. However, the endpoint the connection from ever becoming idle. However, the endpoint
acknowledges non-ACK-eliciting packets when it sends an ACK frame. acknowledges non-ack-eliciting packets when it sends an ACK frame.
An endpoint SHOULD treat receipt of an acknowledgment for a packet it An endpoint SHOULD treat receipt of an acknowledgment for a packet it
did not send as a connection error of type PROTOCOL_VIOLATION, if it did not send as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition. is able to detect the condition.
13.2.2. Managing ACK Ranges 13.2.2. Managing ACK Ranges
When an ACK frame is sent, one or more ranges of acknowledged packets When an ACK frame is sent, one or more ranges of acknowledged packets
are included. Including older packets reduces the chance of spurious are included. Including older packets reduces the chance of spurious
retransmits caused by losing previously sent ACK frames, at the cost retransmits caused by losing previously sent ACK frames, at the cost
skipping to change at page 74, line 5 skipping to change at page 74, line 4
algorithm could cause spurious retransmits, but the sender will algorithm could cause spurious retransmits, but the sender will
continue making forward progress. continue making forward progress.
13.2.4. Limiting ACK Ranges 13.2.4. Limiting ACK Ranges
To limit ACK Ranges (see Section 19.3.1) to those that have not yet To limit ACK Ranges (see Section 19.3.1) to those that have not yet
been received by the sender, the receiver SHOULD track which ACK been received by the sender, the receiver SHOULD track which ACK
frames have been acknowledged by its peer. The receiver SHOULD frames have been acknowledged by its peer. The receiver SHOULD
exclude already acknowledged packets from future ACK frames whenever exclude already acknowledged packets from future ACK frames whenever
these packets would unnecessarily contribute to the ACK frame size. these packets would unnecessarily contribute to the ACK frame size.
When the receiver is only sending non-ACK-eliciting packets, it can
bundle a PING or other small ACK-eliciting frame with a fraction of When the receiver is only sending non-ack-eliciting packets, it can
bundle a PING or other small ack-eliciting frame with a fraction of
them, such as once per round trip, to enable dropping unnecessary ACK them, such as once per round trip, to enable dropping unnecessary ACK
ranges and any state for previously sent packets. The receiver MUST ranges and any state for previously sent packets. The receiver MUST
NOT bundle an ACK-eliciting frame, such as a PING, with all packets NOT bundle an ack-eliciting frame, such as a PING, with all packets
that would otherwise be non-ACK-eliciting, in order to avoid an that would otherwise be non-ack-eliciting, in order to avoid an
infinite feedback loop of acknowledgements. infinite feedback loop of acknowledgements.
To limit receiver state or the size of ACK frames, a receiver MAY To limit receiver state or the size of ACK frames, a receiver MAY
limit the number of ACK Ranges it sends. A receiver can do this even limit the number of ACK Ranges it sends. A receiver can do this even
without receiving acknowledgment of its ACK frames, with the without receiving acknowledgment of its ACK frames, with the
knowledge this could cause the sender to unnecessarily retransmit knowledge this could cause the sender to unnecessarily retransmit
some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare some data. Standard QUIC algorithms ([QUIC-RECOVERY]) declare
packets lost after sufficiently newer packets are acknowledged. packets lost after sufficiently newer packets are acknowledged.
Therefore, the receiver SHOULD repeatedly acknowledge newly received Therefore, the receiver SHOULD repeatedly acknowledge newly received
packets in preference to packets received in the past. packets in preference to packets received in the past.
13.2.5. Measuring and Reporting Host Delay 13.2.5. Measuring and Reporting Host Delay
An endpoint measures the delays intentionally introduced between when An endpoint measures the delays intentionally introduced between when
an ACK-eliciting packet is received and the corresponding an ack-eliciting packet is received and the corresponding
acknowledgment is sent. The endpoint encodes this delay for the acknowledgment is sent. The endpoint encodes this delay for the
largest acknowledged packet in the Ack Delay field of an ACK frame largest acknowledged packet in the Ack Delay field of an ACK frame
(see Section 19.3). This allows the receiver of the ACK to adjust (see Section 19.3). This allows the receiver of the ACK to adjust
for any intentional delays, which is important for getting a better for any intentional delays, which is important for getting a better
estimate of the path RTT when acknowledgments are delayed. A packet estimate of the path RTT when acknowledgments are delayed. A packet
might be held in the OS kernel or elsewhere on the host before being might be held in the OS kernel or elsewhere on the host before being
processed. An endpoint MUST NOT include delays that is does not processed. An endpoint MUST NOT include delays that is does not
control when populating the Ack Delay field in an ACK frame. control when populating the Ack Delay field in an ACK frame.
An endpoint MUST NOT excessively delay acknowledgements of ack-
eliciting packets. An endpoint commits to a maximum delay using the
max_ack_delay transport parameter; see Section 18.2. max_ack_delay
declares an explicit contract: an endpoint promises to never delay
acknowledgments of an ack-eliciting packet by more than the indicated
value. If it does, any excess accrues to the RTT estimate and could
result in delayed retransmissions from the peer. For Initial and
Handshake packets, a max_ack_delay of 0 is used.
13.2.6. ACK Frames and Packet Protection 13.2.6. ACK Frames and Packet Protection
ACK frames MUST only be carried in a packet that has the same packet ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being ACKed (see Section 12.1). For number space as the packet being ACKed (see Section 12.1). For
instance, packets that are protected with 1-RTT keys MUST be instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys. acknowledged in packets that are also protected with 1-RTT keys.
Packets that a client sends with 0-RTT packet protection MUST be Packets that a client sends with 0-RTT packet protection MUST be
acknowledged by the server in packets protected by 1-RTT keys. This acknowledged by the server in packets protected by 1-RTT keys. This
can mean that the client is unable to use these acknowledgments if can mean that the client is unable to use these acknowledgments if
skipping to change at page 114, line 10 skipping to change at page 114, line 10
| Token Length (i) ... | Token Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (*) ... | Token (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW_TOKEN frames contain the following fields: NEW_TOKEN frames contain the following fields:
Token Length: A variable-length integer specifying the length of the Token Length: A variable-length integer specifying the length of the
token in bytes. token in bytes.
Token: An opaque blob that the client may use with a future Initial Token: An opaque blob that the client may use with a future Initial
packet. packet. The token MUST NOT be empty. An endpoint MUST treat
receipt of a NEW_TOKEN frame with an empty Token field as a
connection error of type FRAME_ENCODING_ERROR.
An endpoint might receive multiple NEW_TOKEN frames that contain the An endpoint might receive multiple NEW_TOKEN frames that contain the
same token value. Endpoints are responsible for discarding duplicate same token value. Endpoints are responsible for discarding duplicate
values, which might be used to link connection attempts; see values, which might be used to link connection attempts; see
Section 8.1.2. Section 8.1.2.
Clients MUST NOT send NEW_TOKEN frames. Servers MUST treat receipt Clients MUST NOT send NEW_TOKEN frames. Servers MUST treat receipt
of a NEW_TOKEN frame as a connection error of type of a NEW_TOKEN frame as a connection error of type
PROTOCOL_VIOLATION. PROTOCOL_VIOLATION.
skipping to change at page 136, line 14 skipping to change at page 136, line 14
23.1. Normative References 23.1. Normative References
[DPLPMTUD] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08
(work in progress), June 2019. (work in progress), June 2019.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-23 (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-23 (work in progress). latest (work in progress).
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 137, line 50 skipping to change at page 137, line 50
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-07 (work in progress). draft-ietf-quic-invariants-latest (work in progress).
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-05 Transport Protocol", draft-ietf-quic-manageability-05
(work in progress), July 2019. (work in progress), July 2019.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
skipping to change at page 140, line 23 skipping to change at page 140, line 23
o Rules for preventing correlation by connection ID tightened o Rules for preventing correlation by connection ID tightened
(#2084, #2929) (#2084, #2929)
o Clarified use of CONNECTION_CLOSE in Handshake packets (#2151, o Clarified use of CONNECTION_CLOSE in Handshake packets (#2151,
#2541, #2688) #2541, #2688)
o Discourage regressions of largest acknowledged in ACK (#2205, o Discourage regressions of largest acknowledged in ACK (#2205,
#2752) #2752)
o Improved robusness of validation process for ECN counts (#2534, o Improved robustness of validation process for ECN counts (#2534,
#2752) #2752)
o Require endpoints to ignore spurious migration attempts (#2342, o Require endpoints to ignore spurious migration attempts (#2342,
#2893) #2893)
o Transport parameter for disabling migration clarified to allow NAT o Transport parameter for disabling migration clarified to allow NAT
rebinding (#2389, #2893) rebinding (#2389, #2893)
o Document principles for defining new error codes (#2388, #2880) o Document principles for defining new error codes (#2388, #2880)
skipping to change at page 140, line 46 skipping to change at page 140, line 46
o A maximum ACK delay of 0 is used for handshake packet number o A maximum ACK delay of 0 is used for handshake packet number
spaces (#2646, #2638) spaces (#2646, #2638)
o Improved rules for use of congestion control state on new paths o Improved rules for use of congestion control state on new paths
(#2685, #2918) (#2685, #2918)
o Removed recommendation to coordinate spin for multiple connections o Removed recommendation to coordinate spin for multiple connections
that share a path (#2763, #2882) that share a path (#2763, #2882)
o Allow smaller stateless resets and recommend a smaller minimum on o Allow smaller stateless resets and recommend a smaller minimum on
packets that might trigger a stateless reset (#2770, #2869, #2927) packets that might trigger a stateless reset (#2770, #2869, #2927,
#3007).
o Provide guidance around the interface to QUIC as used by o Provide guidance around the interface to QUIC as used by
application protocols (#2805, #2857) application protocols (#2805, #2857)
o Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825, o Frames other than STREAM can cause STREAM_LIMIT_ERROR (#2825,
#2826) #2826)
o Tighter rules about processing of rejected 0-RTT packets (#2829, o Tighter rules about processing of rejected 0-RTT packets (#2829,
#2840, #2841) #2840, #2841)
 End of changes. 42 change blocks. 
119 lines changed or deleted 119 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/