Re: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))

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

Adding a “grib” sounds reasonable.

I previously mentioned my concern with CID ossification because length or
content might be used in lack of anything better.

The defense suggested - to grease the CID, will not work when a load
balancer says “I only support QUIC connections that use CID length x, and
sets the upper two bits like this.”, and this load balancer then gets a big
market share. Then greasing is out the window.

So it is better to provide an explicit signal for the cases that are
immediately obvious.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 6 April 2018 at 11.39.07, Brian Trammell (IETF) ([e-mail]) wrote:

Hi, Kazuho,

> On 6 Apr 2018, at 11:14, Kazuho Oku <[e-mail]> wrote:
>
>> It's multiplicative by a factor of three, which means that the max flow
concurrency will reduce by a factor of three. I agree it's probably
tolerable, but we do need to understand what we're actually getting for
that cost. I remain dubious about the actual privacy benefits WRT third
party passive surveillance here -- they don't accrue at all unless there's
a CGNAT in the way that doesn't bind an address/port range to a customer at
a given point in time. In the common case, ISTM that just burn more
in-network state than they additionally require at the surveillance point
to track the change. Defenses with such scaling curves are not a good idea.
>>
> I think I share the same concern.
>
> One way to minimize the impact could be to suggest certain amount of
connections (e.g., 5%) to gratuitously migrate to a new tuple just once,
right after the connection is being established.
>
> If we specify that way, we can assume that the impact on the NAT will be
having 5% more flows. Middlebox vendor that mistakenly tries to use the
cleartext bits in the packet header as the signal of connection initiation
will also see failures at the same rate.

If the goal is only ossification agility, ensuring that migration can
actually work, then this seems like a much better approach.

However, I would submit that if we think we are in a position where:

- there is a strong incentive for firewalls/NATs to want to see start- (and
end-) of flow (which seems to me to be the threat model we're trying to
mitigate with this); and

- we do not want arbitrary information in the QUIC wire image to be used to
detect these conditions, since that might cause bits of the wire image we
don't want to end up in the accidental invariants;

then we really should consider adding explicit advisory flow state signals,
both for establishment and teardown. The theory here is that if you give
in-network functions a "grip" in the wire image of the protocol they can
use for state management, they won't try to grab on to the slippery bits.
Together with probabilistic migration, these signals would divorce "on-path
state" from "transport session state", reducing the privacy impact with
respect to SYN/FIN in TCP.

(The alternative is to make the wire image so inscrutable that on-path
state tracking becomes completely futile and goes away. I'm not sure we're
that good at inscrutable wire images.)

Cheers,

Brian