[Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF

Brian Trammell <ietf@trammell.ch> Thu, 19 May 2016 15:07 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: stackevo-discuss@ietfa.amsl.com
Delivered-To: stackevo-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D1D12D142 for <stackevo-discuss@ietfa.amsl.com>; Thu, 19 May 2016 08:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 cuVicHO82ina for <stackevo-discuss@ietfa.amsl.com>; Thu, 19 May 2016 08:07:40 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id AD9D412D4FC for <stackevo-discuss@iab.org>; Thu, 19 May 2016 08:07:39 -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 12B141A0B50 for <stackevo-discuss@iab.org>; Thu, 19 May 2016 17:07:09 +0200 (CEST)
From: Brian Trammell <ietf@trammell.ch>
X-Pgp-Agent: GPGMail 2.6b2
Content-Type: multipart/signed; boundary="Apple-Mail=_7E0F4769-A3AC-4E62-B954-1C1C00DBAF86"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Thu, 19 May 2016 17:07:08 +0200
References: <7EE2C4F8-98D4-493A-9778-FB6697B4A4DF@trammell.ch>
To: stackevo-discuss@iab.org
Message-Id: <825141DA-F346-412A-A52C-53BF81EC6502@trammell.ch>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/NCRJ9iYSwo0uKrV6ND24ibBicY0>
Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF
X-BeenThere: stackevo-discuss@iab.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IP Stack Evolution Discussion List <stackevo-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo-discuss/>
List-Post: <mailto:stackevo-discuss@iab.org>
List-Help: <mailto:stackevo-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2016 15:07:42 -0000

Greetings, all,

Forwarding this to the correct address for this mailing list (oops). Please discuss at spud@ietf.org.

Thanks, cheers,

Brian

> Begin forwarded message:
> 
> From: Brian Trammell <ietf@trammell.ch>
> Subject: Possible WG-forming follow-on to SPUD BoF
> Date: 19 May 2016 at 17:04:50 GMT+2
> To: spud@ietf.org
> Cc: stackevo-discuss@ietf.org, tsv-area@ietf.org, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>et>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
> 
> Greetings, all,
> 
> We propose to hold a working-group forming BoF in Berlin as a follow-on to the SPUD work, to define a common substrate protocol for encrypted transports based on the requirements derived from experimentation with the SPUD prototype.
> 
> First, note that since the acronym "SPUD" refers primarily to the prototype itself, any follow-on working group should have a different name. We're using the derived requirements, not starting for the prototype. The name is a subject for discussion, and suggestions are welcome. To have something to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (PLUS) as a starting point.
> 
> The proposed charter appears below. We're interested in hearing initial feedback on the proposed charter in preparation for a BoF proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to do here within the IETF? Is the scope of the proposed charter appropriate? Is there energy to do this work?
> 
> Thanks, cheers,
> 
> Brian and Mirja
> 
> 
> Path Layer UDP Substrate (PLUS)
> ===============================
> 
> The PLUS working group’s goal is to enable the deployment of new, encrypted
> transport protocols, while providing a transport-independent method to signal
> flow semantics under transport and application control.
> 
> The current Internet protocol stack has no layer for explicit signaling of
> flow semantics and characteristics to network elements, nor an integrated
> signaling mechanism from network elements to back to endpoints and
> applications. This layer never evolved within the stack, because middleboxes
> and other devices on path could simply inspect and modify headers and payload
> of unencrypted traffic at every layer. This implicit use of information from
> the transport and application layers is a key origin of the ossification that
> makes it hard or impossible to deploy new protocols.
> 
> In order to support more ubiquitous deployment of encryption, explicit
> signaling must be added to the stack, and it must be transport protocol
> independent. While IP would seem to be the natural home for this facility,
> both IPv4 and IPv6 options and extensions have deployment problems on their
> own, which makes it hard to include any additional information in these
> protocols.  Additionally, a feedback channel that provides information from
> on-path devices back to endpoints and applications, e.g. for error handling,
> is essential for the deployment and success of an explicit cooperation
> approach.
> 
> The PLUS working group will specify a new protocol as a Path Layer User
> Substrate (PLUS), to support experimental deployment of explicit cooperation
> between endpoints and devices on path, with the following goals:
> 
> - enable ubiquitous deployment of encrypted higher layer protocols by providing exposure of similar semantics to existing protocols (e.g. TCP) to devices on path (e.g. NATs and firewalls)
> 
> - allow applications and transport protocols to explicitly provide limited information to devices on path
> 
> - allow devices on path to provide feedback and information about the path to sending endpoints, under sending endpoint control
> 
> - allow devices on path to provide information about the path to receiving endpoints, with feedback to the sending endpoint, under sending endpoint control
> 
> Note that this approach explicitly gives the control of information exposure
> back the application and/or transport layer protocol on the end host. It is
> the goal of PLUS to minimize the information exposed at the level of detail
> that is useful for the network, while encrypting everything else. This is
> important to avoid future implicit treatment and the resulting ossification,
> as well as to leverage the principle of least exposure to minimize privacy
> risks presented by explicit cooperation.
> 
> Given that the primary goal of PLUS is to enable the deployment of arbitrary,
> fully encrypted transport protocols, we assume that the higher layer protocol
> can provide an encryption context that can be used by PLUS to provide
> authentication, integrity, and encryption where needed. The primary threat
> model to defend against will be modification or deletion of exposed
> information by middleboxes and other devices on path, by allowing a remote
> endpoint to detect modifications.
> 
> The working group will start with an initial set of use cases (see
> draft-kuehlewind-spud-use-cases) and requirements (see draft-trammell-spud-req),
> taken from experience with the Substrate Protocol for User Datagrams prototype.
> The working group's main output will be an experimental protocol specification,
> together with an initial registry of types of information that can be exposed
> using PLUS, clearly aligned to these use cases and requirements. The working
> group will close if it is not able to come to consensus on a protocol design
> to meet these requirements.
> 
> The working group will additionally aim to identify other working groups that
> could or should address parts of these requirements within existing protocols,
> e.g. by specifying new protocol extensions or as input for on-going
> standardization work. It will aim to work with working groups defining
> encryption protocols (e.g. TLS) which could be used for encryption of
> transport protocols running over PLUS.
>