Re: [Network-tokens] Network Tokens and HBH option

[Tom Herbert <[e-mail]>]

On Mon, Jul 13, 2020 at 8:34 AM Toerless Eckert <[e-mail]> wrote:
>
> Lorenzo,
>
> Some of your reasons are exactly why i think it would be great if
> we had a forum to think about how to overcome these issues without
> being constrained by RFC8200, even if for reearch purposes. Aka: COuld
> we build headers that do not have these issues, and if so, how.
>
> We have started to look at some of the problems we see in the current network
> headers in draft-bryant-arch-fwd-layer-ps. We have refrained in that spec
> to do ore than problem analysis. Would love to see feedback about that doc.
>
> more inline:
>
> On Mon, Jul 13, 2020 at 05:14:06PM +0900, Lorenzo Colitti wrote:
> > Is a hop-by-hop option the right tool here? They have several disadvantages:
> >
> >    1. The presence of IPv6 extension headers often causes packets to be
> >    dropped, so anything that relies on them is impossible to deploy reliably
> >    on the Internet.
>
> Indeed. But i am deeply convinced that a good amount of this problem is
> because of bad specs and bad implementations. I make this argument for
> e.g: router-alert, where i think we could easily redo it with a new
> extension header with better spec, leading to better implementations.
> Just as an example.
>
> Besides rfc820 limits, bad specs, bad implementations, there is the fourth
> horseman of the pocalypse, which are on-path filters that filter things
> they shouldn't filter purely because there is money to be made in
> selling the vision of:
>
>    I have a product that can apply policies on anything it can understand,
>    and a great policy is to deny anything that you do not explicitly
>    know and permit.
>
> There are solutions for this like DPI based tokens (Malice draft) or
> encryption (i think Tom has/had this), but i think it would be good to put
> this into a separate bucket. Aka: this is only needed for internet paths, but
> IMHO not for controlled network paths. To most this seems like we would
> already need this level of complexity because Internet paths are most
> important, but i disagree: I think most networks are controlled, including
> all traffic that looks like Internet as long as it stays within the
> access provider of either subscriber of a connection.
>
> >    2. They don't work with forwarded traffic (e.g., a mobile hotspot)
> >    because routers aren't really permitted to add extension headers.
>
> Its expensive to work with rfc8200, e.g.: you need to add another
> encap header and figue ouut where its to be removed. Hence the desire
> to at least research better network headers as well to compare.
>

Toerless,

Please take a look at draft-herbert-6man-eh-attrib-01. I think this
accomplishes what you're looking for in that the host can explicitly
tell the network which options are safe to remove from the packet
without needing the overhead of encapsulation (8 bytes versus 40 bytes
in this case).

Tom

> >    3. They are expensive because IIRC for a long time the standards said
> >    that all intermediate nodes on the path must process them. Many router
> >    implementations do not do this, but probably some do.
>
> The main issue is the cost in ignoring headers you don't bother about because
> because you either don't implement tem, or they are not enabled/configured.
>
> Cheers
>     Toerless
>
> > On Sat, Jul 11, 2020 at 12:54 AM Tom Herbert <[e-mail]> wrote:
> >
> > > Hello,
> > >
> > > This is a draft on "Network Tokens" which is a form of host-to-network
> > > signaling for the purposes of providing a highly granular network
> > > services and QoS to applications. A primary mechanism to carry the
> > > signaling is expected to be a Hop-by-Hop option.
> > >
> > > https://tools.ietf.org/html/draft-yiakoumis-network-tokens-01
> > >
> > > There is also a mailing list in
> > > https://www.ietf.org/mailman/listinfo/network-tokens
> > >
> > > We are planning to present in tsvwg and app aware networking and
> > > possibly have a side meeting on this topic in IETF108.
> > >
> > > Thanks,
> > > Tom
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
>
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
> --
> ---
> [e-mail]