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

[Brian Trammell <[e-mail]>]

hi Michael,

> On 19 May 2016, at 19:12, Scharf, Michael (Nokia - DE) <[e-mail]> wrote:
> 
> Does the sentence ...
> 
>  The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements ...
> 
> actually wants to say something like
> 
>  The current Internet protocol stack has no layer for explicit *in-band* signaling of flow semantics and characteristics ... ?

Yes. One could make the argument that DSCP is an in-band signaling mechanism at the network layer, but as designed really does work at the network layer (i.e., it is explicitly applied per hop).

> I may be wrong, but there is no shortage of IETF and non-IETF protocols that can signal flow semantics and characteristics out-of-band, either path-coupled or path-decoupled, e.g., in the control or management plane. As a result, there are protocol "layers" for that signaling, but they are not in-band. There may also be other ways to fix this problem (e.g., by adding "end-to-end" or "inter-domain" instead of "in-band").

"Interdomain, in-band" would work for me here and be more accurate. "End-to-end" would imply to my ears that we only want the endpoints to participate, for which we don't need a layer -- that's transport's job.

Note that the current requirements document is not explicitly limited to in-band approaches, but the fact that the signaling has to get the same NAT and forwarding treatment would seem to be an implicit limit.

Cheers,

Brian

> Michael
> 
> 
> -----Original Message-----
> From: Stackevo-discuss [mailto:[e-mail]] On Behalf Of Brian Trammell
> Sent: Thursday, May 19, 2016 5:07 PM
> To: [e-mail]
> Subject: [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF
> 
> 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.
>> 
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud