Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a small PoC implementation of a masque. We could use a masque proxy almost as is, if it wasn't for the exorbitant header sizes which interfere with multihop. For the larger packet sizes for multihop, which then enables DAITA, we are looking to extend the protocol to support fragmented packets.
We are looking to use masque to obfuscate our traffic to make it appear as though it was regular QUIC traffic. I'm laying this here so that we have a clear path towards implementing a QUIC Masque proxy for ourselves in the upcoming quarter - we don't need to merge this code as is.
In terms of libraries, I've had to extend
h3
to make use of it, namely, exposing QUIC datagrams to client connections. Other than that, we should be able to use off-the-shelf libraries. For TLS, this is using the exact same rustls as we're using inmullvad-api
. We could move the whole implementation into the obfuscation crate for cleanliness.I have tested this with local
iperf2
, the performance isn't that great, 500mbit/s, yet to test the impact on WireGuard trafficThis change is