Re: [Tsv-art] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

Ole Troan <otroan@employees.org> Thu, 06 December 2018 10:59 UTC

Return-Path: <otroan@employees.org>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC264126F72; Thu, 6 Dec 2018 02:59:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Kjw1DYdbdM3J; Thu, 6 Dec 2018 02:59:57 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E6F126CC7; Thu, 6 Dec 2018 02:59:57 -0800 (PST)
Received: from astfgl.hanazo.no (77.16.73.20.tmi.telenormobil.no [77.16.73.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 6F0A2FECC073; Thu, 6 Dec 2018 10:59:56 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 77A96AB43B9; Thu, 6 Dec 2018 11:59:50 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com>
Date: Thu, 06 Dec 2018 11:59:50 +0100
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, tsv-art <tsv-art@ietf.org>, opsec wg mailing list <opsec@ietf.org>, ietf <ietf@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <19869497-A363-460F-9348-B40141F7600E@employees.org>
References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <c959d8cb6f6a04a8da8318cfa89da341@strayalpha.com> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <C4D47788-0F3D-4512-A4E3-11F3E6EC230B@strayalpha.com> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <C929A8B9-D65C-4EF7-9707-2238AE389BE3@strayalpha.com> <CAL9jLaY4h75KK4Bh-kZC6-5fJupaNdUfm1gK2Dg99jBntMCEyQ@mail.gmail.com> <C47149DC-CAF2-449F-8E18-A0572BBF4746@strayalpha.com> <CAL9jLaYfysKm7qrG=+jq7zV=5ODnSX-tAhBAiTU7SzYF-YmcGw@mail.gma il.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <e5198c02-ebc6-ee3e-96cb-fd2831164f41@gmail.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <E008EA4B-74D3-4251-BFB8-B88F544B2A99@strayalpha.com> <260f1445-0690-691b-5aea-83b7a 43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/1YGR56XZDyizybMoxoUMHXJHnUI>
Subject: Re: [Tsv-art] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2018 10:59:59 -0000

Joe,

I think you misunderstand.

> I’m talking about a conflict in the text of 8200 - which has those fields as required to support - and 7045, which says they can be silently ignored.

8200 says:
If the router is explicitly configured to process the HBH header it MUST adhere to the option flag 2 high order bits.
Otherwise it MUST forward the packet.

There is no conflict.

If you think a different behaviour is required, then propose that. But preferably in 6man and on a different thread.

This was discussed at length. The consequence of relaxing the processing rules, is that an end-host can no longer use those bits to guarantee that every router on the path implements the option. That was the compromise we accepted. There is clearly a need for something like HBH, where it’s a cheap to process for the router signal that this packet requires further attention. The alternative is much worse, that the router must parse deep into the packet and where the trigger to process is a magic cookie in transport somewhere (and yes this has been proposed). 

Ole