Re: [Spud] updated draft PLUS charter, rev. 1 June

[Aaron Falk <[e-mail]>]

Apologies for being behind on the list and maybe repeating points that have
been made.  A few comments based on my review of the BoF proposal & charter:


   - 1st para of the charter says “The working group will not specify any
   new transport protocols.” and the 5th para says “The PLUS working group
   will specify a new protocol”.  I think the latter statement is correct.
   - I’d like to see a comment on PLUS re-enabling ICMP functionality
   - There’s the obvious & unaddressed question about the relation to QUIC
   - The PLUS Bof description should start something like “This BoF is to
   discuss the proposed PLUS working group.  The wg’s goal is to…”
   - No discussion of wg anti-goals.  I had heard some interest in ruling
   middlebox to middlebox signaling as out of scope.
   - (To ADs:) Would like to see the QUIC and PLUS BoFs scheduled
   back-to-back.  While I think the topics are mostly separable, if the
   discussion gets out of sync it will be a headache.

HTH,

--aaron


On Wed, Jun 1, 2016 at 6:45 AM Brian Trammell <[e-mail]> wrote:

> Greetings, all,
>
> We've taken another editing pass to tighten the charter; results inline
> below at on GitHub (https://github.com/ietf-plus/charter). We think this
> is getting close to something it would be useful to discuss and wordsmith
> at a BoF.
>
> Further comments welcome.
>
> Thanks, cheers,
>
> Brian and Mirja
>
>
> 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. 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.
>
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>