Re: [Spud] [Stackevo] New Version Notification for draft-trammell-stackevo-newtea-00.txt

[Brian Trammell <[e-mail]>]

hi Ted,

> On 12 Mar 2015, at 22:00, Ted Hardie <[e-mail]> wrote:
> 
> Hi Brian,
> 
> Thanks for throwing something together (and it's amusing to see a draft which declares itself to have been done "a few minutes before" the deadline).  Two thoughts, just as quick:
> 
> First, you make an important observation about the scope of comparison, but you've buried it a bit.  You note that declarative marking aims "to treat all markings on packets and flows as relative to other markings on packets and flows from the same sender".  That should get a much bigger play in the next version, I think, as it both explains why the incentive to lie is no longer present and has a huge impact on the system.   Per-sender comparative state make sense in some contexts (the scheduler in a browser, based on traffic from tabs, for example), but it gets harder and harder as you increase the number of senders and in some contexts may simply be too expensive.

...here the definition of "sender" might be somewhat flexible. NAT breaks this as it does reputation, of course. So a sender might be an "endpoint, flow, tube ID" tuple in SPUD. This of course ties into the identifier scope question (and what knowing a tube ID proves about you). which I've now convinced myself also needs to be addressed in the next version ("tube ID" is a SPUD-specific concept, "packet group linkability" is not).

> Doing this in contexts where you are already doing packet or flow state manipulation seems the likely target of this work, and it may be best to make it more explicit.

Yep.

> The second thought is around reputation.  There's a lot of experience with reputation systems that suggests that the ability to mint new identities and the ability to assign reputation are in conflict.  NAT, DHCP-reassignment, new IPv6 privacy addresses and many other issues make assigning this reputation to IP-layer addresses problematic.

...this is why the section in question gets handwavey. It also ties into the identifier scope question, although the traceability/reputation tradeoff is unavoidable, and personally I come down on the privacy-for-endpoints side of that one almost every time.

On thinking a bit more about it, it's probably not realistic for devices on path that in a situation where they have to identify endpoints by address to be doing much reputation analysis anyway. I could see access providers shunting users (by link) on to "ignore spud declaration" VLANs if they get caught lying too often -- but this is in a context where all the hardware, software, management, and process infrastructure to be able to do things per user is already in place.

>  Doing it at above that layer with a long-lived cryptographic token has very serious privacy implications and doing it without one means you can mint an identifier freely. A reputation that lasts for the duration of the flow doesn't have these issues, and it may be the best we can do at the moment.

This is another way to do it, though of course you can also always freely mint another flow (with SPUD, merely by opening another tube on the same fivetuple, even).

Endpoints, though, are in a much better position to evaluate the trustworthiness of path declarations, and in this case a coarse remote-endpoint address identifier with a time decay function is probably sufficient. Whether that actually improves quality of connectivity/service for those endpoints is another question.

> Thanks again for kicking off the discussion,

And thanks for continuing it.

Cheers,

Brian

> Ted
> 
> On Thu, Mar 12, 2015 at 3:00 AM, Brian Trammell <[e-mail]> wrote:
> Greetings, all,
> 
> Shortly before the Monday deadline, I threw together a couple of thoughts into a document that might eventually evolve into a more architectural view of the vocabulary of the things we can expect to be able to deployably say with SPUD (separate from the current discussion on the scope of the tube ID). This follows from discussions about trying to keep markings declarative.
> 
> Comments welcome.
> 
> Thanks, cheers,
> 
> Brian
> 
> > Begin forwarded message:
> >
> > From: [e-mail]
> > To: "Brian Trammell" <[e-mail]>, "Brian Trammell" <[e-mail]>
> > Subject: New Version Notification for draft-trammell-stackevo-newtea-00.txt
> > Date: 9 Mar 2015 18:41:02 CET
> >
> >
> > A new version of I-D, draft-trammell-stackevo-newtea-00.txt
> > has been successfully submitted by Brian Trammell and posted to the
> > IETF repository.
> >
> > Name:         draft-trammell-stackevo-newtea
> > Revision:     00
> > Title:                Thoughts on New Transport Encapsulation Approaches
> > Document date:        2015-03-09
> > Group:                Individual Submission
> > Pages:                6
> > URL:            http://www.ietf.org/internet-drafts/draft-trammell-stackevo-newtea-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-trammell-stackevo-newtea/
> > Htmlized:       http://tools.ietf.org/html/draft-trammell-stackevo-newtea-00
> >
> >
> > Abstract:
> >   This document presently consists of a collection of unordered
> >   thoughts about new approaches to using encapsulation in support of
> >   stack evolution and new transport protocol deployment in an
> >   increasingly encrypted Internet.  It aims eventually to enumerate a
> >   set of architectural assumptions for transport evolution based upon
> >   new encapsulations, and discuss limitations on the vocabulary used in
> >   each of these new interfaces necessary to achieve deployment
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> 
> 
> _______________________________________________
> Stackevo mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/stackevo
> 
>