Subject: Re: [Stackevo] [Udp35] Snowden and SPUD

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:
> 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.

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

> - jana
> 
> 
> 
> 
> On Mon, Jul 20, 2015 at 5:00 PM, Michael Welzl <[email-masked]> wrote:
> 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
> 
> _______________________________________________
> Udp35 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/udp35
> 
> _______________________________________________
> Udp35 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/udp35

---

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:
> 
> 
>> On 20. jul. 2015, at 17.14, Jana Iyengar <[email-masked]> wrote:
>> 
>> A few offhand thoughts:
> 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!

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 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.

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: Ken Calvert <[email-masked]>
Date: Mon, 20 Jul 2015 14:42:07 -0400

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

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.

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

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).

KC

> but else this just lacks incentive imo

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

---

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:
> 
> 

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: Brian Trammell <[email-masked]>
Date: Tue, 21 Jul 2015 09:48:58 +0200

(dropping udp35, it'll close soon...)

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

If QUIC develops in such a way that it meets the requirements we eventually decide we have, then that would make be very happy, yes.

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Tue, 21 Jul 2015 09:55:08 +0200

Sent from my iPhone

> On 21. juli 2015, at 09:48, Brian Trammell <[email-masked]> wrote:
> 

... and if it doesn't, who could keep you from making spudv2 look like quic on the wire? it may then lack some things that you want, but (as with spudv1) knowledgeable boxes might know how to correctly interpret the v2 stuff.  maybe, by using udp, quic really opens a door for us here?

or maybe this is getting too crazy...?!

m

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 21 Jul 2015 11:24:46 +0000

>... and if it doesn't, who could keep you from making spudv2 look like quic on the wire? it may then lack some things that you want, but (as with spudv1) knowledgeable boxes might know how to correc…

Yeah, at least you could do minion-mode for QUIC all in user space.

>or maybe this is getting too crazy...?!

Yes.  The architectural goal is to allow new transports to be deployed for a long time into the future. If QUIC hides enough of the transport semantics to ensure that they don't ossify, it could be a starting point.  At the moment, the HTTP semantics are a little too important in QUIC for it to meet the architectural goals, but it could be evolved.

Ideally, we would have a layer we could allow to ossify, a layer of evolving transport semantics, then multiple application semantics that can also be evolved on top of those.

-- 
Joe Hildebrand

---

From: Aaron Falk <[email-masked]>
Date: Tue, 21 Jul 2015 16:02:15 +0200

On Tue, Jul 21, 2015 at 1:24 PM, Joe Hildebrand (jhildebr) <
[email-masked]> wrote:

>
> The architectural goal is to allow new transports to be deployed for a
> long time into the future. If QUIC hides enough of the transport semantics
> to ensure that they don't ossify, it could be a starting point.  At the
> moment, the HTTP semantics are a little too important in QUIC for it to
> meet the architectural goals, but it could be evolved.
>
> Ideally, we would have a layer we could allow to ossify, a layer of
> evolving transport semantics, then multiple application semantics that can
> also be evolved on top of those.
>

Indeed.  I don't think QUIC has taken on any of the explicit communication
to middlebox functionality (but I'm willing to be corrected here).  Keep in
mind that middleboxes provide value to someone.  Again, I encourage folks
to look at Dave Clark's Tussle
<http://www.acm.org/sigs/sigcomm/sigcomm2002/papers/tussle.pdf> paper: if
you don't give key stakeholders the knobs they need to effect their
policies and business models they may very well jam them in anyways and
break your architecture, c.f. NATs.  When doing protocol design you have to
keep in mind that the balance of interests will be different in different
parts of the Internet (federal, enterprise, consumer, secondary schools,
etc etc) and design in knobs that allow those stakeholders (govt's,
operators, employers, citizens) to find the balance that works for them.
In my worse case nightmare scenario, we create a set of technologies that
are completely incompatible with these guys and that part of the Internet
never upgrades ("XP Forever!") or we have awful interworking functions
(remember WAP?) or sufficient governments decide the IETF is too idealistic
that standards control is given to the ITU (shudder).  YMMV.

--aaron

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 21 Jul 2015 07:26:06 -0700

The mayority of applications will be driven to meet the "open Internet"
deployment use case because thats where most of the money is. This use case
then drives most of the stack evolution in the most widely distributed
products. The adoption curve of IPv6 is an interesting example of this
logic. This use-case seems to not have enough interest in middle-boxes to create
good stack evolution. Yes, SPs would like to have better application identity
to better provide fair use policies, but their ecossytem engagements with application
developments is too weak to make a dent so far.

IMHO this is the biggest issue to deal with. 

In IPv6, we evolved across a felt 999 transition v6->v6 IETF solutions
before arriving now at a state where IPv6 is even called out mandatory to
implement by at least one ecossytem vendor and prefered in happy eyeballs. 
I would therefore contend that it is illusionary to do stack evolution without 
also leveraging the potential of similarily crappy/temporary intermediate
steps. 

For example: a stack evolution in which we can provide benefits to existing
unmodified applications is an area that would IMHO be good to
investigate. Example: LD preload library that offers TCP sockets but
uses SCTP over SPUD. In addition it spoofs application properties from
process name, user name etc. pp. Library would be installed by all those
operators in enterprises that do want middlebox friendly transport stacks.

Once something like this kicks in, at some point in time we will get app
developers explicitly programming against the APIs leveraging SPUD natively.

Just as an example. Don't have to love or arrive at SPUD. Scheme could be
applied via a lot of technical solutions. And wouldn't be  nearly as bad as
the pain we'd to go through in IPv4->IPv6 (no temporary transition stack crap on the wire).

Toerless