Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why folks are blocking IPv 6 extension headers? (Episode 1000 and counting) (Linux DoS)
Nick Hilliard <nick@foobar.org> Thu, 08 June 2023 10:03 UTC
Return-Path: <nick@foobar.org>
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 00CF7C14EB1E; Thu, 8 Jun 2023 03:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.887
X-Spam-Level:
X-Spam-Status: No, score=-6.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 vlNXdWXm-JHD; Thu, 8 Jun 2023 03:03:09 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 762B3C15107C; Thu, 8 Jun 2023 03:03:07 -0700 (PDT)
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netability.ie (Postfix) with ESMTPSA id F01AE9CC28; Thu, 8 Jun 2023 11:03:02 +0100 (IST)
To: "Haisheng Yu (Johnson)" <hsyu@biigroup.cn>
Cc: "fgont@si6networks.com" <fgont@si6networks.com>, "tom=40herbertland.com@dmarc.ietf.org" <tom=40herbertland.com@dmarc.ietf.org>, "andrew.campling@419.consulting" <andrew.campling@419.consulting>, "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>
References: <11087a11-476c-5fb8-2ede-e1b3b6e95e48@si6networks.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> <6b3a40ef922c47a483860468aac73502@boeing.com> <CALx6S36Vv57AZFr=2adfEMYnVSOECsowXw1c7pTo_E-FWokB6Q@mail.gmail.com> <CWXP265MB51535486342FD27A30CFEE6EC2459@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <CALx6S35VA7g95HA-HK1kAr4rehX6hmrzybGS-Hx8j6Mit5FBMg@mail.gmail.com> <79E4E13AA53D1956+88643FCA-56CF-4A3B-A7EC-571290B76A9C@biigroup.cn>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <537896e9-ecaa-9a32-3c9d-60955182cecc@foobar.org>
Date: Thu, 08 Jun 2023 11:03:00 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.60
MIME-Version: 1.0
In-Reply-To: <79E4E13AA53D1956+88643FCA-56CF-4A3B-A7EC-571290B76A9C@biigroup.cn>
Content-Type: multipart/alternative; boundary="------------1F7712C8E0FF617FF5800361"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7nqO6P5Mmo0gF8jXHXS0HFwLoRk>
Subject: Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] 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: Thu, 08 Jun 2023 10:03:13 -0000
there's a discussion, and an extensive bibliography, about operational problems associated with EHs in rfc9098. This document should provide some context about the real-world problems associated with EHs. Nick Haisheng Yu (Johnson) wrote on 08/06/2023 09:01: > Hi, Fernando and Tom, > > I have been contemplating Fernando's questions lately, what exactly > hinders the development of extension headers? Is it because IPv6 > adoption is not widespread enough? Or do IPv6 extension headers > themselves serve little purpose? Or is it because the use of IPv6 > extension headers could potentially decrease network efficiency and > security? > I believe all of these reasons have some validity, but none of them > are the primary cause. In my opinion, the main reason is that we lack > a comprehensive understanding of the current development status and > application scenarios of IPv6 extension headers. Only by thoroughly > understanding the benefits and drawbacks of IPv6 extension headers can > we make better use of them. In the current RFC 8200, extension headers > are only recommended for use, and many service providers are concerned > that handling unfamiliar extension headers could impact the efficiency > and security of control-plane devices, as Fernando mentioned in his > email example. Additionally, because many routing devices forward > packets with unknown processing requirements to control-plane devices > for handling, these impacts exist simultaneously at the forwarding and > control layers. > However, as Tom mentioned, the most secure network in the world is one > that is turned off. We should not refrain from using IPv6 extension > headers simply out of fear of the potential effects on efficiency and > security. > Therefore, I suggest that we consider drafting a document specifically > focused on studying the current development status of IPv6 extension > headers. This document should provide guidance on how IPv6 extension > headers should be handled, when they are useful, and how to correctly > use and process them. Alternatively, we can iterate on the foundation > of 6man-eh-limits, and I would be glad to contribute in this regard. > > Best regards > Johnson > > > > > > 喻海生 > Haisheng Yu(Johnson) > 下一代互联网关键技术和评测北京市工程研究中心有限公司 > hsyu@biigroup.cn > 13654947748 > > <https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1&name=%E5%96%BB%E6%B5%B7%E7%94%9F&uid=hsyu%40biigroup.cn&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2F997bfaaa29267122f3b7334a5d4895ce.jpg&company=%E4%B8%8B%E4%B8%80%E4%BB%A3%E4%BA%92%E8%81%94%E7%BD%91%E5%85%B3%E9%94%AE%E6%8A%80%E6%9C%AF%E5%92%8C%E8%AF%84%E6%B5%8B%E5%8C%97%E4%BA%AC%E5%B8%82%E5%B7%A5%E7%A8%8B%E7%A0%94%E7%A9%B6%E4%B8%AD%E5%BF%83%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8&position=Haisheng+Yu%28Johnson%29&items=%5B%22%22%2C%22hsyu%40biigroup.cn%22%2C%22%22%2C%22%22%2C%2213654947748%22%5D> > > ---- Replied Message ---- > From Tom Herbert<tom=40herbertland.com@dmarc.ietf.org> > <mailto:tom=40herbertland.com@dmarc.ietf.org> > Date 5/30/2023 02:32 > To Andrew Campling<andrew.campling@419.consulting> > <mailto:andrew.campling@419.consulting> > Cc Tom Herbert<tom=40herbertland.com@dmarc.ietf.org> , > <mailto:tom=40herbertland.com@dmarc.ietf.org> > v6ops@ietf.org<v6ops@ietf.org> , > <mailto:v6ops@ietf.org> ipv6@ietf.org<ipv6@ietf.org> , > <mailto:ipv6@ietf.org> opsec@ietf.org<opsec@ietf.org> > <mailto:opsec@ietf.org> > Subject Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why folks are > blocking IPv 6 extension headers? (Episode 1000 and counting) (Linux DoS) > > On Sun, May 28, 2023 at 10:13 AM Andrew Campling > <andrew.campling@419.consulting> wrote: > > > On Sat, May 27, 2023 at 11:05 PM Tom Herbert <tom@herbertland.com> > wrote: > > Application developers and stack developers are also players > in this > game. And while each network provider might have the luxury of > only > focusing on their customer set, developers have to potentially > address the needs of all users across the Internet. This is why > network providers' attempts to protect the user are irrelevant to > application developers-- without consistency across the Internet > this level of security may as well not exist from their > perspective. > Obviously this situation didn't materialize overnight and it > shouldn't > be surprising that we've had to implement work-arounds to this > problem. For instance, encryption goes a long way in limiting the > network's visibility in the packet, but that does have its limits. > > > Tom > > Let's not forget that some of those same developers are > responsible for implementing surveillance capitalism, one of the > most egregious invasions of user privacy and surely contrary to > RFC 7258 - I know that people generally seem to focus on > network-based monitoring, however application-based monitoring is > potentially far more invasive. Some of the application-based > "work-arounds" to network security measures you reference could be > helpful in allowing those applications to exfiltrate user data; if > applications behave increasingly like malware then it should not > come as a surprise if they are treated as such by networks in an > effort to protect users. > > > Andrew, > > That's a very general statement. Can you give a specific example? > Maybe one possibility is STT (draft-davie-stt) which was designed to > repurpose TCP protocol number 6 as a tunneling protocol to circumvent > some networks that filter UDP. But that proposal was rejected by IETF > and never accepted into Linux. > > But even if a network assumes responsibility to protect the user from > malware, its ability to offer any reasonable protection to users is > extremely limited and becoming more limited. Network devices don't > have the E2E visibility or context to properly filter application > malware-- this is both true architecturally and in practice given the > prevalence of TLS deployment. > > > As noted elsewhere, I believe that it would be beneficial to the > IETF community if greater efforts were made to engage with > enterprise and public network CISOs, as well as more network > operators. This would help inject more understanding of current > operational security practices and considerations into protocol > development activity, which might help to avoid puzzlement when > new developments are unleashed, only to find them blocked or only > greeted with luke-warm enthusiasm by those that have operational > responsibility for security, customer service etc. > > > "those that have operational responsibility for security, customer > service etc." is not limited to network operators, application > developers, server operators, and OS providers also assume that > operational responsibility-- so if there is a conversation it should > include all the players. Also, I'm not sure that "understanding of > current operational security practices" would be of use here. As far > as I can tell, there are no uniform security practices amongst network > providers on the Internet. For instance, with respect to extension > headers, some providers allow all of them, some allow none, and some > seem to allow a subset. Besides that there's already RFC9098 that > highlights some reasons why packets with extension headers might be > discarded, but doesn't quantify the practices (exactly who is dropping > packets and why). > > Tom > > > Tom > > > Andrew > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- [IPv6] Why folks are blocking IPv6 extension head… Fernando Gont
- Re: [IPv6] Why folks are blocking IPv6 extension … Tom Herbert
- Re: [IPv6] Why folks are blocking IPv6 extension … Ted Lemon
- Re: [IPv6] Why folks are blocking IPv6 extension … David Farmer
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… nalini.elkins@insidethestack.com
- Re: [IPv6] Why folks are blocking IPv6 extension … Jen Linkova
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Vasilenko Eduard
- Re: [IPv6] Why folks are blocking IPv6 extension … Fernando Gont
- Re: [IPv6] Why folks are blocking IPv6 extension … Fernando Gont
- Re: [IPv6] Why folks are blocking IPv6 extension … Tom Herbert
- Re: [IPv6] [OPSEC] Why folks are blocking IPv6 ex… Andrew Campling
- Re: [IPv6] [OPSEC] Why folks are blocking IPv6 ex… Andrew Campling
- Re: [IPv6] Why folks are blocking IPv6 extension … Tom Herbert
- Re: [IPv6] [OPSEC] Why folks are blocking IPv6 ex… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Nick Buraglio
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Dale W. Carder
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Nick Buraglio
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Nick Buraglio
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Ackermann, Michael
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Xipengxiao
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Michael McBride
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Ackermann, Michael
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Fernando Gont
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Brian E Carpenter
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Ole Troan
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Haisheng Yu
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Andrew Campling
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Bob Natale
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Tom Herbert
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Ole Troan
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [EXT] Re: [OPSEC] [v6ops] Why folks ar… Bob Natale
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… David Farmer
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Tom Herbert
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Michael Richardson
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Ole Trøan
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… David Farmer
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Ole Troan
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Tom Herbert
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Fernando Gont
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Tom Herbert
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… nalini.elkins@insidethestack.com
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Ole Troan
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Fernando Gont
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Fernando Gont
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Tom Herbert
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Tom Herbert
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Brian E Carpenter
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… Michael Richardson
- Re: [IPv6] [OPSEC] [v6ops] Why folks are blocking… Brian E Carpenter
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Brian E Carpenter
- Re: [IPv6] [v6ops] Why folks are blocking IPv6 ex… hsyu
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Fernando Gont
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Manfredi (US), Albert E
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Fernando Gont
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Arnaud Taddei
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Vasilenko Eduard
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Arnaud Taddei
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Vasilenko Eduard
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Arnaud Taddei
- Re: [IPv6] [v6ops] [OPSEC] [EXTERNAL] Re: Why fol… nalini.elkins@insidethestack.com
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] [EXTERNAL] Re: Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] [EXTERNAL] Re: Why fol… nalini.elkins@insidethestack.com
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Manfredi (US), Albert E
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Brian E Carpenter
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Manfredi (US), Albert E
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Bob Natale
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Haisheng Yu
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Warren Kumari
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Ole Troan
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Warren Kumari
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Andrew Campling
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Fernando Gont
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Fernando Gont
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Fernando Gont
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Fernando Gont
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Tom Herbert
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Fernando Gont
- Re: [IPv6] [v6ops] [OPSEC] [EXTERNAL] Re: Why fol… Clark Gaylord
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Fernando Gont
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Manfredi (US), Albert E
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Brian E Carpenter
- Re: [IPv6] [OPSEC] [v6ops] [EXTERNAL] Re: Why fol… Brian E Carpenter
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Tom Herbert
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Manfredi (US), Albert E
- Re: [IPv6] [v6ops] [EXTERNAL] Re: [OPSEC] Why fol… Andrew Alston
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Tom Herbert
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Andrew Campling
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Tom Herbert
- Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking… Dirk Trossen
- Re: [IPv6] [EXTERNAL] Re: [v6ops] [OPSEC] Why fol… Mike Simpson
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Haisheng Yu
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Nick Hilliard
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Fernando Gont
- Re: [IPv6] [OPSEC] [EXTERNAL] Re: [v6ops] Why fol… Bob Natale