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

From: Brian Trammell <[email-masked]>
Date: Thu, 12 Mar 2015 11:00:29 +0100

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: [email-masked]
> To: "Brian Trammell" <[email-masked]>, "Brian Trammell" <[email-masked]>
> 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
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 12 Mar 2015 14:00:26 -0700

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

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

Thanks again for kicking off the discussion,

Ted

On Thu, Mar 12, 2015 at 3:00 AM, Brian Trammell <[email-masked]> 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:
> >
> > 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:
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo
>
>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 12 Mar 2015 23:15:23 +0100

hi Ted,

> On 12 Mar 2015, at 22:00, Ted Hardie <[email-masked]> 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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 12 Mar 2015 17:07:43 -0700

On Thu, Mar 12, 2015 at 3:15 PM, Brian Trammell <[email-masked]> wrote:

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

Y​ou're right, though the points Joe made about dispatching might come into
play here.  Anything like a load balancer that is using the identifier to
manage a state table will treat a new identifier as a new flow; that may
mean dispatching it to a new backend.  So an endpoint can do that, but it
is not guaranteed to avoid other side effects.

> 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.
>
>
I
​ ​think we need to be careful not to over-promise here.  An initial state
might be some rate X for verification, with reputation allowing you to
reduce X (or bad data causing you to maintain or increase it).  There are
other options, of course; in a multi-link system, indications that the path
via one link has path elements which are giving you bad/false data might
cause you to consider paths using the other link, but this is definitely
trending into the "try it after proving simpler stuff works" area.

regards​,

Ted

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