Subject: [Spud] SPUD Scope?

From: Szilveszter Nadas <[email-masked]>
Date: Thu, 4 Jun 2015 16:28:34 +0000

Hi all,

I browsed through the mails since last ietf the other day, and I have seen quite big variety in the scope of SPUD in the different mails.

The rage looked like this to me on a high level:
a) only start/stop, hide everything in DTLS
b) Some declarative, safe to ignore, trust but verify markings are OK, but it shall be minimized.
c) "common, middlebox friendly connection/packet signaling layer", extensibility, any communication and behavior is OK as long as it is explicit.

I am personally closest to group c), still I understand that this is far from the average view and that it would be pretty hard to reach a consensus regarding this. I think that it is very hard to "replace DPI" with easy to verify info (assuming encrypted payload) and with declarations with very light consequences. One can argue that middleboxes shall never be able to have that detailed knowledge ever again, still if we embrace the role of middleboxes we probably need more than a) or b).

I completely agree that all kind of signaling shall be safe to ignore and in a normal case ignoring a signal should not result in denial of the service but rather result in some kind of default behavior.  I also think that signaling shall not result on delayed start of the connection (usually it is enough to change handling later on, no real reason to delay the start)

However I do not really see problems with one of the end-point accepting an offer of a middlebox and communicating with the middlebox with a proprietary vocabulary. SPUD is clearly a good way to offer these improvements to end-hosts. Whether the follow up communication is using SPUD as a sub-transport for the signaling conversation or not is a question. Also this communication (when accepted) might have consequences, e.g. some change in charging. Obviously some kind of security solution is needed to authenticate the middlebox and the end-point, which is far from trivial.

At the same time even with the above assumptions, it is not quite clear how something like this can happen.

I really like the philosophy of the "Tussle in Cyberspace" article. Things like "Do not design so as to dictate the outcome". Also the part about "Interfaces of tussle" and their "properties": "Visible exchange of value", "Exposure of cost of choice", "Visibility (or not) of choices made" and "Tools to resolve and isolate faults and failures". I think that if we want to cooperate with middleboxes these are very good guiding principles. I also think that many of us are actually biased towards trying to dictate the outcome. If we provide possibility to achieve a functionality in an explicit way is not it better than making network vendors to invent their own not so transparent solutions for the same?

Assuming something like c) is not happening in SPUD where do you think it could/should happen?

Cheers,
Sz.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 04 Jun 2015 15:24:52 -0400

On Thu 2015-06-04 12:28:34 -0400, Szilveszter Nadas wrote:

> c) "common, middlebox friendly connection/packet signaling layer",
> extensibility, any communication and behavior is OK as long as it is
> explicit.

[...]

> However I do not really see problems with one of the end-point
> accepting an offer of a middlebox and communicating with the middlebox
> with a proprietary vocabulary. SPUD is clearly a good way to offer
> these improvements to end-hosts. Whether the follow up communication
> is using SPUD as a sub-transport for the signaling conversation or not
> is a question. Also this communication (when accepted) might have
> consequences, e.g. some change in charging. Obviously some kind of
> security solution is needed to authenticate the middlebox and the
> end-point, which is far from trivial.

This far-from-trivial authentication mechanism, combined with the UI/UX
concern about helping people to understand exactly who they are leaking
their metadata to, presents a really serious obstacle to deploying
something like this in a way that is safe for end users.

We need to be *reducing* the amount of metadata that our protocols leak,
not providing new channels to leak more of it.

> If we provide possibility to achieve a functionality in an explicit
> way is not it better than making network vendors to invent their own
> not so transparent solutions for the same?

We can explicitly discourage network vendors from trying to coax
arbitrary metadata out of the traffic that passes across their network.
While there are certainly some network vendors that want to do this for
purely benevolent reasons, there are far too many middleboxes that would
do this for malicious reasons, and there is no clear way that a
real-world user can be expected to tell the two apart.

Even if the users *could* distinguish "good" middleboxes from "bad" ones
(of course, different perspectives means different users will not agree
about who is "good" and who is "bad"), there are circumstances where the
user has only one network path available to them.  Providing
arbitrarily-sophisticated metadata-leakage mechanisms provides a way for
that network operator to (in an IETF-blessed fashion) demand arbitrary
metadata from the user as a precondition to the use of the network.  I
think that's not something the IETF should be supporting.

> Assuming something like c) is not happening in SPUD where do you think

I don't think something like (c) is a good idea.  let's try to keep the
smarts (and the knowledge of both content and metadata) at the edges of
the network, and avoid blessing mechanisms that facilitate centralized
surveillance.

Regards,

        --dkg

---

From: Christian Huitema <[email-masked]>
Date: Thu, 4 Jun 2015 19:34:05 +0000

