Subject: [Spud] updated PLUS charter

From: Brian Trammell <[email-masked]>
Date: Tue, 24 May 2016 12:08:28 +0200

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.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 25 May 2016 12:33:01 +0000

Hi,

a few comments:

On 2016-05-24, at 12:08, Brian Trammell <[email-masked]> wrote:
> flow semantics under transport and application control.

Using the plural here ("new, encrypted transport protocols") sounds awfully broad. At the end of the charter, the text says "an experimental protocol specification" is the deliverable, which is much more constrained. Suggest to use similar wording here also.

> The approach from
> independent signaling of flow characteristics to on-path network devices.

I think it's been pointed out that this broad statement is incorrect in several ways, since we have many explicit, transport-independent signaling protocols (RSVP, NSIS, etc.) They are neither in-band (which I think you want here) nor are they generally deployed or deployable (which is also what I think you want here), so I suggest that this text be tightened, so that folks like me don't overreact :-)

> This
> the clear.

Another reason for DPI is that the network can't really in general trust what is signaled by the end points, and so it is attractive to try and obtain "the truth" by DPI (whether that is possible or not in all cases.) I'd like to raise that any new endpoint signaling method - i.e., the work proposed here - will have similar issues. It would be good to have some argument as to why PLUS will be different.

> Inspection and modification of unencrypted protocol headers is a
> transport protocol independent.

I again think you mean "in-band" signaling, since we have out-of-band signaling - well, at least many specs for it :-)

> While IP would seem to be the natural home for

Can we find a better word than "cleartext"? At least my mind immediately jumps to think about unstructured ASCII data in protocol headers. Maybe "unencrypted" or "not integrity-protected"?

> while encrypting everything else.

It would be good to add a half-sentence on how PLUS can achieve that goal (i.e., how can it limit what an app decides to signal)...

> This is important to avoid future

...because as you say that is important.

> TLS) which could be used for encryption of transport protocols

Lars

---

From: Aaron Falk <[email-masked]>
Date: Wed, 25 May 2016 14:41:30 +0000

There's a fair bit of redundancy which encourages nitpicking.  Suggest
cutting the 1st three paragraphs.  Start with "The PLUS working group will
specify a new protocol as a Path Layer User Substrate (PLUS)..."

--aaron

On Wed, May 25, 2016 at 8:33 AM Eggert, Lars <[email-masked]> wrote:

> Using the plural here ("new, encrypted transport protocols") sounds
> awfully broad. At the end of the charter, the text says "an experimental
> protocol specification" is the deliverable, which is much more constrained.
> Suggest to use similar wording here also.
>
> > The approach from
> I think it's been pointed out that this broad statement is incorrect in
> several ways, since we have many explicit, transport-independent signaling
> protocols (RSVP, NSIS, etc.) They are neither in-band (which I think you
> want here) nor are they generally deployed or deployable (which is also
> what I think you want here), so I suggest that this text be tightened, so
> that folks like me don't overreact :-)
>
> > This
> Another reason for DPI is that the network can't really in general trust
> what is signaled by the end points, and so it is attractive to try and
> obtain "the truth" by DPI (whether that is possible or not in all cases.)
> I'd like to raise that any new endpoint signaling method - i.e., the work
> proposed here - will have similar issues. It would be good to have some
> argument as to why PLUS will be different.
>
> I again think you mean "in-band" signaling, since we have out-of-band
> signaling - well, at least many specs for it :-)
>
> Can we find a better word than "cleartext"? At least my mind immediately
> jumps to think about unstructured ASCII data in protocol headers. Maybe
> "unencrypted" or "not integrity-protected"?
>
> It would be good to add a half-sentence on how PLUS can achieve that goal
> (i.e., how can it limit what an app decides to signal)...
>
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 May 2016 08:50:45 -0700

> Using the plural here ("new, encrypted transport protocols") sounds awfully broad. At the end of the charter, the text says "an experimental protocol specification" is the deliverable, which is muc…

The goal should not be as as constrained as the deliverables. The
goal of the PLUS working group is to enable broad followup work 
leveraging PLUS without that work necessarily having to happen in PLUS.

