[Spud] updated PLUS charter
Brian Trammell <ietf@trammell.ch> Tue, 24 May 2016 10:08 UTC
Return-Path: <ietf@trammell.ch>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517EF12D65C for <spud@ietfa.amsl.com>; Tue, 24 May 2016 03:08:33 -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 NIFZ3i1LfjKO for <spud@ietfa.amsl.com>; Tue, 24 May 2016 03:08:31 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2C812B02D for <spud@ietf.org>; Tue, 24 May 2016 03:08:30 -0700 (PDT)
Received: from [IPv6:2001:67c:64:49:f960:f4a2:6702:8e83] (unknown [IPv6:2001:67c:64:49:f960:f4a2:6702:8e83]) by trammell.ch (Postfix) with ESMTPSA id 988F01A167F for <spud@ietf.org>; Tue, 24 May 2016 12:08:29 +0200 (CEST)
From: Brian Trammell <ietf@trammell.ch>
X-Pgp-Agent: GPGMail 2.6b2
Content-Type: multipart/signed; boundary="Apple-Mail=_9314F6F9-A956-433C-87A3-6E70EEC45919"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Date: Tue, 24 May 2016 12:08:28 +0200
Message-Id: <D854766A-83D6-4605-8484-4ED06BB5F9CC@trammell.ch>
To: spud <spud@ietf.org>
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/spud/4eWLrzH4dGajc3G50TuRqFLf_Og>
Subject: [Spud] updated PLUS charter
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 24 May 2016 10:08:33 -0000
Greetings, all, Consolidating edits from yesterday, here's the present state of the charter (working copy at https://github.com/ietf-plus/charter). Thanks, cheers, Brian 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 approach from which the working group will start is a shim layer based on the User Datagram Protocol (UDP), which provides compatibility with existing middleboxes in the Internet as well as ubiquitous support in endpoints, and provides for userspace implementation. The current Internet protocol stack does not provide explicit, transport- independent signaling of flow characteristics to on-path network devices. This has led to the deployment of devices which perform implicit discovery of these characteristics, through inspection of protocol headers all they way up to the application layer, a practice made possible because these headers are sent in the clear. Inspection and modification of unencrypted protocol headers is a key cause of the ossification that makes it hard or impossible to deploy new protocols. In order to support more ubiquitous deployment of encryption, and the encryption of transport headers to allow deployment of new transport protocols, 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 basic TCP-like semantics (e.g. SYN, FIN, RST flags) to devices on path (e.g. NATs and firewalls). - allow applications and transport protocols to explicitly provide limited information in cleartext to devices on path - allow devices on path to provide feedback and information about the path in cleartext to sending endpoints, under sending endpoint control - allow devices on path to provide information about the path in cleartext 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 transport protocols, encrypting transport protocol headers, 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 (SPUD) 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.
- [Spud] updated PLUS charter Brian Trammell
- Re: [Spud] updated PLUS charter Eggert, Lars
- Re: [Spud] updated PLUS charter Aaron Falk
- Re: [Spud] Lars: updated PLUS charter Toerless Eckert
- Re: [Spud] updated PLUS charter Brian Trammell