Re: Packet number encryption

[Mikkel Fahnøe Jørgensen <[e-mail]>]

> 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.

I am fairly convinced that you can and should separate exposure to
middleware from packet numbers in whatever form precisely because we want
packet numbers to not rely on path and because packet numbers may expose
false loss if exposed directly in whatever form.

A path specific counter can be done be exposing a few bits of an internal
path specific counter that is entirely independent of packet numbering used
for AEAD IV and is also independent of any artificial packet number
skipping for ACK attack mitigation etc.. It could also be done be emitting
a known 1-bit signal whose pattern can be used to identify deviance from
that pattern, as discussed in separate thread, e.g. a square wave or a
public pseudo-random sequence.

The next, and separate question is then, do we want to expose anything even
if it only leaks information about loss and reordering on a single path? It
could lead to unwanted latency due to middleware packet sorting. It is a
very good point, but the concern might be based on a historical case that
does not apply to current UDP or future QUIC transports. However, if
ordering is exposed as a pseudo-random 1-bit signal such as the Pi
sequence, then middleware would have to work very harder than it would find
worthwhile to sort packets back in order.