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

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

Hi Toerless,

thanks for the detailed feedback. Find selectively a few comments inline for now. Brian and I will be working on updating the charter and then come back to you and the list.


> Am 20.05.2016 um 17:09 schrieb Toerless Eckert <[e-mail]>:
> 
>> 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.
> 
> Don't like don't understand this paragraph.
> - What if we do not develope new transprt protocols but recipes
>  how to modify existing transport protocols to run in PLUS ?

Sorry, that’s actually seems to be easily miss understandable. What we wanted to say it, that PLUS will make it easier to deploy new protocol as well as encrypted protocols. However, in the wg we do not plan to design any new protocol and as a starting point we will implement PLUS for the use with existing protocols of course. We will clarify this sentences.

> - "We are going to cook stew while juggling 4 balls". The relationship
>  between the two is not really clear from the sentence. 
> - What does "under transport and application control" mean ?

… vs. middlebox control. The big goals is to give the control back to the owner which is the some layer in the endhost.

> - Does not cover the key aspect of being able to implement these protocols
>  as part of application code.

Yes, for us that is not the main goals. However. you do find this in the requirements doc (draft-trammels-spud-req). Of course we do not list all requirements in the charter. For me this is rather a question of deployability (than functionality). However, I know how important this point is for application designers. Still providing PLUS functionality should be possible in user space as well as in the kernel. I’m sure we will have this discussion on-going in a potential wg. I don’t think it not to be emphasized that much in the charter. For it is just one aspect/benefit of many.

> 
> The goal of the PLUS working group is to overcome ossification of
> deployments of new transport layer work. PLUS will develop a new
> transport layer approach with the following properties:
> 
> - The transport protocol is encrypted.
> - A transport protocol independent inband layer is used for signaling of
>  flow semantics.
> - The transport layer can be implemented in application layer code.
> 
>> The current Internet protocol stack has no layer for explicit,
>> in-band signaling of flow semantics and characteristics to network
>> elements in an interdomain context, 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 cause of the ossification that makes it hard or impossible
>> to deploy new protocols.
> 
> First paragraph wrong if you take STUN/ICE/MALICE into account.
> Second paragraph unfair because it's hitting only one side. Give
> the IETF some friendly slapping too, please.

We already added the work in-band here.

