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

[Martin Thomson <[e-mail]>]

I don't know how to game this one out.

If we're looking for mutual benefit, the best I can come up with is
that the middlebox knows about flow up/down, so it can extend timeouts
for most flows and endpoints thereby enjoy better chance of flow
liveness after longer periods of quiescence.  That would be something
like with TCP where you can expect timeouts to be in the order of
minutes or tens of minutes (30 minutes if you pick the right port
number) and not merely tens of seconds.

The problem here is that you need enough of the middlebox population
to extend timeouts in the common case.  Tuning to specific networks is
difficult and time-consuming.  So endpoints would deploy this "grip"
without any expectation of reciprocation for potentially a very long
time.  That's in the order of the end-of-life cycle for home routers,
or an entire Internet era.

In the meantime, endpoints have to assume flow liveness based on the
Internet of today.  30s is the benchmark now, despite the wishful
"requirement" for 2 minutes in RFC 4787.

Thus we end up with the tension between the documented wire image that
says that there is a "done" signal, and the actual wire image, which
has activity every 30 seconds.  Add genuine cases of migration,
crashes, stateless resets, and the other reasons that the "done"
signal doesn't appear and the timer has to come down.

There might be benefits if everything comes together, but it's a long
game to play.

On Fri, Apr 6, 2018 at 7:38 PM, 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