Re: Packet number encryption

[Christian Huitema <[e-mail]>]

On 1/30/2018 10:31 AM, Eric Rescorla wrote:
>
>
> On Tue, Jan 30, 2018 at 6:53 AM, Brian Trammell <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     hi Martin,
>     ...
>     I'm not sure this isn't completely crazy.
>

I think this beats the alternatives, either complex-but-fragile
obfuscation schemes, or separate per-path encryption contexts. Also, I
like that this is somewhat future-proof -- it allows building future
multipath extension at an almost minimal cost.


>     ...
>     Beyond this, though, we need to have a coherent idea of what we're
>     trying to prevent. From discussions to date, I think these are the
>     two cases we care about:
>
>     (1) An unprivileged on-path device that sees a packet from a flow
>     that is migrated on purpose by an endpoint (i.e., due to
>     connection migration or multipath) should not be able to associate
>     that packet to the prior flow.
>

Yes.

>
>     (2) An unprivileged on-path device that sees a packet from a flow
>     that is unintentionally migrated (i.e., one of its globally
>     routable addresses changes without the associated endpoint's
>     knowledge) should not be able to associate that packet to the
>     prior flow.
>

No. That one can only be solved through a voluntary action from the
sender. If the client is in the middle of sending a stream, correlation
is trivial whatever we do. There are however two plausible improvements:

a) Explicit migration after signalling by the NAT box. We would need
some new protocol to do that, maybe ICMP based. It could work in the
"mobile router" case.

b) Opportunistic migration out of quiescence. NAT rebinding typically
happen after a period of silence. Clients that just start sending after
a long silence may decide to "simulate a migration", to break the
correlation.

Both of these improvements will benefit from packet number encryption.

> ...
>
>     As Christian noted, using the short header type field to provide a
>     sort of subsequence number or other packet-number independent
>     explicit signal would mitigate the damage packet number encryption
>     would to do loss and reordering observability, but not completely
>     address them.
>

Yes. We have to be serious about network manageability. There has to be
a sweet spot between expose everything so network management sees it and
encrypt everything so middle boxes do not breach privacy or ossify the
protocol. I think tricks like the spin bit and/or a small-modulo
sequence number may be close to that sweet spot.

Part of me would want to see these spin bit and small modulo sequence
number down in the IP header. That would look like a very nice use of
the IPv6 flow-ID. Wouldn't it be nice if network management was based on
the network header? But failing that, maybe we need to start something
in QUIC.

-- Christian Huitema