Re: [Spud] SPUD Scope?

["FOSSATI, Thomas (Thomas)" <[e-mail]>]

On 06/06/2015 18:44, "Ken Calvert" <[e-mail]> wrote:
>>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.
>
>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.

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