On  Thursday, June 4, 2015 12:25 PM, Daniel Kahn Gillmor wrote:
> To: Szilveszter Nadas; [email-masked]
> Subject: Re: [Spud] SPUD Scope?
> 
> concern about helping people to understand exactly who they are leaking their
> metadata to, presents a really serious obstacle to deploying something like this
> in a way that is safe for end users.

Absolutely. This might only work if the client, server, and middleboxes incentives are well aligned. That may be the case for some basic QOS-type parameters, which is very much what (b) should be about. 

> ...
>
> I don't think something like (c) is a good idea.  let's try to keep the smarts (and
> the knowledge of both content and metadata) at the edges of the network, and
> avoid blessing mechanisms that facilitate centralized surveillance.

And a variety of security issues. The unauthenticated data channel is subject to spoofing, which enables a variety of packet injection attacks. 

-- Christian Huitema

---

From: Szilveszter Nadas <[email-masked]>
Date: Fri, 5 Jun 2015 10:37:53 +0000

Hi,

My concern is whether the whole SPUD exercise is worth the effort without extensibility. Assume that we can agree in a minimal set for b). What if in a few years' time we realize that we need more? Have not we already ossified the middlebox layer? My vision is that SPUD shall allow both Transport Protocol evolution and Middlebox Cooperation evolution in the same flexible way. :) The goal in my mind if to not ossify transport and not ossify the cooperation functionality. 

Also is not b) + extensibility = c)? Or is there more in c), which is of concern?

About "metadata that our protocols leak", I completely agree that protocols should minimize this leaking. I think that explicit conversation is not leaking though and hopefully also discourages the middlebox owners to try to look into the protocol data itself.

Any device/firmware/Operating System/app still have and will have ways to leak whatever it wants, just by not allowing extensibility in SPUD we cannot stop it. At the same time extensible SPUD can be an engine for "good" cooperation. I believe we can potentially gain more than we lose. The only way to stop leaking is to have a "purging proxy", but even that proxy would have pretty hard time to remove all unwanted interactions. Also there are places where you simply cannot place a purging proxy e.g. between your access device and the ISP/mobile operator middlebox.

About "keeping the smarts at the edge" the IAB program at least includes a goal to "(2) Improving path transparency in the presence of firewalls and middleboxes: guidelines for the detection of and cooperation with these devices to evolve away from present limitations on which protocols can be used across network boundaries, in order to facilitate innovation in transport protocol development. ". In a sense it means for me to embrace middlebox functionality, but make it much more explicit. I think that these functions are important to keep our networks working, but I agree that it has to be much more explicit than in the past. But limiting it looks like a way to keep it in the grey.

I agree that security of the metadata layer will be often equally important than the security of user content. I am not quite sure whether it could/should be handled in SPUD or whether SPUD shall "only" allow secure metadata conversions as a substrate. 

About the UI/UX concern. This is definitely an issue and not an easy one to solve. Trust chains, delegation of trust, market apps controlling app rights are pieces of the puzzle to solve this. I think it is possible to find a solution for this with a good balance of ease of use and control. 

Sz.

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]] 
Sent: Thursday, June 04, 2015 21:34
To: Daniel Kahn Gillmor; Szilveszter Nadas; [email-masked]
Subject: RE: [Spud] SPUD Scope?

On  Thursday, June 4, 2015 12:25 PM, Daniel Kahn Gillmor wrote:
> This far-from-trivial authentication mechanism, combined with the 
> UI/UX concern about helping people to understand exactly who they are 
> leaking their metadata to, presents a really serious obstacle to 
> deploying something like this in a way that is safe for end users.

> ...
>
> I don't think something like (c) is a good idea.  let's try to keep 
> the smarts (and the knowledge of both content and metadata) at the 
> edges of the network, and avoid blessing mechanisms that facilitate centralized surveillance.

-- Christian Huitema

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 05 Jun 2015 19:11:21 -0400

On Fri 2015-06-05 06:37:53 -0400, Szilveszter Nadas wrote:

> My concern is whether the whole SPUD exercise is worth the effort
> without extensibility. Assume that we can agree in a minimal set for
> b). What if in a few years' time we realize that we need more? Have
> not we already ossified the middlebox layer?

I think the "ossification of the network stack" means something
different than what you're using it to mean here.

On the networks i deal with, the ossification comes from middleboxes
being too fancy, and not just passing traffic the way that edge devices
expect.  As a result, the software running at the edge squeezes itself
into a very limited profile of network traffic just to avoid
harrassment/breakage by the (often unknown) middleboxes that might sit
on-path to any of its peers.

> About "metadata that our protocols leak", I completely agree that
> protocols should minimize this leaking. I think that explicit
> conversation is not leaking though and hopefully also discourages the
> middlebox owners to try to look into the protocol data itself.

