Subject: [Udp35] Snowden and SPUD

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Jul 2015 17:00:51 +0200

Hi all,

Edward Snowden said yesterday (in the Q&A session following the movie) that he thinks SPUD is a bad idea.

I think what he meant was: "it's a bad idea because it talks to middleboxes"; that anything that talks to middleboxes is a problem is something I would have trouble agreeing with. If we shouldn't try to talk to middleboxes in some way, aren't we stuck making progress regarding this ossification?

I wonder what people think about this, and if others perhaps perceived his statement to come from a different angle?

Cheers,
Michael

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 20 Jul 2015 17:14:09 +0200

A few offhand thoughts:
1. Snowden is not part of the SPUD conversations, so it's easy to be
confused about what the current thinking is. The current thinking is _not_
about simply "leaking" information to middleboxes. The details are
important here -- what information is being transmitted is, as a first
approximation, the same stuff that currently middelboxes get out of TCP and
ICMP (if those worked as intended). If there's more info, it's going to be
debated heavily for privacy concerns.
2. Snowden can engage in IETF SPUD meetings, and I'm sure he'd be welcome
to them.
3. It's all about rough consensus, not an individual's opinion.

4. Finally, and I have been concerned about this for a while now: I've
always said that the SPUD prototype should be distinct in name from the
SPUD effort. The prototype is the face of the effort and represents current
thinking for anyone glancing at this stuff, and it seems scary and
dangerous. We'd all be concerned if the SPUD prototype were the actual
protocol deployed, but that's supposedly not going to be the case. Which
begs the question: why spend any time on a protocol that is destined to not
make it? Why not actually figure out a protocol that *might* and then see
how to build it out?

- jana

On Mon, Jul 20, 2015 at 5:00 PM, Michael Welzl <[email-masked]> wrote:

> I think what he meant was: "it's a bad idea because it talks to
> middleboxes"; that anything that talks to middleboxes is a problem is
> something I would have trouble agreeing with. If we shouldn't try to talk
> to middleboxes in some way, aren't we stuck making progress regarding this
> ossification?
>
> I wonder what people think about this, and if others perhaps perceived his
> statement to come from a different angle?
>
> Cheers,
> Michael
>
> _______________________________________________
> Udp35 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/udp35
>

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Jul 2015 18:47:34 +0200

> On 20. jul. 2015, at 17.14, Jana Iyengar <[email-masked]> wrote:
> 
> A few offhand thoughts:
> 1. Snowden is not part of the SPUD conversations, so it's easy to be confused about what the current thinking is. The current thinking is _not_ about simply "leaking" information to middleboxes. The details are important here -- what information is being transmitted is, as a first approximation, the same stuff that currently middelboxes get out of TCP and ICMP (if those worked as intended). If there's more info, it's going to be debated heavily for privacy concerns.
> 2. Snowden can engage in IETF SPUD meetings, and I'm sure he'd be welcome to them.

I agree about all that - just wanted to hear thoughts (and if I got his message right)

> 4. Finally, and I have been concerned about this for a while now: I've always said that the SPUD prototype should be distinct in name from the SPUD effort. The prototype is the face of the effort and represents current thinking for anyone glancing at this stuff, and it seems scary and dangerous. We'd all be concerned if the SPUD prototype were the actual protocol deployed, but that's supposedly not going to be the case. Which begs the question: why spend any time on a protocol that is destined to not make it? Why not actually figure out a protocol that *might* and then see how to build it out?

Okay, I guess it’s time for me to say what I think about SPUD.

There are two parts here: the later rolled-into-SPUD AE(C)ON-and-before (flow metadata and whatever else it was called) ideas from Cisco. These are what they are, with their pro’s and deficiencies, and this is not what this email is about. I think we should focus on the original idea, which is about getting through middleboxes by “playing nice”. Here I think SPUD is trying to solve a problem that can’t be solved by protocol design. It’s not a design problem, it’s an incentive problem.

Consider the discussion about connection setup/teardown that happened on the SPUD mailing list some time ago. Someone said (s)he thinks it’s useless because in the middlebox, they will need a timer anyway, as one can’t simply trust the teardown message to arrive. Well, people do have more trust in TCP it seems … it seems to me that it’s a story of incentives and trust much more than it’s a story of how the protocol looks.

Here’s a thought experiment. Three (wrong) assumptions: 1) Assume, for a second, that native protocols would have a 50% chance of passing on the Internet (I think that’s too optimistic, but that’s not the point here). 2) Assume that browsers could send out native protocols.  3) Assume that QUIC would be such a native protocol.

