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

Ole Troan <otroan@employees.org> Wed, 05 December 2018 17:57 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 55DF8130E96; Wed, 5 Dec 2018 09:57:34 -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 xTJsHk6cHryL; Wed, 5 Dec 2018 09:57:32 -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 1AF4F128766; Wed, 5 Dec 2018 09:57:31 -0800 (PST)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (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 2CD7BFECC0AA; Wed, 5 Dec 2018 17:57:31 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 17F8DAACD84; Wed, 5 Dec 2018 18:57:29 +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: <20181205164558.GQ1543@Space.Net>
Date: Wed, 05 Dec 2018 18:57:28 +0100
Cc: Joe Touch <touch@strayalpha.com>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Mark Andrews <marka@isc.org>, David Farmer <farmer@umn.edu>, OPSEC <opsec@ietf.org>, tsv-art <tsv-art@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CCFEFC5B-53AE-4079-B64A-A72A71274FAD@employees.org>
References: <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> <20181205122142.GJ1543@Space.Net> <F17C4944-09EC-4AAC-84A0-B660E36AAE89@strayalpha.com> <20181205133821.GL1543@Space.Net> <B6280E0C-6B20-43C1-BB34-170FB06F1EF7@strayalpha.com> <20181205135723.GN1543@Space.Net> <54C715AE-8931-4FA9-AA01-2311EB0055F0@employees.org> <20181205164558.GQ1543@Space.Net>
To: Gert Doering <gert@space.net>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/soN4eq61eu9LNs5RfT3h0t5QvmU>
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 17:57:35 -0000

>>> Chained EHs are a relict from a time when everybody was nice and 
>>> cooperative, bandwith was sparse, routers used CPUs to forward packets,
>>> and money came from governments to research networks in huge amounts.
> [..]
>> This is the exact reason we have layering in the Internet protocols.
>> IPv6 routers are not meant to parse further into packets then the IPv6 header (with one exception (1)).
>> 
>> That network devices find it hard to parse deep into user???s traffic is a feature.
>> I find the argument that we should then change upper layer protocols to accommodate that, hard to digest.
> 
> Ole, you've worked for a vendor long enough, and understand terms like
> "rate limiting" and "hardware”.

You are creating the “perceived” security problem yourself, by requiring processing deeper into the packet than is required.
Just comply with RFC8200. As long as a router is not configured to process any HBH options, it can ignore the header.
You seem to think HBH still means “punt to software”. If it ever meant that.

There’s no need for rate-limiting for not processing HBH obviously.

Cheers,
Ole