> 
> Proposed text:
> 
> Traditionally, the Internet protocols did not provide explicit,
> transport protocol independent signaling of flow characteristics to
> on-path network devices. In return, the industry developed the practice
> of inspecting protocol headers all the way from the transport layer
> ports to application payload. This practice is called DPI (Deep Packet
> Inspection. Later on, middleboxes started to filter or modify deep
> into packets as well, for example to fix up IP addresses in application
> layer protocols in NAT middleboxes. This was all possible because
> historically all these layers where (and partially are) unencrypted. 
> 
> Later IETF standards track onpath signaling work such as RSVP or NSIS could not
> overcome this practice because it could not not solely be implemented by
> applications interested in it because these protocols had to be implemented by
> OS vendors. Investmenting in these protocols was unattractive too, because
> by default middleboxes that do not support these protocols would simply
> drop them: The practice of unspecified, vendor specific DPI had lead to a
> "security" model in middleboxes where it was impossible to deploy new
> transport protocols that could be recognized and supported by pre-existing
> middleboxes without new work on these middleboxes. This lead to ossification
> in deployment of new transport work. 
> 
> In recent years, STUN/ICE and extensions to it started to introduce
> the ability for onpath inband explicit signaling to middleboxes, but
> being limited to be used purely with existing UDP based transport options,
> they do not address how to solve the problem for applications using
> non-UDP transport.

This is very much focused to the application view. This is also right but we tried to keep the charter short and focused and therefore this not further discuss these (as well as other) aspect in detail. Brian and I will have another look at this, but as I said I don’t think it is need to  elaborate (only) this aspect that much.

> 
>> 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.
> 
> Better:
> 
> The natural layer for flow information is between Internet and Transport
> protocols - IP/IPv6 options/extensions or a common transport sublayer.
> Implementation in the IP/IPv6 layer makes it difficult o adopt though
> because it would not allow for implementation in application code.

Your last sentence is not the point we were trying to make here. Again your view is very application-centric (which is not bad; just saying that other people have other views on the problem). We simply wanted to shortly note that there are deployment issues with IP option, e.g. slow path processing of IPv6 options.

> 
>> 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
>                                            ^^^ transport and

Here our view on higher layer is everything above PLUS (higher than PLUS) therefore including transport.

>> 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
> 
> So.. The biggest discussion point i guess will be around the "limited",
> where the privacy advocacy segment of our population will argue
> "nothing", and the evil-network-doer will argue "everything“.

Yes, that discussion need to take place in the wg.
> 
> What i really want to see is this:
> 
> - Allow the application to learn from the network devices what information
>  it must present in the clear to have its traffic be passed through
>  and/or receive additional treatment by the network.
> 
> Aka: "Security guard: Sure, you can go through this door if you show me your <credential> else not"
> 
> Then the app can decide if it wants to show <credential>. Otherwise the
> apps have to operate like corporate drones, carrying around their corp-ID
> in the open all the time hoping that thats the right credential.
> 
> Or to rephrase: if we do not even attempt to overcome TCP port numbers as
> credentials then we're lame and will not be successful.

Okay… I first of all have to simply say no here. I don’t want the middleboxes to require anything here, because why would a middlebox not just say „either you show me all you content in plain or I don’t transport you data“. I believe that’s something we all don’t want and building a mechanism that could lead to this, it the last thing I want. I know what you intention is here, but we have to be more than careful here and the way you’ve just phrased it, I can just disagree. However, I would propose to have this discussion in a separate thread.

> 
>> Note that this approach explicitly gives the control of information
>> exposure back the application and/or transport layer protocol on
>> the end host.
> 
> remove "and/or transport layer protocols". We MUST have auditability
> of what is being sent in the clear by the application. We can not
> have transport protocols inserting information in the clear without
> the app knowing.

Also, again there is not only the application view here. iI e.g. TCP is used over PLUS, it’s the transport that ‚tells‘ PLUS, please expose the equivalent to my SYN such that a firewall knows this is the first packet I’ve sent. More general, a transport will decide about exposing transport semantics and the application might expose traffic characteristics because only the applications know how the traffic should be treated.

> 
>> 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.
> 
> How about a next paragraph about this:
> 
> Text:
> In cases where middleboxes require auditability/unencrypted access to
> the encrypted information of a flow, PLUS can still be used, but the
> encryption keys need to be shared between application and middleboxes
> (or backend thereof). PLUS itself will not consider any mechanisms
> for such encryption key sharing, but instead expects this to be done
> by a higher layer in the application.
> End of text.

So also again, I think this point needs further discussion in a wg. However, for me this is not the primary use case (and therefore not mentioned explicitly in the charter; even though e’ve previously discussed this point). My take is that given the higher layer needs to set up the encryption context anyway, it is the responsibility of the higher who should be allowed to decrypt something. I can see a point that it might makes sense to encryption different part of the PLUS header maybe with different keys. But that’s again just one requirement that should be discussed in a potential wg.

> 
> I would like to see something to this extend, because to me there
> are two classes of key sharing and they have a crucial difference:
> 
> One where the application is actually knowledgable about this and wants
> to support this key sharing, such as in banking applications for auditing middleboxes
> (money laundering rules etc..). And PLUS can be perfectly be used. the app/
> middleboxes will just have to write up their key sharing as another layer in the app
> and middlebox backend.
> 
> The other class of course is (L)I where the premise is that the app is unaware.
> I want to make it as clear as possible that there is nothing in PLUS or
> the encrypted transports it works on that enables this model. If somebody
> wants to make this model work, he has to define another secret key sharing
> layer in the application cocde or other layers, but PLUS needs to stay clean
> 
>> 
>> 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
> "threat model" == "attack vector" ??
>> modification or deletion of exposed information by middleboxes and
>> other devices on path, by allowing a remote endpoint to detect modifications.
> 
> Detection of messups is a pretty low bar. I do not need encryption for
> that. A protected checksum will suffice. The "encryption where needed" is
> also i think a basic question - eg: would be nice we we had clarity during
> charter:
> 
> I as assuming in my above comments that we would ALWAYS have encryption,
> and that we would need application layer key sharing. Is that the model
> we want ?? If not, what are the criteria for not having encryption ? Do
> we think we can agree on criteria during charter ?

Okay, here we are talking about different encryption and we should and will clarify this in the charter (while I thought this was clear). We would envisions that all higher layer protocols will encrypt everything, incl. the transport header; however that’s the responsibility of the higher layer protocol(s) and independent of what PLUS does. However, PLUS will not negotiate an own encryption context, while it will use the context from the higher protocol to encrypt potentially some data in the PLUS header. Of course we will not encrypt the whole PLUS header given the goal is to expose information to middleboxes (even when we don’t have a trust relationship with them). However, there might be other cases where we need even to encrypt something in the PLUS header, e.g. an encrypted feedback channel might be useful. If we don’t have any encryption context from the higher layer, because even unencrypted traffic could decide to use PLUS, we however maybe cannot use all PLUS features.

Mirja

> 
>> 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
>> 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.
>> 
> 
> Cheers
>    Teorless
>> 
>> 
>> 
>>> On 19 May 2016, at 20:56, Scharf, Michael (Nokia - DE) <[e-mail]> wrote:
>>> 
>>> My comment is *only* that the sentence "The current Internet protocol stack has no layer for explicit signaling of flow semantics and characteristics to network elements" needs to be improved, in my personal point of view.
>>> 
>>> For instance, for NAT/FW control, there are many existing out-of-band protocols such as PCP, MEGACO/H.248, NSIS, MIDCOM (and SIMCO), COPS, etc., not to mention all the SDN protocols, which are typically all flow-based. They are all out-of-band but e.g. NSIS would have been end-to-end. The intention and deployment model of these protocols may be very different to what SPUD aims for, and none of them is deployed end-to-end in the Internet. But I think this sentence has to be slightly more specific how to differentiate e.g. from control plane solutions.
>>> 
>>> Michael
>>> 
>>> 
>>> -----Original Message-----
>>> From: Toerless Eckert [mailto:[e-mail]]
>>> Sent: Thursday, May 19, 2016 8:27 PM
>>> To: Tom Herbert
>>> Cc: Scharf, Michael (Nokia - DE); Brian Trammell; [e-mail]
>>> Subject: Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF
>>> 
>>> Tom, Michael
>>> 
>>> I am reading your positions and i am confused:
>>> 
>>> DSCP is very successfull in enterprise networks. SPUD does not have to be successfull "on the Internet". To me it would already be a great success if it would help to improve controlled network services (like enterprise or 4G/5G networks). And their transit traffic across the Internet (without changing anything on the Internet itself).
>>> 
>>> AFAIK, TOS/DSCP/ECN are not per-flow, but per-packet mechanisms. Even if we often think about them as per-flow and ould maybe like them to be restrict to per-flow. At least i don't know any normative reference that defines them to be per-flow.
>>> 
>>> Wrt to out-of-band/out-of-path: The whole reason for SPUD is the analysis that all those mechanisms fail to provide an easily deplopyale framework in the face of middleboxes. Aka: their presence and mostly non-success should be an argument FOR working on spud. Not against it.
>>> 
>>> If a NAT/FW does support any flow signaling, its most likely inband. Every NAT/firwall supports flow recognition via the explicit signaling of flow-based transport protoocols like TCP. They do try to do the same for UDP and because that has no explicit flow signaling, thats where the problem starts. NAT/FW do deep packet inspection which has all these problems we know. SPUD sets out to solve/reduce these NAT/FW issues.
>>> 
>>> Non-support of anything like IP options is IMHO primarily driven by the absence of unform cross-OS/Dev-language APIs for them. Yes. It may suck architecturally by designing protocol stacks based on reality like: applications will only be able to use UDP and TCP, so lets do new work on top of them, but to me the most important goal is to find the best deployable solution to a problem. Not the architecturally cleanest one. If you give me research money to work outside of reality i will happily take it though and represent a different perspective.
>>> 
>>> Please, i do not want to dismiss your opposition, i just don't understand how the arguments you make are working out. Maybe you can explain to me where i am going wrong in my interpretations above.
>>> 
>>> Cheers
>>>  Toerless
>>> 
>>> On Thu, May 19, 2016 at 10:50:21AM -0700, Tom Herbert 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. Given
>>>> that they've been around for many years but have never been widely
>>>> deployed on the Internet 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.
>>>> 
>>>> 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.
>>>> 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.
>>>> 
>>>> 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
>>>> 
>>>> _______________________________________________
>>>> Spud mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/spud
>>> 
>>> --
>>> ---
>>> Toerless Eckert, [e-mail]
>> 
> 
> 
> 
>> _______________________________________________
>> Spud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spud
> 
> 
> -- 
> ---
> Toerless Eckert, [e-mail]
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud