RE: Packet number encryption

[Praveen Balasubramanian <[e-mail]>]

Couple of things to add:

1. Connection migration is an optional portion of the transport and not mandatory. It does not seem to be incrementally deployable with today's unmodified load balancers. Many devices may also be single homed and not have multiple active network interfaces. I also think the app and system settings will have to opt-in to it (to prevent aggressive usage of metered cellular data). If this is the case, cross-path linkability will be of limited concern for many QUIC connections. There is also the fact that perfect unlinkability seems to be hard against a motivated adversary.

2. If middlebox ossification is a big concern, we mainly need obfuscation and not encryption. Another option for example would be an XOR transform with some variable field in the encrypted portion of the packet (as an example sequence number of the first stream frame if it is present or some random pad bytes when its not present). I hope we can be creative here to reduce computation cost.


From: Marten Seemann [mailto:[e-mail]]
Sent: Wednesday, February 7, 2018 12:01 AM
To: huitema <[e-mail]>
Cc: Praveen Balasubramanian <[e-mail]>; [e-mail]
Subject: Re: Packet number encryption


On Wed, Feb 7, 2018 at 3:20 PM Christian Huitema <[e-mail]<mailto:[e-mail]>> wrote:



On 2/6/2018 8:55 PM, Praveen Balasubramanian wrote:

First, the proposal does not obscure the position of the packet number field in the header. The field contains a number that increments with every packet, and is thus easy to identify. This means that middle-boxes will get accustomed to seeing that field and tracking its increments.

Hence, this simple obfuscation provides no protection against ossification of the packet number field.



Well it seems like it is a requirement (see bullet 3 in Jana's list) to allow middleboxes to see sequencing information. By picking the initial random value middleboxes cannot assume any particular value. If packet number location and size is not part of invariants then it cannot be ossified, middleboxes will need to be resilient.

This is why I would rather see the exposed bits copied at a fixed location, while the PN itself cannot be located. That way, the exposed bits can ossify, but the actual PN does not.

We still need to be very careful here. If we decide to expose bits, we must make sure that a middlebox can only extract coarse-grained information, if we want to prevent middleboxes from buffering and delaying packets in order to fix / reduce reordering.
At this point however, I'm not convinced that exposing any reordering information to the network should be a requirement at all. There's a real risk of misuse of this information, and of ossification of whatever bits we expose.