Change:
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 David'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 don't think that you should include the entirety of David's code. There are ways in which that will contribute to ossification. Indeed, I don't think that it is helpful to list draft versions here either.

Discussion:
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 <del> packet. </del> <ins> 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. </ins> source and destination connection ID: short and long packet headers carry a destination connection ID, a variable-length field

based application identification impossible through passive measurement. <ins> 3.3.1. 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. 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. 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. 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. 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. 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. </ins> 3.4. The QUIC Connection ID (see rebinding) is designed to allow an on-

7. <ins> Thanks to Martin Thomson and Martin Duke for contributing by reviewing and providing text proposals. </ins> 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. <ins> 8. This appendix uses the following conventions: array[i] - one byte at index i of array array[i:j] - subset of array starting with index i (inclusive) up to j-1 (inclusive) array[i:] - subset of array starting with index i (inclusive) up to the end of the array 8.1. This section contains algorithms that allows parsing versions from both Google QUIC and IETF QUIC.  These mechanisms will become irrelevant when IETF QUIC is fully deployed and Google QUIC is deprecated. Note that other than this appendix, nothing in this document applies to Google QUIC.  And the purpose of this appendix is merely to distinguish IETF QUIC from any versions of Google QUIC. Conceptually, a Google QUIC version is an opaque 32bit field.  When we refer to a version with four printable characters, we use its ASCII representation: for example, Q050 refers to {'Q', '0', '5', '0'} which is equal to {0x51, 0x30, 0x35, 0x30}. Otherwise, we use its hexadecimal representation: for example, 0xff00001d refers to {0xff, 0x00, 0x00, 0x1d}. QUIC versions that start with 'Q' or 'T' followed by three digits are Google QUIC versions.  Versions up to and including 43 are documented by <https://docs.google.com/document/d/ 1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/preview>.  Versions Q046, Q050, T050, and T051 are not fully documented, but this appendix should contain enough information to allow parsing Client Hellos for those versions. To extract the version number itself, one needs to look at the first byte of the QUIC packet, in other words the first byte of the UDP payload. 8.2. </ins>