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

[Brian Trammell <[e-mail]>]

hi Mark,

Thanks for the questions. We have indeed spent a fair amount of time thinking about how to address the threats to privacy discussed at the Dallas BoF, and I'd like to get text into the draft charter that scopes the work appropriately to address them.

So let me answer them in terms of how we're thinking the PLUS protocol will handle them; of course, we'll actually do the engineering in the WG, should it be chartered:

> On 23 May 2016, at 04:07, Mark Nottingham <[e-mail]> wrote:
> 
> Hi Brian,
> 
> At the BoF, I and several other people highlighted concerns about privacy and SPUD:
>   http://www.ietf.org/proceedings/92/minutes/minutes-92-spud  (under "Open Discussion")
> 
> The response at that time was that these considerations were important, and that work on them could happen in parallel with the SPUD experiment.
> 
> Unfortunately, there doesn't appear to have been much obvious progress in list discussion, and draft-trammell-spud-req is quite brief on the topic:
> 
> """
> SPUD must allow endpoints to control the amount of information exposed to middleboxes, with the default being the minimum necessary for correct functioning.  This includes the cryptographic protection of transport layer headers from inspection by devices on path, in order to prevent ossification of these headers.
> """
> 
> However, I can see that some thought along these lines has been put into the proposed charter below. So, a few questions.
> 
> * In the proposed approach, will it be possible for a network operator to use PLUS mechanisms to insert arbitrary metadata (e.g., a user identifier) in the server-bound stream of a client-server protocol?  

Short answer: No.

Detailed answer: The "under endpoint control" language in the spud-req and PLUS charters is meant to describe something like the following:

A sending endpoint (here, the client) controls the type and content of information exposed to the path (as TLV, CBOR, whatever; conceptually, it's a key-value mapping). Each of the keys in this mapping has a meaning. Some of the keys are "application-to-path" keys, and are set by the sender and protected by a MAC using a secret derived from the superstrate session key. Some of the keys are "path-to-application" keys, or requests for information from the path to be sent to the far endpoint (which can then echo them back, encrypted, in a subsequent packet). These are set by the sender to a fixed-length array of 0x00 bytes, to be filled in by anything along the path which understands them. The presence of the key and the length of its data are protected by the MAC, but *not* the content. 

In this case, if everyone is following the protocol, the client has to create a key ("path-to-application-user-id") to let the access network put its user ID in it. As Mirja points out, I doubt that an IETF following a restrictive key allocation policy would standardize such a thing, given BCP 188. And if so, a client could simply fail to create this key, and there would be no space in the PLUS header for the user ID. (To answer your what I suspect your next question would be, "what if the access network requires me to put the user ID path-to-app key in my packets", see the answer to the questions below). 

Of course, MUSTS and SHOULDS are nice, but what if an access network gateway abuses the header? Two possibilities here: it could co-opt an existing path-to-application key, or wedge new information into the header underneath the MTU and tear it back off. In the first case, a complicit server endpoint wouldn't even have to ignore a MAC failure, and could echo back 0, signifying "nobody on path understood this". (There might be ways to put a nonce here to defend against this, but I'm not sure what the details would look like). One way to prevent this being used for large identifier spaces would be to make most such accumulators use only a few bits, and most of the ones we're thinking of (delay accumulators, path MTU) have this property.

The second case isn't really any different from today: any endpoint can stick a shim header between TCP and the (TLS-protected) payload if it knows something on the far end will rip it off, given room under the path MTU. And if there's no room under the path MTU, then you can't steal bits from PLUS either. Indeed, if PLUS makes good use of PLPMTUD, or supported explicit PMTU in a future with PLUS-enabled routers, then the amount of space available for such shenanigans could be reduced. There are also countless out-of-band ways to associate user IDs with flow identifiers that PLUS can't do anything about, either.

> * In the proposed approach, will it be possible for a network operator to require a client to insert a particular kind of metadata into a stream, e.g., to gain network access?
> 
> * In the proposed approach, will it be possible for a network to offer a different quality of service to servers that insert specific metadata into their streams (thereby affecting network neutrality)?

I think these are two different shades of the same threat: "tell me something I want to hear, or I drop your packets", "tell me something I want to hear, or I'll give you crap service", where "something I want to hear" is either some secret verifying you've done something the operator wants you to do (paid money, watched an ad) or information about the traffic the operator could independently verify but doesn't want to have to (otherwise, you could just lie).

Short answer: I do not think it is possible to prevent this kind of behavior, even in the current architecture, because it isn't really a technical problem. But it would be possible with PLUS to make it transparent (which is the reason I don't see PLUS as enabling this behavior).

Long answer: Here, the threat is above layer 7: the application is "forced" to hand over a token in order to get connectivity of acceptable performance. This token might represent information that could currently be taken through DPI, but can't when that information is protected via TLS. 

Sadly, I can see no technical solution to this problem at all. An operator could today force an to place information in bits under its control (IPv6 source and destination address, flow label; TCP source port) for such a thing, or leverage the relative ease of five-tuple routing plus the ease of standing up HTTPS servers in random bits of the cloud to use out-of-band mechanisms ("give me your token and your five-tuple via a TLS-protected API with a server somewhere on a CDN network that you can't easily tell is Your Friendly Local ISP, and you get to ride in the fast lane.") So assuming such a mechanism is deployed without standardization, at least the presence of the keys in the PLUS header would make this behavior visible to *everyone* on the network. That alone is IMO a reason it wouldn't be deployed in this way -- the relatively vigorous opposition to this kind of thing from customers who care means operators would rather hide it.

Thanks, cheers,

Brian


> See also: http://mnot.github.io/I-D/transport-metadata-impact/
> 
> Cheers,
> 
> 
>> On 20 May 2016, at 9:02 PM, Brian Trammell <[e-mail]> wrote:
>> 
>> Hi, all,
>> 
>> I've heard one concrete charter suggestion so far; the edited draft charter (changed paragraph 2) is below. If others would like to see points clarified to answer their questions, please send suggested edits. :)
>> 
>> I take the fact that we're diving into technical discussion as an indication that those participating are at least interested in the BoF, if not (yet ;) ) convinced of the need for a WG at this space?
>> 
>> Thanks, cheers,
>> 
>> Brian
>> 
>> 
>> 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,
>> 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.
>> 
>> 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 (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.
>> 
>> 
>> 
>> 
>>> 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
> 
> --
> Mark Nottingham   https://www.mnot.net/
>