Re: IPv6 header insertion in a controlled domain

otroan@employees.org Sun, 08 December 2019 17:19 UTC

Return-Path: <otroan@employees.org>
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 840E21200A4 for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 09:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 gUJFCrJrtM6x for <ipv6@ietfa.amsl.com>; Sun, 8 Dec 2019 09:19:06 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C27120025 for <ipv6@ietf.org>; Sun, 8 Dec 2019 09:19:06 -0800 (PST)
Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id DE6EE4E11ADA; Sun, 8 Dec 2019 17:19:05 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id A325D2555902; Sun, 8 Dec 2019 18:19:03 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: IPv6 header insertion in a controlled domain
From: otroan@employees.org
In-Reply-To: <CALx6S34tpSKa1AhOB0Wr3v_NLxaNeO1aOdvb2FAULErfxn=Jpw@mail.gmail.com>
Date: Sun, 08 Dec 2019 18:19:03 +0100
Cc: Mark Smith <markzzzsmith@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D6F543F-FFDE-4959-B4FF-5F09B77D79AF@employees.org>
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> <CALx6S34tpSKa1AhOB0Wr3v_NLxaNeO1aOdvb2FAULErfxn=Jpw@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KlCB1SKlm156NsjpvfHQ380W8K0>
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 17:19:08 -0000

Tom,

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

I started this thread to see if there was agreement that the mechanism _could_ be made to work in the most simple topology.
I don't think "why" is required to have that discussion.

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

Right, I would imagine those could be mitigated.
A tunnel head-end must implement an ICMP proxy anyway.

With regards to the open Internet, I think we know and agree that EH insertion cannot be made to "work" there.
(At least not for my definition of work).

Best regards,
Ole