WIP QUIC: Improving initial packet dissection and building.

[sippejw]

Checklist:

• If you are new to Scapy: I have checked CONTRIBUTING.md (esp. section submitting-pull-requests)
• I squashed commits belonging together
• I added unit tests or explained why they are not relevant
• I executed the regression tests (using cd test && ./run_tests or tox)
• If the PR is still not finished, please create a Draft Pull Request

This PR aims to improve the capability of the QUIC layer, specifically building and dissecting QUIC initial packets.

List of changes:

• Refactor QUIC into dedicated directory within layers
• Begin implementing the cryptography features required for QUIC, including initial packet encryption
• Improve structure of QUIC fields to better represent ideas present in RFC 9000
• WIP: Build and dissect entire QUIC initial packets

[sippejw]

I have opened this draft PR to start a discussion on the best way to handle dissecting/building QUIC which has fields that must be protected/unprotected as well as payloads that must be encrypted/decrypted. For now, I am mostly focused on the dissection but I believe that building will follow a lot of the same structure.

1. For protected fields, i.e. the second half of QUIC header byte or the packet number, would it be better to "unprotect" these in the pre_dissect so that the fields_desc object on the Packet class has a clean definition of the unprotected fields?

I have started to go down this route, but it does mean effectively parsing the packet twice. Once in the pre_dissect in order to generate the values necessary to create the crypto context and then again in dissect to actually populate the fields.

Have any other layers encountered something like this? If so, I'd be interested in taking a look at how it was handled.

2. A QUIC packet consists of a QUIC header (of varying sizes and descriptions) followed by an encrypted payload. This encrypted payload is made up of QUIC frames (CRYPTO, PADDING, PING, STREAM, etc.). I am curious what approach would be preferred for handling this encrypted payload. Should the payload be treated as a separate layer? When should decryption occur?

If I include the QUIC payload (the list of frames and their subsequent dissections) as part of the existing QUIC layer, I think it would make the most sense to handle the decryption in the pre_dissect, again allowing the fields_desc object to have a clean definition of the entire packet. However, this has the same downfall as with the protected fields where essentially the QUIC header is parsed twice.

@gpotter2 I want to loop you in due to your involvement with previous QUIC development in Scapy.

Let me know your thoughts and I appreciate any input!

[sippejw]

I should've included this in the previous comment...
Another option is to handle unprotection in the post_dissect, I find this to be messier as it either leaves fields out of the fields_desc object or it means that those fields have an incorrect value for some period of time. This could also create issues with properly parsing the packet number and payload due to not knowing the packet number length.

If we are going to treat the QUIC frames as some type of second layer, then it may be appropriate to handle the payload decryption in the post_dissect.