Subject: Network Tokens and HBH option

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2020 08:54:00 -0700

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

---

From: Erik Kline <[email-masked]>
Date: Sun, 12 Jul 2020 22:42:07 -0700

Is this APN6 w/ an added authentication element?

I maybe have not fully digested everything, but there seems to me to
be some cause for concern about abuse.  For example, what's to keep an
enormous incumbent mobile operator from mandating the use of this on
devices permitted to attach to their network?  Seems like there could
be concerning aspects for users/OSes that are hidden behind the
promise of things like zero rating.

On Fri, Jul 10, 2020 at 8:54 AM Tom Herbert <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Mon, 13 Jul 2020 06:11:17 +0000

(cross-posting on network-tokens - apologies for duplicates)

Hi Erik,

While there is an overlap with APN, there is more than just an authentication element.

Take for example a user-centric, application-agnostic QoS service, where the tokens just describe the type of service a user wants to use (e.g., low latency). There is nothing there that specifies the application which will use the token, and the OS can step up and manage/acquire tokens on behalf of the user. (We've been developing this use case as one that matches EU's net neutrality framework for QoS).

Regarding abuse: we are thinking of tokens as an equivalent of access tokens/JWT and OATH workflows. Surely one could abuse them, but we expect/want the community to come-up with a small number of well-defined workflows that are well understood, widely adopted, and protect users.

Best,

Yiannis

=====================
Yiannis Yiakoumis
Co-Founder & CEO
https://selfienetworks.com | +1-650-644-7857

On Sun, Jul 12, 2020 at 10:42 PM, Erik Kline < [email-masked] > wrote:

