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

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)
> 下一代互联网关键技术和评测北京市工程研究中心有限公司
> [email protected]
> 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<[email protected]> 
> <mailto:[email protected]>
> Date 	5/30/2023 02:32
> To 	Andrew Campling<[email protected]> 
> <mailto:[email protected]>
> Cc 	Tom Herbert<[email protected]> ,
> <mailto:[email protected]> 
> [email protected]<[email protected]> ,
> <mailto:[email protected]> [email protected]<[email protected]> ,
> <mailto:[email protected]> [email protected]<[email protected]> 
> <mailto:[email protected]>
> 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
> <[email protected]> wrote:
>
>
>     On Sat, May 27, 2023 at 11:05 PM Tom Herbert <[email protected]>
>     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
>     [email protected]
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------