Subject: [Spud] Whats missing in SPUD (was: Re: Multipath/Mobility (was Questions based on draft-trammell-spud-req-00))

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 11:41:47 -0700

As a generic side thought based on Christians concern about privacy
(why would an app want to show a shared Tube-ID across multipath/mobile flows for example).

To me, the problem is best explained on the following workflow:

"Here is your new ID card".
"Why would i want to have an ID card, everybody who checks ID cards is evil"
"You do not have to show your ID card if you don't want to"
"Lets go to the bar"
"ID card please"
"Booze or anonymity... that's the question"
"Lets choose booze"

So, whats missing in SPUD (or any prior endpoint<->network) signaling is the
signaling element "If you do not show ID card, you will not get booze" or
"if you do not use a cross-subflow Tube-ID, your load-sharing, mobility or multipath
performance will suck or not work".

Using the same Tube-ID is just one example. This interaction really applies
to any possible signaling element: The anonymity freak will argue to his
death that he doesn't want to provide information to the network... unless
the network can persuade him that the benefit of showing outweights the
loss of anonymity. 

This is primarily a question of creating a data-model of what the network can offer
and tie that to a data model for what to show to get it....

Cheers
    Toerless

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Aug 2015 12:12:12 -0700

Howdy,

> "Booze or anonymity... that's the question"
​You've just demonstrated a bad workflow.  To drink booze in many
jurisdictions, you need to be of a certain age.  Associating that age with
a token that can be shown (of-booze-consuming-age) is enough to meet the
requirement; showing an identity is most assuredly not required.

There are states that change your ID card when you pass that age, for
example; it is a horizontal picture in one and ​a vertical in the other.
When asked for proof of age, you can show just the picture and be granted
entrance, without showing your name, home address, or other identifying
characteristics.

What we are looking for in SPUD is a set of declarative statements that can
be made from the application to the network about the network treatment
desired and from the network to the application about the network treatment
provided.  Anything beyond that is not just surplus to requirements, it's
dangerous because you can end up subverting the security properties of the
overlying protocol (which is what the application sees and is relying on).

My two cents, in any case,

Ted

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 12:40:18 -0700

;-) Thanks for detailling the minimum requirements for the example
exchange. But my point was really about showing the <insert right token>
only after you know why you would have to show it. 

If i read your reply correctly, you are reconfirming
that the current goal in SPUD is to show tokens whether or not they are needed
and without knowing what benefit you would get when you show them. Its like
carrying that vertical or hirozontal picture card openly without knowing
that you'll have a benefit from it.

Thats what i think is one of the main reasons why we have this ongoing discussion
between privacy and spud sides. If spud had the framework to tell
the how what to show and what benefit it would then get, i am arguing
the pushback would be a lot smaller.

Cheers
    Toerless

On Mon, Aug 10, 2015 at 12:12:12PM -0700, Ted Hardie wrote:
> ???You've just demonstrated a bad workflow.  To drink booze in many
> example; it is a horizontal picture in one and ???a vertical in the other.

-- 
---
Toerless Eckert, [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Aug 2015 13:02:39 -0700

> ​So, let's assume that the request is from an application like a WebRTC
application working inside a browser.   It wants to tell the network that a
specific set of packets are grouped together (they are a tube) even when
there are other packets on the same five-tuple.  For the ones within the
tube, it would prefer packet drop on delay, rather than buffering.  Sure,
it could wait until every middlebox along the way reported its likely
treatment of the tube before specifying what it wanted, but it is faster
and more reasonable to make the declarative statement when the desire is
expressed.

That's more like, "show the picture when you are entering bar, rather than
waiting to see if a bouncer asks for your ID"​.  Yes, the bouncer might
look at you and pass you based on inference, but why rely on that?

Ted

> > > So, whats missing in SPUD (or any prior endpoint<->network) signaling
> is
> > > the
> > > "if you do not use a cross-subflow Tube-ID, your load-sharing,
> mobility or
> > > multipath
> > > This is primarily a question of creating a data-model of what the
> network
> > > can offer

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 13:12:59 -0700

Counter example is when the presence of the advanced processing
that the app wants to have in the network would actually impact how the
application sends packets. For example if i can know at least one middlebox
can do advanced priority based packet dropping, then i'd do the video encoding
slightly different.

And i still contend that privacy advocats would think it is less intrusive
if you have the ability to signal your tokens only after figuring out why
what you get for it). Independent of whether the app would change it's behavior.

Cheers
    Toerless

On Mon, Aug 10, 2015 at 01:02:39PM -0700, Ted Hardie wrote:
> > ???So, let's assume that the request is from an application like a WebRTC
> waiting to see if a bouncer asks for your ID"???.  Yes, the bouncer might