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

Tom Herbert <tom@herbertland.com> Thu, 28 July 2016 18:17 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965FB12DB86 for <spud@ietfa.amsl.com>; Thu, 28 Jul 2016 11:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LwgNdqAw-eO for <spud@ietfa.amsl.com>; Thu, 28 Jul 2016 11:17:33 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A4B12DB8D for <spud@ietf.org>; Thu, 28 Jul 2016 11:17:29 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id f6so174509694ith.1 for <spud@ietf.org>; Thu, 28 Jul 2016 11:17:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=B4x34olIjqeWr2IMILdcKrCiXOwQR7TJ9cwovHsiB04=; b=XFOHnvlXUTpNESl0qmmo16UZKscIdpnlX8wLXDLyYFs3C8XzsTFiyAiA1FRsZ8hyOJ BJ0rPDDTrZj+3w1+sVOuEwk1bWp5M0daY6fJylIbrPccC87GIphvfmt7nguQ6Q0HcBQv 0zo33iUIgNw13rMj90ulPPwNqsgzIg1baV+yq4Vzwz8XmtiARj6feM934E0qefjK8yvU 6lbXrM6xkNr44aSs+w162CIjFBLDzpYEPWcPluUKDJRq3AYa0rjDBlTu+PIzMU2ESq6+ hpvCVqoJSiGNGdsz3EZZEme4UICvRmQ9p32Zc0l3PeCcScShrYEx9y+UgQ5ta/UTOdyv LglA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=B4x34olIjqeWr2IMILdcKrCiXOwQR7TJ9cwovHsiB04=; b=fOstj1zOTVMcPrKM90RgvPYCGK6R0/iGdK5IlXXY0Kbka7efPIkRnY6F3X51cltTjZ nIZ0H4mCboGVUst6H2GwujVIlCykzDC5VKCDwQJAByQHL8Dvh9Tq5xJltfCYftLjxm84 VYDXoFnRoZ24dGykEXQTKRgUFGqapyLeOALRiUgpovFYfNPDDRKL6eDDlZ7RgeF0c3N2 XNkELssN5stMw3J0Rje7tFH/8CxgxhICUv/gwy3JPHMJLHG5mFd3n9I6yFIUlsrM2Ohg rkfZotX4YH0WrcO6qBys9jSORojvzahXWA9DSWHMh+GtcL2KMwu7jXvjLHLodlX6lUMZ DrNw==
X-Gm-Message-State: ALyK8tKPV3sISNAdBna0iHJIQCM3lAArUxt+CsSiCz3eqJQN0fXj/iY9PKV5g2du5NHLhIRvdLctWK886Vifqw==
X-Received: by 10.36.80.2 with SMTP id m2mr51119129itb.37.1469729848895; Thu, 28 Jul 2016 11:17:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.130 with HTTP; Thu, 28 Jul 2016 11:17:28 -0700 (PDT)
In-Reply-To: <E8355113905631478EFF04F5AA706E98310462EA@wtl-exchp-2.sandvine.com>
References: <CAKC-DJjVF_mQb49BJmHNpt-VkJSX6JHXH8hTbYMm2bEYg3rgwA@mail.gmail.com> <CALx6S3636tzxpqjr5b+31sU5vg+8UyekhhR=R-3SUYeQhYvjug@mail.gmail.com> <E8355113905631478EFF04F5AA706E98310462EA@wtl-exchp-2.sandvine.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 28 Jul 2016 11:17:28 -0700
Message-ID: <CALx6S36jXoWZxrbictFD2z3=x8XTU6OAGLw-CJjkxrMwpaouYQ@mail.gmail.com>
To: Dave Dolson <ddolson@sandvine.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/l0C-WgQ5G_tWlmfpOaHd-7H0DQE>
Cc: Erik Nygren <erik+ietf@nygren.org>, Kyle Rose <krose@krose.org>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, spud <spud@ietf.org>
Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2016 18:17:35 -0000

On Thu, Jul 28, 2016 at 10:20 AM, Dave Dolson <ddolson@sandvine.com> 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: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