[Spud] Possible WG-forming follow-on to SPUD BoF

[Brian Trammell <[e-mail]>]

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.