Subject: [Spud] network/middle boxes information

From: Salvatore Loreto <[email-masked]>
Date: Wed, 25 Mar 2015 19:27:41 +0000

During the open discussion Andrew expressed the fact that the networks have a lot of information
that can be of interest (or even useful) to the end points (we have seen a proof of this already in tsvwg yesterday).

I want make clear that privacy and security is also important the network not only for the endpoints.
We have to make sure that the middle box that is requested to share some info with the endpoint
can do that in a secure/encrypted way (i.e. be able to decide who will be able to see the info in clear)

br
Salvatore

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 30 Mar 2015 11:33:54 -0700

Hi Salvatore,

we are currently focusing on use case where you ‚may trust but verify‘ (see constraints). If you want to establish an explicit trust relationship with the middlebox, I personally thing that is currently out of scope. I believe there is information that both, middle and end, are willing to release without a trust relation and which could already provide useful input to e.g. better support certain app requirements. Often these kind of information is already available today by DPI (or at least assumptions are taken based on DPI, which might or might not be true). Providing control which information should be exposed (while encrypting the rest) actually provides better control of information leakage and privacy than we often have today. Further, as these information are only declarative, you can anyway never rely on them: that means you should for all your action always take into account that the information might be wrong (or alter by another entity). However, having some information as a starting point is very often extremely useful, if the alternative is having no information at all.

That’s just my view on scoping.

Mirja

> Am 25.03.2015 um 12:27 schrieb Salvatore Loreto <[email-masked]>:
> 
> 
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 31 Mar 2015 07:02:31 +0000

Hi Mirja

thanks a lot for the answer.

I do agre that having some information is a better alternative that anything
and I am happy to see finally SPUD happening 

I am sure that we can find a common set of information that both, middle and end are
willing to release without a trust relation and which could already improve the status quo
My concern is that this set, the set middle and end are willing to release without a trust relation,
end up to be so minimalistic that would be extremely difficult to include anything else then
start and stop without at least a cryptographic protection

Anyway from your answer I understand that at moment in your view it wouldn't be possible
to use (extend?) SPUD to share network information with endpoint like for example
a "mobile throughput guidance" [1] 
or other net info that would help the endpoints but today are not available to them at all.

BTW I see a contradiction in the fact that we are focusing the SPUD on the ‘may trust but verify’
assumption and at same time we are hoping that SPUD will help to get rid of DPI.
I think that unfortunately if we relay on the ‘may trust but verify’ assumption
the network will continue to make use of DPI at least to verify the declarative info.

[1] http://www.ietf.org/id/draft-sprecher-mobile-tg-exposure-req-arch-01.txt

br
Sal

> On 30 Mar 2015, at 20:33, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Salvatore,
>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 31 Mar 2015 10:23:04 +0200

> On 31 Mar 2015, at 09:02, Salvatore Loreto <[email-masked]> wrote:
> 
> Hi Mirja
> 

...and stop might need cryptographic protection, too (on which I'll reply once the jetlag subsides...)

> the network will continue to make use of DPI at least to verify the declarative info.

This whole effort is, in essence, an exercise in balancing contradictions.

Let's be clear: SPUD isn't going to be what gets rid of DPI. End-to-end encryption with key management to detect and prohibit TLS MTIM is what gets rid of DPI, at the application layer and below. This is happening, and will happen, without SPUD, for reasons that are entirely unrelated to transport ossification.

Yes, SPUD makes it possible to encrypt the transport layer headers, as well, which in turn makes it possible for the transport protocols to make explicit the contract between the endpoints and the path, and to be explicit about the division between the endpoint's role in making transport work and the path's. Selective exposure within SPUD makes it possible to do some of the things we're doing with DPI now, for which DPI is a wholly inappropriate tool, without doing DPI.

I would strenuously warn against treating DPI as "ground truth" in today's environment, much less as verification in a more explicit environment such as that we hope to build with SPUD. We need to recognize that much of the DPI that's out there is by necessity pretty simple, and therefore reasonably easy for endpoints cooperating with each other to spoof. And much of what DPI can tell you *directly* is really not interesting from a traffic classification and engineering standpoint in an Internet context.

Cheers,

Brian