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

Fernando Gont <fgont@si6networks.com> Mon, 22 May 2023 19:05 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 D9680C14CE51; Mon, 22 May 2023 12:05:33 -0700 (PDT)
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 dGmEvnXR8GJ6; Mon, 22 May 2023 12:05:29 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (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 0F9ABC14CE33; Mon, 22 May 2023 12:05:28 -0700 (PDT)
Received: from [10.89.9.171] (unknown [91.90.189.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EC24F280689; Mon, 22 May 2023 16:05:24 -0300 (-03)
Message-ID: <87a1b11d-5d70-022a-f934-193f89d211c1@si6networks.com>
Date: Mon, 22 May 2023 21:05:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: Ole Troan <otroan=40employees.org@dmarc.ietf.org>, Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
Cc: Andrew Campling <andrew.campling@419.consulting>, IPv6 Operations <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, 6man WG <ipv6@ietf.org>, Fernando Gont <fernando@gont.com.ar>
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> <CWXP265MB5153E4687BE45480DBC5A531C2439@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <CALx6S35aUNqgyO+8H_QnP4FPp6eRi6aAUfi38AF16SXWAqa6UQ@mail.gmail.com> <E54182CA-D47C-4EFE-ACE1-03C10F72D55A@employees.org>
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
In-Reply-To: <E54182CA-D47C-4EFE-ACE1-03C10F72D55A@employees.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ljQr1TyRPcuapRJp7gh4eOxRpQc>
Subject: Re: [v6ops] [IPv6] [OPSEC] 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 19:05:33 -0000

Hi, Ole,

On 22/5/23 15:36, Ole Troan wrote:
[...]>>
>> As a host and networking stack developer, I view the network and these
>> arbitrary inconsistent security policies as the problem not as the
>> solution to application and host security. The best tool developers
>> have is to encrypt as much of the packet as possible to keep network
>> providers from meddling in protocol layers they shouldn't be, but
>> unfortunately that isn't applicable to all protocols like EH for
>> instance (although, given that IPsec was on Fernando's approved list
>> of extension headers, I suppose we could hide all the extension
>> headers we want in IPsec :-) )
> 
> I don’t think Fernando has argued the case that some EHs should be filtered in public transit networks?

No, I certainly wasn't. -- I was just arguing about filtering at e.g. an 
Enterprise edge.

As for transit networks... it's tricky. In a lof of cases, the dropping 
of such packets doesn't have to do with trying to protect the 
destination AS, but rather because EHs may result in e.g. performance 
issues when the transit AS tries to protect e.g. their own 
infrastructure (see RFC9098). In such scenarios, I'm not sure there are 
many alternatives to just dropping the offending packets (even if 
undesirable).


> In the whole I think it’s not a good idea that the IETF has some working groups working hard at defining new protocols and other working groups working hard at defining policies to block them.

FWIW, I don't think anyone wants to block them, but rather to provide 
guidance about what's sensible to do. e.g., what to do with EHs at the 
Enterprise trust boundary is a usual question from Enterprise folks.



> Now for EHs in general. Their functionality of providing a separate signalling channel independent of the application… it might be time that we accept that this was a bad idea. Which deployment status has confirmed.

Agreed on this.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494