Re: IPv6 header insertion in a controlled domain

Tom Herbert <tom@herbertland.com> Sun, 08 December 2019 16:36 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 AFE12120041 for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 08:36:03 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 V9cNLMvTLyVV for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 08:36:01 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 81A1D120025 for <ipv6@ietf.org>; Sun, 8 Dec 2019 08:36:01 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id cx19so10332064edb.1 for <ipv6@ietf.org>; Sun, 08 Dec 2019 08:36:01 -0800 (PST)
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=S3RNX4HX3PkXMQdXU3By8Tax4vE7djxp4Ql3rAp4F48=; b=zsc/FWATpjUHrS72nuGQjNPtQrco6pEb6zErpwtJhcLupERrDuMkDT65wyXAY3DNXi lQSI7xXW3CK2ytDwIobZ0arfYuKSmKC1plBXR0NRq/mqgIgGOeXQlldoVIH/aYBI6NFw yThN+tKVJSo5tJerRQciyqBWYqMaOlFXN2T6ZYeqKhcoiCYumpqZAuS2nHH+AjwQJH49 tDGjCo+Kg1O6bv5TYewAsIGJXjjfwv7IIKp2AXwwOqEIpOwqAwcE0WGGnQf1w5A/zn0R NqhsTdWygkV/ft+M8AEcInz7/Up++xJ0gp+OiiuBVFenWvZWAaIPhxMpQsvvK0BwXjWx E5Nw==
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=S3RNX4HX3PkXMQdXU3By8Tax4vE7djxp4Ql3rAp4F48=; b=kxgxFwakoJxTA5PML803+6HI+2PKR4WaEuYkViDCuhJCipEb3/R7DatwCJBt8zoGHJ pCLgDEFtUs6UAmS836SynqeTwlNcGC0/eHO5htsbDgFxEsN7p3NqvKLcuFCHWBU8NsNf QebrmYmYU0gjzmOUT4j5D343/KMt4+/gTobB/N9heMvEyDnb2IJx4ObqSqlOGdr74aTH oyIohHROMmB0qkT4hG/kiulyZfgmnkZ2A22+6VN5LMJ/x7du0kLAJYSpufPbLmn+4gI5 fnGb81fId3dHpAG0AfiQRtAwiKnkid3sOoD2Ftp/PnpKK6NcwNpm12yKidFsF1EjkJ57 0y5g==
X-Gm-Message-State: APjAAAUEANHWomTw7l1XBGMKFu9qN5zXK1OrvUVV+leNp11iXvQII0nv +asIRVJPrTbWh63016nSMLjv9w8kKSGZf5F7JxIUTg==
X-Google-Smtp-Source: APXvYqyDy2A8eL0c7FQOQAfBXU1/hdJNKpVWCbFlOhf7xmxIsRqYK4CHUXtgOI9FgtGh4gx08PCVqjnvscUCNocQdAw=
X-Received: by 2002:a50:8d52:: with SMTP id t18mr28060982edt.26.1575822362453; Sun, 08 Dec 2019 08:26:02 -0800 (PST)
MIME-Version: 1.0
References: <CALx6S3588ja9AZzBQ0dqwx0j-ki6A5tusye+odQKPyAyF+hEww@mail.gmail.com> <10E890EA-3278-44EE-881E-EBC91D419587@employees.org> <88287cb0-c0c3-f990-4dd7-338df87c7fb2@joelhalpern.com> <4E76C386-FB1E-4E48-814D-BB626466BEE3@employees.org> <CAO42Z2ze7tmkGh=E-YrPuJHMeD8V6EuxgjjaJ33iz+Ms3abNsA@mail.gmail.com> <ED9B7C60-ACDE-4107-A121-AE2DAEA6B640@employees.org>
In-Reply-To: <ED9B7C60-ACDE-4107-A121-AE2DAEA6B640@employees.org>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 08 Dec 2019 08:25:51 -0800
Message-ID: <CALx6S34tpSKa1AhOB0Wr3v_NLxaNeO1aOdvb2FAULErfxn=Jpw@mail.gmail.com>
Subject: Re: IPv6 header insertion in a controlled domain
To: Ole Troan <otroan@employees.org>
Cc: Mark Smith <markzzzsmith@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pHPHDoPyKCA-B_HdrvQxzD2G2vM>
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: Sun, 08 Dec 2019 16:36:04 -0000

On Sun, Dec 8, 2019 at 1:25 AM <otroan@employees.org> wrote:
>
> Mark,
>
> [...]
> [renamed thread]
>
> > Take an example of 3 routers A, B and C that is under the same control.
> > Traffic travels from left to right.
> >
> > A -- B -- C
> >
> > A has a tunnel to C using ULA source and destination.
> > A packet ingresses on A, is encapsulated and forwarded towards C.
> > A has for reasons unknown to us outsourced a function to B. Where B insert an extension header in the packet originated by A.
> > C is also in on the game, being a tunnel end-point, removing the encapsulating header and extension header.
> >
> > If you can leave the nuances of SR and the whatever they propose on the shelf for a minute.
> >
> > Do you agree in principle that this approach of "header insertion in a controlled domain" can be made to work,
> > and should be indiscernible from A inserting the extension header itself?
>
> Yes, there are obviously many ways of skinning this cat.
> In this thread I don't want to try solve whatever problem the EH insertion camp wants solved. I don't think I understand it well enough.
> And I'm unconvinced the 6man group in general understands the underlaying routing problems leading to the proposed solution.
> What I was interested in exploring in this thread was if we could reach agreement that there in principle is a safe way of doing header insertion.
>
Ole,

IMO, even before we ask the of how to make header insertion work, we
need to ask and get answers to the question why it's needed. That's
why I created the thread on necessity (please comment on it). Until
there is a clear justification for this mechanism, I personally don't
see why the WGshould spend time trying to "make it work".

> In my simple example above.
> Do you agree that in a controlled distributed system there is no perceivable difference between node A inserting the header or node B doing it?
> Conceptually you could think of it as a tunnel with muliple endpoints (although that's a bit hard to visualize ;-)).
>
> Can we agree that inserting headers and changing the packet size among participating nodes in a distributed system is not inherently unsafe?

Please see draft-smith-6man-in-flight-eh-insertion-harmful-01.
Contrary to some interpretations of that draft, it is intended to be
applicable to the whole Internet and not just saying that EH insertion
is harmful on the "open Internet". For instance, loss of attribution
and ICMP breakage will be problems in controlled domains. One might
argue that those problems can be mitigated in such domains, however
have worked in large operator networks I am skeptical that any
mitigations will be sufficient.

Tom

> As far as I can think of the only complication to be considered is that node A must be aware of packet size changes when doing PMTU estimation.
> (typically though in these types of networks, one simply declares that "MTU must be well managed. i.e. large enough".
>
> Cheers,
> Ole
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------