feat: QUIC Long & Short Header Support

[jecsand838]

feat: Add QUIC packet parsing support

This PR introduces the initial implementation for parsing QUIC protocol headers. It adds the quic.rs module, which contains the core logic for handling QUIC Long and Short headers, and a new macros.rs file with eBPF-friendly parsing utilities.

The entire implementation is designed from the ground up to be compatible with the eBPF verifier and operate within the strict constraints of the kernel environment.

Key Features

1. eBPF-Friendly Parsing Macros (macros.rs)

To handle the complexities of QUIC's variable-length integers and fields, a new macros.rs file provides a set of reusable, eBPF-verifier-friendly utilities:

• read_var_buf_32!: Safely reads a variable-length buffer (up to 32 bytes) from a TC context without using complex loops that the verifier would reject.
• read_var_buf_from_len_byte_16!: A specialized macro for reading QUIC variable-length integers where the length is encoded in the first byte.
• read_var_u32_from_slice! & write_var_u32_to_slice!: Efficiently convert between byte buffers and u32 values using match statements to avoid verifier issues with dynamic indexing.

2. QUIC Header Implementation (quic.rs)

The quic.rs module provides the primary parsing logic and data structures for QUIC headers.

Strategy: Kernel-Friendly Variable Field Parsing
Our strategy for handling variable-length fields (like Connection IDs) is to use fixed-size, padded arrays (e.g., dc_id: [u8; 20]) within the header structs. The parser then populates these arrays with the actual data, up to the length specified in the packet. This approach ensures that our data structures have a constant, predictable size on the eBPF stack, which is a critical requirement for passing the verifier.

Skipping the Token Field Due to Memory Constraints
The eBPF kernel space is limited to a 512-byte stack, which presents a challenge for fields like the QUIC token that can have a variable and potentially large length. To guarantee that our parser does not exceed this limit, we have made a deliberate trade-off: we do not parse the token's value.

The parser reads the token's length, advances the context offset accordingly, but does not store the token's bytes. This prevents a potential stack overflow and ensures the parser remains lightweight and reliable within the kernel.

Evidence

• Quic Long Header

• Quic Short Header

Follow-ups

• Research and explore an approach for handling large fields that cannot fit into the limited eBPF stack memory, such as the QUIC token.

Closes: #53

---

This change is 

[jecsand838]

CC: @svencowart