Draft: draft-ietf-quic-manageability

Commentary: Mostly nits , some text about versions . Some reflow , and fixed up section references to other documents . If there 's anything you think needs to be lifted out to a separate PR / issue , I 'm happy to do that .
Paragraph (version A):
Given that QUIC is an end-to-end transport protocol, all information
in the protocol header, even that which can be inspected, is not
meant to be mutable by the network, and is therefore integrity-
protected.  While less information is visible to the network than for
TCP, integrity protection can also simplify troubleshooting, because
none of the nodes on the network path can modify the transport layer
information.
Paragraph (version A):
This document provides guidance for network operations that manage
QUIC traffic.  This includes guidance on how to interpret and utilize
information that is exposed by QUIC to the network, requirements and
assumptions that the QUIC design with respect to network treatment,
and a description of how common network management practices will be
impacted by QUIC.
Paragraph (version B):
Given that QUIC is an end-to-end transport protocol, no information
in the protocol header - even that which can be inspected - is meant
to be mutable by the network.  Therefore, these headers are
integrity-protected.  While less information is visible to the
network than in TCP, integrity protection can also simplify
troubleshooting, because none of the nodes on the network path can
modify the transport layer information.
Paragraph (version B):
This document provides guidance for network operations that manage
QUIC traffic.  This includes guidance on how to interpret and utilize
information that is exposed by QUIC to the network, requirements and
assumptions of the QUIC design with respect to network treatment, and
a description of how common network management practices will be
impacted by QUIC.
Paragraph (version A):
QUIC packets may have either a long header, or a short header.  The
first bit of the QUIC header is the Header Form bit, and indicates
which type of header is present.  The purpose of this bit is
invariant across QUIC versions.
Paragraph (version A):
The long header exposes more information.  It is used during
connection establishment, including version negotiation, retry, and
0-RTT data.  It contains a version number, as well as source and
destination connection IDs for grouping packets belonging to the same
flow.  The definition and location of these fields in the QUIC long
header are invariant for future versions of QUIC, although future
versions of QUIC may provide additional fields in the long header
QUIC-INVARIANTS.
Paragraph (version A):
Short headers are used after connection establishment, and contain
only an optional destination connection ID and the spin bit for RTT
measurement.
Paragraph (version A):
"fixed bit": the second most significant bit of the first octet
most QUIC packets of the current version is currently set to 1,
for endpoints to demultiplex with other UDP-encapsulated
protocols.  Even thought this bit is fixed in the QUICv1
specification, endpoints may use a version or extension that
varies the bit.  Therefore, observers cannot depend on it as an
identifier for QUIC.
Paragraph (version A):
latency spin bit: the third most significant bit of first octet in
the short packet header.  The spin bit is set by endpoints such
that tracking edge transitions can be used to passively observe
end-to-end RTT.  See spin-usage for further details.
Paragraph (version A):
version number: the version number is present in the long header,
and identifies the version used for that packet.  During Version
Negotiation (see version and Section 17.2.1 of QUIC-TRANSPORT),
the version number field has a special value (0x00000000) that
identifies the packet as a Version Negotiation packet.  QUIC
version 1 uses version 0x00000001.  Operators should expect to
observe packets with other version numbers as a result of various
Internet experiments, future standards, and greasing.  All
deployed versions are maintained in an IANA registry (see
Section 22.2 of QUIC-TRANSPORT).
Paragraph (version B):
QUIC packets may have either a long header or a short header.  The
first bit of the QUIC header is the Header Form bit, and indicates
which type of header is present.  The purpose of this bit is
invariant across QUIC versions.
Paragraph (version B):
The long header exposes more information.  In version 1 of QUIC, it
is used during connection establishment, including version
negotiation, retry, and 0-RTT data.  It contains a version number, as
well as source and destination connection IDs for grouping packets
belonging to the same flow.  The definition and location of these
fields in the QUIC long header are invariant for future versions of
QUIC, although future versions of QUIC may provide additional fields
in the long header QUIC-INVARIANTS.
Paragraph (version B):
Short headers contain only an optional destination connection ID and
the spin bit for RTT measurement.  In version 1 of QUIC, they are
used after connection establishment.
Paragraph (version B):
version number: the version number is present in the long header,
and identifies the version used for that packet.  During Version
Negotiation (see Section 17.2.1 of QUIC-TRANSPORT and version),
the version number field has a special value (0x00000000) that
identifies the packet as a Version Negotiation packet.  QUIC
version 1 uses version 0x00000001.  Operators should expect to
observe packets with other version numbers as a result of various
Internet experiments, future standards, and greasing.  All
deployed versions are maintained in an IANA registry (see
Section 22.2 of QUIC-TRANSPORT).
Paragraph (version B):
"fixed bit": The second-most-significant bit of the first octet of
most QUIC packets of the current version is set to 1, enabling
endpoints to demultiplex with other UDP-encapsulated protocols.
Even though this bit is fixed in the version 1 specification,
endpoints might use an extension that varies the bit.  Therefore,
observers cannot reliably use it as an identifier for QUIC.
Paragraph (version B):
latency spin bit: The third-most-significant bit of the first
octet in the short packet header for version 1.  The spin bit is
set by endpoints such that tracking edge transitions can be used
to passively observe end-to-end RTT.  See spin-usage for further
details.
Paragraph (version A):
Further, as QUIC has a connection ID, it is also possible to maintain
multiple QUIC connections over one 5-tuple.  However, if the
connection ID is not present in the packet header, all packets of the
5-tuple belong to the same QUIC connection.
Paragraph (version B):
Further, as QUIC has a connection ID, it is also possible to maintain
multiple QUIC connections over one 5-tuple.  However, if the
connection ID is zero-length, all packets of the 5-tuple belong to
the same QUIC connection.
Paragraph (version A):
Datagrams that contain a QUIC Initial Packet (Client Hello, Server
Hello, and some Initial Completion) contain at least 1200 octets of
UDP payload.  This protects against amplification attacks and
verifies that the network path meets the requirements for the minimum
QUIC IP packet size, see Section 14 of QUIC-TRANSPORT.  This is
accomplished by either adding PADDING frames within the Initial
packet, coalescing other packets with the Initial packet, or leaving
unused payload in the UDP packet after the Initial packet.  A network
path needs to be able to forward at least this size of packet for
QUIC to be used.
Paragraph (version B):
Datagrams that contain a QUIC Initial Packet (Client Hello, Server
Hello, and some Initial Completion) contain at least 1200 octets of
UDP payload.  This protects against amplification attacks and
verifies that the network path meets the requirements for the minimum
QUIC IP packet size; see Section 14 of QUIC-TRANSPORT.  This is
accomplished by either adding PADDING frames within the Initial
packet, coalescing other packets with the Initial packet, or leaving
unused payload in the UDP packet after the Initial packet.  A network
path needs to be able to forward at least this size of packet for
QUIC to be used.
Paragraph (version A):
The Client Hello datagram exposes version number, source and
destination connection IDs without encryption.  Information in the
TLS Client Hello frame, including any TLS Server Name Indication
(SNI) present, is obfuscated using the Initial secret.  Note that the
location of PADDING is implementation-dependent, and PADDING frames
may not appear in a coalesced Initial packet.
Paragraph (version A):
The Server Hello datagram also exposes version number, source and
destination connection IDs and information in the TLS Server Hello
message which is obfuscated using the Initial secret.
Paragraph (version B):
The Client Hello datagram exposes version number, source and
destination connection IDs without encryption.  Information in the
TLS Client Hello frame, including any TLS Server Name Indication
(SNI) present, is obfuscated using the Initial secret.  Note that the
location of PADDING is implementation-dependent, and PADDING frames
might not appear in a coalesced Initial packet.
Paragraph (version B):
The Server Hello datagram also exposes version number, source and
destination connection IDs in the clear; information in the TLS
Server Hello message is obfuscated using the Initial secret.
Paragraph (version A):
As soon as the cryptographic context is established, all information
in the QUIC header, including exposed information, is integrity
protected.  Further, information that was sent and exposed in
handshake packets sent before the cryptographic context was
established are validated later during the cryptographic handshake.
Therefore, devices on path cannot alter any information or bits in
QUIC packets.  Such alterations would cause the integrity check to
fail, which results in the receiver discarding the packet.  Some
parts of Initial packets could be altered by removing and re-applying
the authenticated encryption without immediate discard at the
receiver.  However, the cryptographic handshake validates most fields
and any modifications in those fields will result in connection
establishment failing later on.
Paragraph (version A):
The connection ID in the QUIC packet headers allows routing of QUIC
packets at load balancers on other than five-tuple information,
ensuring that related flows are appropriately balanced together; and
to allow rebinding of a connection after one of the endpoint's
addresses changes - usually the client's.  Client and server
negotiate connection IDs during the handshake; typically, however,
only the server will request a connection ID for the lifetime of the
connection.  Connection IDs for either endpoint may change during the
lifetime of a connection, with the new connection ID being negotiated
via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT.  Therefore,
observing a new connection ID does not necessary indicate a new
connection.
Paragraph (version A):
Server-generated connection IDs should seek to obscure any encoding,
of routing identities or any other information.  Exposing the server
mapping would allow linkage of multiple IP addresses to the same host
if the server also supports migration.  Furthermore, this opens an
attack vector on specific servers or pools.
Paragraph (version B):
As soon as the cryptographic context is established, all information
in the QUIC header, including exposed information, is integrity-
protected.  Further, information that was exposed in packets sent
before the cryptographic context was established is validated during
the cryptographic handshake.  Therefore, devices on path cannot alter
any information or bits in QUIC packets.  Such alterations would
cause the integrity check to fail, which results in the receiver
discarding the packet.  Some parts of Initial packets could be
altered by removing and re-applying the authenticated encryption
without immediate discard at the receiver.  However, the
cryptographic handshake validates most fields and any modifications
in those fields will result in connection establishment failing later
on.
Paragraph (version B):
The connection ID in the QUIC packet headers allows routing of QUIC
packets at load balancers using information independent of the five-
tuple.  This helps ensure that related flows are appropriately
balanced together and allows rebinding of a connection after one of
the endpoints experiences an address change - usually the client.
Client and server negotiate connection IDs during the handshake;
typically, however, only the server will request a connection ID for
the lifetime of the connection.  Connection IDs for either endpoint
may change during the lifetime of a connection, with the new
connection ID being supplied via encrypted frames (see Section 5.1 of
QUIC-TRANSPORT).  Therefore, observing a new connection ID does not
necessary indicate a new connection.
Paragraph (version B):
Server-generated connection IDs should seek to obscure any encoded
routing identities or any other information.  Exposing the server
mapping would allow linkage of multiple IP addresses to the same host
if the server also supports migration.  Furthermore, this opens an
attack vector on specific servers or pools.
Paragraph (version A):
QUIC_LB further specified possible algorithms to generate connection
IDs at load balancers.
Paragraph (version A):
The packet number field is always present in the QUIC packet header;
however, it is always encrypted.  The encryption key for packet
number protection on handshake packets sent before cryptographic
context establishment is specific to the QUIC version, while packet
number protection on subsequent packets uses secrets derived from the
end-to-end cryptographic context.  Packet numbers are therefore not
part of the wire image that is visible to on-path observers.
Paragraph (version A):
Version Negotiation packets are used by the server to indicate that a
requested version from the client is not supported (see section 6 of
QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically
protected, but QUIC versions can use later encrypted messages to
verify that they were authentic.  Therefore any modification of this
list will be detected and may cause the endpoints to terminate the
connection attempt.
Paragraph (version A):
Also note that the list of versions in the Version Negotiation packet
may contain reserved versions.  This mechanism is used to avoid
ossification in the implementation on the selection mechanism.
Further, a client may send a Initial Client packet with a reserved
version number to trigger version negotiation.  In the Version
Negotiation packet the connection ID and packet number of the Client
Initial packet are reflected to provide a proof of return-
routability.  Therefore changing this information will also cause the
connection to fail.
Paragraph (version B):
QUIC_LB further specifies possible algorithms to generate connection
IDs at load balancers.
Paragraph (version B):
The packet number field is always present in the QUIC packet header
in version 1; however, it is always encrypted.  The encryption key
for packet number protection on handshake packets sent before
cryptographic context establishment is specific to the QUIC version,
while packet number protection on subsequent packets uses secrets
derived from the end-to-end cryptographic context.  Packet numbers
are therefore not part of the wire image that is visible to on-path
observers.
Paragraph (version B):
Version Negotiation packets are used by the server to indicate that a
requested version from the client is not supported (see Section 6 of
QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically
protected, but future QUIC versions will use later encrypted messages
to verify that they were authentic.  Therefore any modification of
this list will be detected and may cause the endpoints to terminate
the connection attempt.
Paragraph (version B):
Also note that the list of versions in the Version Negotiation packet
may contain reserved versions.  This mechanism is used to avoid
ossification in the implementation on the selection mechanism.
Further, a client may send a Initial Client packet with a reserved
version number to trigger version negotiation.  In the Version
Negotiation packet, the connection IDs of the Client Initial packet
are reflected to provide a proof of return-routability.  Therefore,
changing this information will also cause the connection to fail.
Paragraph (version A):
The only application binding defined by the IETF QUIC WG is HTTP/3
QUIC-HTTP at the time of this writing; however, many other
applications are currently being defined and deployed over QUIC, so
an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP
over QUIC uses UDP port 443 by default, although URLs referring to
resources available over HTTP/3 may specify alternate port numbers.
Simple assumptions about whether a given flow is using QUIC based
upon a UDP port number may therefore not hold; see also RFC7605
section 5.
Paragraph (version A):
While the second most significant bit (0x40) of the first octet is
set to 1 in most QUIC packets of the current version (see public-
header and section 17 of QUIC-TRANSPORT), this method of recognizing
QUIC traffic is not reliable.  First, it only provides one bit of
information and is prone to collision with UDP-based protocols other
than those that this static bit is meant to allow multiplexing with.
Second, this feature of the wire image is not invariant QUIC-
INVARIANTS and may change in future versions of the protocol, or even
be negotiated during the handshake via the use of transport
parameters.
Paragraph (version A):
Even though transport parameters transmitted in the client initial
are obserable by the network, they cannot be modified by the network
without risking connection failure.  Further, the negotiated reply
from the server cannot be observed, so observers on the network
cannot know which parameters are actually in use.
Paragraph (version A):
An in-network observer assuming that a set of packets belongs to a
QUIC flow can infer the version number in use by observing the
handshake: for QUIC version 1 if the version number in the Initial
packet from a client is the same as the version number in Initial
packet of the server response, that version has been accepted by both
endpoints to be used for the rest of the connection.
Paragraph (version A):
Negotiated version cannot be identified for flows for which a
handshake is not observed, such as in the case of connection
migration; however, it might be possible to associate a flow with a
flow for which a version has been identified; see sec-flow-
association.
Paragraph (version A):
This document focuses on QUIC Version 1, and this section applies
only to packets belonging to Version 1 QUIC flows; for purposes of
on-path observation, it assumes that these packets have been
identified as such through the observation of a version number
exchange as described above.
Paragraph (version A):
A related question is whether a first packet of a given flow on a
known QUIC-associated port is a valid QUIC packet, to support in-
network filtering of garbage UDP packets (reflection attacks, random
backscatter).  While heuristics based on the first byte of the packet
(packet type) could be used to separate valid from invalid first
packet types, the deployment of such heuristics is not recommended,
as packet types may have different meanings in future versions of the
protocol.
Paragraph (version B):
The only application binding defined by the IETF QUIC WG is HTTP/3
QUIC-HTTP at the time of this writing; however, many other
applications are currently being defined and deployed over QUIC, so
an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3
uses UDP port 443 by default, although URLs referring to resources
available over HTTP/3 may specify alternate port numbers.  Simple
assumptions about whether a given flow is using QUIC based upon a UDP
port number may therefore not hold; see also Section 5 of RFC7605.
Paragraph (version B):
While the second-most-significant bit (0x40) of the first octet is
set to 1 in most QUIC packets of the current version (see public-
header and Section 17 of QUIC-TRANSPORT), this method of recognizing
QUIC traffic is not reliable.  First, it only provides one bit of
information and is prone to collision with UDP-based protocols other
than those considered in RFC7983.  Second, this feature of the wire
image is not invariant QUIC-INVARIANTS and may change in future
versions of the protocol, or even be negotiated during the handshake
via the use of an extension.
Paragraph (version B):
Even though transport parameters transmitted in the client's Initial
packet are observable by the network, they cannot be modified by the
network without risking connection failure.  Further, the reply from
the server cannot be observed, so observers on the network cannot
know which parameters are actually in use.
Paragraph (version B):
An in-network observer assuming that a set of packets belongs to a
QUIC flow can infer the version number in use by observing the
handshake: for QUIC version 1, if the version number in the Initial
packet from a client is the same as the version number in the Initial
packet of the server response, that version has been accepted by both
endpoints to be used for the rest of the connection.
Paragraph (version B):
The negotiated version cannot be identified for flows for which a
handshake is not observed, such as in the case of connection
migration; however, it might be possible to associate a flow with a
flow for which a version has been identified; see sec-flow-
association.
Paragraph (version B):
This document focuses on QUIC version 1, and this section applies
only to packets belonging to QUIC version 1 flows; for purposes of
on-path observation, it assumes that these packets have been
identified as such through the observation of a version number
exchange as described above.
Paragraph (version B):
A related question is whether the first packet of a given flow on a
port known to be associated with QUIC is a valid QUIC packet.  This
determination supports in-network filtering of garbage UDP packets
(reflection attacks, random backscatter, etc.).  While heuristics
based on the first byte of the packet (packet type) could be used to
separate valid from invalid first packet types, the deployment of
such heuristics is not recommended, as bits in the first byte may
have different meanings in future versions of the protocol.
Paragraph (version A):
Connection establishment uses Initial and Handshake packets
containing a TLS handshake, and Retry packets that do not contain
parts of the handshake.  Connection establishment can therefore be
detected using heuristics similar to those used to detect TLS over
TCP.  A client initiating a 0-RTT connection may also send data
packets in 0-RTT Protected packets directly after the Initial packet
containing the TLS Client Hello.  Since these packets may be
reordered in the network, 0-RTT Protected data packets could be seen
before the Initial packet.
Paragraph (version A):
Note that clients send Initial packets before servers do, servers
send Handshake packets before clients do, and only clients send
Initial packets with tokens.  Therefore, the role as a client or
server can generally be confirmed by an on- path observer.  An
attempted connection after Retry can be detected by correlating the
token on the Retry with the token on the subsequent Initial packet
and the destination connection ID of the new Initial packet.
Paragraph (version B):
Connection establishment uses Initial and Handshake packets
containing a TLS handshake, and Retry packets that do not contain
parts of the handshake.  Connection establishment can therefore be
detected using heuristics similar to those used to detect TLS over
TCP.  A client initiating a connection may also send data in 0-RTT
packets directly after the Initial packet containing the TLS Client
Hello.  Since these packets may be reordered in the network, 0-RTT
packets could be seen before the Initial packet.
Paragraph (version B):
Note that in this version of QUIC, clients send Initial packets
before servers do, servers send Handshake packets before clients do,
and only clients send Initial packets with tokens.  Therefore, an
endpoint can be identified as a client or server by an on-path
observer.  An attempted connection after Retry can be detected by
correlating the contents of the Retry packet with the Token and the
Destination Connection ID fields of the new Initial packet.
Paragraph (version A):
The cleartext TLS handshake may contain Server Name Indication (SNI)
RFC6066, by which the client reveals the name of the server it
intends to connect to, in order to allow the server to present a
certificate based on that name.  It may also contain information from
Application-Layer Protocol Negotiation (ALPN) RFC7301, by which the
client exposes the names of application-layer protocols it supports;
an observer can deduce that one of those protocols will be used if
the connection continues.
Paragraph (version A):
Work is currently underway in the TLS working group to encrypt the
SNI in TLS 1.3 TLS-ESNI.  This would make SNI-based application
identification impossible by on-path observation for QUIC and other
protocols that use TLS.
Paragraph (version A):
If the SNI is not encrypted it can be derived from the QUIC Initial
packet by calculating the Initial Secret to decrypt the packet
payload and parse the QUIC CRYPTO Frame containing the TLS
ClientHello.
Paragraph (version A):
As both the initial salt for the Initial Secret as well as CRYPTO
frame itself are version-specific, the first step is always to parse
the version number (second to sixth byte of the long header).  Note
that only long header packets carry the version number, so it is
necessary to also check the if first bit of the QUIC packet is set to
1, indicating a long header.
Paragraph (version A):
Note that proprietary QUIC versions, that have been deployed before
standardization, might not set the first bit in a QUIC long header
packets to 1.  To parse these versions, example code is provided in
the appendix (see sec-google-version), however, it is expected that
these versions will gradually disappear over time.
Paragraph (version A):
When the version has been identified as QUIC version 1, the packet
type needs to be verified as an Initial packet by checking that the
third and fourth bit of the header are both set to 0.  Then the
client destination connection ID needs to be extracted to calculate
the Initial Secret together with the version specific initial salt,
as described in QUIC-TLS.  The length of the connection ID is
indicated in the 6th byte of the header followed by the connection ID
itself.
Paragraph (version B):
The client's TLS ClientHello may contain a Server Name Indication
(SNI) RFC6066 extension, by which the client reveals the name of the
server it intends to connect to, in order to allow the server to
present a certificate based on that name.  It may also contain an
Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by
which the client exposes the names of application-layer protocols it
supports; an observer can deduce that one of those protocols will be
used if the connection continues.
Paragraph (version B):
Work is currently underway in the TLS working group to encrypt the
contents of the ClientHello in TLS 1.3 TLS-ECH.  This would make SNI-
based application identification impossible by on-path observation
for QUIC and other protocols that use TLS.
Paragraph (version B):
If the ClientHello is not encrypted, it can be derived from the
client's Initial packet by calculating the Initial secret to decrypt
the packet payload and parsing the QUIC CRYPTO Frame containing the
TLS ClientHello.
Paragraph (version B):
As both the derivation of the Initial secret and the structure of the
Initial packet itself are version-specific, the first step is always
to parse the version number (second to sixth bytes of the long
header).  Note that only long header packets carry the version
number, so it is necessary to also check if the first bit of the QUIC
packet is set to 1, indicating a long header.
Paragraph (version B):
Note that proprietary QUIC versions, that have been deployed before
standardization, might not set the first bit in a QUIC long header
packet to 1.  To parse these versions, example code is provided in
the appendix (see sec-google-version).  However, it is expected that
these versions will gradually disappear over time.
Paragraph (version B):
When the version has been identified as QUIC version 1, the packet
type needs to be verified as an Initial packet by checking that the
third and fourth bits of the header are both set to 0.  Then the
Destination Connection ID needs to be extracted to calculate the
Initial secret using the version-specific Initial salt, as described
in Section 5.2 of QUIC-TLS.  The length of the connection ID is
indicated in the 6th byte of the header followed by the connection ID
itself.
Paragraph (version A):
To determine the end of the header and find the start of the payload,
the packet number length, the source connection ID length, and the
token length need to be extracted.  The packet number length is
defined by the seventh and eight bits of the header as described in
section 17.2. of QUIC-TRANSPORT, but is obfuscated as described in
QUIC-TLS.  The source connection ID length is specified in the byte
after the destination connection ID.  And the token length, which
follows the source connection ID, is a variable length integer as
specified in Section 16 of QUIC-TRANSPORT.
Paragraph (version A):
After decryption, the Initial Client packet can be parsed to detect
the CRYPTO frame that contains the TLS Client Hello, which then can
be parsed similarly to TLS over TCP connections.  The Initial client
packet may contain other frames, so the first bytes of each frame
need to be checked to identify the frame type, and if needed skip
over it.  Note that the length of the frames is dependent on the
frame type.  In QUIC version 1, the packet is expected to only carry
the CRYPTO frame and optionally padding frames.  However, PADDING
frames, each consisting of a single zero byte, may also occur before
or after the CRYPTO frame.
Paragraph (version A):
Note that client Initial packets after the first do not always use
the destination connection ID that was used to generate the Initial
keys.  Therefore, attempts to decrypt these packets using the
procedure above might fail.
Paragraph (version A):
The QUIC connection ID (see rebinding) is designed to allow an on-
path device such as a load-balancer to associate two flows as
identified by five-tuple when the address and port of one of the
endpoints changes; e.g. due to NAT rebinding or server IP address
migration.  An observer keeping flow state can associate a connection
ID, if present, with a given flow, and can associate a known flow
with a new flow when when observing a packet sharing the same
connection ID in the same direction between client and server and
sharing one endpoint address (IP address and port) with the known
flow.
Paragraph (version A):
However, since the connection ID may change multiple times during the
lifetime of a flow, and the negotiation of connection ID changes is
encrypted, packets with the same 5-tuple but different connection IDs
may or may not belong to the same connection.
Paragraph (version A):
The connection ID value should be treated as opaque; see sec-
loadbalancing for caveats regarding connection ID selection at
servers.
Paragraph (version B):
To determine the end of the header and find the start of the payload,
the packet number length, the source connection ID length, and the
token length need to be extracted.  The packet number length is
defined by the seventh and eight bits of the header as described in
Section 17.2 of QUIC-TRANSPORT, but is obfuscated as described in
Section 5.4 of QUIC-TLS.  The source connection ID length is
specified in the byte after the destination connection ID.  The token
length, which follows the source connection ID, is a variable-length
integer as specified in Section 16 of QUIC-TRANSPORT.
Paragraph (version B):
After decryption, the client's Initial packet can be parsed to detect
the CRYPTO frame that contains the TLS ClientHello, which then can be
parsed similarly to TLS over TCP connections.  The client's Initial
packet may contain other frames, so the first bytes of each frame
need to be checked to identify the frame type, and if needed skip
over it.  Note that the length of the frames is dependent on the
frame type.  In QUIC version 1, the packet is expected to contain
only CRYPTO frames and optionally PADDING frames.  PADDING frames,
each consisting of a single zero byte, may occur before, after, or
between CRYPTO frames.  There might be multiple CRYPTO frames.
Finally, an extension might define additional frame types which could
be present.
Paragraph (version B):
Note that subsequent Initial packets might contain a Destination
Connection ID other than the one used to generate the Initial secret.
Therefore, attempts to decrypt these packets using the procedure
above might fail unless the Initial secret is retained by the
observer.
Paragraph (version B):
The QUIC connection ID (see rebinding) is designed to allow an on-
path device such as a load-balancer to associate two flows as
identified by five-tuple when the address and port of one of the
endpoints changes; e.g. due to NAT rebinding or address migration.
An observer keeping flow state can associate a connection ID, if
present, with a given flow, and can associate a known flow with a new
flow when when observing a packet sharing the same connection ID in
the same direction between client and server and sharing one endpoint
address (IP address and port) with the known flow.
Paragraph (version B):
However, since the connection ID may change multiple times during the
lifetime of a flow, and the negotiation of connection ID changes is
encrypted, packets with the same 5-tuple but different connection IDs
might or might not belong to the same connection.
Paragraph (version B):
Connection IDs should be treated as opaque; see sec-loadbalancing for
caveats regarding connection ID selection at servers.
Paragraph (version A):
QUIC does not expose the end of a connection; the only indication to
on-path devices that a flow has ended is that packets are no longer
observed.  Stateful devices on path such as NATs and firewalls must
therefore use idle timeouts to determine when to drop state for QUIC
flows, see further section sec-stateful.
Paragraph (version B):
QUIC does not expose the end of a connection; the only indication to
on-path devices that a flow has ended is that packets are no longer
observed.  Stateful devices on path such as NATs and firewalls must
therefore use idle timeouts to determine when to drop state for QUIC
flows; see sec-stateful.
Paragraph (version A):
Round-trip time of QUIC flows can be inferred by observation once per
flow, during the handshake, as in passive TCP measurement; this
requires parsing of the QUIC packet header and recognition of the
handshake, as illustrated in handshake.  It can also be inferred
during the flow's lifetime, if the endpoints use the spin bit
facility described below and in QUIC-TRANSPORT, section 17.3.1.
Paragraph (version A):
In the common case, the delay between the Initial packet containing
the TLS Client Hello and the Handshake packet containing the TLS
Server Hello represents the RTT component on the path between the
observer and the server.  The delay between the TLS Server Hello and
the Handshake packet containing the TLS Finished message sent by the
client represents the RTT component on the path between the observer
and the client.  While the client may send 0-RTT Protected packets
after the Initial packet during 0-RTT connection re-establishment,
these can be ignored for RTT measurement purposes.
Paragraph (version A):
Handshake RTT can be measured by adding the client-to-observer and
observer-to-server RTT components together.  This measurement
necessarily includes any transport and application layer delay (the
latter mainly caused by the asymmetric crypto operations associated
with the TLS handshake) at both sides.
Paragraph (version B):
The round-trip time of QUIC flows can be inferred by observation once
per flow, during the handshake, as in passive TCP measurement; this
requires parsing of the QUIC packet header and recognition of the
handshake, as illustrated in handshake.  It can also be inferred
during the flow's lifetime, if the endpoints use the spin bit
facility described below and in Section 17.3.1 of QUIC-TRANSPORT.
Paragraph (version B):
In the common case, the delay between the client's Initial packet
(containing the TLS ClientHello) and the server's Initial packet
(containing the TLS ServerHello) represents the RTT component on the
path between the observer and the server.  The delay between the
server's first Handshake packet and the Handshake packet sent by the
client represents the RTT component on the path between the observer
and the client.  While the client may send 0-RTT packets after the
Initial packet during connection re-establishment, these can be
ignored for RTT measurement purposes.
Paragraph (version B):
Handshake RTT can be measured by adding the client-to-observer and
observer-to-server RTT components together.  This measurement
necessarily includes any transport- and application-layer delay (the
latter mainly caused by the asymmetric crypto operations associated
with the TLS handshake) at both sides.