IETF Logo Mail Archive

Re: [v6ops] [OPSEC] [IPv6] 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: 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 844DFC159A1D for <v6ops@ietfa.amsl.com>; Mon, 22 May 2023 10:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.431
X-Spam-Level:
X-Spam-Status: No, score=-1.431 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 pQLl5RHTf7-4 for <v6ops@ietfa.amsl.com>; Mon, 22 May 2023 10:09:37 -0700 (PDT)
Received: from proxmox03.kjsl.com (proxmox03.kjsl.com [204.17.39.173]) (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 10DD3C13AE2C for <v6ops@ietf.org>; Mon, 22 May 2023 10:09:37 -0700 (PDT)
Received: from proxmox03.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox03.kjsl.com (Proxmox) with ESMTP id A3BC2142FD5 for <v6ops@ietf.org>; 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 proxmox03.kjsl.com (Proxmox) with ESMTPS id 8B1A5142FD2 for <v6ops@ietf.org>; 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/v6ops/0E5E-WOaSnIBocEr6Dx6nnxbKgc>
Subject: Re: [v6ops] [OPSEC] [IPv6] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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: 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.

v2.23.0 | Report a Bug | By Email