Q: what would happen to the non-supportive paths?

I think we would quickly see this 50% number grow - because there’s a customer need associated with QUIC. People want it because it makes their browsers faster, as simple as that! Plus, it will earn trust points over time because it’s only generated in user space, comes from browsers, comes from Google, has been wider and wider tested….

Now, assume that QUIC would become a general-purpose carrier. All kinds of applications would start using it. Everything would be multiplexed over QUIC. What would middleboxes do? They would start looking deeper into QUIC, right? Same problem again!

The point of this story: I think you can’t make a general-purpose carrier that “plays nice” and convinces middleboxes that all is fine. That’s a bit too much Jedi magic IMHO.  What you can do is to try to convince them, service by service (“faster web browser”, ..). Now, here, Joe Hildebrand had a “carrot and stick” story that didn’t convince me - but perhaps I just never got it. Anyway, that’s the crux of the matter: IF AND ONLY IF the carrot - stick story makes sense, SPUD makes any sense. Else, you have to create a greater incentive, as QUIC will certainly do, but only for browsers.

(side note, this thinking is also behind TAPS)

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Mon, 20 Jul 2015 18:50:40 +0200

hi Jana, Michael, all,

> On 20 Jul 2015, at 17:14, Jana Iyengar <[email-masked]> wrote:
> 
> A few offhand thoughts:

Yep. So my cynical take on this is that Snowden doesn't like SPUD because the briefing sheet he had in front of him said he didn't like SPUD. I saw a lot of dkg's argument in Snowden's response. This argument goes something like this, as I understand it: a mechanism to expose *any* metadata from the endpoint will be misused to expose *all* metadata, and all that metadata will be used for tracking and fingerprinting; a mechanism that allows the addition of metadata will be misused by operators to gate packet forwarding on all sorts of evil things (from the "you watched the ad" cookie to the "your government supports your opinion, citizen" cookie).

Of course, you can already do all of these things and much, much more in the app layer *now*.

> 2. Snowden can engage in IETF SPUD meetings, and I'm sure he'd be welcome to them.

If anyone has a working email address that might end up with a message in front of him, I would be happy to send an invitation to do so. :)

> 3. It's all about rough consensus, not an individual's opinion.

Indeed. And I doubt this one individual's opinion has changed any minds on this point

> 4. Finally, and I have been concerned about this for a while now: I've always said that the SPUD prototype should be distinct in name from the SPUD effort.

Yes.

> The prototype is the face of the effort and represents current thinking for anyone glancing at this stuff, and it seems scary and dangerous.

What I have learned from this entire experience is that you can keep saying and saying and saying "this is a prototype and we will not build the real protocol on it" and nobody will believe you.

Stay tuned (on stackevo@) for a suggestion about renaming and reorganization that I hope will serve to reduce confusion.

> We'd all be concerned if the SPUD prototype were the actual protocol deployed, but that's supposedly not going to be the case. Which begs the question: why spend any time on a protocol that is destined to not make it? Why not actually figure out a protocol that *might* and then see how to build it out?

I'll let Joe answer that one because he'll be more eloquent about it.

Cheers,

Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Jul 2015 19:06:36 +0200

Hi Michael,

> Consider the discussion about connection setup/teardown that happened on the SPUD mailing list some time ago. Someone said (s)he thinks it’s useless because in the middlebox, they will need a timer…

Yes.  Sort of.  But I feel the need to jump up and down and TYPE IN ALL
CAPS:

A firewall in particular that is attempting to limit connectivity to
that which the host has initiated takes it as granted that a host knows
what to do if it sees a SYN ACK or ACK for a 5-tuple that has never been
SYN'd.  That requires ZERO state to maintain AND it even works with
multihoming.  That stateless firewall is good enough for many MANY
people.  Anything stateful can be built atop that simple understanding. 
If SPUD duplicates those semantics for UDP, that will have taken us a
long way.

> The point of this story: I think you can’t make a general-purpose carrier that “plays nice” and convinces middleboxes that all is fine. 

And yet we have proof of existence of just such a carrier: TCP

???

Eliot

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Jul 2015 19:11:49 +0200

Sent from my iPhone

> On 20. juli 2015, at 19:06, Eliot Lear <[email-masked]> wrote:
> 
> Hi Michael,
> 

ok, i see; not sure we have the same view of LONG here though. anyway, no harm in trying i s'ppose. i just think it's not solving the real problem cause it can't.

> And yet we have proof of existence of just such a carrier: TCP

wasn't that http?   (making my point)

you can get another tcp, i grant you that. what does that solve?

