IETF Logo Mail Archive

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

Nick Hilliard <nick@foobar.org> Wed, 05 December 2018 12:48 UTC

Return-Path: <nick@foobar.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 416D6124BF6; Wed, 5 Dec 2018 04:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 CBsOdHhJeW68; Wed, 5 Dec 2018 04:48:33 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB160124D68; Wed, 5 Dec 2018 04:48:32 -0800 (PST)
X-Envelope-To: ietf@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wB5CmTo3046426 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2018 12:48:30 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
To: Joe Touch <touch@strayalpha.com>
Cc: David Farmer <farmer@umn.edu>, IETF-Discussion Discussion <ietf@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec@ietf.org, tsv-art@ietf.org
References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <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> <CAL9jLaYHVdHr+rVoWeNtXTXgLxbTaX8V9gn3424tvsLW60Kvow@mail.gmail.com> <5E70C208-0B31-4333-BB8C-4D45E678E878@isc.org> <CAN-Dau0go6_Puf0A9e7KBpk0ApJBUvcxYtezxnwNc-8pKJ3PwQ@mail.gmail.com> <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <9a613af3-c71e-1c30-d10a-f8a57aee3250@foobar.org>
Date: Wed, 05 Dec 2018 12:48:28 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.6
MIME-Version: 1.0
In-Reply-To: <4D69FA8E-FB8A-4A16-9CA6-690D8AE33C9E@strayalpha.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/KqfF026AfLr6a_HtXO_dgCL35xU>
Subject: Re: [Tsv-art] [OPSEC] 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: Wed, 05 Dec 2018 12:48:36 -0000

Joe Touch wrote on 05/12/2018 12:13:
> Then THAT is the security issue..  Not the packets that cause a broken 
> implementation to have problems.

In this specific case:

1. the protocol definition states that HBH packets should be processed 
per intermediate node.

2. even small routers can now handle terabits of data plane throughput.

What do we do?

1. declare that these routers should be able to process terabits of HBH 
packets (or experimental EHs because we don't know whether experimental 
EHs are required to be processed HBH or by end points only).

2. formally drop the requirement for intermediate routers to process HBH 
headers

3. build routers which will take some HBH headers at low packet rates 
and drop the rest (+ update rfcs to make this formally compliant).

4. something else.

Nick

v2.23.0 | Report a Bug | By Email