Re: Packet number encryption

[Marten Seemann <[e-mail]>]

On Wed, Feb 7, 2018 at 3:20 PM Christian Huitema <[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.