Draft: draft-ietf-quic-manageability

Commentary: This goes to the end of " Server Name Indication " Some changes are attempts at clarifications , but I could have incorrectly clarified something , so feel free to reject changes .
Paragraph (version A):
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.  This is achieved through integrity
protection of the wire image WIRE-IMAGE.  Encryption of most control
signaling means that less information is visible to the network than
is the case with TCP.
Paragraph (version A):
Integrity protection can also simplify troubleshooting, because none
of the nodes on the network path can modify transport layer
information.  However, it does imply that in-network operations that
depend on modification of data are not possible without the
cooperation of a QUIC endpoint.  This might be possible with the
introduction of a proxy which authenticates as an endpoint.  Proxy
operations are not in scope for this document.
Paragraph (version B):
QUIC is an end-to-end transport protocol.  No information in the
protocol header, even that which can be inspected, is mutable by the
network.  This is achieved through integrity protection of the wire
image WIRE-IMAGE.  Encryption of most control signaling means that
less information is visible to the network than is the case with TCP.
Paragraph (version B):
Integrity protection can also simplify troubleshooting, because none
of the nodes on the network path can modify transport layer
information.  However, it means in-network operations that depend on
modification of data are not possible without the cooperation of an
QUIC endpoint.  This might be possible with the introduction of a
proxy which authenticates as an endpoint.  Proxy operations are not
in scope for this document.
Paragraph (version A):
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):
The long header exposes more information.  It contains a version
number, as well as source and destination connection IDs for
associating packets with a QUIC connection.  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):
In version 1 of QUIC, the long header is used during connection
establishment to transmit crypto handshake data, perform version
negotiation, retry, and send 0-RTT data.
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 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):
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 (RFC7801).
All deployed versions are maintained in an IANA registry (see
Section 22.2 of QUIC-TRANSPORT).
Paragraph (version A):
packet number: All packets except Version Negotiation and Retry
packets have an associated packet number; however, this packet
number is encrypted, and therefore not of use to on-path
observers.  The offset of the packet number is encoded in long
headers, while it is implicit (depending on destination connection
ID length) in short headers.  The length of the packet number is
cryptographically obfuscated.
Paragraph (version B):
packet number: All packets except Version Negotiation and Retry
packets have an associated packet number; however, this packet
number is encrypted, and therefore not of use to on-path
observers.  The offset of the packet number can be decoded in long
headers, while it is implicit (depending on destination connection
ID length) in short headers.  The length of the packet number is
cryptographically obfuscated.
Paragraph (version A):
A typical handshake starts with the client sending of a Client
Initial datagram as shown in fig-client-initial, which elicits a
Server Initial datagram as shown in fig-server-initial typically
containing three packets: an Initial packet with the beginning of the
server's side of the TLS handshake, a Handshake packet with the rest
of the server's side of the TLS handshake, and initial 1-RTT data, if
present.
Paragraph (version B):
A typical handshake starts with the client sending of a Client
Initial datagram as shown in fig-client-initial, which elicits a
Server Initial datagram as shown in fig-server-initial typically
containing three packets: an Initial packet with the beginning of the
server's side of the TLS handshake, a Handshake packet with the rest
of the server's side of the TLS handshake, and 1-RTT data, if
present.
Paragraph (version A):
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):
Even though transport parameters transmitted in the client's Initial
packet are observable by the network, they cannot be modified by the
network without causing 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 A):
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):
This document focuses on QUIC version 1, and this Connection
Confirmation 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 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 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):
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 packets may be reordered or lost in the network, 0-RTT
packets could be seen before the Initial packet.
Paragraph (version A):
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):
If the ClientHello is not encrypted, SNI 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.