Re: Network Tokens and HBH option
Tom Herbert <tom@herbertland.com> Mon, 13 July 2020 15:48 UTC
Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864533A138A for <ipv6@ietfa.amsl.com>; Mon, 13 Jul 2020 08:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJH0FSdJGuRM for <ipv6@ietfa.amsl.com>; Mon, 13 Jul 2020 08:48:45 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B6C3A1377 for <6man@ietf.org>; Mon, 13 Jul 2020 08:48:45 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id d18so14083490edv.6 for <6man@ietf.org>; Mon, 13 Jul 2020 08:48:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PPlRa6tZngr42pmif9y9yBd40tkg/ukCLXkbunFzL1g=; b=jqVcqBhqWT7drFytz8ezquY/q6u1/KGTv5IYux4qaUFk+r1GXL2PB4TUbN8aBHXims uaj7ELCvl+BAfBNr97zZ+3ETYFobphaxbhiPbUAD3As7YDMbViXJD3HMYWOdbjC34NXY cAVFa0tlSVqjORrvLA4qHzLwqwKkeyyrbYQlTlpqSqPs7vgjWozXm7WZ/kA8CDgGUG9/ WGts/15x+iWq1kCrVMIuuAHocU5Qg57WF7CxUCHRB+kEZvZWt5rLBDUanER/sSJUU486 +pQ6pwb4YH/ibcpweHEsqq89ZKteC7+0zEH8O41as2+BoH9nGQ1mTlEWf5ufobEnJ/5L 5HbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PPlRa6tZngr42pmif9y9yBd40tkg/ukCLXkbunFzL1g=; b=AlF9KNvmD38aoOodN1gPlZWy8GJRsaira5edKwCcw1RGPM8RUUXdzOnO4QVRgWI2SA Zp98Xea9wCI1MxWqPRDBI3ZQXAMpEa6zEnDZR+yI7YOlnzhttOOlWoFKmsjwooL9TB9B kAnRzZ9gv4qKs9NEThBRjmo0A/DyuvveeKHA3SJPLkUrdoY2QtYKsl0RxQaH/Gouqc1N mcs23TTzwkfW5xbB/Nd30zj/HBM5NAiqbp4rGELJd6obfJ2EklS4hMMAbbtGJPhhBpFN jVIxn6/tEb2UMPRNYXOOUXCTnVOfiQsDlxkNmBeZVF1lrMfF7Cknz7R0lSbCVK2un/4r PtMQ==
X-Gm-Message-State: AOAM530bvqAv3VV+zqepzSitOn5ibs35MqYc6iezn6fMKx4Aa9kNBldr LcOtU+dSK40TAKwguSkBdVHCgUd2YM5ujHbK6jdyCA==
X-Google-Smtp-Source: ABdhPJx/5OXpBw3pSGtx7lAGHg7l/5lZeu/uGXCFfFHRWWNiSPLqBVZ+rTvMWAVbOBdJdNpg76E6RC8XvrpwKKTYQq4=
X-Received: by 2002:a05:6402:3138:: with SMTP id dd24mr71569edb.118.1594655323753; Mon, 13 Jul 2020 08:48:43 -0700 (PDT)
MIME-Version: 1.0
References: <CALx6S35sXX6J75dzQH=hN7pC5=9wZP=o6SqOMpivGPtOdo+YNQ@mail.gmail.com> <CAKD1Yr2iUA9SWJoNsDNFdNYDksKcw8YE2oSB1eJBfy9hiJXb4g@mail.gmail.com> <20200713153422.GZ42197@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20200713153422.GZ42197@faui48f.informatik.uni-erlangen.de>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 13 Jul 2020 08:48:32 -0700
Message-ID: <CALx6S346B0hn+jB+7wj6UoyUYMfT1pR6F9wdJiq2u8zqcvSNkQ@mail.gmail.com>
Subject: Re: Network Tokens and HBH option
To: Toerless Eckert <tte@cs.fau.de>
Cc: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, 6MAN <6man@ietf.org>, network-tokens@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vdRqadEdOYqpgL59lnbOG5b6fpg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2020 15:48:48 -0000
On Mon, Jul 13, 2020 at 8:34 AM Toerless Eckert <tte@cs.fau.de> 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 <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 > > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -- > --- > tte@cs.fau.de
- Network Tokens and HBH option Tom Herbert
- Re: Network Tokens and HBH option Erik Kline
- Re: Network Tokens and HBH option Yiannis Yiakoumis
- Re: Network Tokens and HBH option Lorenzo Colitti
- Re: Network Tokens and HBH option Yiannis Yiakoumis
- Re: Network Tokens and HBH option Toerless Eckert
- Re: Network Tokens and HBH option Tom Herbert
- Re: Network Tokens and HBH option Tom Herbert
- Re: Network Tokens and HBH option Philip Homburg
- Re: Network Tokens and HBH option Tom Herbert