Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)

[Tom Herbert <[e-mail]>]

On Thu, Jul 28, 2016 at 8:02 AM, Erik Nygren <[e-mail]> wrote:
> On Mon, Jul 25, 2016 at 4:20 PM, Mirja Kühlewind
> <[e-mail]> wrote:
>>
>> As mentioned by Ted, this is actually not what we propose. The mechanism
>> we propose is exposing information under endpoint control which is a very
>> important point here. The endpoint has to add an option to send (or request)
>> a specific bit of information (which also must be registered by IANA with
>> IESG approval). This is just the same as TCP options or IP option headers.
>> The only difference is that PLUS has a MAC which allows detection of
>> middlebox manipulation (which is not the case for other existing protocols
>> such as TCP options). This is another a very big and important aspect of
>> what we propose with PLUS as our goal is to encrypt everything above PLUS
>> including the TCP header and TCP options in future. Especially encrypting
>> TCP option is important because TCP options provide much less control than
>> what we propose with PLUS today which is a problem (especially as currently
>> still unto 90% of the traffic is TCP). So I actually though we are on the
>> same page here and have a common goal.
>
>
> I'm not sure that we get enough value out of extensibility or being overly
> generic here, at least for practical non-research purposes.  If there is a
> tightly defined set of things allowed, we'll quickly ossify on these
> anyways.  As firewall vendors will just bake in those registered by IANA
> when they ship their product and then we'll be right back where we are today
> with IPv6 extension headers.
>
> I'd propose that it may make more sense to define a fixed header prefix
> format that contains the right set of features needed to solve the problems
> of QUIC and WebRTC (and other future UDP protocols).  Along with this, also
> define a common set of requirements for protocols using this header prefix
> (eg, around DDoS reflection prevention).
>
> Having a toolkit for things like handling connection ids in a way that
> support multipath mobility, stateless load-balancers, DDoS resiliance, and
> which minimize linkability would also be a nice-to-have to prevent each UDP
> protocol from having to come up with subtly different ways to solve this set
> of problems.
>
> For example, a bare minimum set of features might include:
>
> * Opportunistic signalling to middle-boxes (NATs and Firewalls) for when
> they can discard connection state.  Unless we want to declare that new UDP
> protocols only work with IPv6 (worth seriously considering, but perhaps not
> realistic yet), there just aren't enough {IPv4,port} tuples available for
> NATs to support large numbers of users with large numbers of UDP connections
> without having crazy-short keep-alive lifetimes.  Middle-boxes will always
> need to be aware that this is best-effort (the FINs can be dropped or lost
> or not sent by malicious clients, especially during multipath transitions)
> but this could make life much better for well-behaved clients and things
> like the existing NATs which use port ranges per client might encourage
> clients to be well-behaved here on average.
>
>From an application provider point of view, I am still very dubious of
purposely exposing connection state so that anonymous middleboxes can
track my connections. As pointed out at the mic during the PLUS BOF,
firewalls currently assume that all packets go through their device--
if packets are routed to some random middlebox then my transport layer
connection can be dropped by the device just because the middlebox
doesn't have state. This breaks the E2E model of the Internet and
kills our ability to use multipath and multihoming. Any device that
assumes a singular path for a connection is therefore the problem;
this is not a model that we want to perpetuate in PLUS.

Tom