Re: Network Tokens and HBH option

[Toerless Eckert <[e-mail]>]

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.

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