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

Yiannis Yiakoumis <> Mon, 13 July 2020 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C38C43A0B3C for <>; Mon, 13 Jul 2020 08:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PgabfcacPrhq for <>; Mon, 13 Jul 2020 08:15:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBA093A0B70 for <>; Mon, 13 Jul 2020 08:15:45 -0700 (PDT)
Received: by with SMTP id d11so4278032vsq.3 for <>; Mon, 13 Jul 2020 08:15:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:to:cc:from:message-id :subject; bh=uuvUZyHe0o/X9nc4e5RTcJ0m+RLm0J32/1z8jPhDy4Q=; b=ArzxUzQosDj/xdi4SxB/nyYmqfkSagXnNlo5cIvvAGIqGt92tiF116d1ei+iGs9Wzt B2yMV68X4gg2S+fck4+/LT5XVJvxKwpZgm9ll+cwzyvbRFUaYSdha+P1fxPKxbc6h44B Uyop/HGegMhoBWfvfpJPVTYi4x55CqXtWsHqzi89MTWGFoER3zMDOBW9Jdhl5keegfmr 61LmpGOunBpT8t4kl1Ac69vPd//oQekFwj5Z6NlwjMs1TJ36H+B5XUrMQWBO/koMIKoJ 6hrhJV6zL6hTO8w/YOcPhqzZlX8eFrYG98Puy66ib/RrihuePak+YvxTZD3ot8fj152R LduQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:date:to:cc :from:message-id:subject; bh=uuvUZyHe0o/X9nc4e5RTcJ0m+RLm0J32/1z8jPhDy4Q=; b=tgI8w1zVAdbHMrntxo6v5uYwQDbK09I3W1a3QV5nEFZwxgBd7H0+khkdUPL6Qnc8nI uVQZ3X2aEin7H3TjFScx0BFljlnhF15xLcHiqlDHKPP4mMrwtCg64ln3Om4SCrjBILlU /bqhKhlTIWxb7oRsXpPRcx1MRX9Npf+5uRSRvnhFnslTfhJ9DuFXNx9EC6f4zuMITRwM HFh6VLMcjN0/NKYIkbkC9Xe0lps4Ib2adOO2Ka0UkDN5NMDl+qDV+LL9eJ38i9LK2fQV weLcL9NUzkOMmQSO1ysHF6rjw27Isyc6jff8cJipf3DHU0ZYWmXMRWbGHDsH9LT6FYhJ vhnw==
X-Gm-Message-State: AOAM532pRLPM9tJVderasR3LGI2dI12Rs50pV2Varjze8R20kelVwXYl kUQBgE6RAA0pGVub1lOXW75HDpt/hCY=
X-Google-Smtp-Source: ABdhPJySk3aSoqSXjDpbS9vjj/y/Z5yPNdQ31AutNqlzwElY3Avas0mDOVQBQ/Mx/C8qRIBC+ofzGA==
X-Received: by 2002:a67:69c1:: with SMTP id e184mr30016133vsc.119.1594653344400; Mon, 13 Jul 2020 08:15:44 -0700 (PDT)
Received: from localhost ( []) by with ESMTPSA id w85sm1786710vsw.32.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 08:15:44 -0700 (PDT)
Mime-Version: 1.0
In-Reply-To: <>
References: <> <>
Date: Mon, 13 Jul 2020 15:13:33 +0000
To: "Lorenzo Colitti" <>
Cc: "6MAN" <>,, "Tom Herbert" <>
X-Superhuman-ID: kcknc61u.f8a8ccf1-c8d1-416a-aba1-32b74eb31dde
X-Superhuman-Draft-ID: draft003f0c4a4a971804
From: "Yiannis Yiakoumis" <>
Message-ID: <>
X-Mailer: Superhuman Desktop (2020-07-10T22:05:59Z)
Content-Type: multipart/alternative; boundary=a928ff64600654919a94c87b57d21bfa0f36954cc6ca202d73a5900c2e1f
Archived-At: <>
Subject: Re: [Network-tokens] Network Tokens and HBH option
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for network tokens <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jul 2020 15:15:49 -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 Yiakoumis
Co-Founder & CEO | +1-650-644-7857

On Mon, Jul 13, 2020 at 1:14 AM, Lorenzo Colitti < > 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 (
> ) > 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
>> ipv6@ ietf. org ( )
>> Administrative Requests: https:/ / www. ietf. org/ mailman/ listinfo/ ipv6
>> ( )
>> --------------------------------------------------------------------