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
--------------------------------------------------------------------
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
