QUIC protocol - parsing the first byte?

QUIC
retag add tags

Hi.

So I've been meaning to write a QUIC parser/plugin to extend on the existing parser, mainly for learning. And while using some example data I noticed the first byte changes in value but wireshark parses the values the same.

I can't find any information on why this is and where it's documented. In the example below, the first byte c2 is treated as Long Header, Fixed Bit: True, Packet Type: Initial, the reserved two bits and Packet Number Length: 2 bytes. But c5 in the second frame is parsed in the exact same way.

So my question is, how can c2 and c5 be parsed identically? gif

I suspected they might be part of the CRYPTO payload, but from what I've gathered the initial flags are not encrypted.

$ wireshark -v

Wireshark 4.0.0 (Git v4.0.0 packaged as 4.0.0-1).

Compiled (64-bit) using GCC 12.2.0, with GLib 2.74.0, with PCRE2, with zlib 1.2.12, with Qt 5.15.6, with libpcap, with POSIX capabilities (Linux), with libnl 3, with Lua 5.2.4, with GnuTLS 3.7.8 and PKCS #11 support, with Gcrypt 1.10.1-unknown, with Kerberos (MIT), with MaxMind, with nghttp2 1.50.0, with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.10.2, without libsmi, with QtMultimedia, without automatic updates, with SpeexDSP (using system library), with Minizip, with binary plugins.

Running on Linux 6.0.2-arch1-1, with AMD Ryzen 9 5900X 12-Core Processor (with SSE4.2), with 64230 MB of physical memory, with GLib 2.74.0, with PCRE2 10.40 2022-04-14, with zlib 1.2.13, with Qt 5.15.6, with libpcap 1.10.1 (with TPACKET_V3), with c-ares 1.18.1, with GnuTLS 3.7.8, with Gcrypt 1.10.1-unknown, with nghttp2 1.50.0, with brotli 1.0.9, with LZ4 1.9.4, with Zstandard 1.5.2, with LC_TYPE=en_US.UTF-8, binary plugins supported.

Torxed

asked 2022-10-30 23:19:39 +0000

Chuckc

updated 2022-11-01 12:24:33 +0000

edit flag offensive 0 remove flag close merge delete

Comments

Can you update the question with the output of wireshark -v or Help->About Wireshark:Wireshark.

Chuckc (2022-10-30 23:40:00 +0000) edit

On Initial Packets, only the first 4 bits of the first byte are in clear-text; the remaining bits are obfuscated. See Fig 7 RFC9001

ivan81 (2022-10-31 09:20:26 +0000) edit

add a comment see more comments

/** Per-packet information about QUIC, populated on the first pass. */ struct quic_packet_info { struct quic_packet_info *next; guint64 packet_number; /** Reconstructed full packet number. */ quic_decrypt_result_t decryption; guint8 pkn_len; /** Length of PKN (1/2/3/4) or unknown (0). */ guint8 first_byte; /** Decrypted flag byte, valid only if pkn_len is non-zero. */ guint8 packet_type; bool retry_integrity_failure : 1; bool retry_integrity_success : 1; };

if (quic_packet->pkn_len) { proto_tree_add_uint(quic_tree, hf_quic_long_reserved, tvb, offset, 1, first_byte); proto_tree_add_uint(quic_tree, hf_quic_packet_number_length, tvb, offset, 1, first_byte); }

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

QUIC protocol - parsing the first byte? edit

Comments

1 Answer

Comments