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

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
https://selfienetworks.com | +1-650-644-7857

On Mon, Jul 13, 2020 at 1:14 AM, Lorenzo Colitti < lorenzo@google.com > wrote:

> 
> Is a hop-by-hop option the right tool here? They have several
> disadvantages:
> * 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.
> * 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
> implementations do not do this, but probably some do.
> 
> 
> On Sat, Jul 11, 2020 at 12:54 AM Tom Herbert < tom@ herbertland. com (
> tom@herbertland.com ) > 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 (
>> 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 (
>> 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 ( ipv6@ietf.org )
>> Administrative Requests: https:/ / www. ietf. org/ mailman/ listinfo/ ipv6
>> ( https://www.ietf.org/mailman/listinfo/ipv6 )
>> --------------------------------------------------------------------
> 
> 
>