Re: [Spud] SPUD Scope?

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2015-06-05 06:37:53 -0400, Szilveszter Nadas wrote:

> My concern is whether the whole SPUD exercise is worth the effort
> without extensibility. Assume that we can agree in a minimal set for
> b). What if in a few years' time we realize that we need more? Have
> not we already ossified the middlebox layer?

I think the "ossification of the network stack" means something
different than what you're using it to mean here.

On the networks i deal with, the ossification comes from middleboxes
being too fancy, and not just passing traffic the way that edge devices
expect.  As a result, the software running at the edge squeezes itself
into a very limited profile of network traffic just to avoid
harrassment/breakage by the (often unknown) middleboxes that might sit
on-path to any of its peers.

> About "metadata that our protocols leak", I completely agree that
> protocols should minimize this leaking. I think that explicit
> conversation is not leaking though and hopefully also discourages the
> middlebox owners to try to look into the protocol data itself.

how does the endpoint know that it is talking to an actual middlebox
that is relevant to its communication?  the endpoint wants to talk to
someone *other* than the middlebox (it wants to talk to the remote peer,
the middlebox is just a postal carrier), and it puts itself (and maybe
its peer) at risk if it entertains any "explicit conversation" from an
adversary posing as a middlebox.

There will always be middlebox vendors who think their business is the
deepest of packet inspection, whether they claim to offer Data Loss
Prevention or Malware Detection or some other unattainable goal.  I
don't see how any SPUD-like mechanism would deter those vendors from
cracking open any layer they can try to crack open.  And it sounds like
it would give them some points of leverage to start with, as well.

> Any device/firmware/Operating System/app still have and will have ways
> to leak whatever it wants, just by not allowing extensibility in SPUD
> we cannot stop it. At the same time extensible SPUD can be an engine
> for "good" cooperation.

Let's hear some examples of that "good" cooperation, and make sure they
include protections against abuse.  So far, the only example i've heard
is the ability for peers to mark each packet as delay-tolerant ("please
queue") or disposable ("please discard"), so that the middleboxes can
make a marginally better guess what to with it do under load.  The
argument for start/stop signalling for UDP still seems weak to me.

> About "keeping the smarts at the edge" the IAB program at least
> includes a goal to "(2) Improving path transparency in the presence of
> firewalls and middleboxes: guidelines for the detection of and
> cooperation with these devices to evolve away from present limitations
> on which protocols can be used across network boundaries, in order to
> facilitate innovation in transport protocol development. ".

You know why we can't innovate in transport protocol development, right?
Because too many middleboxes like to block traffic that they find
surprising.  If they were to stop blocking much of that traffic, we
could run things like SCTP or TCPCrypt reliably on the open Internet
instead of everyone pretending to be TLS-on-port-443, without the need
of anything like SPUD.

> About the UI/UX concern. This is definitely an issue and not an easy
> one to solve. Trust chains, delegation of trust, market apps
> controlling app rights are pieces of the puzzle to solve this. I think
> it is possible to find a solution for this with a good balance of ease
> of use and control.

I've seen no evidence of this (i also don't know what "market apps
controlling app rights" means). I'd love to see some pointers to
examples of UI/UX mockups that we can reason about (though i don't know
if SPUD is the right place to do this).

Regards,

     --dkg