Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01

Fernando Gont <fgont@si6networks.com> Thu, 03 December 2020 07:53 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F383A0A73 for <v6ops@ietfa.amsl.com>; Wed, 2 Dec 2020 23:53:22 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UJOnOcWcr5sQ for <v6ops@ietfa.amsl.com>; Wed, 2 Dec 2020 23:53:19 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0173D3A09C0 for <v6ops@ietf.org>; Wed, 2 Dec 2020 23:53:15 -0800 (PST)
Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3BCAB28462B; Thu, 3 Dec 2020 07:53:07 +0000 (UTC)
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, v6ops@ietf.org
Cc: fernando@gont.com.ar
References: <d97ca0fd-776a-1525-50d1-3a62fd7edf5f@erg.abdn.ac.uk> <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <c6b62aaf-79a1-bfdd-765a-b963177a13b2@si6networks.com>
Date: Thu, 3 Dec 2020 04:50:19 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/EDMm2KAi9HOoRuUOja2yvjWcznw>
Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 07:53:29 -0000

Hi, Gorry,

On 1/12/20 13:30, Gorry Fairhurst wrote:
[----]
> 
> Hope this helps, Fernando. If you need any clarification or other help, 
> just let me know,

I had promised to read "Threats and Surprises behind IPv6 Extension 
Headers" (http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf)

My read of the paper is essentially that EHs are largely unused. And 
when it comes to actual use of EHs, they seem to boil down to fragmented 
UDP (already considered fragile, per RFC8900), local-link traffic (e.g. 
MLD), some IPsec, and what seem to be bogus traffic (e.g., ICMPv6 errors 
being fragmented or employing HbH headers).

No surprises here.


Then, in the "Conclusions" section, the authors note:

"Dropping all packets that contain Extension Headers is a bad practice" 
-- with which I disagree. Not that I think it is great to have to resort 
to dropping packets with EHs, but rather because folks that a network to 
run, and if allowing such packets will prevent them from doing what they 
need to do, or open their network to DoS, then, given the options they 
have on the table, dropping such packets might be the most acceptable one.

They also note:
"The share of traffic containing more than one EH however,
is very small. For the design of hardware able to handle the
dynamic nature of EHs, we therefore recommend to support
at least one EH: the exceptional packets containing more EHs
can be handled in the slow-path, i.e. a slower CPU in the
network device, without substantial performance loss, while
still offering flexibility to drop packets with e.g. more than
three EHs to prevent the possible Denial of Service attack"

This doesn't seem to make a lot of sense. A key design choice is the 
EH-chain length to be supported, rather than EH # count.  And no, I 
don't think you want to process packets in the slower path -- unless you 
rate limit them to such a small number, that it wouldn't make sense, anyway.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492