Subject: [Spud] PLUS charter rev. 23 June

From: Brian Trammell <[email-masked]>
Date: Thu, 23 Jun 2016 11:29:34 +0200

Greetings, all,

We've updated the proposed PLUS charter based on outstanding issues (Christian's comment on threat modeling and mitigations) and added a list of things we believe to be out of scope based on list discussion.

New charter, as always, at https://github.com/ietf-plus/charter/blob/master/charter-plus.txt, and inline below.

Cheers,

Brian

Path Layer UDP Substrate (PLUS)
===============================

The PLUS working group's goal is to define a common shim layer atop the User
Datagram Protocol (UDP) to provide a transport-independent method to signal
flow semantics under transport and application control, necessary to enable
the deployment of new, encrypted transport protocols within the existing
Internet. UDP provides compatibility with currently deployed middleboxes as
well as ubiquitous support in endpoints, and supports userspace implementation
of new transport protocols. The working group will not specify any new
transport protocols.

The current Internet protocol stack does not provide explicit, in-band,
transport-independent signaling to on-path network devices. This has led to
the deployment of devices which perform implicit discovery of transport
semantics and traffic characteristics via inspection of protocol headers and
payload, a practice made possible when these are sent in the clear.

In order to support more ubiquitous deployment of encryption, and the
encryption of transport headers to allow deployment of new transport
protocols, explicit in-band signaling must be added to the stack. This
signaling must be transport protocol independent, and the types of information
signaled must be based on characteristics that can be independently verified
by devices on path, or that can be usefully applied without requiring a trust
relationship between endpoints and the path. Further, 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.

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.

The PLUS working group will specify a new protocol as a Path Layer
UDP 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 with integrity protection to devices on path

- allow devices on path to provide unencrypted feedback and information
  about the path directly to sending endpoints, under sending endpoint
  control

- allow devices on path to provide unencrypted information about the
  path to receiving endpoints, with encrypted feedback to the
  sending endpoint, under sending endpoint control

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, to make information exposure
transparent, and to limit the level of detail to that useful for network
treatment, while encrypting everything else. Endpoint verification of
signaling integrity, careful design of minimal data structures, and
restrictive policies for registration of signals can help to meet this goal.
This is important to avoid future implicit treatment and resulting
ossification, as well as to minimize the privacy risks presented by explicit
cooperation.

Given that the primary goal of PLUS is to enable the deployment of transport
protocols with encrypted 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 the use cases determined by the
working group. This specification will consider potential attacks against the
protocol, both arising from the encapsulation chosen as well as new attacks
made possible by the protocol, and propose mitigations for these attacks.

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 and work with other
working groups that could 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. DTLS) which could be used for encryption of
transport protocols running over PLUS.

Out of scope for the working group are:

- The design and specification of new transport protocols running over PLUS.
- Mechanisms for signaling among multiple devices on path between two endpoints
- Mechanisms for key exchange or cryptographic context establishment between endpoints and devices on path

---

From: Youjianjie <[email-masked]>
Date: Fri, 24 Jun 2016 03:20:02 +0000

Hi Brian,

If I understand correctly, I think PLUS provides an explicit in-band signaling which is protected by endpoint verification. Both the information provided to the devices on path or retrieved from the devices on path cannot be verified by each other. So it has some limitation on the information exposed. But we think it's a useful method for transport and encryption. We'd like to see more on this. 

Thanks,
Jianjie

> -----邮件原件-----
> 发件人: Spud [mailto:[email-masked]] 代表 Brian Trammell
> 发送时间: 2016年6月23日 17:30
> 收件人: spud
> 主题: [Spud] PLUS charter rev. 23 June
> 
> Greetings, all,
> 
> We've updated the proposed PLUS charter based on outstanding issues
> (Christian's comment on threat modeling and mitigations) and added a list of
> things we believe to be out of scope based on list discussion.
> 
> New charter, as always, at
> https://github.com/ietf-plus/charter/blob/master/charter-plus.txt, and inline
> below.
> 
> Cheers,
> 
> Brian
> 
> 
> well as ubiquitous support in endpoints, and supports userspace
> implementation of new transport protocols. The working group will not specify
> any new transport protocols.
> 
> protocols, explicit in-band signaling must be added to the stack. This signaling
> must be transport protocol independent, and the types of information signaled
> must be based on characteristics that can be independently verified by devices
> on path, or that can be usefully applied without requiring a trust relationship
> between endpoints and the path. Further, 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.
> 
> IPv6 options and extensions have deployment problems on their own, which
> makes it hard to include any additional information in these protocols.
> 
> The PLUS working group will specify a new protocol as a Path Layer UDP
> Substrate (PLUS), to support experimental deployment of explicit cooperation
> between endpoints and devices on path, with the following goals:
> 
> treatment, while encrypting everything else. Endpoint verification of signaling
> integrity, careful design of minimal data structures, and restrictive policies for
> registration of signals can help to meet this goal.
> This is important to avoid future implicit treatment and resulting ossification,
> as well as to minimize the privacy risks presented by explicit cooperation.
> 
> protocols with encrypted headers, we assume that the higher-layer protocol
> can provide an encryption context that can be used by PLUS to provide
> specification, together with an initial registry of types of information that can
> be exposed using PLUS, clearly aligned to the use cases determined by the
> 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