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

Tom Herbert <tom@herbertland.com> Thu, 25 May 2023 15:15 UTC

Return-Path: <tom@herbertland.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 3F7E7C153CBF for <v6ops@ietfa.amsl.com>; Thu, 25 May 2023 08:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_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=herbertland.com
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 8mejsb1HEHRL for <v6ops@ietfa.amsl.com>; Thu, 25 May 2023 08:15:32 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 10EB2C13AE24 for <v6ops@ietf.org>; Thu, 25 May 2023 08:15:31 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-5289ce6be53so837782a12.0 for <v6ops@ietf.org>; Thu, 25 May 2023 08:15:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1685027731; x=1687619731; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=M6M5yOoACsxizWstn7Hnfc9EUmyT2ehI3Ye4436EMQI=; b=aibnqZ9lygiUBzs89dsNM4s1SUBtDmxMTXW2XYIe8olcVuKYxGB3ivm/FG7jNzeZvd RuG4kMZqi0hkDfKoG7ydXz/qS6wf+jW14oW648tvessi3McvloRSBFRJP1luP3fEDVkC jKUrMkPs4Z2lt5OLPXWkZVLvFCzW85F4FfdK16vPiAoaOiDAsKMoTyx9VVu6vYEh5kch g4t3dIz/+u18aD0C915P0r2v/fmJSunChEoNrZRFmSyV6RepzYrNaU0R6DN59VuFiNFu djHqoiPkrizRMbHSNVpQbSHkRsoEyr1rrZ056XtxMaE8ngpw6wDOUHgG4/OAPEBaEF5R mmkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685027731; x=1687619731; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=M6M5yOoACsxizWstn7Hnfc9EUmyT2ehI3Ye4436EMQI=; b=KTkAGoxpb9BgwaLFKH3AVEJipR/aJ2Q0d9SWUfzI8X2mme60ZooS9JYoYbuIXUCst4 8Ih9X9AtmobVwZ5JT8H5SuIpSfvFun7xdXR1lfW8ZNM4WDwSqjaM5IQQzHL7okG9gsl2 /ACkjdjSErCvXqaPGtuNB7NjkrRfFTtsRRwEdctp+BW8PrYU6tts/JnsTpEKytWbPZdz 7GC8tXE9GfyhdNiCM93WEu/YttCc2JVonEcg+Ou1Gr8z1KogHyBW8ycjXuqdY3zMvg7S dwc3tE9bS+Q2/Bdh6Kx1Ngn6DBtDdWfLVN4LtxuSXdx9nE+UXCyyHv6uXqANT5iAinjn /JWA==
X-Gm-Message-State: AC+VfDx8OmYCVPaPSTgqpoO53pxh01fepsBosgv91pX8ogDvXng7g+Vs nw6W9uvn60fg/EHxYbfpakU5h5q7kzrJMTcHV6WVBg==
X-Google-Smtp-Source: ACHHUZ62WbexUhyLKVjbP04pTvQeewV/ZE3VM9FjzH92SyiLKgy8wAm60wlUuIwvS+U/SPBfo8O5Vqz2Ihz0XcoOynE=
X-Received: by 2002:a17:903:41cf:b0:19c:3d78:6a54 with SMTP id u15-20020a17090341cf00b0019c3d786a54mr2191371ple.14.1685027731238; Thu, 25 May 2023 08:15:31 -0700 (PDT)
MIME-Version: 1.0
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> <27d28224-0cb0-eec2-8d54-f0d175596c85@gmail.com> <f5758380-9967-b67b-744d-dc36b7b599ab@si6networks.com> <72784f8e65f34bcc9f5652c0a553c70c@boeing.com> <1cf9c93b-32db-6d30-9ea9-951172587a9a@si6networks.com> <588C62B7-0FA1-4C3F-8EE2-1CB58A667407@broadcom.com> <f42e5db6d0ad4ed284c7ae9c4d6abecb@huawei.com> <5057DFBA-3593-4939-8C92-7B6C58DDFA04@broadcom.com> <be71e1ef87ac4a27b776104bc43f7efc@huawei.com> <402D5736-9E62-4166-8309-6051E9749EE3@broadcom.com> <1782809155.2506667.1685023463014@mail.yahoo.com>
In-Reply-To: <1782809155.2506667.1685023463014@mail.yahoo.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 25 May 2023 08:15:19 -0700
Message-ID: <CALx6S361r+jdHpL6xCNJ92z-sZiJZpvN3HEoXhMWsycXqXoSWw@mail.gmail.com>
To: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
Cc: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>, Arnaud Taddei <arnaud.taddei=40broadcom.com@dmarc.ietf.org>, Fernando Gont <fgont@si6networks.com>, "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>, IPv6 Operations <v6ops@ietf.org>, 6man <ipv6@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tbMuvJUaYKklQNa2yVe0L43oa4g>
Subject: Re: [v6ops] [OPSEC] [EXTERNAL] Re: [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: Thu, 25 May 2023 15:15:36 -0000

On Thu, May 25, 2023 at 7:05 AM nalini.elkins@insidethestack.com
<nalini.elkins@insidethestack.com> wrote:
>
> Arnaud,
>
> First, nice to hear from you.
>
> Next, I think blocking EH without nuance or care is throwing out the baby with the bathwater.
>
> IMHO, if we have problems with EH because people have not carefully considered their use.   I think if we do not make IPv6 an extensible and flexible protocol, we will be looking at creating a new version - IPv8?  IPv10? before we know it.

Nalini,

We've already had an attempt at IPv10 :-)

>
> There are many problems with, for example, some TCP packets, and we do not say "just block TCP".

Also, look at how much effort was required to get network providers to
allow QUIC/UDP to pass. Not all network providers blocked it, but
enough did that it impeded deployment for a while. The good news is
that the providers and protocol developers worked together to address
any issues and it's now deployed, the bad news is it took a behemoth,
i.e. Google, to motivate these providers to facilitate innovation on
the Internet.

Tom

>
> Thanks,
>
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
>
> On Thursday, May 25, 2023 at 12:23:02 AM PDT, Arnaud Taddei <arnaud.taddei=40broadcom.com@dmarc.ietf.org> wrote:
>
>
> Ok Eduard I recognise a bit of the epidermic reaction (after all I am half latin blood) and missed the telco context because I see the drama in enterprise context every single day!
>
> Now ironically the example I took below was a telco!
>
> But I buy your point … all good
>
> On 25 May 2023, at 07:58, Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:
>
> Hi Arnaud,
> It is a good point that Enterprises have much more serious attention to security. But Telco is not so much paranoid about security.
> The last initiative in this WG is about “to push Telco to tolerate all EHs”. The context of this discussion is more about Telco.
>
> > The additional cost you can find ways to write them off
> In the majority of cases “No”. Because tests could not be free, support could not be free either. Performance penalty may be close to Zero (only a small loss of bandwidth) – depending on the EH type (maybe a 2x drop of performance because of recirculation).
>
> > the ‘additional cost’ and the ’security risk’ are not symmetric at all.
> Yes, it is an apple and orange comparison. But both exist, and both may be discussed.
>
> Ed/
> From: Arnaud Taddei [mailto:arnaud.taddei=40broadcom.com@dmarc.ietf.org]
> Sent: Thursday, May 25, 2023 8:47 AM
> To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
> Cc: Fernando Gont <fgont@si6networks.com>; Manfredi (US), Albert E <albert.e.manfredi@boeing.com>; IPv6 Operations <v6ops@ietf.org>; 6man <ipv6@ietf.org>; opsec@ietf.org
> Subject: Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
>
> +1 just that the ‘additional cost’ and the ’security risk’ are not symmetric at all.
>
> The additional cost you can find ways to write them off
>
> The security risk is much more damaging because it is a compliancy risk (think DORA for the FSI in EU), a reputation risk that is now captured by credit rating agencies, a revenue risk, a  stock rating agencies (your stock will drop), insurance ratings, etc. and 1) it is getting substantial and 2) it is even existential with a few examples that some organizations literally lost e.g. an MNO of €1.3B and 30 years of existence (only survived by 1 backup link), etc
>
>
> On 25 May 2023, at 07:21, Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:
>
> IMHO: Fernando comes here with a good example (EH DoS). Security is a good reason to block EHs.
> But for business, every feature should be tested, supported, and somebody should pay an additional performance penalty.
> I am not sure which reason is bigger: additional cost or security risk. It depends on the organization type.
> Ed/
> -----Original Message-----
> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Arnaud Taddei
> Sent: Thursday, May 25, 2023 8:12 AM
> To: Fernando Gont <fgont@si6networks.com>
> Cc: Manfredi (US), Albert E <albert.e.manfredi@boeing.com>; IPv6 Operations <v6ops@ietf.org>; 6man <ipv6@ietf.org>; opsec@ietf.org
> Subject: Re: [OPSEC] [EXTERNAL] Re: [IPv6] [v6ops] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
>
> Would like to support Fernando again, and not just because I have a Sony TV too.
>
> Cybersecurity is in such a bad state that I can only plea for a sense of realism and pragmatism vs dogmatism to get real solutions at hand to the defenders practitioners
>
> If not I will ask people here to consider spending a week in a Security Operation Center when there is a Ransomware breaking up
>
> Fernando’s paper intentions will be appreciated by the defenders
>
>
>
>
> On 25 May 2023, at 03:07, Fernando Gont <fgont@si6networks.com> wrote:
>
>
>
> On 25/5/23 02:01, Manfredi (US), Albert E wrote:
>
> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Fernando Gont
>
> Given the amount of things that get connected to the Net (smart bulbs, refrigerators, etc.) -- and that will super-likely never receive security updates, you may have to **rely on your own network**.
>
> For instance, I wouldn't have my smart TV "defend itself".
>
> Agreed, "on your own network." >From the viewpoint of a household, whatever network defense has to be behind that household's router, for it to be credible, and preferably right in each host. Yeah, some IoT devices may not be updated regularly.
>
>
> So, that's why people block them at the edge.
>
> (just the messenger)
>
>
>
>
> The ISP has to worry about protecting that ISP's own network.
>
>
> That's e.g. where RFC9098 comes in, with notes on why they are dropped in places other than the edge network.
>
>
>
>
> Households have to be responsible for protecting their household's
> network. (And connected TVs do get regular software updates, as a
> matter of fact.)
>
>
> I guess it all depends on the TV? e.g., I for one I'm not planning to throw it out just because Sony decided to quit pushing updates (which were never automatic for my set).
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.ietf.org/mailman/listinfo/ops&source=gmail-imap&ust=1685596906000000&usg=AOvVaw1SaRszq_Trn0SZdoxCGfAf
> ec&source=gmail-imap&ust=1685581681000000&usg=AOvVaw2CR1KLp2V-YO9ZOvhw
> rWtn
>
>
>
> --
> This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
>
>
>
> This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
>
>
> This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops