Re: [Udp35] Snowden and SPUD

Michael Welzl <michawe@ifi.uio.no> Mon, 20 July 2015 16:47 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: udp35@ietfa.amsl.com
Delivered-To: udp35@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6A21ACE92 for <udp35@ietfa.amsl.com>; Mon, 20 Jul 2015 09:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 sAtixiEkkPjP for <udp35@ietfa.amsl.com>; Mon, 20 Jul 2015 09:47:45 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378B71ACE74 for <udp35@ietf.org>; Mon, 20 Jul 2015 09:47:38 -0700 (PDT)
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1ZHEE4-0006po-G1; Mon, 20 Jul 2015 18:47:36 +0200
Received: from [130.129.233.50] by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1ZHEE3-0007dL-SQ; Mon, 20 Jul 2015 18:47:36 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <CAGD1bZbwkaYmH7WR_jb-wgkXfM7EjyExAy=P11V3CR_u40KKFQ@mail.gmail.com>
Date: Mon, 20 Jul 2015 18:47:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AED99648-40DE-4857-9F67-861C52252DF7@ifi.uio.no>
References: <DD4CE423-ABFD-41CA-8AA8-79DE2779A47B@ifi.uio.no> <CAGD1bZbwkaYmH7WR_jb-wgkXfM7EjyExAy=P11V3CR_u40KKFQ@mail.gmail.com>
To: Jana Iyengar <jri@google.com>
X-Mailer: Apple Mail (2.2070.6)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 31195 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 4AE5DBF3890BF93ECD1C33F19715AA5E2E952B3B
X-UiO-SPAM-Test: remote_host: 130.129.233.50 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 16 max/h 4 blacklist 0 greylist 0 ratelimit 0
Archived-At: <http://mailarchive.ietf.org/arch/msg/udp35/8c6gp-4V3gLKpvnlux3RibQdLco>
Cc: udp35@ietf.org
Subject: Re: [Udp35] Snowden and SPUD
X-BeenThere: udp35@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Life beyond UDP <udp35.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/udp35>, <mailto:udp35-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/udp35/>
List-Post: <mailto:udp35@ietf.org>
List-Help: <mailto:udp35-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/udp35>, <mailto:udp35-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2015 16:47:48 -0000

> On 20. jul. 2015, at 17.14, Jana Iyengar <jri@google.com> 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.
> 3. It's all about rough consensus, not an individual's opinion.

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