Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)

Ole Troan <otroan@employees.org> Mon, 22 May 2023 17:33 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12340C151545 for <ipv6@ietfa.amsl.com>; Mon, 22 May 2023 10:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh7AEfNxp-CR for <ipv6@ietfa.amsl.com>; Mon, 22 May 2023 10:33:08 -0700 (PDT)
Received: from proxmox02.kjsl.com (proxmox02.kjsl.com [198.137.202.33]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49747C15109D for <ipv6@ietf.org>; Mon, 22 May 2023 10:33:08 -0700 (PDT)
Received: from proxmox02.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox02.kjsl.com (Proxmox) with ESMTP id 0BB8D183CD0; Mon, 22 May 2023 17:33:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=employees.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=prox2023; bh=nsS8/Dufb6XaqfSC oEL9ETUuTVaMxi8F44DXQncxCds=; b=hqv6PQ+iwi2DnBSmtgpxRnibH+bbZFqZ XZ9y0KUulXyW/U6BjVdQ9PRZ1MqWccBh06wVG8M2YUSsXrITFUlzsxw/ZL7PhNy6 nH5/BTQf5BHOrxeAR0HLKZ/cIxJxKyWNeRUOA+/JC1fqn1SOYQ2LgXZzQN7YycyG I9RhUFdJGLVsofoN2todbpmiL3C4K7uNj0D3qYbxNKf3hCCFhRvIF+w7vyy/lUQj AIpKuOGVqVEv/HiWXBpYwkWa4WTZAoPYZQ1gerYBTweXo1OTk6+Ci5POD6U/Yftt 3EV6Omx4KV8r37MHyApg8tfh96/+xw587OitrMbu30A4jXObgzxaeQ==
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by proxmox02.kjsl.com (Proxmox) with ESMTPS id E0301183CCE; Mon, 22 May 2023 17:33:07 +0000 (UTC)
Received: from smtpclient.apple (77.16.68.193.tmi.telenormobil.no [77.16.68.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 255214E11ACE; Mon, 22 May 2023 17:33:05 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CALx6S35g39O6sc+ECwXFb9Zm6c2fNWvJRVY2TMw-ewznT4ZGQQ@mail.gmail.com>
Date: Mon, 22 May 2023 19:32:53 +0200
Cc: Ole Troan <otroan=40employees.org@dmarc.ietf.org>, "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>, "opsec@ietf.org" <opsec@ietf.org>, 6man WG <ipv6@ietf.org>, IPv6 Operations <v6ops@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A22D3D2-CA87-4829-B722-F246AE1B72C7@employees.org>
References: <338409937.875780.1684768913874@mail.yahoo.com> <C90EF571-2754-4C12-B7D6-FEDD1D17CA19@employees.org> <193402587.928006.1684773327427@mail.yahoo.com> <9078375A-F5F7-4D44-AAB8-03CED422B6F7@employees.org> <CALx6S35g39O6sc+ECwXFb9Zm6c2fNWvJRVY2TMw-ewznT4ZGQQ@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xmiBilWaF3gimGH7ciTk1jp5zmk>
Subject: Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 May 2023 17:33:12 -0000

Tom,

>> Unless the application had a particular use for a extension header I would not implement it.
> 
> So you only run one application in your network? :-) Even if you
> polled every user in the network about every application they're
> running and found they don't currently use a certain protocol, what
> happens the next day when one of your customers wants to use the
> banned protocol?

The customer is the application.
My case is where the application and load-balancer is tightly coupled.
The point I was trying to make is that applications are built out of quite complex building blocks.
And I don’t think you have made a strong case for why those building blocks should support passing EHs transparently to an application that doesn’t use them. To the extent that you can actually define where the application endpoint starts/ends.
If we were to build an application that had some use for an EH, then we’d just build that into the app.

Everything that has an IP address, isn’t going to be a full fledged fully generic host stack.

But unless this moves away from being hypothetic...

O.