Re: [Udp35] Snowden and SPUD

[Michael Welzl <[e-mail]>]

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

> On 20. juli 2015, at 19:06, Eliot Lear <[e-mail]> wrote:
> 
> Hi Michael,
> 
> On 7/20/15 6:47 PM, Michael Welzl wrote:
> 
> 
>> 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.
> 
> 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.
> 
>> 
>> 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.
> 
> And yet we have proof of existence of just such a carrier: TCP
> 
> ???
> 
> Eliot
> 
>