search

private-octopus / fuzi_q

Over the net fuzzing of QUIC servers or clients.
MIT License
19 stars 4 forks source link

Run time parameters for migration, rebinding, key rotation. #4

Open huitema opened 2 years ago

huitema commented 2 years ago

Consider parameters for client such as number of simultaneous connections, duration of fuzz. Also consider whether triggering migration, rebinding, key rotation.

huitema commented 2 years ago

First version already supports nb simultaneous connections, nb trials, duration of fuzz.

huitema commented 2 years ago

Rebinding and CID renewal are triggered by API calls, should be easy to support. NAT rebinding requires simulation of NAT rebinding at the socket layer, i.e., probably a change to the current code. In practice that will require migrating all the connections at the same time, or alternately adding code in the socket layer. Migration would work if the socket layers supports multiple outgoing ports. May want to build that into the default loop.

Testing the stateless reset requires server action. Might be useful in the "server" mode, to test how client reacts, for example setting the reset required bit. May also require invalidating the STEK key occasionally on the server, or clearing the ticket database on the client, to get out of resumption mode.

Interop testing has a "post quantum" mode. Might want to exercise it occasionally on the client, e.g., test what happens if 2nd or 3rd Initial packet is fuzzed.

May also want to exercise the QUIC bit option, spin bit option, and version negotiation.