> I maybe have not fully digested everything, but there seems to me to be
> some cause for concern about abuse. For example, what's to keep an
> devices permitted to attach to their network? Seems like there could be
> concerning aspects for users/OSes that are hidden behind the promise of
> things like zero rating.
> 
> 
> 
> On Fri, Jul 10, 2020 at 8:54 AM Tom Herbert < tom@ herbertland. com (
> [email-masked] ) > wrote:
> 
> 
>> 
>> 
>> Hello,
>> 
>> 
>> 
>> 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 (
>> https://tools.ietf.org/html/draft-yiakoumis-network-tokens-01 )
>> 
>> 
>> 
>> https:/ / www. ietf. org/ mailman/ listinfo/ network-tokens (
>> 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
>> ipv6@ ietf. org ( [email-masked] )
>> Administrative Requests: https:/ / www. ietf. org/ mailman/ listinfo/ ipv6
>> ( https://www.ietf.org/mailman/listinfo/ipv6 )

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 13 Jul 2020 17:14:06 +0900

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.
   2. They don't work with forwarded traffic (e.g., a mobile hotspot)
   because routers aren't really permitted to add extension headers.
   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.

---

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Mon, 13 Jul 2020 15:13:33 +0000

Hi Lorenzo,

We describe tokens as a mechanism that can be used as an extension in different protocols (the I-D defines IPv6 extension headers, TLS Client/Server Hello Extensions, and STUN message attributes.). There are a few trade-offs to consider, and I expect this topic to be heavily debated down the road.

Doing it as an IPv6 extension header has the benefit that it can work for all traffic, and you can potentially use tokens on a per-packet basis, with no connection state at the network. You mentioned the main disadvantages, another one is that it is often far away from the app developer (who uses higher level frameworks like OkHTTP etc), and therefore you'll need to expose it multiple ways upwards.

Doing it at the transport layer means you are closer to the developer and the user, and it's easier to expose this as an API. Intermediate network nodes are also less likely to interfere, and the tokens themselves can be part of the packets signature/checksum which prevents any mangling. We've used them with both TLS and STUN across the Internet and saw no interference from the network (it even worked with client-only support and legacy servers).  The drawbacks are that this is not a narrow waist, so one integration would not apply for all. It also restricts the use to per-flow tokens.

A related debate is per-packet vs per-flow tokens. Per-packet tokens need to be small, and require fast processing in the network. They don't require connection state. I feel that they will look more like opaque tokens with little/no internal structure, which means that the network will have to keep state about tokens to properly match against them. I think Tom has an early prototype here and can comment more.

Per-flow tokens are sent only once per-flow,  can therefore be larger in size, and they are processed only once per-flow. This makes it easier to add structure and encrypt them (assuming you detect them at the fast path and process them at the slow path). They require connection state in the network node that processes them (similar to a NAT), but you can make them largely stateless otherwise, as the token can carry all the state (similarly to a JWT). Frankly, what you need at the network is the single key used to encrypt the tokens.

What do you think? Do you have other suggestions on what would be the right place to insert tokens?

Yiannis

=====================
Yiannis Yiakoumis
Co-Founder & CEO

On Mon, Jul 13, 2020 at 1:14 AM, Lorenzo Colitti < [email-masked] > wrote:

> * The presence of IPv6 extension headers often causes packets to be
> * They don't work with forwarded traffic (e.g., a mobile hotspot) because
> routers aren't really permitted to add extension headers.
> * They are expensive because IIRC for a long time the standards said that
> all intermediate nodes on the path must process them. Many router
> On Sat, Jul 11, 2020 at 12:54 AM Tom Herbert < tom@ herbertland. com (

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jul 2020 17:34:22 +0200

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:

>    dropped, so anything that relies on them is impossible to deploy reliably

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.

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

>    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

-- 
---
[email-masked]

---

From: Tom Herbert <[email-masked]>
Date: Mon, 13 Jul 2020 08:41:23 -0700

Lorenzo,

>From a protocol perspective, Hop-by-Hop options are not only the right
tool, but they are the only correct method to perform host to network
signaling robustly beyond whatever information is in the IP header.
The alternatives like DPI in transport headers payload (see SPUD for
instance) aren't robust in the end and inevitably lead to more
protocol ossification and limits to how we use protocol.

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

This is the typical RFC7872 argument. Network tokens can be scoped to
local domains that support them. It's the network that provides tokens
to applications, so the network should be able to know if the tokens
are usable to the requested destination.

> They don't work with forwarded traffic (e.g., a mobile hotspot) because routers aren't really permitted to add extension headers.

The primary use case is UE to first hop in the network. It's possible
that the network can remove the options at the point if they are not
needed beyond the first hop. Likewise the options can be removed at an
egress router before sending into the Internet. or at the egress
router in a limited domain. draft-herbert-6man-eh-attrib-01 defines a
mechanism to safely remove options.

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

As I said, we can restrict use to limited domains as necessary where
the nodes properly support hop-by-hop options.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 13 Jul 2020 08:48:32 -0700

> 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

---

From: Philip Homburg <[email-masked]>
Date: Mon, 13 Jul 2020 20:06:28 +0200

>to do ore than problem analysis. Would love to see feedback about that doc.

I think this draft could benefit from a companion draft that describes a
good solution to the stated requirements that completely ignores IPv6 and
IPv6-related constraints. 

A next step would be to have a draft that describes a solution within the
IPv6 space and compares it to the best case solution.

Then it gets interesting. An economic impact analysis of proposed changes to
IPv6. Which parties need to change, and of those parties, which parties have
little benefit from the new features.

For example, if all hosts would have to change to support variable length
IP address, then that is very unlikely to happen. If on other hand some
link type would send IPv6 packets in a funny way, then that may be a lot
easier to coordinate.

One more thing, I think it would be nice to have a (working)group that
creates protocols and prototype implementations without any constraints.
In particular working prototypes are often required to convince people that
some radical idea is actually worth the effort of making major changes to
existing protocols.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 13 Jul 2020 11:16:57 -0700

> some radical idea is actually worth the effort of making major changes to
Isn't that what IRTF is for?