Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt

> On 17 Mar 2015, at 06:01, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Catching up...
> 
>> On 12 Mar 2015, at 1:52 am, Patrick McManus <mcmanus@ducksong.com> wrote:
>> 
>> On Wed, Mar 11, 2015 at 9:47 AM, Brian Trammell <ietf@trammell.ch> wrote:
>> 
>> Perhaps we can apply the question that led to the separation of TCP and IP in the first place: does the path need to see it / can the path do something universally useful with it? Put it in SPUD. Is it end-to-end? Stick it above SPUD, encrypt it, and hide the key from the path.
>> 
>> I like that as a guiding principle
> 
> +1 here too. Nice way to avoid this becoming an application services kitchen sink.

If we really want to build a nice expansive vocabulary for end to end metadata signaling, and we want to reuse chunks of the SPUD codebase to do so (maybe so the app can take the same signals and selectively expose them to the path or not) and we have a solution to the tube MTU problem which works so we know how many bits we can burn, and we believe we can restrict it to the point that it will ever interoperable -- this latter part is where I get skeptical -- then we can do this very simply, inside the crypto veil:

 +--------------------------+
 | addr addr ttl stuff      | IP
 +--------------------------+
 | port port csum len       | UDP
 +--------------------------+
 | magic tube flags cbor    | SPUD
 +--------------------------+             pathside
 | cbor 0: DTLS             | -----------------------
 +--------------------------+              appside
 | cbor                     | SPUD-lite
 +--------------------------+
 | cbor 0: payload          | your favorite transport
 +--------------------------+

Here SPUD-lite is *just* the CBOR part of SPUD.

I'm not sure this is a good idea -- though the diagram above looks a little less scary if you think of the goal of SPUD as a facility of reduced-profile, future DTLS -- but this arrangement would give us the flexibility to define things we want to say first then to freely move them between pathside and appside contexts. On the appside, the trust situation is easier because we presume we've solved the key-and-trust-management problem in a way that makes sense for a given application.

Cheers,

Brian

> --
> Mark Nottingham   https://www.mnot.net/
> 
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud

Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt

Attachment: signature.asc