how does the endpoint know that it is talking to an actual middlebox
that is relevant to its communication?  the endpoint wants to talk to
someone *other* than the middlebox (it wants to talk to the remote peer,
the middlebox is just a postal carrier), and it puts itself (and maybe
its peer) at risk if it entertains any "explicit conversation" from an
adversary posing as a middlebox.

There will always be middlebox vendors who think their business is the
deepest of packet inspection, whether they claim to offer Data Loss
Prevention or Malware Detection or some other unattainable goal.  I
don't see how any SPUD-like mechanism would deter those vendors from
cracking open any layer they can try to crack open.  And it sounds like
it would give them some points of leverage to start with, as well.

> Any device/firmware/Operating System/app still have and will have ways
> to leak whatever it wants, just by not allowing extensibility in SPUD
> we cannot stop it. At the same time extensible SPUD can be an engine
> for "good" cooperation.

Let's hear some examples of that "good" cooperation, and make sure they
include protections against abuse.  So far, the only example i've heard
is the ability for peers to mark each packet as delay-tolerant ("please
queue") or disposable ("please discard"), so that the middleboxes can
make a marginally better guess what to with it do under load.  The
argument for start/stop signalling for UDP still seems weak to me.

> About "keeping the smarts at the edge" the IAB program at least
> includes a goal to "(2) Improving path transparency in the presence of
> firewalls and middleboxes: guidelines for the detection of and
> cooperation with these devices to evolve away from present limitations
> on which protocols can be used across network boundaries, in order to
> facilitate innovation in transport protocol development. ".

You know why we can't innovate in transport protocol development, right?
Because too many middleboxes like to block traffic that they find
surprising.  If they were to stop blocking much of that traffic, we
could run things like SCTP or TCPCrypt reliably on the open Internet
instead of everyone pretending to be TLS-on-port-443, without the need
of anything like SPUD.

> About the UI/UX concern. This is definitely an issue and not an easy
> one to solve. Trust chains, delegation of trust, market apps
> controlling app rights are pieces of the puzzle to solve this. I think
> it is possible to find a solution for this with a good balance of ease
> of use and control.

I've seen no evidence of this (i also don't know what "market apps
controlling app rights" means). I'd love to see some pointers to
examples of UI/UX mockups that we can reason about (though i don't know
if SPUD is the right place to do this).

Regards,

     --dkg

---

From: Ken Calvert <[email-masked]>
Date: Sat, 6 Jun 2015 13:44:33 -0400

> instead of everyone pretending to be TLS-on-port-443, without the need

Some middleboxes are paranoid for good (or at least understandable) reason:  they are there to implement trust domain boundaries.  Because those boundaries don't exist in the original architecture, firewalls work by overloading mechanisms that are poorly suited for the job.

A well-designed mechanism that enables a packet to certify policy-compliance in-band, without DPI, would at least help with firewalls.  It seems to be a necessary condition for reducing the need to force everything through the TLS-over-443 tube, while still allowing end-to-end encryption.

Yes, the path is fraught with challenges; I don't disagree with most of your points.  On the other hand, call me an optimist, but I believe such a mechanism could not only help break the "ossification" logjam, but perhaps eventually shift the balance of power back toward the end users by giving them more choices w.r.t. network services.

Ken Calvert

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 07 Jun 2015 14:30:59 -0400

On Sat 2015-06-06 13:44:33 -0400, Ken Calvert wrote:
> Some middleboxes are paranoid for good (or at least understandable)
> reason: they are there to implement trust domain boundaries.  Because
> those boundaries don't exist in the original architecture, firewalls
> work by overloading mechanisms that are poorly suited for the job.

Maybe.  This sounds a lot like someone is still thinking in terms of
"perimeter defense", but on most modern, public networks, perimeters are
*extremely* porous.  And of course, once a threat is inside the
perimeter, such a defense is useless.

> A well-designed mechanism that enables a packet to certify
> policy-compliance in-band, without DPI, would at least help with
> firewalls.

Maybe we just need to start using "the evil bit" as specified:

  https://tools.ietf.org/html/rfc3514

;)

Apologies for the snark, but that RFC illuminates the difficulties with
providing such an indication in a way that satisfies the security goals
you're targeting.  Would this be done to implement "trust domain
boundaries" securely?

> Yes, the path is fraught with challenges; I don't disagree with most
> of your points.  On the other hand, call me an optimist, but I believe
> such a mechanism could not only help break the "ossification" logjam,
> but perhaps eventually shift the balance of power back toward the end
> users by giving them more choices w.r.t. network services.

