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

[Mirja Kühlewind <[e-mail]>]

Hi Aaron,

a few comments/answers mostly as proponent (if not indicated differently) in line. 

> Am 07.06.2016 um 19:44 schrieb 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.

As AD, I find this less important then the rest of the text. As proponent, I think the milestones/deliverables are more important than the dates... And there are actually a few open questions here, that I would like to discuss in BoF. But I guess we can start this discussion on the list before the meeting.

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

No both is correct. Yes, we want to specify a new protocol, but I wouldn’t call it a transport protocol, because it’s ‚only‘ a signal shim layer, which does not have any of the other typical transport feature because there always has to be a ‚real‘ transport protocol on top. With this first sentences we wanted to make that clear; maybe it’s still not clear enough.

> 	• I’d like to see a comment on PLUS re-enabling ICMP functionality

Yes, that’s a very good use case and clearly in scope. However, there are other good use cases as well, see the use case draft, and we decided to not explicitly outline one (of a subset of them) in the charter.

> 	• There’s the obvious & unaddressed question about the relation to QUIC

I also think that this does not really belong in the charter. It’s for sure important to make this clear in the BoF and that why we have the agenda item on 'Relationship to other work in the IETF‘.

> 	• The PLUS Bof description should start something like “This BoF is to discuss the proposed PLUS working group.  The wg’s goal is to…”

Don’t know; isn’t that implicit for a working group forming BoF…?

> 	• No discussion of wg anti-goals.  I had heard some interest in ruling middlebox to middlebox signaling as out of scope.

That’s a good point. I believe that’s out of scope and would be willing to add that.

> 	• (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.

As AD, we already discussed that we would like to see the QUIC BoF first because at least I believe otherwise there is a high risk to have the QUIC BoF in the SPUD BoF. However, I don’t think back to back is a good idea (to have some cooling down phase in the mean time). And given that both BoFs look for a 2.5h slots, they probably will be in two morning slots on different days.

Mirja



> 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=====
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud