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

Ole Troan <otroan@employees.org> Mon, 22 May 2023 10:04 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 C1CABC17B342 for <v6ops@ietfa.amsl.com>; Mon, 22 May 2023 03:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.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_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=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 XfiYnlw5wJwX for <v6ops@ietfa.amsl.com>; Mon, 22 May 2023 03:04:14 -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 C7D6DC14CE40 for <v6ops@ietf.org>; Mon, 22 May 2023 03:04:12 -0700 (PDT)
Received: from proxmox02.kjsl.com (localhost.localdomain [127.0.0.1]) by proxmox02.kjsl.com (Proxmox) with ESMTP id 557FF1838CD for <v6ops@ietf.org>; Mon, 22 May 2023 10:04:12 +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=9StE75w8M5tL03uP 3rHfLAyRhUQ9HjNI4iRLJGngCP0=; b=Qh2TG7qa9GNqZsU9OO9/0bHB3RAKQ53/ u2tUxYgAncsbvSi2hPDfnwaJoBnxhSPWtyp8lAi5qfGdjpFHqa3oAgnCVPnzhHsN /lciBulz4D97CxeRVuNkCMod0sjitPdUsY+Win5OIDn47d0CCJr3sPTYtvWDGxZ7 yT6wEAeR/Qv0mgsnXwND+BAcOfq73c+51yZIfNQCi41NzDTRQZLIRAI06YYewCO5 Nlsyk3adw3BGYuUyKR6WRH7Cy5COpkIbMQKSkQ3mZvdNk95CyCmOPzM+ZoWsqaLe dvz+WSlzFlmNagZYeuk5XXZ0b1zwtd/RthcAE1Db+9IDBjP3kjqceg==
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) server-digest SHA256) (No client certificate requested) by proxmox02.kjsl.com (Proxmox) with ESMTPS id 2D3881838CA for <v6ops@ietf.org>; Mon, 22 May 2023 10:04:12 +0000 (UTC)
Received: from smtpclient.apple (unknown [IPv6:2a02:20c8:5921:200:6d03:be25:4c86:2eee]) (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 23C604E11B08; Mon, 22 May 2023 10:04:10 +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: <a411a1b0-c521-c456-3d44-d99a1cc0975b@gmail.com>
Date: Mon, 22 May 2023 12:03:57 +0200
Cc: Fernando Gont <fernando@gont.com.ar>, IPv6 Operations <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, opsec@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F9838657-B1C0-480B-8F78-28A4027ADEF3@employees.org>
References: <11087a11-476c-5fb8-2ede-e1b3b6e95e48@si6networks.com> <CALx6S343f_FPXVxuZuXB4j=nY-SuTEYrnxb3O5OQ3fv5uPwT8g@mail.gmail.com> <CAN-Dau1pTVr6ak9rc9x7irg+aLhq0N8_WOyySqx5Syt74HMX=g@mail.gmail.com> <a087b963-1e12-66bf-b93e-5190ce09914b@si6networks.com> <CALx6S349nNA8L5+_1hrbWayqp8GfTYypWy_SP57c_Xxams=csg@mail.gmail.com> <51a066b3-4b4c-d573-ffbe-d6b44a4f193f@gont.com.ar> <a411a1b0-c521-c456-3d44-d99a1cc0975b@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7FS0lcuFvKrL56eEVEbsTQrrruc>
Subject: Re: [v6ops] [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 10:04:20 -0000

It depends on your position in the network.

A) Transit AS:
Should transparently pass all traffic and not look beyond the 40-byte IPv6 header.

With the exception of NH=0.
Let’s have that discussion if there ever is a HBH option with “transit AS applicability”.

B) Limited Domain

C) Modern application
With modern applications, it has become blurry where the application ends and the network starts.
Where the “application” is disaggregated, embeds a custom network stack for it’s purpose.
Has a set of IP addresses representing the “service”, but those addresses does in no way represent an interface on a host.
That “cluster” of services is only going to support the functions that the application needs.
An EH would essentially be a side channel here.

D) Enterprises
What Fernando says.

It’s somewhat ironic that 25 years in, this debate is still hypothetical.
“What if we ever got an EH that has Internet wide applicability”
(and for the sake of argument I’ve rebranded ESP to a tunnel encap).

O.

> On 21 May 2023, at 23:28, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 21-May-23 21:33, Fernando Gont wrote:
>> Hi, Tom,
>> On 18/5/23 15:27, Tom Herbert wrote:
>> [....]
>>>>> 
>>>>> So, I’m not really happy with the all or nothing approach the two of you
>>>>> seem to be offering for IPv6 extension headers, is there something in
>>>>> between? If not, then maybe that is what we need to be working towards.
>>>> 
>>>> FWIW, I[m not arguing for a blank "block all", but rather "just allow
>>>> the ones you really need" -- which is a no brainer.
>>> 
>>> Fernando,
>>> 
>>> I'm not sure how that's a no brainer, who decides "the ones you really
>>> need"?
>> Typically. whoever runs the destination AS or network. Or the transit
>> AS, if the packets will affect the transit AS.
> 
> And there's the problem. The operator of a large network cannot possibly
> know which extension headers every host on the network needs. It's
> called permissionless innovation, and is supposed to be one of the main
> success factors for the Internet.
> 
>>> If everyone independently makes that decision then we wind up
>>> with an Internet that can't evolve and is perpetually stuck in the
>>> status quo.
>> Well, yes, there's no big brother making decisions about mine or your
>> networks' policies.... hence everyone makes decisions independently.
> 
> From the point of view of hosts, there is an anonymous Big Brother, the
> moment that any upstream operator blocks a wanted extension header.
> 
>> (IN a way that's why QUIC runs on top of UDP ... although in the case of
>> QUIC, I bet it has more to do with NATs thatn with explicit firewalling)
> 
> It's to do with *any* barrier to IP layer transparency. This is a very
> basic tussle in the architecture.
> 
>   Brian
> 
>>>> The list you need
>>>> is, maybe Frag and, say, IPsec at the global level? (from the pov of
>>>> most orgs).
>>>> 
>>>> (yeah... HbH and the like are mostly fine for the local link (e.g. MLD).
>>>> 
>>> It might be productive if you suggested a more concrete direction
>>> here. Maybe a proposed BCP suggesting the EHs that you believe should
>>> be universally blocked and the rationalization for that and why the
>>> problems with them can't be fixed.
>> Are your referring to the "transit AS" case, the "dest AS/network" case,
>> or both?
>> In any case, my comment was simply a two-liner email comment, as opposed
>> to full-fledged advice.
>> Thanks!
>> Regards,
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops