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

hsyu <hsyu@cfiec.net> Tue, 23 May 2023 06:15 UTC

Return-Path: <hsyu@cfiec.net>
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 804AEC15108B; Mon, 22 May 2023 23:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.786
X-Spam-Level:
X-Spam-Status: No, score=-6.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 2JW1XbridM_J; Mon, 22 May 2023 23:15:27 -0700 (PDT)
Received: from smtpbg156.qq.com (smtpbg156.qq.com [15.184.82.18]) (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 9AECFC15152B; Mon, 22 May 2023 23:15:22 -0700 (PDT)
X-QQ-mid: bizesmtp71t1684822453trs01nif
Received: from DESKTOP-3U2VLEE ( [60.247.14.2]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 23 May 2023 14:14:10 +0800 (CST)
X-QQ-SSF: 00400000000000C0Z000000A0000000
X-QQ-FEAT: HPkwb3INVpBJYl7F1c5Xp+cdhx61AtCgzTwb3p9+R4KAaIx0iSvwLW3sXipcA ZrevzPEuGJ9YOquHSIbJkSmyncsgPVw0OTDc7sXHLSNKBsvwE+vTn8OyirDsbhSZxhQ7mAD vzwhZysDjW3nzHJMakKWfLCOlJ9eN4xOqa0VpZ7tHbb+5nci8TqtCRjazc9/zfqZa0FCcR5 ESYPa3n3MKBD7LEc6+UTnkoW5j7mEvHqNDW3ASZNllOvFFbJFKqf07HCtuIPGLCh5EpzIVl EiOiAK0+911ptek+e4nqqQ9MvRjLPkfAR2ptPWIFFauYhVbADgu1gaR8yHvdeIq1ezjs2Ik pcmwy4eX2/zbKtP8v75wiBvbFrDTrVtkq8zP4g7vAJ+aEn/wJU5JHVwfKEVFQ==
X-QQ-GoodBg: 2
X-BIZMAIL-ID: 14009275961264296345
Date: Tue, 23 May 2023 14:14:08 +0800
From: hsyu <hsyu@cfiec.net>
To: "tom=40herbertland.com@dmarc.ietf.org" <tom=40herbertland.com@dmarc.ietf.org>
Cc: "fernando@gont.com.ar" <fernando@gont.com.ar>, "farmer=40umn.edu@dmarc.ietf.org" <farmer=40umn.edu@dmarc.ietf.org>, "mcr+ietf@sandelman.ca" <mcr+ietf@sandelman.ca>, "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
Message-ID: <E0AE53D0753ECCDF+96251CBB-17EC-4075-9E9B-EC2B7056307E@cfiec.net>
In-Reply-To: <CALx6S34kizt4GrNsGHsObHdkJ9v4GOxP3FmVxKjVn=2fRYaO4g@mail.gmail.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> <CAN-Dau3MLvK2A_Rt_TnXqZY-zOR12NhF-16tKDv4E4s9qR1D_Q@mail.gmail.com> <2341.1684770818@localhost> <CAN-Dau04XOL0Afyrb-msE5OHX2c9KFuYt2N5san9mqq8k1BW3w@mail.gmail.com> <4d2abda3-19a1-4afb-85f6-95ddb9fc9043@gont.com.ar> <CALx6S34kizt4GrNsGHsObHdkJ9v4GOxP3FmVxKjVn=2fRYaO4g@mail.gmail.com>
X-Mailer: MailMasterPC/4.17.9.1009 (Win10 19H2)
X-CUSTOM-MAIL-MASTER-SENT-ID: 043CD53C-9585-4BEC-A23F-84D7E16487A4
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:cfiec.net:qybglogicsvrgz:qybglogicsvrgz6a-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vsrd0i4ThSw6QwZPiPSW5N5Rb5A>
Subject: Re: [IPv6] [v6ops] Why folks are blocking IPv6 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: Tue, 23 May 2023 06:15:31 -0000

Hi, Tom

Hi, David,

On 22/5/23 18:05, David Farmer wrote:
[...]

I think that many of us are still reeling from default configuration of
certain "firewalls" that banks seemed like, which dropped packets
containing
ECN, and TCP options, and made it very very difficult to deploy new
things.
Even when at the IETF standards level... (so "innovation with
permission")


So, I think we need "permissionless innovation" at the Internet level.
Nevertheless, that doesn't mean "innovation with permission" isn't
appropriate in some or even many situations. For example, in a situation
involving public safety, like a nuclear reactor or a missile control
system. We can all agree that "permissionless innovation" isn't
necessarily appropriate in situations like these.

For the Security guy, the "nuclear reactor" is the infrastructure that,
if compromised or DoS, causes clients to complain, money to be lost, and
eventually, staff to be fired.


Fernando,

That's the viewpoint for a Network Security guy, but as a Host
Security guy, network policy ostensibly put in place to protect the
host is irrelevant. The reason should be obvious, unless there was a
network security policy consistently implemented across all networks,
we, host developers and application developers, can't count on it and
it really doesn't help securing the host. In fact it's more likely
that these inconsistent policies are counter productive since we have
to insert hacks to try to work around network secure policies which
themselves could create issues (for instance, think about the hacks we
need to do to try to keep an anonymous stateful firewall in the path
from arbitrarily evicting our connection from its cache).

Tom

Tom,

I agree with you.

Host operators and network operators have different priorities when it comes to security and efficiency. Host operators focus more on ensuring basic data security while improving the speed of data transmission. On the other hand, network operators prioritize network security while striving to maximize network efficiency.

Based on what I've observed, most data breaches on the internet occur due to security vulnerabilities in applications (like leaks of usernames and passwords) or physical intrusions, rather than issues during data transmission over the network.

During the process of transmitting data through the network, there is indeed a Nash equilibrium relationship between security and efficiency, and this balance determines the overall user experience. If we excessively prioritize security without considering efficiency, it can lead to slower performance and reduce the usefulness for users. Similarly, if we focus too much on network efficiency without ensuring adequate security measures, it can result in data breaches, which also diminishes the user experience. Therefore, to achieve the best user experience, both security and efficiency need to be taken into account and maintained.

The network also experiences what is called the "bucket effect," where the security of the entire network depends on the weakest part within it. Even if most subnetworks within the network are secure, the presence of a vulnerability in one subnetwork can pose a threat to the overall network security. Therefore, network operators need to pay special attention to and strengthen the security of the weakest subnetwork to ensure the overall security of the entire network.

Johnson Yu

Yes, I love to play with EHs.... in a lab. :-)

Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01

_______________________________________________
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