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

[Kazuho Oku <[e-mail]>]

2018-04-06 21:39 GMT+09:00 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.

Thank you for the clarification.

>> 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".

The case of server reviving the connection is interesting.

If we are to have some signal, I think that should be "path-visible
indication of consent to continue communicating" as you describe,
specifically, as a signal that can be set on every packet for which,
at the moment of sending, the endpoint is sure that the server will
not send any more packets unless it receives a new packet from the
client.

A NAT aware of the signal can drop an idle UDP flow on which the last
packet had that flag set, after couple of round-trips, thereby giving
other flows a longer idle timeout.

The benefit of defining the signal this way is that there would be no
need to send FIN after quiescence to shut down the hole.

That said, I would prefer not discussing this as a feature of QUICv1
for several reasons: i) this can be implemented in v2 ii) having such
signal is not going give us benefit in the short-term, so no need to
hurry iii) many of us are interested in shipping v1 as early as
possible iv) HTTP (which is the application protocol in focus for v1)
is not going to suffer a lot from the server-revives-connection
problem since HTTP is a request-response protocol.

>
> 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.
>



-- 
Kazuho Oku