Draft: draft-ietf-quic-manageability

Commentary: The manageability document should illustrate all the various packet sequences in a handshake , preferably with pretty pictures . 
 Now the transport draft has these illustrations as well . However , I think we should still at them in manageability as well . Actually I would like to try the SVG format here . Anybody in for that ? 
 The handshake illustrations here should only concern themselves with the wire image , unlike those in the transport draft , but yes we should derive them from the transport draft . Happy to do these in ASCII as well as SVG . 
 The problem with examples is that they might be typical , but they rarely capture the breadth of options well . Maybe you should purposefully diverge from established practice in these to avoid certain illusions from being formed . For instance , put PADDING first .
Paragraph (version A):
As soon as the cryptographic context is established, all information
in the QUIC header, including those exposed in the packet header, is
integrity protected.  Further, information that were sent and exposed
in previous packets when the cryptographic context was established
yet, e.g. for the cryptographic initial handshake itself, will be
validated later during the cryptographic handshake.  Therefore,
devices on path MUST NOT change any information or bits in QUIC
packet headers, since alteration of header information will lead to a
failed integrity check at the receiver, and can even lead to
connection termination.
Paragraph (version B):
New QUIC connections are established using a handshake, which is
distinguishable on the wire and contains some information that can be
passively observed.
Paragraph (version B):
To illustrate the information visible in the QUIC wire image during
the handshake, we first show the general communication pattern
visible in the UDP datagams containing the QUIC handshake, then
examine each of the datagrams in detail.
Paragraph (version B):
In the nominal case, the QUIC handshake can be recognized on the wire
through at least four datagrams we'll call "QUIC Client Hello", "QUIC
Server Hello", and "Initial Completion", and "Handshake Completion",
for purposes of this illustration, as shown in fig-handshake.
Paragraph (version B):
Packets in the handshake belong to three separate cryptographic and
transport contexts ("Initial", which contains observable payload, and
"Handshake" and "1-RTT", which do not).  QUIC packets in separate
contexts during the handshake are generally coalesced (see coalesced)
in order to reduce the number of UDP datagrams sent during the
handshake.
Paragraph (version B):
As shown here, the client can send 0-RTT data as soon as it has sent
its Client Hello, and the server can send 1-RTT data as soon as it
has sent its Server Hello.
Paragraph (version B):
A typical handshake starts with the client sending of a QUIC Client
Hello datagram as shown in fig-client-hello, which elicits a QUIC
Server Hello datagram as shown in fig-server-hello typically
containing three packets: an Initial packet with the Server Hello, 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):
The content of QUIC Initial packets are encrypted using Initial
Secrets, which are derived from a per-version constant and the
client's destination connection ID; they are therefore observable by
any on-path device that knows the per-version constant; we therefore
consider these as visible in our illustration.  The content of QUIC
Handshake packets are encrypted using keys established during the
initial handshake exchange, and are therefore not visible.
Paragraph (version B):
Initial, Handshake, and the Short Header packets transmitted after
the handshake belong to cryptographic and transport contexts.  The
Initial Completion fig-init-complete and the Handshake Completion
fig-hs-complete datagrams finish these first two contexts, by sending
the final acknowledgment and finishing the transmission of CRYPTO
frames.
Paragraph (version B):
The Client Hello datagram exposes version number, source and
destination connection IDs, and information in the TLS Client Hello
message, including any TLS Server Name Indication (SNI) present, in
the clear.  The QUIC PADDING frame is present to ensure the Client
Hello datagram has a minumum size of 1200 octets, to mitigate the
possibility of handshake amplification.
Paragraph (version B):
The Server Hello datagram exposes version number, source and
destination connection IDs, and information in the TLS Server Hello
message.
Paragraph (version B):
The Initial Completion datagram does not expose any additional
information; however, recognizing it can be used to determine that a
handshake has completed (see sec-confirm), and for three-way
handshake RTT estimation as in sec-rtt.
Paragraph (version B):
Similar to Initial Competion, Handshake Completion also exposes no
additional information; observing it serves only to determine that
the handshake has completed.
Paragraph (version B):
When the client uses 0-RTT connection resumption, 0-RTT data may also
be seen in the QUIC Client Hello datagram, as shown in fig-client-
hello-0rtt.
Paragraph (version B):
In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only
present if necessary to increase the size of the datagram with 0RTT
data to at least 1200 bytes.  Additional datagrams containing only
0-RTT protected long header packets may be sent from the client to
the server after the Client Hello datagram, containing the rest of
the 0-RTT data.  The amount of 0-RTT protected data is limited by the
initial congestion window, typically around 10 packets RFC6928.
Paragraph (version B):
As soon as the cryptographic context is established, all information
in the QUIC header, including information exposed in the packet
header, 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 MUST NOT change any
information or bits in QUIC packet headers, since alteration of
header information will lead to a failed integrity check at the
receiver, and can even lead to connection termination.
Paragraph (version A):
Connection establishment uses Initial, Handshake, and Retry packets
containing a TLS handshake on Stream 0.  Connection establishment can
therefore be detected using heuristics similar to those used to
detect TLS over TCP.  A client using 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, note that 0-RTT Protected data packets may
be seen before the Initial packet.  Note that only clients send
Initial packets, so the sides of a connection can be distinguished by
QUIC packet type in the handshake.
Paragraph (version B):
Connection establishment uses Initial, Handshake, and Retry packets
containing a TLS handshake.  Connection establishment can therefore
be detected using heuristics similar to those used to detect TLS over
TCP.  A client using 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, note that 0-RTT Protected data packets may be seen before
the Initial packet.  Note that only clients send Initial packets, so
the sides of a connection can be distinguished by QUIC packet type in
the handshake.
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 the cleartext TLS
handshake on stream 0.
Paragraph (version B):
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.