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

Tom,
Yes, firewalls do assume all packets go through them. This is how they
protect a (stub) network. They must be deployed such that this is true.

The E2E principle, I think, is intended to provide application developers
with a very useful abstraction, to make it easier to reason about the network.

But for network operators, the network isn't an abstract thing.
It isn't a cloud that provides infinite bandwidth between any pair of nodes.
There have been many creative ideas about how to build such a network,
which have been beneficial but led to ossification.

I think we need to understand what is to be the new contract between
endpoints and the network, to limit the "creativity".

-Dave

-----Original Message-----
From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Tom Herbert
Sent: Thursday, July 28, 2016 12:23 PM
To: Erik Nygren
Cc: Kyle Rose; Mirja Kühlewind; spud
Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)

On Thu, Jul 28, 2016 at 8:02 AM, Erik Nygren <erik+ietf@nygren.org> wrote:
> On Mon, Jul 25, 2016 at 4:20 PM, Mirja Kühlewind
> <mirja.kuehlewind@tik.ee.ethz.ch> 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

_______________________________________________
Spud mailing list
Spud@ietf.org
https://www.ietf.org/mailman/listinfo/spud