[Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF

[Brian Trammell <[e-mail]>]

Greetings, all,

Forwarding this to the correct address for this mailing list (oops). Please discuss at [e-mail].

Thanks, cheers,

Brian

> Begin forwarded message:
> 
> From: Brian Trammell <[e-mail]>
> Subject: Possible WG-forming follow-on to SPUD BoF
> Date: 19 May 2016 at 17:04:50 GMT+2
> To: [e-mail]
> Cc: [e-mail], [e-mail], "Mirja Kuehlewind (IETF)" <[e-mail]>, Spencer Dawkins at IETF <[e-mail]>
> 
> Greetings, all,
> 
> We propose to hold a working-group forming BoF in Berlin as a follow-on to the SPUD work, to define a common substrate protocol for encrypted transports based on the requirements derived from experimentation with the SPUD prototype.
> 
> First, note that since the acronym "SPUD" refers primarily to the prototype itself, any follow-on working group should have a different name. We're using the derived requirements, not starting for the prototype. The name is a subject for discussion, and suggestions are welcome. To have something to put in the proposed charter, we'd propose "Path Layer UDP Substrate" (PLUS) as a starting point.
> 
> The proposed charter appears below. We're interested in hearing initial feedback on the proposed charter in preparation for a BoF proposal (the cutoff date is two weeks from tomorrow, on Friday 3 June). Is there work to do here within the IETF? Is the scope of the proposed charter appropriate? Is there energy to do this work?
> 
> Thanks, cheers,
> 
> Brian and Mirja
> 
> 
> 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 current Internet protocol stack has no layer for explicit signaling of
> flow semantics and characteristics to network elements, nor an integrated
> signaling mechanism from network elements to back to endpoints and
> applications. This layer never evolved within the stack, because middleboxes
> and other devices on path could simply inspect and modify headers and payload
> of unencrypted traffic at every layer. This implicit use of information from
> the transport and application layers is a key origin of the ossification that
> makes it hard or impossible to deploy new protocols.
> 
> In order to support more ubiquitous deployment of encryption, 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 similar semantics to existing protocols (e.g. TCP) to devices on path (e.g. NATs and firewalls)
> 
> - allow applications and transport protocols to explicitly provide limited information to devices on path
> 
> - allow devices on path to provide feedback and information about the path to sending endpoints, under sending endpoint control
> 
> - allow devices on path to provide information about the path 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,
> fully encrypted transport protocols, 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 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.
>