Draft: draft-ietf-quic-transport

Commentary: This breaks down some of the packet protection text in favour of more specific language about the protections provided . By preference , this talks about integrity protection and confidentiality protection as it relates to those packets that are protected using keys derived from TLS . For Initial packets this means avoid use of " packet protection " as much as possible ( I 'm sure that I have missed some of these ) . The same for Retry . This required some additional framing , but it was n't too intrusive . Most of the changes are cosmetic . ( I could maybe have split the exposition about initial secrets from this , but it would mean juggling conflicting changesets . ) 
 In Transport , we say : However , in TLS we have a section named " Packet Protection " ( Section 5 ) with subsections describing how to protect Initial ( 5.2 ) and Retry ( 5.8 ) packets which talk about Initial , at least , as using packet protection . I think it would be clearer to describe the lack of security properties that this limited form of protection provides , rather than say they 're not protected at all . Alternatively , we could rework the language in TLS , but that feels like a bigger terminology change . 
 ekr suggested that we limit the use of " integrity protection " ( and I presume " confidentiality protection " ) to those cases where the protection is real , and not based on fixed keys or trivially - acquired keys . I think that might be the best answer here , even if that takes more effort to get right . 
 : That sounds good like a good way forward . 
 a few nits
Paragraph (version A):
The endpoint initiating a QUIC connection.
Paragraph (version A):
The endpoint accepting incoming QUIC connections.
Paragraph (version A):
An opaque identifier that is used to identify a QUIC connection at
an endpoint.  Each endpoint sets a value for its peer to include
in packets sent towards the endpoint.
Paragraph (version B):
The endpoint that initiates a QUIC connection.
Paragraph (version B):
The endpoint that accepts a QUIC connection.
Paragraph (version B):
When used without qualification, the tuple of IP version, IP
address, and UDP port number that represents one end of a network
path.
Paragraph (version B):
An identifier that is used to identify a QUIC connection at an
endpoint.  Each endpoint selects one or more Connection IDs for
its peer to include in packets sent towards the endpoint.  This
value is opaque to the peer.
Paragraph (version B):
Packet and frame diagrams in this document use a custom format.  The
purpose of this format is to summarize, not define, protocol
elements.  Prose defines the complete semantics and details of
structures.
Paragraph (version B):
Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application.  Streams can be unidirectional or
bidirectional.
Paragraph (version A):
The least significant two bits from a stream ID therefore identify a
stream as one of four types, as summarized in stream-id-types.
Paragraph (version A):
Within each type, streams are created with numerically increasing
stream IDs.  A stream ID that is used out of order results in all
streams of that type with lower-numbered stream IDs also being
opened.
Paragraph (version A):
The first bidirectional stream opened by the client has a stream ID
of 0.
Paragraph (version B):
The two least significant bits from a stream ID therefore identify a
stream as one of four types, as summarized in stream-id-types.
Paragraph (version B):
reset the stream (abrupt termination), resulting in a RESET_STREAM
frame (frame-reset-stream) if the stream was not already in a
terminal state.
Paragraph (version A):
These states are largely informative.  This document uses stream
states to describe rules for when and how different types of
frames can be sent and the reactions that are expected when
different types of frames are received.  Though these state
machines are intended to be useful in implementing QUIC, these
states aren't intended to constrain implementations.  An
implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements
these states.
Paragraph (version B):
These state machines shown in this section are largely informative.
This document uses stream states to describe rules for when and how
different types of frames can be sent and the reactions that are
expected when different types of frames are received.  Though these
state machines are intended to be useful in implementing QUIC, these
states aren't intended to constrain implementations.  An
implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements these
states.
Paragraph (version B):
In some cases, a single event or action can cause a transition
through multiple states.  For instance, sending STREAM with a FIN
bit set can cause two state transitions for a sending stream: from
the Ready state to the Send state, and from the Send state to the
Data Sent state.
Paragraph (version B):
The receiving part of a stream initiated by a peer (types 1 and 3 for
a client, or 0 and 2 for a server) is created when the first STREAM,
STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that
stream.  For bidirectional streams initiated by a peer, receipt of a
MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the
stream also creates the receiving part.  The initial state for the
receiving part of a stream is "Recv".
Paragraph (version B):
It is possible that all stream data has already been received when a
RESET_STREAM is received (that is, in the "Data Recvd" state).
Similarly, it is possible for remaining stream data to arrive after
receiving a RESET_STREAM frame (the "Reset Recvd" state).  An
implementation is free to manage this situation as it chooses.
Paragraph (version B):
Senders MUST not send data in excess of either limit.
Paragraph (version A):
If a sender has sent data up to the limit, it will be unable to send
new data and is considered blocked.  A sender SHOULD send a
STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to
write but is blocked by flow control limits.  If a sender is blocked
for a period longer than the idle timeout (idle-timeout), the
connection might be closed even when data is available for
transmission.  To keep the connection from closing, a sender that is
flow control limited SHOULD periodically send a STREAM_DATA_BLOCKED
or DATA_BLOCKED frame when it has no ack-eliciting packets in flight.
Paragraph (version B):
If a sender has sent data up to the limit, it will be unable to send
new data and is considered blocked.  A sender SHOULD send a
STREAM_DATA_BLOCKED or DATA_BLOCKED frame to indicate it has data to
write but is blocked by flow control limits.  If a sender is blocked
for a period longer than the idle timeout (idle-timeout), the
receiver might close the connection even when the sender has data
that is available for transmission.  To keep the connection from
closing, a sender that is flow control limited SHOULD periodically
send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when it has no ack-
eliciting packets in flight.
Paragraph (version B):
On receipt of a RESET_STREAM frame, an endpoint will tear down state
for the matching stream and ignore further data arriving on that
stream.
Paragraph (version B):
An endpoint will know the final size for a stream when the receiving
part of the stream enters the "Size Known" or "Reset Recvd" state
(stream-states).  The receiver MUST use the final size of the stream
to account for all bytes sent on the stream in its connection level
flow controller.
Paragraph (version A):
An endpoint that is unable to open a new stream due to the peer's
limits SHOULD send a STREAMS_BLOCKED frame (frame-streams-blocked).
This signal is considered useful for debugging.  An endpoint MUST NOT
wait to receive this signal before advertising additional credit,
since doing so will mean that the peer will be blocked for at least
an entire round trip, and potentially for longer if the peer chooses
to not send STREAMS_BLOCKED frames.
Paragraph (version A):
QUIC's connection establishment combines version negotiation with the
cryptographic and transport handshakes to reduce connection
establishment latency, as described in handshake.  Once established,
a connection may migrate to a different IP or port at either endpoint
as described in migration.  Finally, a connection may be terminated
by either endpoint, as described in termination.
Paragraph (version B):
Sending timely updates of flow control limits can improve
performance.  Sending packets only to provide flow control updates
can increase network load and adversely affect performance.  Sending
flow control updates along with other frames, such as ACK frames,
reduces the cost of those updates.
Paragraph (version A):
A Version Negotiation (packet-version) packet echoes the connection
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
response to an Initial packet.
Paragraph (version B):
A Version Negotiation (packet-version) packet echoes the connection
IDs selected by the client, both to ensure correct routing toward the
client and to demonstrate that the packet is in response to a packet
sent by the client.
Paragraph (version A):
Additional connection IDs are communicated to the peer using
NEW_CONNECTION_ID frames (frame-new-connection-id).  The sequence
number on each newly-issued connection ID MUST increase by 1.  The
connection ID randomly selected by the client in the Initial packet
and any connection ID provided by a Retry packet are not assigned
sequence numbers unless a server opts to retain them as its initial
connection ID.
Paragraph (version B):
An endpoint that initiates migration and requires non-zero-length
connection IDs SHOULD ensure that the pool of connection IDs
available to its peer allows the peer to use a new connection ID on
migration, as the peer will be unable to respond if the pool is
exhausted.
Paragraph (version B):
Invalid packets that lack strong integrity protection, such as
Initial, Retry, or Version Negotiation, MAY be discarded.  An
endpoint MUST generate a connection error if processing the contents
of these packets prior to discovering an error resulted in changes to
connection state that cannot be reverted.
Paragraph (version B):
be informed when Early Data has been accepted or rejected by a
server.
Paragraph (version B):
Version negotiation allows a server to indicate that it does not
support the version the client used.  A server sends a Version
Negotiation packet in response to each packet that might initiate a
new connection; see packet-handling for details.
Paragraph (version A):
QUIC relies on a combined cryptographic and transport handshake to
minimize connection establishment latency.  QUIC uses the CRYPTO
frame frame-crypto to transmit the cryptographic handshake.  Version
0x00000001 of QUIC uses TLS as described in QUIC-TLS; a different
QUIC version number could indicate that a different cryptographic
handshake protocol is in use.
Paragraph (version B):
During the handshake, packets with the long header (long-header) are
used to establish the connection IDs used by both endpoints.  Each
endpoint uses the Source Connection ID field to specify the
connection ID that is used in the Destination Connection ID field of
packets being sent to them.  After processing the first Initial
packet, each endpoint sets the Destination Connection ID field in
subsequent packets it sends to the value of the Source Connection ID
field that it received.
Paragraph (version B):
When an Initial packet is sent by a client that has not previously
received an Initial or Retry packet from the server, the client
populates the Destination Connection ID field with an unpredictable
value.  This Destination Connection ID MUST be at least 8 bytes in
length.  Until a packet is received from the server, the client MUST
use the same Destination Connection ID value on all packets in this
connection.
Paragraph (version B):
The Destination Connection ID field from the first Initial packet
sent by a client is used to determine packet protection keys for
Initial packets.  These keys change after receiving a Retry packet;
see Section 5.2 of QUIC-TLS.
Paragraph (version B):
A client MUST change the Destination Connection ID it uses for
sending packets in response to only the first received Initial or
Retry packet.  A server MUST set the Destination Connection ID it
uses for sending packets based on the first received Initial packet.
Any further changes to the Destination Connection ID are only
permitted if the values are taken from NEW_CONNECTION_ID frames; if
subsequent Initial packets include a different Source Connection ID,
they MUST be discarded.  This avoids unpredictable outcomes that
might otherwise result from stateless processing of multiple Initial
packets with different Source Connection IDs.
Paragraph (version B):
Each endpoint includes the value of the Source Connection ID field
from the first Initial packet it sent in the
initial_source_connection_id transport parameter; see transport-
parameter-definitions.  A server includes the Destination Connection
ID field from the first Initial packet it received from the client in
the original_destination_connection_id transport parameter; if the
server sent a Retry packet, this refers to the first Initial packet
received before sending the Retry packet.  If it sends a Retry
packet, a server also includes the Source Connection ID field from
the Retry packet in the retry_source_connection_id transport
parameter.
Paragraph (version B):
QUIC includes the encoded transport parameters in the cryptographic
handshake.  Once the handshake completes, the transport parameters
declared by the peer are available.  Each endpoint validates the
values provided by its peer.
Paragraph (version B):
Using 0-RTT depends on both client and server using protocol
parameters that were negotiated from a previous connection.  To
enable 0-RTT, endpoints store the value of the server transport
parameters from a connection and apply them to any 0-RTT packets that
are sent in subsequent connections to that peer.  This information is
stored with any information required by the application protocol or
cryptographic handshake; see Section 4.6 of QUIC-TLS.
Paragraph (version B):
Remembered transport parameters apply to the new connection until the
handshake completes and the client starts sending 1-RTT packets.
Once the handshake completes, the client uses the transport
parameters established in the handshake.  Not all transport
parameters are remembered, as some do not apply to future connections
or they have no effect on use of 0-RTT.
Paragraph (version B):
The server uses the NEW_TOKEN frame (frame-new-token) to provide the
client with an address validation token that can be used to validate
future connections.  In a future connection, the client includes this
token in Initial packets to provide address validation.  The client
MUST include the token in all Initial packets it sends, unless a
Retry replaces the token with a newer one.  The client MUST NOT use
the token provided in a Retry for future connections.  Servers MAY
discard any Initial packet that does not carry the expected token.
Paragraph (version A):
Path validation is used during connection migration (see migration
and preferred-address) by the migrating endpoint to verify
reachability of a peer from a new local address.  In path validation,
endpoints test reachability between a specific local address and a
specific peer address, where an address is the two-tuple of IP
address and port.
Paragraph (version A):
An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that
are used for path validation with other frames.  In particular, an
endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU
discovery, or an endpoint may bundle a PATH_RESPONSE with its own
PATH_CHALLENGE.
Paragraph (version B):
An endpoint MAY include PATH_CHALLENGE and PATH_RESPONSE frames that
are used for path validation with other frames.  In particular, an
endpoint can pad a packet carrying a PATH_CHALLENGE for Path Maximum
Transfer Unit (PMTU) discovery (see pmtud), or an endpoint can
include a PATH_RESPONSE with its own PATH_CHALLENGE.
Paragraph (version A):
An endpoint MAY probe for peer reachability from a new local address
using path validation migrate-validate prior to migrating the
connection to the new local address.  Failure of path validation
simply means that the new path is not usable for this connection.
Failure to validate a path does not cause the connection to end
unless there are no valid alternative paths available.
Paragraph (version B):
An endpoint MAY probe for peer reachability from a new local address
using path validation (migrate-validate) prior to migrating the
connection to the new local address.  Failure of path validation
simply means that the new path is not usable for this connection.
Failure to validate a path does not cause the connection to end
unless there are no valid alternative paths available.
Paragraph (version A):
Receiving a PATH_CHALLENGE frame from a peer indicates that the peer
is probing for reachability on a path.  An endpoint sends a
PATH_RESPONSE in response as per migrate-validate.
Paragraph (version A):
Receiving acknowledgments for data sent on the new path serves as
proof of the peer's reachability from the new address.  Note that
since acknowledgments may be received on any path, return
reachability on the new path is not established.  No method is
provided to establish return reachability, as endpoints independently
determine reachability on each direction of a path.  To establish
reachability on the new path, an endpoint MAY concurrently initiate
path validation migrate-validate on the new path.  An endpoint MAY
defer path validation until after a peer sends the next non-probing
frame to its new address.
Paragraph (version B):
To establish reachability on the new path, an endpoint initiates path
validation (migrate-validate) on the new path.  An endpoint MAY defer
path validation until after a peer sends the next non-probing frame
to its new address.
Paragraph (version B):
Path validation is necessary to verify reachability of a peer on a
new network path.  Acknowledgments cannot be used for path validation
as they contain insufficient entropy and might be spoofed.  No method
is provided to establish return reachability, as endpoints
independently determine reachability on each direction of a path.
Paragraph (version A):
If an endpoint skips validation of a peer address as described in
migration-response, it does not need to limit its sending rate.
Paragraph (version B):
If an endpoint skips validation of a peer address as described above,
it does not need to limit its sending rate.
Paragraph (version A):
To protect the connection from failing due to such a spurious
migration, an endpoint MUST revert to using the last validated peer
address when validation of a new peer address fails.
Paragraph (version B):
To protect the connection from failing due to such a spurious
migration, an endpoint MUST revert to using the last validated peer
address when validation of a new peer address fails.  Additionally,
receipt of packets with higher packet numbers from the legitimate
peer address will trigger another connection migration.  This will
cause the validation of the address of the spurious migration to be
abandoned, thus containing migrations initiated by the attacker
injecting a single packet.
Paragraph (version A):
Note that receipt of packets with higher packet numbers from the
legitimate peer address will trigger another connection migration.
This will cause the validation of the address of the spurious
migration to be abandoned.
Paragraph (version B):
Using a stable connection ID on multiple network paths would allow a
passive observer to correlate activity between those paths.  An
endpoint that moves between networks might not wish to have their
activity correlated by any entity other than their peer, so different
connection IDs are used when sending from different local addresses,
as discussed in connection-id.  For this to be effective, endpoints
need to ensure that connection IDs they provide cannot be linked by
any other entity.
Paragraph (version B):
An endpoint SHOULD NOT initiate migration with a peer that has
requested a zero-length connection ID, because traffic over the new
path might be trivially linkable to traffic over the old one.  If the
server is able to associate packets with a zero-length connection ID
to the right connection, it means that the server is using other
information to demultiplex packets.  For example, a server might
provide a unique address to every client, for instance using HTTP
alternative services ALTSVC.  Information that might allow correct
routing of packets across multiple network paths will also allow
activity on those paths to be linked by entities other than the peer.
Paragraph (version A):
Migrating a connection to a new server address mid-connection is left
for future work.  If a client receives packets from a new server
address not indicated by the preferred_address transport parameter,
the client SHOULD discard these packets.
Paragraph (version B):
Once the handshake is confirmed, the client SHOULD select one of the
two addresses provided by the server and initiate path validation
(see migrate-validate).  A client constructs packets using any
previously unused active connection ID, taken from either the
preferred_address transport parameter or a NEW_CONNECTION_ID frame.
Paragraph (version B):
A server might receive a packet addressed to its preferred IP address
at any time after it accepts a connection.  If this packet contains a
PATH_CHALLENGE frame, the server sends a packet containing a
PATH_RESPONSE frame as per migrate-validate.  The server MUST send
non-probing packets from its original address until it receives a
non-probing packet from the client at its preferred address and until
the server has validated the new path.
Paragraph (version A):
If the connection to the server's preferred address is not from the
same client address, the server MUST protect against potential
attacks as described in address-spoofing and on-path-spoofing.  In
addition to intentional simultaneous migration, this might also occur
because the client's access network used a different NAT binding for
the server's preferred address.
Paragraph (version B):
If packets received at the server's preferred address have a
different source address than observed from the client during the
handshake, the server MUST protect against potential attacks as
described in address-spoofing and on-path-spoofing.  In addition to
intentional simultaneous migration, this might also occur because the
client's access network used a different NAT binding for the server's
preferred address.
Paragraph (version B):
Allowing retransmission of a closing packet is an exception to the
requirement that a new packet number be used for each packet in
packet-numbers.  Sending new packet numbers is primarily of
advantage to loss recovery and congestion control, which are not
expected to be relevant for a closed connection.  Retransmitting
the final packet requires less state.
Paragraph (version A):
A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header.  The remainder of the first byte
and an arbitrary number of bytes following it that are set to values
that SHOULD be indistinguishable from random.  The last 16 bytes of
the datagram contain a Stateless Reset Token.
Paragraph (version B):
A stateless reset uses an entire UDP datagram, starting with the
first two bits of the packet header.  The remainder of the first byte
and an arbitrary number of bytes following it are set to values that
SHOULD be indistinguishable from random.  The last 16 bytes of the
datagram contain a Stateless Reset Token.
Paragraph (version A):
The stateless reset token MUST be difficult to guess.  In order to
create a Stateless Reset Token, an endpoint could randomly generate
RFC4086 a secret for every connection that it creates.  However, this
presents a coordination problem when there are multiple instances in
a cluster or a storage problem for an endpoint that might lose state.
Stateless reset specifically exists to handle the case where state is
lost, so this approach is suboptimal.
Paragraph (version B):
Application-specific protocol errors are signaled using the
CONNECTION_CLOSE frame with a frame type of 0x1d.  Errors that are
specific to the transport, including all those described in this
document, are carried in the CONNECTION_CLOSE frame with a frame type
of 0x1c.
Paragraph (version B):
QUIC packets have different levels of cryptographic protection based
on the type of packet.  Details of packet protection are found in
QUIC-TLS; this section includes an overview of the protections that
are provided.
Paragraph (version B):
Version Negotiation packets have no cryptographic protection; see
QUIC-INVARIANTS.
Paragraph (version B):
Retry packets use an authenticated encryption with associated data
function (AEAD; AEAD) to protect against accidental modification.
Paragraph (version B):
All other packets are protected with keys derived from the
cryptographic handshake.  The cryptographic handshake ensures that
only the communicating endpoints receive the corresponding keys for
Handshake, 0-RTT, and 1-RTT packets.  Packets protected with 0-RTT
and 1-RTT keys have strong confidentiality and integrity protection.
Paragraph (version B):
The Packet Number field that appears in some packet types has
alternative confidentiality protection that is applied as part of
header protection; see Section 5.4 of QUIC-TLS for details.  The
underlying packet number increases with each packet sent in a given
packet number space; see packet-numbers for details.
Paragraph (version B):
Endpoints that track all individual packets for the purposes of
detecting duplicates are at risk of accumulating excessive state.
The data required for detecting duplicates can be limited by
maintaining a minimum packet number below which all packets are
immediately dropped.  Any minimum needs to account for large
variations in round trip time, which includes the possibility that a
peer might probe network paths with much larger round trip times; see
migration.
Paragraph (version B):
The Frame Type field uses a variable-length integer encoding (see
integer-encoding) with one exception.  To ensure simple and efficient
implementations of frame parsing, a frame type MUST use the shortest
possible encoding.  For frame types defined in this document, this
means a single-byte encoding, even though it is possible to encode
these values as a two-, four- or eight-byte variable-length integer.
For instance, though 0x4001 is a legitimate two-byte encoding for a
variable-length integer with a value of 1, PING frames are always
encoded as a single byte with the value 0x01.  This rule applies to
all current and future QUIC frame types.  An endpoint MAY treat the
receipt of a frame type that uses a longer encoding than necessary as
a connection error of type PROTOCOL_VIOLATION.
Paragraph (version B):
A sender sends one or more frames in a QUIC packet; see frames.
Paragraph (version A):
When sending a packet for any reason, an endpoint SHOULD attempt to
bundle an ACK frame if one has not been sent recently.  Doing so
helps with timely loss detection at the peer.
Paragraph (version B):
When sending a packet for any reason, an endpoint SHOULD attempt to
include an ACK frame if one has not been sent recently.  Doing so
helps with timely loss detection at the peer.
Paragraph (version B):
The algorithms in QUIC-RECOVERY are expected to be resilient to
receivers that do not follow the guidance offered above.  However, an
implementation should only deviate from these requirements after
careful consideration of the performance implications of a change,
for connections made by the endpoint and for other users of the
network.
Paragraph (version A):
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are
included in packets with ack-eliciting frames.  An endpoint SHOULD
bundle ACK frames with other frames when there are new ack-eliciting
packets to acknowledge.  When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to bundle an ACK frame with outgoing frames.
Paragraph (version B):
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgements are
included in packets with ack-eliciting frames.  An endpoint SHOULD
send an ACK frame with other frames when there are new ack-eliciting
packets to acknowledge.  When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to include an ACK frame with outgoing frames.
Paragraph (version B):
On the other hand, reducing the frequency of packets that carry only
acknowledgements reduces packet transmission and processing cost at
both endpoints.  It can improve connection throughput on severely
asymmetric links and reduce the volume of acknowledgment traffic
using return path capacity; see Section 3 of RFC3449.
Paragraph (version B):
When an ACK frame is sent, one or more ranges of acknowledged packets
are included.  Including acknowledgements for older packets reduces
the chance of spurious retransmissions caused by losing previously
sent ACK frames, at the cost of larger ACK frames.
Paragraph (version B):
In cases without ACK frame loss, this algorithm allows for a minimum
of 1 RTT of reordering.  In cases with ACK frame loss and reordering,
this approach does not guarantee that every acknowledgement is seen
by the sender before it is no longer included in the ACK frame.
Packets could be received out of order and all subsequent ACK frames
containing them could be lost.  In this case, the loss recovery
algorithm could cause spurious retransmissions, but the sender will
continue making forward progress.
Paragraph (version B):
A receiver that sends only non-ack-eliciting packets, such as ACK
frames, might not receive an acknowledgement for a long period of
time.  This could cause the receiver to maintain state for a large
number of ACK frames for a long period of time, and ACK frames it
sends could be unnecessarily large.  In such a case, a receiver could
send a PING or other small ack-eliciting frame occasionally, such as
once per round trip, to elicit an ACK from the peer.
Paragraph (version B):
A receiver MUST NOT send an ack-eliciting frame in all packets that
would otherwise be non-ack-eliciting, to avoid an infinite feedback
loop of acknowledgements.
Paragraph (version B):
ACK frames MUST only be carried in a packet that has the same packet
number space as the packet being acknowledged; see packet-protected.
For instance, packets that are protected with 1-RTT keys MUST be
acknowledged in packets that are also protected with 1-RTT keys.
Paragraph (version B):
ACK frames carry the most recent set of acknowledgements and the
Ack Delay from the largest acknowledged packet, as described in
sending-acknowledgements.  Delaying the transmission of packets
containing ACK frames or resending old ACK frames can cause the
peer to generate an inflated RTT sample or unnecessarily disable
ECN.
Paragraph (version A):
The current connection maximum data is sent in MAX_DATA frames.
An updated value is sent in a MAX_DATA frame if the packet
containing the most recently sent MAX_DATA frame is declared lost,
or when the endpoint decides to update the limit.  Care is
necessary to avoid sending this frame too often as the limit can
increase frequently and cause an unnecessarily large number of
MAX_DATA frames to be sent.
Paragraph (version B):
The current connection maximum data is sent in MAX_DATA frames.
An updated value is sent in a MAX_DATA frame if the packet
containing the most recently sent MAX_DATA frame is declared lost,
or when the endpoint decides to update the limit.  Care is
necessary to avoid sending this frame too often as the limit can
increase frequently and cause an unnecessarily large number of
MAX_DATA frames to be sent; see fc-credit.
Paragraph (version A):
Other versions of QUIC might have different properties to this
version.  The properties of QUIC that are guaranteed to be consistent
across all versions of the protocol are described in QUIC-INVARIANTS.
Paragraph (version B):
Other versions of QUIC might have different properties from this
version.  The properties of QUIC that are guaranteed to be consistent
across all versions of the protocol are described in QUIC-INVARIANTS.
Paragraph (version B):
The Destination Connection ID field follows the Destination
Connection ID Length field, which indicates the length of this
field.  negotiating-connection-ids describes the use of this field
in more detail.
Paragraph (version B):
The Source Connection ID field follows the Source Connection ID
Length field, which indicates the length of this field.
negotiating-connection-ids describes the use of this field in more
detail.
Paragraph (version B):
The header form bit, Destination and Source Connection ID lengths,
Destination and Source Connection ID fields, and Version fields of a
long header packet are version-independent.  The other fields in the
first byte are version-specific.  See QUIC-INVARIANTS for details on
how packets from different versions of QUIC are interpreted.
Paragraph (version B):
The packet number field is 1 to 4 bytes long.  The packet number
is protected using header protection; see Section 5.4 of QUIC-TLS.
The length of the packet number field is encoded in the Packet
Number Length bits of byte 0; see above.
Paragraph (version A):
The Initial packet contains a long header as well as the Length and
Packet Number fields.  The first byte contains the Reserved and
Packet Number Length bits.  Between the Source Connection ID and
Length fields, there are two additional fields specific to the
Initial packet.
Paragraph (version B):
The Initial packet contains a long header as well as the Length and
Packet Number fields; see long-header.  The first byte contains the
Reserved and Packet Number Length bits; see also long-header.
Between the Source Connection ID and Length fields, there are two
additional fields specific to the Initial packet.
Paragraph (version B):
The value of the token that was previously provided in a Retry
packet or NEW_TOKEN frame; see validate-handshake.
Paragraph (version B):
A 0-RTT packet uses long headers with a type value of 0x1, followed
by the Length and Packet Number fields; see long-header.  The first
byte contains the Reserved and Packet Number Length bits; see long-
header.  A 0-RTT packet is used to carry "early" data from the client
to the server as part of the first flight, prior to handshake
completion.  As part of the TLS handshake, the server can accept or
reject this early data.
Paragraph (version B):
A server SHOULD treat a violation of remembered limits (zerortt-
parameters) as a connection error of an appropriate type (for
instance, a FLOW_CONTROL_ERROR for exceeding stream data limits).
Paragraph (version B):
A Handshake packet uses long headers with a type value of 0x2,
followed by the Length and Packet Number fields; see long-header.
The first byte contains the Reserved and Packet Number Length bits;
see long-header.  It is used to carry cryptographic handshake
messages and acknowledgments from the server and client.
Paragraph (version B):
The Connection ID field and the Stateless Reset Token field
contain an alternative connection ID that has a sequence number of
1; see issue-cid.  Having these values sent alongside the
preferred address ensures that there will be at least one unused
active connection ID when the client initiates migration to the
preferred address.
Paragraph (version A):
Endpoints can use PING frames (type=0x01) to verify that their peers
are still alive or to check reachability to the peer.  As shown in
ping-format a PING frame contains no content.
Paragraph (version B):
When present, there are 3 ECN counts, as shown in ecn-count-format.
Paragraph (version B):
A variable-length integer indicating the final size of the stream
by the RESET_STREAM sender, in unit of bytes; see final-size.
Paragraph (version B):
All data sent in STREAM frames counts toward this limit.  The sum of
the largest received offsets on all streams - including streams in
terminal states - MUST NOT exceed the value advertised by a receiver.
An endpoint MUST terminate a connection with a FLOW_CONTROL_ERROR
error if it receives more data than the maximum data value that it
has sent.  This includes violations of remembered limits in Early
Data; see zerortt-parameters.
Paragraph (version B):
The data sent on a stream MUST NOT exceed the largest maximum stream
data value advertised by the receiver.  An endpoint MUST terminate a
connection with a FLOW_CONTROL_ERROR error if it receives more data
than the largest maximum stream data that it has sent for the
affected stream.  This includes violations of remembered limits in
Early Data; see zerortt-parameters.
Paragraph (version A):
An endpoint MUST NOT open more streams than permitted by the current
stream limit set by its peer.  For instance, a server that receives a
unidirectional stream limit of 3 is permitted to open stream 3, 7,
and 11, but not stream 15.  An endpoint MUST terminate a connection
with a STREAM_LIMIT_ERROR error if a peer opens more streams than was
permitted.
Paragraph (version B):
An endpoint MUST NOT open more streams than permitted by the current
stream limit set by its peer.  For instance, a server that receives a
unidirectional stream limit of 3 is permitted to open stream 3, 7,
and 11, but not stream 15.  An endpoint MUST terminate a connection
with a STREAM_LIMIT_ERROR error if a peer opens more streams than was
permitted.  This includes violations of remembered limits in Early
Data; see zerortt-parameters.
Paragraph (version B):
A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes
to send data, but is unable to do so due to connection-level flow
control; see flow-control.  DATA_BLOCKED frames can be used as input
to tuning of flow control algorithms; see fc-credit.
Paragraph (version A):
A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
wishes to send data, but is unable to due to stream-level flow
control.  This frame is analogous to DATA_BLOCKED (frame-data-
blocked).
Paragraph (version B):
A sender SHOULD send a STREAM_DATA_BLOCKED frame (type=0x15) when it
wishes to send data, but is unable to do so due to stream-level flow
control.  This frame is analogous to DATA_BLOCKED (frame-data-
blocked).
Paragraph (version A):
A variable-length integer indicating the stream which is flow
control blocked.
Paragraph (version B):
A sender SHOULD send a STREAMS_BLOCKED frame (type=0x16 or 0x17) when
it wishes to open a stream, but is unable to due to the maximum
stream limit set by its peer; see frame-max-streams.  A
STREAMS_BLOCKED frame of type 0x16 is used to indicate reaching the
bidirectional stream limit, and a STREAMS_BLOCKED frame of type 0x17
is used to indicate reaching the unidirectional stream limit.
Paragraph (version A):
The sequence number assigned to the connection ID by the sender.
See issue-cid.
Paragraph (version B):
The sequence number assigned to the connection ID by the sender,
encoded as a variable-length integer; see issue-cid.
Paragraph (version A):
Transmission errors, timeouts and retransmissions might cause the
same NEW_CONNECTION_ID frame to be received multiple times.  Receipt
of the same frame multiple times MUST NOT be treated as a connection
error.  A receiver can use the sequence number supplied in the
NEW_CONNECTION_ID frame to identify new connection IDs from old ones.
Paragraph (version B):
Transmission errors, timeouts and retransmissions might cause the
same NEW_CONNECTION_ID frame to be received multiple times.  Receipt
of the same frame multiple times MUST NOT be treated as a connection
error.  A receiver can use the sequence number supplied in the
NEW_CONNECTION_ID frame to handle receiving the same
NEW_CONNECTION_ID frame multiple times.
Paragraph (version A):
A variable length integer error code which indicates the reason
for closing this connection.  A CONNECTION_CLOSE frame of type
0x1c uses codes from the space defined in error-codes.  A
CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space; see app-error-codes.
Paragraph (version A):
A human-readable explanation for why the connection was closed.
This can be zero length if the sender chooses to not give details
beyond the Error Code.  This SHOULD be a UTF-8 encoded string
RFC3629.
Paragraph (version A):
An extension to QUIC that wishes to use a new type of frame MUST
first ensure that a peer is able to understand the frame.  An
endpoint can use a transport parameter to signal its willingness to
receive one or more extension frame types with the one transport
parameter.
Paragraph (version B):
An extension to QUIC that wishes to use a new type of frame MUST
first ensure that a peer is able to understand the frame.  An
endpoint can use a transport parameter to signal its willingness to
receive extension frame types.  One transport parameter can indicate
support for one or more extension frame types.
Paragraph (version A):
The attacks commonly known as Slowloris SLOWLORIS try to keep many
connections to the target endpoint open and hold them open as long as
possible.  These attacks can be executed against a QUIC endpoint by
generating the minimum amount of activity necessary to avoid being
closed for inactivity.  This might involve sending small amounts of
data, gradually opening flow control windows in order to control the
sender rate, or manufacturing ACK frames that simulate a high loss
rate.
Paragraph (version B):
The attacks commonly known as Slowloris (SLOWLORIS) try to keep many
connections to the target endpoint open and hold them open as long as
possible.  These attacks can be executed against a QUIC endpoint by
generating the minimum amount of activity necessary to avoid being
closed for inactivity.  This might involve sending small amounts of
data, gradually opening flow control windows in order to control the
sender rate, or manufacturing ACK frames that simulate a high loss
rate.
Paragraph (version A):
An adversarial endpoint can open lots of streams, exhausting state on
an endpoint.  The adversarial endpoint could repeat the process on a
large number of connections, in a manner similar to SYN flooding
attacks in TCP.
Paragraph (version B):
An adversarial endpoint can open a large number of streams,
exhausting state on an endpoint.  The adversarial endpoint could
repeat the process on a large number of connections, in a manner
similar to SYN flooding attacks in TCP.
Paragraph (version A):
If a packet can be routed to different instances that share a static
key, for example by changing an IP address or port, then an attacker
can cause the server to send a stateless reset.  To defend against
this style of denial service, endpoints that share a static key for
stateless reset (see reset-token) MUST be arranged so that packets
with a given connection ID always arrive at an instance that has
connection state, unless that connection is no longer active.
Paragraph (version A):
In the case of a cluster that uses dynamic load balancing, it's
possible that a change in load balancer configuration could occur
while an active instance retains connection state.  Even if an
instance retains connection state, the change in routing and
resulting stateless reset will result in the connection being
terminated.  If there is no chance in the packet being routed to the
correct instance in this new configuration, it is better to send a
stateless reset than wait for connections to time out.  However, this
is acceptable only if the routing cannot be influenced by an
attacker.
Paragraph (version B):
If a packet can be routed to different instances that share a static
key, for example by changing an IP address or port, then an attacker
can cause the server to send a stateless reset.  To defend against
this style of denial of service, endpoints that share a static key
for stateless reset (see reset-token) MUST be arranged so that
packets with a given connection ID always arrive at an instance that
has connection state, unless that connection is no longer active.
Paragraph (version B):
In the case of a cluster that uses dynamic load balancing, it is
possible that a change in load balancer configuration could occur
while an active instance retains connection state.  Even if an
instance retains connection state, the change in routing and
resulting stateless reset will result in the connection being
terminated.  If there is no chance of the packet being routed to the
correct instance, it is better to send a stateless reset than wait
for the connection to time out.  However, this is acceptable only if
the routing cannot be influenced by an attacker.
Paragraph (version B):
Address validation (address-validation) is used to verify that an
entity that claims a given address is able to receive packets at that
address.  Address validation limits amplification attack targets to
addresses for which an attacker can observe packets.
Paragraph (version B):
The entire handshake is cryptographically protected, with the Initial
packets being encrypted with per-version keys and the Handshake and
later packets being encrypted with keys derived from the TLS key
exchange.  Further, parameter negotiation is folded into the TLS
transcript and thus provides the same integrity guarantees as
ordinary TLS negotiation.  An attacker can observe the client's
transport parameters (as long as it knows the version-specific salt)
but cannot observe the server's transport parameters and cannot
influence parameter negotiation.
Paragraph (version B):
Permanent registrations in QUIC registries use the Specification
Required policy (RFC8126), unless otherwise specified.  The
designated expert(s) verify that a specification exists and is
readily accessible.  Expert(s) are encouraged to be biased towards
approving registrations unless they are abusive, frivolous, or
actively harmful (not merely aesthetically displeasing, or
architecturally dubious).  The creation of a registry MAY specify
additional constraints on permanent registrations.
Paragraph (version B):
All registrations in this document are assigned a permanent status
and list as contact the IETF (quic@ietf.org).
Paragraph (version B):
The "QUIC Transport Parameters" registry governs a 62-bit space.
This registry follows the registration policy from iana-policy.
Permanent registrations in this registry are assigned using the
Specification Required policy (RFC8126).
Paragraph (version B):
In addition to the advice in iana-policy, specifications for new
permanent registrations SHOULD describe the means by which an
endpoint might determine that it can send the identified type of
frame.  An accompanying transport parameter registration is expected
for most registrations; see iana-transport-parameters.
Specifications for permanent registrations also need to describe the
format and assigned semantics of any fields in the frame.