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

Stewart Bryant <stewart.bryant@gmail.com> Wed, 05 December 2018 18:08 UTC

Return-Path: <stewart.bryant@gmail.com>
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 04D35130E96; Wed, 5 Dec 2018 10:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CU1Oq95eX_yP; Wed, 5 Dec 2018 10:08:14 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 7D5E5128766; Wed, 5 Dec 2018 10:08:12 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id j10so20656703wru.4; Wed, 05 Dec 2018 10:08:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=S8BXuuDoXeEuholN91ngej8bnWvedut/WWaMyfqYaZc=; b=JB5pbi7VBM1P+HwoMVu+W6m+WmTxYaeDeGG+aCzd8iq4pSHXydVRAkihIk/42trJnc nP0XPsOLLAB7YaclBAjXspamFQm36Ivv/IOyOGC4nkSSg0SB4188dEbz4dwHD/yY3JPb LcpobBQrun+EgYYJmcW6fcBKW1ScYC/TS1sSGUHvH6W4QPCadgZouistf1QHHV66xMw6 1mmXx+wIo1jQeywvf1gu+UGNv8c7IdrKVdCqelYncL0FmnAU/OIbXYJ3qOHWCmfhztES 2WCgUr6zNo2QsLajs+TrSrTVNx+9eOb3eKr4eQDFPESFOlq1zanGeGyP0vbGPJS3QTHC Ev1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=S8BXuuDoXeEuholN91ngej8bnWvedut/WWaMyfqYaZc=; b=pofyq0jAgGY0zzQns1HUHYTug560Qc3CZnFeLi/tjio/tnWkOG7uYrhOi0AJJRMaVC EQdj9NXqT48AioyoxwbysT3L6LN4FQph1xNmqDYOjNOO2kcbAAuOodAg1WfbUKdxDs9P QEwNtuj9KUKHfEn3ATrOrYqUaTR8bi0d+IodbymlnIh9vC9xH/L/x5Ewa+m6NbWExdJq Qy6MOz5GnR8Z72n91itn1JHHTr0oqO/rX0ddVBkGTbWrKlKmr8ihk8t0/GaeEyueLrFW xKttn2AngG9/T9ci9arwYKnyUYjPNSwhVYWhx9gg+yecj8fsdB8YgfjVGbXV2VhqOCfA wHsg==
X-Gm-Message-State: AA+aEWbQC3/beG91GJvqwyMBLzvjir08fMnO/uJ8nirIR8mDhlIIe1At pLLWPrZMRhsEV2JV4nI6glvlNyik
X-Google-Smtp-Source: AFSGD/W+gVt/RBreKzZYIXXpyCR23GBQEdEZWnwU5Yhan94mvi7z6QuHOEEauYKJPtvZYWygGrachQ==
X-Received: by 2002:adf:b201:: with SMTP id u1mr22782785wra.165.1544033290498; Wed, 05 Dec 2018 10:08:10 -0800 (PST)
Received: from [192.168.2.198] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id y9sm19776352wrq.55.2018.12.05.10.08.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 10:08:09 -0800 (PST)
To: Ole Troan <otroan@employees.org>, Gert Doering <gert@space.net>
Cc: draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, OPSEC <opsec@ietf.org>, tsv-art <tsv-art@ietf.org>, IETF-Discussion Discussion <ietf@ietf.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> <CCFEFC5B-53AE-4079-B64A-A72A71274FAD@employees.org>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <cda0e10e-a56d-4598-dcd4-eabeeac52fb0@gmail.com>
Date: Wed, 05 Dec 2018 18:08:07 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CCFEFC5B-53AE-4079-B64A-A72A71274FAD@employees.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/E1iw2aJqqnzl3yMaLMY1R9hrWe4>
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 18:08:16 -0000


On 05/12/2018 17:57, Ole Troan wrote:
>>>> 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.
Of course it still needs to step through them all to do ECMP even if 
they are all disabled. Of course here it is only looking for two values 
(TCP or UDP).

If it has to look at any it has a much more complex set of tests, or a 
large vector table  given the way the EH space is fragmented.

Stewart



>
> Cheers,
> Ole