Re: [Spud] network/middle boxes information

[Brian Trammell <[e-mail]>]

> On 31 Mar 2015, at 09:02, Salvatore Loreto <[e-mail]> wrote:
> 
> 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

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

> 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.

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

> [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 <[e-mail]> wrote:
>> 
>> 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 <[e-mail]>om>:
>>> 
>>> 
>>> 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
>>> _______________________________________________
>>> Spud mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spud
>> 
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud