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

Tom Herbert <tom@herbertland.com> Sat, 27 May 2023 17:27 UTC

Return-Path: <tom@herbertland.com>
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 B47DAC151066 for <ipv6@ietfa.amsl.com>; Sat, 27 May 2023 10:27:25 -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=ham 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 c0VP_aiR01EU for <ipv6@ietfa.amsl.com>; Sat, 27 May 2023 10:27:21 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 D9F9FC151062 for <ipv6@ietf.org>; Sat, 27 May 2023 10:27:21 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1b01d912924so12654805ad.1 for <ipv6@ietf.org>; Sat, 27 May 2023 10:27:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1685208441; x=1687800441; 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=Czx1B3488WPY8P99AdoAKYjM8GIR45yzHlUO4Jhdnq0=; b=Q4Fz3disgQmK4i5bCYKHFhPAlFgzzn+5LXNMXJOu2ogCmM0ZOmhfOMvtSfTuNoDbg9 tEkLQNbJJr5G9CCSrEf9A9ndXlYVpJWajnAtteopFxIeI4zPsYCJ16omsym82+xr2S1X wMxVIiN2IgHoZ54yqBKx30Ud7vOdLhBHxfTh6TDT7rfhoD3HK7oOW5B6+l8NV4YLe+2S D+le/f7ipCqy9N+tjFgvWP/7pRhPW2bZVJz4mbxw1MgGqjsbzB7HuAtEscB1n9mTaZ46 dln7LM298EsM4pBTd96leeLkus7SMkYq9GlxGYLTQdXvas+1orthO6q0mFErs1DdYdHx txDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685208441; x=1687800441; 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=Czx1B3488WPY8P99AdoAKYjM8GIR45yzHlUO4Jhdnq0=; b=PLcKtpSaTM7dg+j7aKayuMo5jhvoww9htMctHa81XQVN+MjlIhbOXIXki0fFYCmUY3 mOMX9Sy9Asf31dlEWTfzxZSP2lkyPDlYtNGYy3dc1Yd4ZeZiqpXKiuX2jJPLX8xPK3Po 63BB956fCA/eRcopdZcqkRABtx0k30pWQh0Ep7pQsozqC4hr/rTuyimo29P5SXFhTcb/ /uyUotYCd9e0exf33Z4YuvPoEpdR2uXkHZEPgze1RHChgyQ3r9oWbYktzlilC1NbDtwI xtnjX+G41FacXEOqxVEdGVBoEtJUxYqnEKnG+nSgsqCMIxXAUp2RoOqKexaX5YkEGxn9 nYSA==
X-Gm-Message-State: AC+VfDzVf3WnOEXWa2ysL7O8Ig+9j6F44EahuOXpq51IWTm1RcwLFd3I eI3oOP0H++IxQY2GzR4vhzOJLTSpKuRP9oM3xCuRjw==
X-Google-Smtp-Source: ACHHUZ5+nqEJmOdpYWCZCsouWVDaMfwUPH8YhgU9/3HG9FtHOO+7KGcpqiIsaR8dR9A0uhPEOWFkljq5DboaCdiOIF8=
X-Received: by 2002:a17:902:e806:b0:1af:d00c:7f04 with SMTP id u6-20020a170902e80600b001afd00c7f04mr8268468plg.12.1685208441090; Sat, 27 May 2023 10:27:21 -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> <4FCF75B585A1D068+7D9B99BB-B24B-4FE8-A3FD-54877C7C1131@cfiec.net> <375ea678-b05f-7bb6-5ae2-43c54cd271f4@si6networks.com> <CALx6S34u5=2UxEz3zeApv+_-W=PTj0PzMRHS1UC=zRchqVCDyQ@mail.gmail.com> <882610dc-cf8f-e08d-8d9e-0e786097f520@si6networks.com> <CALx6S34AnMaVyEVQxaO0b1JGbQetQvDC+xDHk6aH5vbXM-KT7A@mail.gmail.com> <2a02905427604fa6a4c95e2eaa1dd165@boeing.com>
In-Reply-To: <2a02905427604fa6a4c95e2eaa1dd165@boeing.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 27 May 2023 10:27:08 -0700
Message-ID: <CALx6S36pmsZighJVBLEZWvYqTh1tJtU4SH2Ym0V7oS87dPWAHQ@mail.gmail.com>
To: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6@ietf.org" <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/ipv6/OGOW1oW5GMZ7VpivBodjC3XTsj8>
Subject: Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why folks are blocking IPv 6 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: Sat, 27 May 2023 17:27:25 -0000

On Fri, May 26, 2023 at 4:26 PM Manfredi (US), Albert E
<albert.e.manfredi@boeing.com> wrote:
>
> -----Original Message-----
> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Tom Herbert
>
> > And IETF exists for the good of the Internet and the world's population, not so your company can make money!
>
> Ouch, Tom, let's not devolve the conversation here.
>
> "Making money," legally of course, is nothing more than proof the system works. The IETF exists because many companies around the world see a great benefit in having such a communications tool available to them. These companies pay some of their people to participate. IETF participants are not typically just independently wealthy free agents. Each of these guys fits in some category of participant (equipment vendor, network provider, application designers) and each has a responsibility to see that their interests are met, not ignored.
>
> If the communications tool introduces vulnerabilities that would potentially detract from their businesses, the IETF participants have the responsibility to bring that to light. We can’t expect some nebulous "greater good," however each of us defines that, to cause damage to users of the Internet. Besides which, ideas of what constitutes an actual "the greater good" are probably as varied as are the IETF participants.

Albert,

Correct, that's the fundamental problem. When public network providers
apply ad hoc protocol filtering, that limits the capabilities and
opportunities to provide value to the users. For instance, if someone
came up with a new transport protocol that improves user security by
10x, we couldn't deploy it because some network providers would block
it. So the very security policies that are ostensibly in place to
protect the users can actually harm them.

As for what constitutes the "the greater good", like pretty much
everything else in IETF shouldn't that be something determined by
"rough consensus"? If someone wants to write the BCP as to what
extension headers should be regularly blocked and provide clear
rationale why they need to be blocked and why the problems can't be
fixed, that would be something to discuss and try to achieve consensus
on. Even if the consensus were that extension headers need to be
deprecated, to me that would be better than the current situation
where we, specifically application and host developers, need to deal
with a patchwork of anonymous and seemingly arbitrary network provider
policies that degenerate the end to end services we can provide to
users to rely only on least common denominator of protocols which we
can only deduce by guess work.

Tom


>
> Bert
>