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

["Brian Trammell (IETF)" <[e-mail]>]

hi Kazuho,

Thanks for your message, comments inline, omitting some history for clarity...

> On 6 Apr 2018, at 12:10, Kazuho Oku <[e-mail]> wrote:
> 
> Hi Brian,
> 
> My comments inline.
> 
> 2018-04-06 18:38 GMT+09:00 Brian Trammell (IETF) <[e-mail]>:
>> 
>> 
>> 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.
> 
> I think that this is a very interesting question asking what the
> requirements of QUIC as a protocol is. Thank you for bringing the
> topic to table.
> 
> My argument against having an explicit signal for flow creation is
> that it is impossible to have such signal in a reliable way, and that
> trying to have no signal is better than having an unreliable signal.

I should say I'm not all that convinced that an advisory "flow start" signal is a good idea(*) -- I'm just saying that we seem to be trying very hard to keep a de facto advisory flow start signal from forming (which I would agree would be extremely undesirable indeed)... and we should step back and think about what properties flow start and end should have in QUIC, explicitly, as a function of requirements as opposed to philosophy.

> Let me explain why I think we cannot have a reliable signal.

<snip> All this makes very good sense and I agree with it: the signal cannot possibly be reliable in the general case.

> For flow closure, I think saving the battery by not sending a FIN
> packet after quiescence is more important than sending good signal to
> middleboxes

This is a hard problem, and it cuts both ways; if a server wants to maintain the ability to connect a client after more than the standard UDP NAT timeout (30s), it needs to send keepalives more often than once every 30s (thereby waking the client if it's on battery). Which side of this coin wastes more power is difficult to determine, since it's entirely dependent on the prevalence of each kind of activity in a given network. We can make plausible guesses both in favor of "get rid of FIN, it wastes endpoint power" or "we really need FIN to keep from wasting endpoint power".

So I'm more convinced of the value of advisory-end than advisory-start.

>> (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.)
> 
> I would rather argue that the goal of the alternative approach is to
> make the intentional flow creation not easily distinguishable to the
> extent that the middlebox vendors will refer to the RFC. Then, they
> can decide either to not limit QUIC flows starting from a 1-RTT
> packet, or to drop QUIC completely. And the issue is solved.


Let me try to rephrase this in wildly different terminology: "we can't come up with a grip that we think will wotk, so we should make flow start as slippery as possible"; or rather, a middlebox that thinks it's seeing QUIC should make its drop decision based on "this is QUIC" and not anything based on the state of the connection. That definitely has desirable properties with respect to future flexibility -- the start and end signaling would end up in the invariants rather quickly whether intentional or not. And ISTM that the probabilistic migration behavior would help to achieve it.

Cheers,

Brian


(*): "Advisory flow start" is somewhat different than "path-visible proof of return routability" and "path-visible indication of consent to continue communicating". The latter, IMO, has more value as part of a design to support in-network rejection of UDP garbage. But it's a more complex signal, since it involves revealing things that are hard to fake at flow establishment time, and is of course subject to the philosophical question of whether that's a good idea.