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:09 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 9A791C13AE2C; Mon, 22 May 2023 10:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 MmZPn5wjs061; Mon, 22 May 2023 10:09:37 -0700 (PDT)
Received: from proxmox02.kjsl.com (proxmox02.kjsl.com [IPv6:2607:7c80:54:3:250:56ff:fe9b:c983]) (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 023BCC151991; Mon, 22 May 2023 10:09:36 -0700 (PDT)
Received: from proxmox02.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox02.kjsl.com (Proxmox) with ESMTP id 7F2D5183CB4; Mon, 22 May 2023 17:09:36 +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=f8nDlfiYSO+lJeHD Oc/Ci5k9cQ53+rCwx2zcc5liWmg=; b=Nb/zhq+/g3jmWNrGrGG8YWYRvYDth7Kl 2yTH3rKhfwLCDoBlqCn5up6u1lQZuyUNkrhrdkn+aSoDCNOpQh4PmqHDXRAlRtDn FBxxiWhPsjySItQrjz93g2+Ff0v0Ynb3XgfNxYuEpRTePQvmNHZ/lVYSQyF6lIEk XU+FJMS/DbYqNZhUDuR+ghhpE+U57SSLd7rkyyuVkbQIvcD7USxDgkKM6kh0ZsDg cO/UNNYMWN863zlDQwH3JWqE/7dOhJ5Me9Du3shvUebX8WtJAy7HL5bFBZsk49Ek I5Sbd6F/p8ffODk7iDAGjLJ3Q301NIl/jnIozoaMM/WYWvoSYcFL6g==
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.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 5F8C5183CAE; Mon, 22 May 2023 17:09:36 +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 9ADBD4E11A2E; Mon, 22 May 2023 17:09:34 +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: <193402587.928006.1684773327427@mail.yahoo.com>
Date: Mon, 22 May 2023 19:09:19 +0200
Cc: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>, Ole Troan <otroan=40employees.org@dmarc.ietf.org>, "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: <9078375A-F5F7-4D44-AAB8-03CED422B6F7@employees.org>
References: <338409937.875780.1684768913874@mail.yahoo.com> <C90EF571-2754-4C12-B7D6-FEDD1D17CA19@employees.org> <193402587.928006.1684773327427@mail.yahoo.com>
To: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RzXtPW_p-A3-hF606hYGV8NXtkM>
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:09:41 -0000

Nalini,

> 
> Once bugs are fixed, then we need to consider carefully what BCP around EHs should be done, taking into account various common topologies as well as devices such as proxies and load balancers.  I mention those in particular as what we have found points to those devices in particular as posing problems rather than transit networks.  

I look at load balancers as an extension of the application (or network function).
Unless the application had a particular use for a extension header I would not implement it.
And that’s with an implementors hat on. Writing custom load-balancers for network services.
What would you even do with EHs through a load balancer? Provide ALGs for EHs containing addresses inside of them? It would have to be on a case by case basis.


> Of course, our testing to date is absolute lack of transmission rather than lack of transmission based on EH length or type.  We felt that was the logical first step.

O.