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

[Brian Trammell <[e-mail]>]

hi Tom,

> On 19 May 2016, at 19:50, Tom Herbert <[e-mail]> wrote:
> 
> On Thu, May 19, 2016 at 10:12 AM, 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 ... ?
>> 
>> 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").
>> 
> Not to mention that TOS and diff-serv are in-band signaling mechanisms
> to the network, ECN is explicitly signaling from the network.

DSCP is properly network-layer. If you believe in a "path layer" (which I'm pretty sure I do), you can argue that ECN is the first path layer protocol.

> Given
> that they've been around for many years but have never been widely
> deployed on the Internet

DCSP was defined in such a way that it makes little sense in an interdomain context, and its widespread intradomain deployment means that it will never deploy across domains in the general case.

I still hold out a (potentially irrational) hope for ECN's deployment.

> makes me wonder if any in-band signaling
> mechanism will ever catch on. The use of out of band signaling should
> be considered, especially considered that in many cases like NAT and
> firewall the network elements that need signaling are likely in local
> networks of one side of the connection.

As noted, out of band signaling is not explicitly out of scope in the current

> I have a similar concern about the statement that IP options/EH and
> extension headers are being left off the table as part of a solution.

I don't think they are off the table; a protocol such as what we propose to develop in PLUS could certainly use IPv6 extension headers, provided they can be implemented such that applications actually get access to those headers. IPv4 options are more of a stretch, simply due to questions about how well the path treats them.

> The fact that neither have these caught on in the Internet and that
> tells me two things 1) No IP option is needed for the Internet to
> operate and be successful which makes me wonder if signaling between
> network and hosts is even required 2) If the extensibility mechanisms
> of IP are chronically not deployable, I wonder why any alternative
> that does not yet exist but intends to solve the same problem would be
> any more deployable.

I'd assert that encapsulating things in UDP is certainly much more deployable *at the endpoints*. The open question is about adoption by on-path devices.

Cheers,

Brian

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