proto: Add option to pad all application data packets to MTU

[FlorianUekermann]

The goal is to provide an option to pad all outgoing packets that contain application data to MTU. Our usecase is a VPN, which transmits packets via QUIC datagrams. The benefit is that src <-> relay packets (the tunnel) can't be as easily associated with resulting relay <-> dest traffic if all tunnel packets are padded to MTU.
This generally mitigates some fingerprinting concerns in other usecases as well.

[djc]

Why?

[FlorianUekermann]

I updated the PR description with our motivation.

[Ralith]

Can't roughly the same analysis still be performed based on timing?

[FlorianUekermann]

Can't roughly the same analysis still be performed based on timing?

For our usecase:

Yes, both timing and size are relevant features. Removing size makes association of individual packets within a time window a lot harder. And the application layer is free to delay delay packets or even generate fake traffic. Packet size is just the one traffic feature where the transport implementation (e.g. quinn) needs to cooperate.
Note that with many users sharing an outgoing relay IP, association has to happen per connection (basically the pair of outgoing port + dest), so for some connections the amount of observable information is very limited and attribution of relay <-> dest traffic to a tunnel has to be done per connection.

In general (affects our usecase and others):

Packet sizes patterns can can be used as client or traffic type fingerprints [1].

[1] https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting

[Ralith]

Ah, yeah, makes sense that this would be pretty effective when there's many users.

[Ralith]

I still need to take a careful look at the interaction with GSO batching.

[Ralith]

LGTM. It's a little non-obvious how segment_size is guaranteed to always be the MTU when this option is set, but I don't immediately see a way to make that clearer, the change in logic is basically simple, and I am satisfied that it's correct.

[djc]

Thanks!

[djc]

Hmm, not sure why CI is failing in the merge queue:

error[E0283]: type annotations needed
    --> quinn-proto/src/tests/mod.rs:3256:52
     |
3256 |     assert_eq!(pair.client.outbound[0].0.size, MTU.into());
     |                                                    ^^^^
     |
     = note: cannot satisfy `_: From<u16>`
     = note: required for `u16` to implement `Into<_>`
help: try using a fully qualified path to specify the expected types
     |
3256 -     assert_eq!(pair.client.outbound[0].0.size, MTU.into());
3256 +     assert_eq!(pair.client.outbound[0].0.size, <u16 as Into<T>>::into(MTU));

[FlorianUekermann]

Strange... Maybe a different Rust version? I'll change MTU.into() to usize::from(MTU). The error looks like that would fix it.