[Spud] questions we need a prototype for

Brian Trammell <ietf@trammell.ch> Tue, 14 April 2015 13:27 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B161A9131 for <spud@ietfa.amsl.com>; Tue, 14 Apr 2015 06:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 q_vI6QywNkZE for <spud@ietfa.amsl.com>; Tue, 14 Apr 2015 06:27:06 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA6C1A912F for <spud@ietf.org>; Tue, 14 Apr 2015 06:27:06 -0700 (PDT)
Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 6DDAC1A00E5 for <spud@ietf.org>; Tue, 14 Apr 2015 15:27:05 +0200 (CEST)
From: Brian Trammell <ietf@trammell.ch>
X-Pgp-Agent: GPGMail 2.5b6
Content-Type: multipart/signed; boundary="Apple-Mail=_99D39EF5-A626-4222-928D-304213C6C338"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Tue, 14 Apr 2015 15:27:05 +0200
Message-Id: <FC8557A8-5B12-4BB7-B861-FF7819C1A58E@trammell.ch>
To: spud@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/HgKHNVE_G64vTDxhxuCBZVUc6aE>
Subject: [Spud] questions we need a prototype for
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2015 13:27:09 -0000

Greetings, all,

Following a discussion of the BoF proponents and chairs, we wanted to address the fact that many of the concerns raised at the BoF focused on the prototype itself: its current lack of anything that looks like security, the danger of it becoming The Spud Protocol, etc... So we thought it would be useful to ask, why do we want a prototype?

The discussion on this list of the threat models a substrate protocol must face has been useful, as have the discussions on what might be useful to expose -- it's clear even among people who think something like SPUD is a good idea that we have somewhat different visions and assumptions about this, and these discussions can get us closer to consensus on these questions. But we think the most direct way to answer these questions is to actually put packets on the MAC layer of your choice and see what happens.

Hence a prototype.

The first few questions we want answers to seem to be the following:

- ​​​​What current transport-and-payload-inspecting-middlebox features can be replaced by the selective exposure of which data by the endpoints when the application and transport information is encrypted, and we presume protection against MITM and cleartext fallback?

- What declarations (from applications, and from the path) are most useful from the application's point of view?

- What declarations (from applications, and potentially other path elements) are most useful from the point of view of devices on path?

- What are the incentives to deploy on both sides?

- What kinds of cooperation can we engender in an untrusted environment composed of path and application?

- What are the implicit trust relationships between endpoints and on-path devices now, and can making these explicit improve cooperation at all?

- Are explicit trust relationships even possible without significant latency, management overhead, and other costs?

- Are there mitigations for attacks on that cooperation?

From there we'll need to answer questions about the abstract interfaces among the layers and interlayers, but these "how" questions are a bit more fluid than the "what" questions. The http://github.com/iptube/SPUDlib is the start of one codebase we can use to set up experiments to try to answer these questions. My question to the list: what other questions can experimentation help answer?

Thanks, cheers,

Brian