michael

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Jul 2015 19:16:25 +0200

oh and btw: your syn / synack assumes middleboxes trust end systems' tcps to act right - which is a point i made. will they immediately trust spud? why should they - just cause it's easy?  that's a weird reason to trust someone.

Sent from my iPhone

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Jul 2015 19:21:44 +0200

> oh and btw: your syn / synack assumes middleboxes trust end systems' tcps to act right - which is a point i made. will they immediately trust spud? why should they - just cause it's easy?  that's a…

"Immediately" is a word I might have some difficulty with, but if the
semantics are such that there's at least a high likelihood that the host
will do the right thing, that makes getting UDP through firewalls
easier, and that's got to be worth something to both app developers and
their users (the people who have a relationship with the people who
manage the firewalls).

And so this brings me back to your earlier note: nobody wants to
duplicate ALL of TCP.  It's there.  Twice if you count SCTP ;-)  But
others ARE using UDP and might find their applications more deployable
if they layer them atop SPUD (which could yet come for free with DTLS).

Eliot

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Jul 2015 19:30:57 +0200

Sent from my iPhone

> On 20. juli 2015, at 19:21, Eliot Lear <[email-masked]> wrote:
> 
> 
> 

but my point wasn't about functionality. it was about tcp's ability to pass. what i meant is: you can get yet another carrier that would work on port 80 for the web, etc.  fwiw.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 20 Jul 2015 19:33:25 +0200

(copying stackevo again as the successor to udp35)

> On 20 Jul 2015, at 18:47, Michael Welzl <[email-masked]> wrote:
> 
> 

Except they can't, because QUIC encrypts everything except the things that are explicitly exposed to the middleboxes. This is the intention with SPUD as well -- we redraw the network/transport layer boundary, this time with a big fat red marker that says go ahead, bruteforce my keys.

> The point of this story: I think you can’t make a general-purpose carrier that “plays nice” and convinces middleboxes that all is fine. That’s a bit too much Jedi magic IMHO.  What you can do is to…

The stick is "go ahead, bruteforce my keys."

The carrot is "here is something I am willing to tell you and you have to decide on your own if you trust me.

The axe-head attached to the stick is "if you don't let this through, then you get a giant pile of entropy that tells you nothing."

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Jul 2015 19:43:41 +0200

Sent from my iPhone

> On 20. juli 2015, at 19:33, Brian Trammell <[email-masked]> wrote:
> 

oops sorry

> The axe-head attached to the stick is "if you don't let this through, then you get a giant pile of entropy that tells you nothing."

i heard that before and wondered, on wondered, why would anyone let any of that pass, then?

so, and i'm serious: if we could do this with quic, that would help, right?

people would want quic to pass.... so "all or nothing" becomes a harder trade.

but else this just lacks incentive imo

---

From: Brian Trammell <[email-masked]>
Date: Mon, 20 Jul 2015 19:46:34 +0200

> On 20 Jul 2015, at 19:43, Michael Welzl <[email-masked]> wrote:
> 
> 
> Sent from my iPhone
> 

If QUIC comes into the IETF with IETF change control and acceptable licensing terms, SPUD and QUIC might not be different things.

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Jul 2015 23:47:07 +0200

> On 20. jul. 2015, at 20.42, Ken Calvert <[email-masked]> wrote:
> 
> 
> Same reason they would let QUIC pass: it will make applications work better - otherwise nobody will use it.  (Of course there's the obvious problem that it's not defined yet :-).  In any case, I agree that without noticeable improvement for users in some dimension(s), there's no point.
> 
> For some applications.  For others, it depends on whether the parts of QUIC "behind the veil" allow for evolution.
> Also, whatever is exposed will become ossified, so it should be designed with evolution in mind (whatever that means).

maybe that's not a problem?!

i just saw a part of brian's email that i had overlooked before as i was answering on my phone:

>> Except they can't, because QUIC encrypts everything except the things that are explicitly exposed to the middleboxes. This is the intention with SPUD as well -- we redraw the network/transport lay…

... doesn't that indeed make SPUD the ideal carrier for anything?  People have an incentive to let it pass, already now - but given that it's encrypted, they can't really be sure it is web traffic. SPUD lacks the incentive, but QUIC has it - make QUIC your new SPUD and you have it???

Cheers,
Michael

---

From: Ken Calvert <[email-masked]>
Date: Mon, 20 Jul 2015 14:42:07 -0400

KC

> but else this just lacks incentive imo

Ken Calvert
Professor
Gartner Group Chair in Network Engineering
Computer Science, University of Kentucky