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

"Manfredi (US), Albert E" <albert.e.manfredi@boeing.com> Sat, 27 May 2023 21:16 UTC

Return-Path: <albert.e.manfredi@boeing.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 7FC72C14CEED; Sat, 27 May 2023 14:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.395
X-Spam-Level:
X-Spam-Status: No, score=-4.395 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_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 wxbiEc7yf_7t; Sat, 27 May 2023 14:16:18 -0700 (PDT)
Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A388AC14CE2F; Sat, 27 May 2023 14:16:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 34RLGGdV042290; Sat, 27 May 2023 14:16:17 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1685222177; bh=7V5lSFpBGXsK2mJ0jHRq9eG6wuv+n3O+vsR2QWp191I=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=BmqxVFRPsqxjQ4GlokqSpS0wkr2w8APintbKu/XSQEBpScerbM6LTmZAnMK4YQ3bp B5crCMf1ouvhRMRd9cXYC+VKTjohz5NyRKqn/fnns8hnutPJfOc/tho4U16oTuYL1j YfIO/t+rdaMUoYojuXOlxtFO3gTZbOq9H1D132gJUfH+oD4hSKFNmqbAy0uMzZoo1h vyEjfSUQXvJsmOWS2rCa2CJywhnRZ3yOKaBLR3OSGWadJRIF2MfSuZKa9Uqp6HanQv bQ/nEw10wu0i84iDmBK0ov/OCeXpdYB8LJOdX3O+CkREMBZnnrEplGro14TyvbwCUe t8h/NAUlKsjPA==
Received: from XCH16-08-04.nos.boeing.com (xch16-08-04.nos.boeing.com [137.137.111.43]) by ewa-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 34RLGACU042270 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 27 May 2023 14:16:10 -0700
Received: from XCH16-08-01.nos.boeing.com (137.137.111.40) by XCH16-08-04.nos.boeing.com (137.137.111.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.17; Sat, 27 May 2023 14:16:09 -0700
Received: from XCH16-08-01.nos.boeing.com ([fe80::e4ad:46fa:7f1a:20e4]) by XCH16-08-01.nos.boeing.com ([fe80::e4ad:46fa:7f1a:20e4%10]) with mapi id 15.01.2507.017; Sat, 27 May 2023 14:16:09 -0700
From: "Manfredi (US), Albert E" <albert.e.manfredi@boeing.com>
To: Tom Herbert <tom@herbertland.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: [EXTERNAL] Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking IPv 6 extension headers? (Episode 1000 and counting) (Linux DoS)
Thread-Index: AQHZj+txfXFBIdickkiF/1PMPMcXtK9tez4AgAAOsgD//6PyoIABqIwA///CIcA=
Date: Sat, 27 May 2023 21:16:09 +0000
Message-ID: <6b3a40ef922c47a483860468aac73502@boeing.com>
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> <CALx6S36pmsZighJVBLEZWvYqTh1tJtU4SH2Ym0V7oS87dPWAHQ@mail.gmail.com>
In-Reply-To: <CALx6S36pmsZighJVBLEZWvYqTh1tJtU4SH2Ym0V7oS87dPWAHQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.115.204.6]
x-tm-snts-smtp: 0F9538C167DFB4ED05B11D3EF881F15621E19CD9FB4419FF35C73A603D30A58C2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8mS-Ln2tdu6NgLEVFKbNBA04Yjk>
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 21:16:23 -0000

-----Original Message-----
From: Tom Herbert <tom@herbertland.com> 

> 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.

Potentially, I agree. Problem is, each of the players has to determine what is an acceptable risk. If an ISP wants to keep his infrastructure secure, he's got the responsibility to make it so, as best he can. He can’t trust mechanisms that either don’t exist yet or that might introduce their own new vulnerabilities. Someone says, trust me, these extensions will be for your own good, and yet he is fully cognizant that those extensions could also be used in ddos attacks, he'll say thanks but no thanks. Maybe I'll let those through after we're satisfied with testing and experience.

> As for what constitutes the "the greater good", like pretty much everything else in IETF shouldn't that be something determined by "rough consensus"?

Yes, but unfortunately, that does not absolve the players of their own responsibilities. In matters of security, no one will blindly follow "rough consensus." We are 180 degrees from the Postel principle:

"Be conservative in what you do, be liberal in what you accept from others," is turned on its head, as we know. For system security, you cannot be liberal in what you accept from others.

> 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.

I get your point completely. We don’t have an IETF dictatorship though, so what happens is that over time, smart people have to decide how best to do their jobs, given the realities of today. There is a lot of infrastructure flexibility, and apps, thought really cool when they were developed, that go unused for just this reason. Such as, you might be better off, in your network, to use proxy-MLD and to block PIM-SM. Same goes for some or even much of ICMP. It's the tussle Brian C talks about.

Bert