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

[Aaron Falk <[e-mail]>]

Oh, and there should be some draft deliverables so we can have a fight
about the realism of the associated dates.

On Tue, Jun 7, 2016 at 1:40 PM Aaron Falk <[e-mail]> wrote:

> 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
>>
> --
--aaron

=====Short message from my phone=====