Draft: draft-ietf-quic-manageability

Commentary: This PR adds a new section on extracting the SNI . I also copied ( most of ) the pseudo code from Davids document into the appendix . We need to decide if we want to keep this and if so , potentially add some more explanation there . Also we could further strengthen the point out that both the 5 - tuple and conn ID can change ( as in  's doc ) . There is already text directly following the new SNI section on " flow association " . If we want stronger text there , maybe we can capture that in a separate issue though . 
 I do n't think that you should include the entirety of  's code . There are ways in which that will contribute to ossification . Indeed , I do n't think that it is helpful to list draft versions here either .
Paragraph (version A):
version number: the version number present in the long header, and
identifies the version used for that packet.  Note that 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.
Paragraph (version B):
version number: the version number present in the long header, and
identifies the version used for that packet.  Note that 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 versions that start with 0xff are IETF drafts.  QUIC
versions that start with 0x0000 are reserved for IETF consensus
documents, for example the QUIC version 1 is expected to use
version 0x00000001.
Paragraph (version B):
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 B):
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 B):
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 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 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):
To determine the end of the header and find the start of the payload
further the packet number length, the source connection ID length, as
well as 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.  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 B):
Finally after decryption, the Initial Client packet can be parsed to
detect the CRYPTO frame that contains the TLS Client Hello, which
then can be respectively parsed similar as for all other TLS
connections.  The Initial client packet may contain other frames, so
the first byte of each frame need to be checked to identify the frame
type and the skip over the frame.  Note that the length of the frames
is dependent on the frame type.  Usually for QUIC version 1, the
packet is expected to only carry the CRYPTO frame and optionally
padding frames.  However, padding which is one byte of zeros, may
also occur before or after the CRYPTO frame.
Paragraph (version B):
Thanks to Martin Thomson and Martin Duke for contributing by
reviewing and providing text proposals.
Paragraph (version B):
This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat
for Education, Research, and Innovation under contract no. 15.0268.
This support does not imply endorsement.