how would this mechanism give the users more choice w.r.t. network
services?  It looks lke a way to facilitate additional metadata leakage
*to* network providers.  are you suggesting that some network providers
would require more metadata than others, and users collectively ("the
marketplace") could collectively select network providers on the basis
of their metadata collection policies?

If this is the suggestion, i think it vastly overestimates the average
user's (a) knowledge of the underlying mechanism, (b) ability to assess
their own risk from particular metadata leakage to a given provider, and
(c) time available to deal with the choicepoints presented (by each
network connection?) by this scenario.

        --dkg

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 8 Jun 2015 09:57:28 +0200

Hi dkg,

only one second/last point…

> Am 07.06.2015 um 20:30 schrieb Daniel Kahn Gillmor <[email-masked]>:
> 
It’s not the different network providers that need different information but you may want to provide different information about different ‚kind‘ of services so that the provider might be able to treat your traffic more appropriately (which effectively can provide you a better service as well as save network resources). However, a user might choose to not reveal this information and only get the default treatment which might or might not be good enough (whatever ‚good‘ means here). And here there might actually be differences between the providers (and the contract that the user made with its provider).

Mirja

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Mon, 8 Jun 2015 11:26:50 +0000

On 06/06/2015 18:44, "Ken Calvert" <[email-masked]> wrote:
>those boundaries don't exist in the original architecture, firewalls work
>by overloading mechanisms that are poorly suited for the job.
>
>firewalls.  It seems to be a necessary condition for reducing the need to
>force everything through the TLS-over-443 tube, while still allowing
>end-to-end encryption.
>
>Yes, the path is fraught with challenges; I don't disagree with most of
>your points.  On the other hand, call me an optimist, but I believe such
>a mechanism could not only help break the "ossification" logjam, but
>perhaps eventually shift the balance of power back toward the end users
>by giving them more choices w.r.t. network services.

I totally agree with you, as long as the underlying principles are:
- explicit vs implicit service;
- ability of endpoints to choose based on clear information about the
service value vs leaked meta-data;
- preservation of e2e security properties.

I think the biggest (though not insurmountable) challenges are:
- UX (as already noted by Daniel);
- scale mechanism to n middle boxes.

We probably need a good deal of research to solve scale and UX, and I hope
stackevo has enough breath to account for this.

Cheers, t

---

From: Szilveszter Nadas <[email-masked]>
Date: Mon, 8 Jun 2015 14:20:07 +0000

Hi,

>>your points.  On the other hand, call me an optimist, but I believe 

I share the same belief.

I think that middleboxes must demonstrate their value for one of the ends in order to receive metadata. This is what I mean on them being explicit. However if they do demonstrate then I believe in giving them the information they want. 

I personally prefer that even without metadata a reasonable default service is available. How to achieve this is a good question. I guess regulators have bigger rule here than engineers. Though I believe that engineers are responsible to educate regulators to find the right path. Without the right regulation blocking when not getting metadata can always happen even if we make it harder with protocol design.

>- ability of endpoints to choose based on clear information about the service value vs leaked meta-data;
>We probably need a good deal of research to solve scale and UX, and I hope stackevo has enough breath to account for this.

I agree. I am thinking about writing a draft along these lines and also include some example use cases with "good" cooperation examples.

Cheers,
Sz.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 08 Jun 2015 10:26:54 -0400

Hi Mirja--

On Mon 2015-06-08 03:57:28 -0400, Mirja Kühlewind wrote:
> It’s not the different network providers that need different
> information but you may want to provide different information about
> different ‚kind‘ of services so that the provider might be able to
> treat your traffic more appropriately (which effectively can provide
> you a better service as well as save network resources). However, a
> user might choose to not reveal this information and only get the
> default treatment which might or might not be good enough (whatever
> ‚good‘ means here). And here there might actually be differences
> between the providers (and the contract that the user made with its
> provider).

We've been talking about generic middleboxes so far, and this is the
Internet; almost by definition there will be middleboxes that have no
contracts with the user.  It's quite likely for any given path between
two peers that there will be *no* middleboxes on the path that actually
have a contractual relationship with either peer.

     --dkg

---

From: Tom Herbert <[email-masked]>
Date: Mon, 8 Jun 2015 09:08:57 -0700

> have a contractual relationship with either peer.
Unfortunately this is isn't completely true between end users and
middleboxes. There are growing use cases where middleboxes are used to
enforce a service contract with users as to what applications are
allowed to pass through the network. For instance, some network
providers will not allow video as a basic service (IMO this is the
antithesis of net neutrality, but nevertheless we need to consider
this reality). One upshot of this is that middleboxes need to perform
DPI which becomes a problem if middleboxes can't identify the
application, so a consequence may be that e2e security (e.g. TLS) is
completely disallowed.

Tom

>      --dkg
>
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud