Draft: draft-ietf-quic-transport

Commentary: I made some proposed tweaks in my local copy as I was doing my IESG review . 
 I would like some help with the CI issues ( I do n't currently have a CircleCI account and would prefer to not have to read the T&C just for this pull request ) . 
 afaict the failure is simply line length . If you hard wrap everything to 80 characters all should be good . 
 ah , thanks . 
 said : 
 This is a part of , so I 'll leave that fixing this . 
 A couple of nits , which I 'll commit , but otherwise lgtm .
Paragraph (version B):
The QUIC handshake combines negotiation of cryptographic and
transport parameters.  QUIC integrates the TLS (TLS13) handshake,
although using a customized framing for protecting packets.  The
integration of TLS and QUIC is described in more detail in QUIC-TLS.
The handshake is structured to permit the exchange of application
data as soon as possible.  This includes an option for clients to
send data immediately (0-RTT), which requires some form of prior
communication or configuration to enable.
Paragraph (version B):
Endpoints communicate in QUIC by exchanging QUIC packets.  Most
packets contain frames, which carry control information and
application data between endpoints.  QUIC authenticates the entirety
of each packet and encrypts as much of each packet as is practical.
QUIC packets are carried in UDP datagrams (UDP) to better facilitate
deployment in existing systems and networks.
Paragraph (version A):
Accompanying documents describe QUIC's loss detection and congestion
control QUIC-RECOVERY, and the use of TLS for key negotiation QUIC-
TLS.
Paragraph (version B):
Accompanying documents describe QUIC's loss detection and congestion
control QUIC-RECOVERY, and the use of TLS and other cryptographic
mechanisms QUIC-TLS.
Paragraph (version B):
Unidirectional streams use either the sending or receiving state
machine depending on the stream type and endpoint role.
Bidirectional streams use both state machines at both endpoints.  For
the most part, the use of these state machines is the same whether
the stream is unidirectional or bidirectional.  The conditions for
opening a stream are slightly more complex for a bidirectional stream
because the opening of either the send or receive side causes the
stream to open in both directions.
Paragraph (version A):
In the "Send" state, an endpoint transmits - and retransmits as
necessary - stream data in STREAM frames.  The endpoint respects the
flow control limits set by its peer, and continues to accept and
process MAX_STREAM_DATA frames.  An endpoint in the "Send" state
generates STREAM_DATA_BLOCKED frames if it is blocked from sending by
stream flow control limits data-flow-control.
Paragraph (version B):
In the "Send" state, an endpoint transmits - and retransmits as
necessary - stream data in STREAM frames.  The endpoint respects the
flow control limits set by its peer, and continues to accept and
process MAX_STREAM_DATA frames.  An endpoint in the "Send" state
generates STREAM_DATA_BLOCKED frames if it is blocked from sending by
stream flow control limits (data-flow-control).
Paragraph (version B):
For a bidirectional stream, the receiving part enters the "Recv"
state when the sending part initiated by the endpoint (type 0 for a
client, type 1 for a server) enters the "Ready" state.
Paragraph (version B):
An endpoint SHOULD copy the error code from the STOP_SENDING frame to
the RESET_STREAM frame it sends, but can use any application error
code.  An endpoint that sends a STOP_SENDING frame MAY ignore the
error code in any RESET_STREAM frames subsequently received for that
stream.
Paragraph (version A):
Stream flow control, which prevents a single stream from consuming
the entire receive buffer for a connection by limiting the amount
of data that can be sent on any stream.
Paragraph (version B):
Stream flow control, which prevents a single stream from consuming
the entire receive buffer for a connection by limiting the amount
of data that can be sent on each stream.
Paragraph (version B):
Once a receiver advertises a limit for the connection or a stream, it
is not an error to advertise a smaller limit, but the smaller limit
has no effect.
Paragraph (version B):
Multiple connection IDs are used so that endpoints can send packets
that cannot be identified by an observer as being for the same
connection without cooperation from an endpoint; see migration-
linkability.
Paragraph (version B):
A zero-length connection ID can be used when a connection ID is not
needed to route to the correct endpoint.  However, multiplexing
connections on the same local IP address and port while using zero-
length connection IDs will cause failures in the presence of peer
connection migration, NAT rebinding, and client port reuse.  An
endpoint MUST NOT use the same IP address and port for multiple
concurrent connections with zero-length connection IDs, unless it is
certain that those protocol features are not in use.
Paragraph (version A):
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, unless it fully
reverts these changes.
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, or fully revert any
changes made during that processing.
Paragraph (version B):
If a server receives a packet that indicates an unsupported version
and if the packet is large enough to initiate a new connection for
any supported version, the server SHOULD send a Version Negotiation
packet as described in send-vn.  A server MAY limit the number of
packets to which it responds with a Version Negotiation packet.
Servers MUST drop smaller packets that specify unsupported versions.
Paragraph (version B):
Version Negotiation packets are designed to allow for functionality
to be defined in the future that allows QUIC to negotiate the version
of QUIC to use for a connection.  Future standards-track
specifications might change how implementations that support multiple
versions of QUIC react to Version Negotiation packets received in
response to an attempt to establish a connection using this version.
Paragraph (version B):
How to perform version negotiation is left as future work defined by
future standards-track specifications.  In particular, that future
work will ensure robustness against version downgrade attacks; see
version-downgrade.
Paragraph (version B):
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.  The
version of QUIC defined in this document is identified as 0x00000001
and uses TLS as described in QUIC-TLS; a different QUIC version could
indicate that a different cryptographic handshake protocol is in use.
Paragraph (version A):
fig-hs shows a simplified handshake and the exchange of packets and
frames that are used to advance the handshake.  Exchange of
application data during the handshake is enabled where possible,
shown with a '*'.  Once completed, endpoints are able to exchange
application data.
Paragraph (version B):
fig-hs shows a simplified handshake and the exchange of packets and
frames that are used to advance the handshake.  Exchange of
application data during the handshake is enabled where possible,
shown with a '*'.  Once the handshake is complete, endpoints are able
to exchange application data freely.
Paragraph (version B):
Endpoints can use packets sent during the handshake to test for
Explicit Congestion Notification (ECN) support; see ecn.  An endpoint
validates support for ECN by observing whether the ACK frames
acknowledging the first packets it sends carry ECN counts, as
described in ecn-validation.
Paragraph (version A):
Upon first receiving an Initial or Retry packet from the server, the
client uses the Source Connection ID supplied by the server as the
Destination Connection ID for subsequent packets, including any 0-RTT
packets.  This means that a client might have to change the
connection ID it sets in the Destination Connection ID field twice
during connection establishment: once in response to a Retry, and
once in response to an Initial packet from the server.  Once a client
has received a valid Initial packet from the server, it MUST discard
any subsequent packet it receives with a different Source Connection
ID.
Paragraph (version B):
Upon first receiving an Initial or Retry packet from the server, the
client uses the Source Connection ID supplied by the server as the
Destination Connection ID for subsequent packets, including any 0-RTT
packets.  This means that a client might have to change the
connection ID it sets in the Destination Connection ID field twice
during connection establishment: once in response to a Retry, and
once in response to an Initial packet from the server.  Once a client
has received a valid Initial packet from the server, it MUST discard
any subsequent packet it receives on that connection with a different
Source Connection ID.
Paragraph (version A):
The values provided by a peer for these transport parameters MUST
match the values that an endpoint used in the Destination and Source
Connection ID fields of Initial packets that it sent.  Including
connection ID values in transport parameters and verifying them
ensures that that an attacker cannot influence the choice of
connection ID for a successful connection by injecting packets
carrying attacker-chosen connection IDs during the handshake.
Paragraph (version B):
The values provided by a peer for these transport parameters MUST
match the values that an endpoint used in the Destination and Source
Connection ID fields of Initial packets that it sent (and received,
for servers).  Endpoints MUST validate that received transport
parameters match received Connection ID values.  Including connection
ID values in transport parameters and verifying them ensures that
that an attacker cannot influence the choice of connection ID for a
successful connection by injecting packets carrying attacker-chosen
connection IDs during the handshake.
Paragraph (version A):
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):
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 that use a session
ticket issued on that connection.  This information is stored with
any information required by the application protocol or cryptographic
handshake; see Section 4.6 of QUIC-TLS.
Paragraph (version A):
A client that does not understand a transport parameter can discard
it and attempt 0-RTT on subsequent connections.  However, if the
client adds support for a discarded transport parameter, it risks
violating the constraints that the transport parameter establishes if
it attempts 0-RTT.  New transport parameters can avoid this problem
by setting a default of the most conservative value.
Paragraph (version B):
A client that does not understand a transport parameter can discard
it and attempt 0-RTT on subsequent connections.  However, if the
client adds support for a discarded transport parameter, it risks
violating the constraints that the transport parameter establishes if
it attempts 0-RTT.  New transport parameters can avoid this problem
by setting a default of the most conservative value.  Clients can
avoid this problem by remembering all parameters, even ones not
currently supported.
Paragraph (version B):
A token sent in a NEW_TOKEN frame or a Retry packet MUST be
constructed in a way that allows the server to identify how it was
provided to a client.  These tokens are carried in the same field,
but require different handling from servers.
Paragraph (version B):
A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server can
discard tokens provided using the NEW_TOKEN frame.  In comparison, a
token obtained in a Retry packet MUST be used immediately during the
connection attempt and cannot be used in subsequent connection
attempts.
Paragraph (version B):
When a server receives an Initial packet with an address validation
token, it MUST attempt to validate the token, unless it has already
completed address validation.  If the token is invalid then the
server SHOULD proceed as if the client did not have a validated
address, including potentially sending a Retry.  Tokens provided with
NEW_TOKEN frames and Retry packets can be distinguished by servers
(see token-differentiation), and the latter validated more strictly.
If the validation succeeds, the server SHOULD then allow the
handshake to proceed.
Paragraph (version A):
An address validation token MUST be difficult to guess.  Including a
large enough random value in the token would be sufficient, but this
depends on the server remembering the value it sends to clients.
Paragraph (version B):
An address validation token MUST be difficult to guess.  Including a
random value with at least 128 bits of entropy in the token would be
sufficient, but this depends on the server remembering the value it
sends to clients.
Paragraph (version B):
Attackers could replay tokens to use servers as amplifiers in DDoS
attacks.  To protect against such attacks, servers MUST ensure that
replay of tokens is prevented or limited.  Servers SHOULD ensure that
tokens sent in Retry packets are only accepted for a short time, as
they are returned immediately by clients.  Tokens that are provided
in NEW_TOKEN frames (frame-new-token) need to be valid for longer,
but SHOULD NOT be accepted multiple times.  Servers are encouraged to
allow tokens to be used only once, if possible; tokens MAY include
additional information about clients to further narrow applicability
or reuse.
Paragraph (version B):
If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not
expanded to at least 1200 bytes, and if the response to it validates
the peer address, the path is validated but not the path MTU.  As a
result, the endpoint can now send more than three times the amount of
data that has been received.  However, the endpoint MUST initiate
another path validation with an expanded datagram to verify that the
path supports the required MTU.
Paragraph (version A):
An endpoint could also use heuristics to improve detection of this
style of attack.  For instance, NAT rebinding is improbable if
packets were recently received on the old path, similarly rebinding
is rare on IPv6 paths.  Endpoints can also look for duplicated
packets.  Conversely, a change in connection ID is more likely to
indicate an intentional migration rather than an attack.
Paragraph (version B):
An endpoint could also use heuristics to improve detection of this
style of attack.  For instance, NAT rebinding is improbable if
packets were recently received on the old path; similarly, rebinding
is rare on IPv6 paths.  Endpoints can also look for duplicated
packets.  Conversely, a change in connection ID is more likely to
indicate an intentional migration rather than an attack.
Paragraph (version A):
A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period
of inactivity.  Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection
migration.  This ensures that the mechanisms that support migration
are exercised even for clients that do not experience NAT rebindings
or genuine migrations.  Changing port number can cause a peer to
reset its congestion state (see migration-cc), so the port SHOULD
only be changed infrequently.
Paragraph (version B):
A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period
of inactivity.  Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection
migration.  This ensures that the mechanisms that support migration
are exercised even for clients that do not experience NAT rebindings
or genuine migrations.  Changing port number can cause a peer to
reset its congestion control state (see migration-cc), so the port
SHOULD only be changed infrequently.
Paragraph (version A):
Once the server has completed its path validation and has received a
non-probing packet with a new largest packet number on its preferred
address, the server begins sending non-probing packets to the client
exclusively from its preferred IP address.  It SHOULD drop packets
for this connection received on the old IP address, but MAY continue
to process delayed packets.
Paragraph (version B):
Once the server has completed its path validation and has received a
non-probing packet with a new largest packet number on its preferred
address, the server begins sending non-probing packets to the client
exclusively from its preferred IP address.  The server SHOULD drop
newer packets for this connection that are received on the old IP
address.  The server MAY continue to process delayed packets that are
received on the old IP address.
Paragraph (version B):
Each endpoint advertises a max_idle_timeout, but the effective value
at an endpoint is computed as the minimum of the two advertised
values (or the sole advertised value, if only one endpoint advertises
a nonzero value).  By announcing a max_idle_timeout, an endpoint
commits to initiating an immediate close (immediate-close) if it
abandons the connection prior to the effective value.
Paragraph (version B):
An endpoint MAY enter the draining state from the closing state if it
receives a CONNECTION_CLOSE frame, which indicates that the peer is
also closing or draining.  In this case, the draining state ends when
the closing state would have ended.  In other words, the endpoint
uses the same end time, but ceases transmission of any packets on
this connection.
Paragraph (version A):
A single static key can be used across all connections to the same
endpoint by generating the proof using a second iteration of a
preimage-resistant function that takes a static key and the
connection ID chosen by the endpoint (see connection-id) as input.
An endpoint could use HMAC RFC2104 (for example, HMAC(static_key,
connection_id)) or HKDF RFC5869 (for example, using the static key as
input keying material, with the connection ID as salt).  The output
of this function is truncated to 16 bytes to produce the Stateless
Reset Token for that connection.
Paragraph (version B):
The stateless reset token MUST be difficult to guess.  In order to
create a Stateless Reset Token, an endpoint could randomly generate
(RANDOM) 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):
A single static key can be used across all connections to the same
endpoint by generating the proof using a pseudorandom function that
takes a static key and the connection ID chosen by the endpoint (see
connection-id) as input.  An endpoint could use HMAC RFC2104 (for
example, HMAC(static_key, connection_id)) or HKDF RFC5869 (for
example, using the static key as input keying material, with the
connection ID as salt).  The output of this function is truncated to
16 bytes to produce the Stateless Reset Token for that connection.
Paragraph (version A):
An endpoint that chooses not to retransmit packets containing a
CONNECTION_CLOSE frame risks a peer missing the first such packet.
The only mechanism available to an endpoint that continues to receive
data for a terminated connection is to use the stateless reset
process (stateless-reset).
Paragraph (version B):
An endpoint that chooses not to retransmit packets containing a
CONNECTION_CLOSE frame risks a peer missing the first such packet.
The only mechanism available to an endpoint that continues to receive
data for a terminated connection is to attempt the stateless reset
process (stateless-reset).
Paragraph (version A):
Application data space: All 0-RTT (packet-0rtt) and 1-RTT (packet-
1rtt) encrypted packets are in this space.
Paragraph (version B):
Application data space: All 0-RTT (packet-0rtt) and 1-RTT (packet-
1rtt) packets are in this space.
Paragraph (version B):
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
is able to detect the condition.  Further discussion of how this
might be achieved is in optimistic-ack-attack.
Paragraph (version B):
This requirement to support a UDP payload of 1200 bytes limits the
space available for IPv6 extension headers to 32 bytes or IPv4
options to 52 bytes if the path only supports the IPv6 minimum MTU
of 1280 bytes.  This affects Initial packets and path validation.
Paragraph (version B):
If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses cannot support the smallest allowed maximum
datagram size of 1200 bytes, it MUST immediately cease sending QUIC
packets, except for those in PMTU probes or those containing
CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY
terminate the connection if an alternative path cannot be found.
Paragraph (version B):
Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201)
relies on reception of ICMP messages (e.g., IPv6 Packet Too Big
messages) that indicate when an IP packet is dropped because it is
larger than the local router MTU.  DPLPMTUD can also optionally use
these messages.  This use of ICMP messages is potentially vulnerable
to attacks by entities that cannot observe packets but might
successfully guess the addresses used on the path.  These attacks
could reduce the PMTU to a bandwidth-inefficient value.
Paragraph (version B):
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
from packet injection as specified in RFC8201 and Section 5.2 of
RFC8085.  This validation SHOULD use the quoted packet supplied in
the payload of an ICMP message to associate the message with a
corresponding transport connection (see Section 4.6.1 of DPLPMTUD).
ICMP message validation MUST include matching IP addresses and UDP
ports (RFC8085) and, when possible, connection IDs to an active QUIC
session.  The endpoint SHOULD ignore all ICMP messages that fail
validation.
Paragraph (version A):
This means that integers are encoded on 1, 2, 4, or 8 bytes and can
encode 6, 14, 30, or 62 bit values respectively.  integer-summary
summarizes the encoding properties.
Paragraph (version B):
Values do not need to be encoded on the minimum number of bytes
necessary, with the sole exception of the Frame Type field; see
frames.
Paragraph (version A):
At a receiver, protection of the packet number is removed prior to
recovering the full packet number.  The full packet number is then
reconstructed based on the number of significant bits present, the
value of those bits, and the largest packet number received on a
successfully authenticated packet.  Recovering the full packet number
is necessary to successfully remove packet protection.
Paragraph (version B):
At a receiver, protection of the packet number is removed prior to
recovering the full packet number.  The full packet number is then
reconstructed based on the number of significant bits present, the
value of those bits, and the largest packet number received in a
successfully authenticated packet.  Recovering the full packet number
is necessary to successfully remove packet protection.
Paragraph (version B):
The semantics of the lower four bits (those with a mask of 0x0f)
of byte 0 are determined by the packet type.
Paragraph (version A):
The server MUST include the value from the Source Connection ID field
of the packet it receives in the Destination Connection ID field.
The value for Source Connection ID MUST be copied from the
Destination Connection ID of the received packet, which is initially
randomly selected by a client.  Echoing both connection IDs gives
clients some assurance that the server received the packet and that
the Version Negotiation packet was not generated by an off-path
attacker.
Paragraph (version B):
The server MUST include the value from the Source Connection ID field
of the packet it receives in the Destination Connection ID field.
The value for Source Connection ID MUST be copied from the
Destination Connection ID of the received packet, which is initially
randomly selected by a client.  Echoing both connection IDs gives
clients some assurance that the server received the packet and that
the Version Negotiation packet was not generated by an entity that
did not observe the Initial packet.
Paragraph (version A):
In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys
(Initial keys) as described in QUIC-TLS.  This protection does not
provide confidentiality or integrity against on-path attackers, but
provides some level of protection against off-path attackers.
Paragraph (version B):
In order to prevent tampering by version-unaware middleboxes, Initial
packets are protected with connection- and version-specific keys
(Initial keys) as described in QUIC-TLS.  This protection does not
provide confidentiality or integrity against attackers that can
observe packets, but provides some level of protection against
attackers that cannot observe packets.
Paragraph (version B):
A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete, as defined in Section 4.1.1 of QUIC-TLS.
Paragraph (version B):
Clients MUST discard Retry packets that have a Retry Integrity Tag
that cannot be validated; see the Retry Packet Integrity section of
QUIC-TLS.  This diminishes an attacker's ability to inject a Retry
packet and protects against accidental corruption of Retry packets.
A client MUST discard a Retry packet with a zero-length Retry Token
field.
Paragraph (version A):
The packet number field is 1 to 4 bytes long.  The packet number
has confidentiality protection separate from packet protection, as
described in Section 5.4 of QUIC-TLS.  The length of the packet
number field is encoded in Packet Number Length field.  See
packet-encoding for details.
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 Packet Number
Length field.  See packet-encoding for details.
Paragraph (version B):
The spin bit is an OPTIONAL feature of this version of QUIC.  An
endpoint that does not support this feature MUST disable it, as
defined below.
Paragraph (version B):
Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection.  Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on
a per-connection basis.  Even when the spin bit is not disabled by
the administrator, endpoints MUST disable their use of the spin bit
for a random selection of at least one in every 16 network paths, or
for one in every 16 connection IDs, in order to ensure that QUIC
connections that disable the spin bit are commonly observed on the
network.  As each endpoint disables the spin bit independently, this
ensures that the spin bit signal is disabled on approximately one in
eight network paths.
Paragraph (version A):
The initial maximum bidirectional streams parameter is an integer
value that contains the initial maximum number of bidirectional
streams the peer is permitted to initiate.  If this parameter is
absent or zero, the peer cannot open bidirectional streams until a
MAX_STREAMS frame is sent.  Setting this parameter is equivalent
to sending a MAX_STREAMS (frame-max-streams) of the corresponding
type with the same value.
Paragraph (version A):
The initial maximum unidirectional streams parameter is an integer
value that contains the initial maximum number of unidirectional
streams the peer is permitted to initiate.  If this parameter is
absent or zero, the peer cannot open unidirectional streams until
a MAX_STREAMS frame is sent.  Setting this parameter is equivalent
to sending a MAX_STREAMS (frame-max-streams) of the corresponding
type with the same value.
Paragraph (version B):
The initial maximum bidirectional streams parameter is an integer
value that contains the initial maximum number of bidirectional
streams the endpoint that receives this transport parameter is
permitted to initiate.  If this parameter is absent or zero, the
peer cannot open bidirectional streams until a MAX_STREAMS frame
is sent.  Setting this parameter is equivalent to sending a
MAX_STREAMS (frame-max-streams) of the corresponding type with the
same value.
Paragraph (version B):
The initial maximum unidirectional streams parameter is an integer
value that contains the initial maximum number of unidirectional
streams the endpoint that receives this transport parameter is
permitted to initiate.  If this parameter is absent or zero, the
peer cannot open unidirectional streams until a MAX_STREAMS frame
is sent.  Setting this parameter is equivalent to sending a
MAX_STREAMS (frame-max-streams) of the corresponding type with the
same value.
Paragraph (version A):
The disable active migration transport parameter is included if
the endpoint does not support active connection migration
(migration) on the address being used during the handshake.  When
a peer sets this transport parameter, an endpoint MUST NOT use a
new local address when sending to the address that the peer used
during the handshake.  This transport parameter does not prohibit
connection migration after a client has acted on a
preferred_address transport parameter.  This parameter is a zero-
length value.
Paragraph (version B):
The disable active migration transport parameter is included if
the endpoint does not support active connection migration
(migration) on the address being used during the handshake.  An
endpoint that receives this transport parameter MUST NOT use a new
local address when sending to the address that the peer used
during the handshake.  This transport parameter does not prohibit
connection migration after a client has acted on a
preferred_address transport parameter.  This parameter is a zero-
length value.
Paragraph (version B):
The server's preferred address is used to effect a change in
server address at the end of the handshake, as described in
preferred-address.  This transport parameter is only sent by a
server.  Servers MAY choose to only send a preferred address of
one address family by sending an all-zero address and port
(0.0.0.0:0 or [::]:0) for the other family.  IP addresses are
encoded in network byte order.
Paragraph (version A):
If present, transport parameters that set initial flow control limits
(initial_max_stream_data_bidi_local,
initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni)
are equivalent to sending a MAX_STREAM_DATA frame (frame-max-stream-
data) on every stream of the corresponding type immediately after
opening.  If the transport parameter is absent, streams of that type
start with a flow control limit of 0.
Paragraph (version B):
If present, transport parameters that set initial per-stream flow
control limits (initial_max_stream_data_bidi_local,
initial_max_stream_data_bidi_remote, and initial_max_stream_data_uni)
are equivalent to sending a MAX_STREAM_DATA frame (frame-max-stream-
data) on every stream of the corresponding type immediately after
opening.  If the transport parameter is absent, streams of that type
start with a flow control limit of 0.
Paragraph (version B):
Receivers send ACK frames (types 0x02 and 0x03) to inform senders of
packets they have received and processed.  The ACK frame contains one
or more ACK Ranges.  ACK Ranges identify acknowledged packets.  If
the frame type is 0x03, ACK frames also contain the cumulative count
of QUIC packets with associated ECN marks received on the connection
up until this point.  QUIC implementations MUST properly handle both
types and, if they have enabled ECN for packets they send, they
SHOULD use the information in the ECN section to manage their
congestion state.
Paragraph (version B):
A variable-length integer specifying the number of ACK Range
fields in the frame.
Paragraph (version B):
A variable-length integer indicating the number of contiguous
packets preceding the Largest Acknowledged that are being
acknowledged.  That is, the smallest packet acknowledged in the
range is determined by subtracting the First ACK Range value from
the Largest Acknowledged.
Paragraph (version B):
Each ACK Range consists of alternating Gap and ACK Range Length
values in descending packet number order.  ACK Ranges can be
repeated.  The number of Gap and ACK Range Length values is
determined by the ACK Range Count field; one of each value is present
for each value in the ACK Range Count field.
Paragraph (version B):
Gap and ACK Range Length values use a relative integer encoding for
efficiency.  Though each encoded value is positive, the values are
subtracted, so that each ACK Range describes progressively lower-
numbered packets.
Paragraph (version B):
The largest value for an ACK Range is determined by cumulatively
subtracting the size of all preceding ACK Range Lengths and Gaps.
Paragraph (version B):
The ACK frame uses the least significant bit of the type value (that
is, type 0x03) to indicate ECN feedback and report receipt of QUIC
packets with associated ECN codepoints of ECT(0), ECT(1), or CE in
the packet's IP header.  ECN Counts are only present when the ACK
frame type is 0x03.
Paragraph (version B):
Additional diagnostic information for the closure.  This can be
zero length if the sender chooses not to give details beyond the
Error Code.  This SHOULD be a UTF-8 encoded string RFC3629, though
the frame does not carry information, such as language tags, that
would aid comprehension by any entity other than the one that
created the text.
Paragraph (version A):
An endpoint received transport parameters that were badly
formatted, included an invalid value, was absent even though it is
mandatory, was present though it is forbidden, or is otherwise in
error.
Paragraph (version B):
An endpoint received transport parameters that were badly
formatted, included an invalid value, omitted a mandatory
transport parameter, included a forbidden transport parameter, or
were otherwise in error.
Paragraph (version B):
Attackers are additionally categorized as either on-path attackers or
off-path attackers.  An on-path attacker can read, modify, or remove
any packet it observes such that it no longer reaches its
destination, while an off-path attacker observes the packets, but
cannot prevent the original packet from reaching its intended
destination.  Both types of attackers can also transmit arbitrary
packets.  This definition differs from that of Section 3.5 of SEC-
CONS in that an off-path attacker is able to observe packets.
Paragraph (version B):
Any attack on the TLS handshake that compromises the secrecy or
uniqueness of session keys, or the authentication of the
participating peers, affects other security guarantees provided by
QUIC that depend on those keys.  For instance, migration (migration)
depends on the efficacy of confidentiality protections, both for the
negotiation of keys using the TLS handshake and for QUIC packet
protection, to avoid linkability across network paths.
Paragraph (version B):
Packet protection (packet-protected) applies authenticated encryption
to all packets except Version Negotiation packets, though Initial and
Retry packets have limited protection due to the use of version-
specific keying material; see QUIC-TLS for more details.  This
section considers passive and active attacks against protected
packets.
Paragraph (version A):
A blind attacker, one who injects packets without being able to
observe valid packets for a connection, is unlikely to be successful,
since packet protection ensures that valid packets are only generated
by endpoints that possess the key material established during the
handshake; see handshake and handshake-properties.  Similarly, any
active attacker that observes packets and attempts to insert new data
or modify existing data in those packets should not be able to
generate packets deemed valid by the receiving endpoint.
Paragraph (version B):
A blind attacker, one who injects packets without being able to
observe valid packets for a connection, is unlikely to be successful,
since packet protection ensures that valid packets are only generated
by endpoints that possess the key material established during the
handshake; see handshake and handshake-properties.  Similarly, any
active attacker that observes packets and attempts to insert new data
or modify existing data in those packets should not be able to
generate packets deemed valid by the receiving endpoint, other than
Initial packets.
Paragraph (version B):
This section describes the intended security properties of connection
migration under various types of DoS attacks.
Paragraph (version B):
An on-path attacker can prevent use of a path for a connection,
causing the connection to fail if it cannot use a different path
that does not contain the attacker.  This can be achieved by
dropping all packets, modifying them so that they fail to decrypt,
or other methods.
Paragraph (version B):
An off-path attacker can create modified copies of packets that it
has observed and inject those copies into the network, potentially
with spoofed source and destination addresses.
Paragraph (version B):
For the purposes of this discussion, it is assumed that an off-path
attacker has the ability to inject a modified copy of a packet into
the network that will reach the destination endpoint prior to the
arrival of the original packet observed by the attacker.  In other
words, an attacker has the ability to consistently "win" a race with
the legitimate packets between the endpoints, potentially causing the
original packet to be ignored by the recipient.
Paragraph (version B):
The Source and Destination Connection ID fields are the primary means
of protection against off-path attack during the handshake; see
validate-handshake.  These are required to match those set by a peer.
Except for an Initial and stateless reset packets, an endpoint only
accepts packets that include a Destination Connection ID field that
matches a value the endpoint previously chose.  This is the only
protection offered for Version Negotiation packets.
Paragraph (version B):
The Destination Connection ID field in an Initial packet is selected
by a client to be unpredictable, which serves an additional purpose.
The packets that carry the cryptographic handshake are protected with
a key that is derived from this connection ID and a salt specific to
the QUIC version.  This allows endpoints to use the same process for
authenticating packets that they receive as they use after the
cryptographic handshake completes.  Packets that cannot be
authenticated are discarded.  Protecting packets in this fashion
provides a strong assurance that the sender of the packet saw the
Initial packet and understood it.
Paragraph (version B):
The number of active streams is limited by the
initial_max_streams_bidi and initial_max_streams_uni transport
parameters as updated by any received MAX_STREAMS frames, as
explained in controlling-concurrency.  If chosen judiciously, these
limits mitigate the effect of the stream commitment attack.  However,
setting the limit too low could affect performance when applications
expect to open large number of streams.
Paragraph (version A):
Applications to register codepoints in QUIC registries MAY include a
codepoint as part of the registration.  IANA MUST allocate the
selected codepoint if the codepoint is unassigned and the
requirements of the registration policy are met.
Paragraph (version B):
Applications to register codepoints in QUIC registries MAY include a
requested codepoint as part of the registration.  IANA MUST allocate
the selected codepoint if the codepoint is unassigned and the
requirements of the registration policy are met.
Paragraph (version B):
This review and consultation process also applies to requests to
change a provisional registration into a permanent registration,
except that the goal is not to determine whether there is no use of
the codepoint, but to determine that the registration is an accurate
representation of any deployed usage.