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 10:20 AM, Dave Dolson <[e-mail]> wrote:
> 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.
>
The abstraction is only useful up to the point that networks preserve
the model. If the network breaks the model in ad hoc ways that forces
the application to try to compensate with more ad hoc mechanisms or
just stop innovating altogether as we see happened with protocol
ossification.

> But for network operators, the network isn't an abstract thing.

I think that would more appropriately be stated that for network
operators *their* network isn't an abstract thing. We haven't
particularly seem a lot of consistency how different operators run
their networks.

> 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.
>
Some of this creativity is beneficial, but it is also true that some
has also been malevolent. The problem from an application point of
view is that we have no insight as to what is being done with the data
being exposed. The only recourse we have to eliminate malicious use
and stop protocol ossification is to hide as much as possible from the
network-- this is why we want to encrypt the transport layer in the
first place.

> I think we need to understand what is to be the new contract between
> endpoints and the network, to limit the "creativity".
>
"contract" is a key word here. If there is an explicit trust
relationship with guarantees established between end nodes and devices
in the attached network, then there is a much better chance we
(application providers) would be willing to share transport layer
information (this the philosophy in the mobile guidance). Volunteering
arbitrary transport layer information to the network on the off chance
that some anonymous device we don't even know exists might find it
useful still seems like a big stretch to me.

Tom

>
> -Dave
>
>
>
> -----Original Message-----
> From: Spud [mailto:[e-mail]] 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 <[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
>
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud