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

[Fernando Gont <[e-mail]>]

Hi, Haisheng Yu (Johnson),

On 8/6/23 10:01, Haisheng Yu (Johnson) wrote:
> 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?

RFC9098 and associated pointers.



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

Strongly disagree. In fact, having been on the seat to make such 
decisions, you're probably assuming that the EH topic, for the folks 
making such decisions, is more important than it actually is. i.e., you 
don't have the luxury to spend a lot of time on a feature that, for the 
most part, doesn't have a real use case in the deployed wor;d (other 
than the recent SRv6 in limited domains).

For development and use cases, 
https://www.rfc-editor.org/rfc/rfc9288.txt is your friend -- that part 
is the important part of the document, I'd say.



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

Yes. And RFC9098 provides enough references with datapoints proving that.



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

That's not the way a security team works: What you normally want to do 
is eliminate unnecessary risk.  Risk associated with a feature that is 
for the most part, not used for production, is risk you want to eliminate.



> We should not refrain from using IPv6 extension 
> headers simply out of fear of the potential effects on efficiency and 
> security.

Yes. Everyone is free to play in their own lab or network. Now, if what 
you want is me granting arbitrary folks permission to play with EHs in 
my production systems, the answer is simple: "No, thank you".



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

RFC9288 essentially already provides that.



> Alternatively, we can iterate on the foundation of 
> 6man-eh-limits, and I would be glad to contribute in this regard.

As long as you/we can't agree on:

* Minimum common denominator (as opposed to a requirement of supporting 
arbitrary IPv6 header chains, which is unreal)
* Who is going to pay the associated cost (because in a lot of cases, 
processing EHs in the fast path requires $ )

and,

* Have vednors be able to gracefully handle EH chains, without trivial 
syntax-processing bugs found every now and then

and,

* provide a compelling feature that folks require (other than |I feel 
like playing with EHs)

... the outcome is going to be the same.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494