Re: [Spud] updated PLUS charter

[Aaron Falk <[e-mail]>]

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 <[e-mail]> wrote:

> Hi,
>
> a few comments:
>
> On 2016-05-24, at 12:08, Brian Trammell <[e-mail]> wrote:
> > 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.
>
> 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
> > 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.
>
> 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
> > 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.
>
> 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
> > 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.
>
> 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
> > 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
>
> 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"?
>
> > 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.
>
> 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
> > implicit treatment and the resulting ossification, as well as to
> > leverage the principle of least exposure to minimize privacy risks
> > presented by explicit cooperation.
>
> ...because as you say that is important.
>
> > 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.
>
> Lars
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>