"NEW" is actually a big constraint. IMHO, it acknowledges that as far as IETF semantics
is concerned, that even taking TCP and trying to put it in PLUS would constitute
a NEW protocol and should not be seen as simply a different encap method of
TCP because of the current tie in's between TCP and IP (pseudoheader) that
would have to be reviewed and potentially require modifications to
the transport protocols semantic (see Joe's comments).

"Encrypted" is also a big constraint.

What in this thinking do you not agree to ? What text would you propose ?

> Another reason for DPI is that the network can't really in general trust what is signaled by the end points, and so it is attractive to try and obtain "the truth" by DPI (whether that is possible o…

Well, the strategy is "change even current TCP traffic to TCP-NG over PLUS. With TCP-NG
headers encrypted, the middlebox is forced to use PLUS signaling for session
detection". Once thats in in middleboxes, we can also do SCTP-NG over PLUS and
ACMETP over PLUS without the middlebox having any chance to do anything against this,
because it wouldn't be able to see the difference, it only sees PLUS headers/signaling.
(*-NG being acks to the NEW transport considerations from above)

Obviously, this strategy is based on getting some really busines critical
traffic on top of PLUS in the first place to make middleboxes start implementing
PLUS based filtering. Thats the industry dependency we have with a lot of
IETF work outcome, so not unusual. And given how nobody has stood up with a
better plan to achieve the goal defined by PLUS, thats why we should give it
a try. At least i can't see that any of the past IETF work did try this strategy,
so PLUS IMHO can't be shot down by the often heard "IETF been here, done that" mantra.

Not sure about the best way to make this strategy textually more crystal clear in the
charter.

Wrt to trusting the signaling from PLUS in middleboxes, the safe fallback
position seems to be "dear middlebox, just use the UDP port number space for filtering,
you've been doiong that crap with TCP port numbrers for decades, and we couldn't
stop you, so justs continue". Thats safe and pragmatic.

I too would like to see also more than just that to happen in PLUS,
eg: cryptographic authentication mechanisms of PLUS headers with middleboxes.
Alas, i've done a bit of research into this myself, and its quite tricky, so
if i was trying to go for WG chair in PLUS like Brian and Mirja are doing, then
i'd certainly would not want to have this on a first round of deliverables. If
PLUS manages to deliver the pragmatic solution, maybe we can put that onto a
charter for round 2.

> Can we find a better word than "cleartext"? At least my mind immediately jumps to think about unstructured ASCII data in protocol headers. Maybe "unencrypted" or "not integrity-protected"?

"Not integrity-protected" would be wrong. Some form of integrity protection
for either signaling in PLUS might actually be a first step towards (see above)
setting it further apart from prior technologies (Ok, admittedly RSVP
did explore it as well).

"unencrypted" +1 

> It would be good to add a half-sentence on how PLUS can achieve that goal (i.e., how can it limit what an app decides to signal)...

"Every PLUS attribute will be subject to IETF privacy inquisition waterboarding".

Oops, sorry. PC version: PLUS attributes will be subject to a privacy review
mechanism (to be defined). 

I would like to see as described in other emails mechanisms to allow
filtering of attributes when PLUS signaling leaves a trusted
controled (eg: home) network as well. Didn't see anyone picking up on that.

Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Brian Trammell <[email-masked]>
Date: Thu, 26 May 2016 10:06:27 +0200

Hi, Lars,

Thanks for the comments! Comment-comments inline, language mentioned has been added to the working copy of the draft charter.

> On 25 May 2016, at 14:33, Eggert, Lars <[email-masked]> wrote:
> 
> Hi,
> 
> a few comments:
> 

Hm; I see the point, it does set up the expectation that we're going to have lots of new transport protocols, as opposed to only the common substrate. How about:

The PLUS working group's goal is to define a common substrate protocol for
transport-independent of flow semantics under application and transport layer
control and encryption of transport layer headers, therefore enabling the
deployment of new transports in the Internet.

> I think it's been pointed out that this broad statement is incorrect in several ways, since we have many explicit, transport-independent signaling protocols (RSVP, NSIS, etc.) They are neither in-b…

Ah, oops... "in-band" fell back out here after the last rewrite of this paragraph. :/

> Another reason for DPI is that the network can't really in general trust what is signaled by the end points, and so it is attractive to try and obtain "the truth" by DPI (whether that is possible o…

Yep. So this becomes two paragraphs now IMO; how about:

The current Internet protocol stack does not provide explicit, in-band,
transport-independent signaling of transport semantics and 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.

Current signaling approaches are not generally deployable across administrative
domains, as they rely on out-of-band enforcement of honesty. There is no
incentive to believe and act on an imperative signal sent by an untrusted
endpoint or middlebox. By relying on a small signaling vocabulary in terms
of declarations of intentions, tolerances, and explicit tradeoffs, PLUS aims
to improve on this situation.

> I again think you mean "in-band" signaling, since we have out-of-band signaling - well, at least many specs for it :-)

Yep; will s/explicit signaling/explicit, in-band signaling/

> Can we find a better word than "cleartext"? At least my mind immediately jumps to think about unstructured ASCII data in protocol headers. Maybe "unencrypted" or "not integrity-protected"?

Yep. Technically, it's "and", and we don't talk about integrity protection yet, so the last three become:

- 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

> ...because as you say that is important.

Yep. So adding a sentence and tweaking the para slightly, how about:

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, 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.

Thanks, cheers,

Brian