Hi, all

I have written a blog on APNIC discussing the limitations of using extension headers in IPv6, the security issues associated with extension headers, and how to optimize the use of IPv6 extension headers.

Here is the link to the blog on APNIC where I discussed the limitations of using extension headers in IPv6, the security issues associated with extension headers, and how to optimize their usage:

APNIC BLOG:https://blog.apnic.net/2022/12/14/ipv6-extension-headers-in-routing-security/




Haisheng Yu
---- Replied Message ----
From Ole Troan<[email protected]>
Date 5/22/2023 18:04
To Brian E Carpenter<[email protected]>
Cc Fernando Gont<[email protected]> ,
IPv6 Operations<[email protected]> ,
6man WG<[email protected]> ,
<[email protected]>
Subject Re: [IPv6] [v6ops] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
It depends on your position in the network.

A) Transit AS:
Should transparently pass all traffic and not look beyond the 40-byte IPv6 header.

With the exception of NH=0.
Let’s have that discussion if there ever is a HBH option with “transit AS applicability”.

B) Limited Domain

C) Modern application
With modern applications, it has become blurry where the application ends and the network starts.
Where the “application” is disaggregated, embeds a custom network stack for it’s purpose.
Has a set of IP addresses representing the “service”, but those addresses does in no way represent an interface on a host.
That “cluster” of services is only going to support the functions that the application needs.
An EH would essentially be a side channel here.

D) Enterprises
What Fernando says.

It’s somewhat ironic that 25 years in, this debate is still hypothetical.
“What if we ever got an EH that has Internet wide applicability”
(and for the sake of argument I’ve rebranded ESP to a tunnel encap).

O.

On 21 May 2023, at 23:28, Brian E Carpenter <[email protected]> wrote:

On 21-May-23 21:33, Fernando Gont wrote:
Hi, Tom,
On 18/5/23 15:27, Tom Herbert wrote:
[....]

So, I’m not really happy with the all or nothing approach the two of you
seem to be offering for IPv6 extension headers, is there something in
between? If not, then maybe that is what we need to be working towards.

FWIW, I[m not arguing for a blank "block all", but rather "just allow
the ones you really need" -- which is a no brainer.

Fernando,

I'm not sure how that's a no brainer, who decides "the ones you really
need"?
Typically. whoever runs the destination AS or network. Or the transit
AS, if the packets will affect the transit AS.

And there's the problem. The operator of a large network cannot possibly
know which extension headers every host on the network needs. It's
called permissionless innovation, and is supposed to be one of the main
success factors for the Internet.

If everyone independently makes that decision then we wind up
with an Internet that can't evolve and is perpetually stuck in the
status quo.
Well, yes, there's no big brother making decisions about mine or your
networks' policies.... hence everyone makes decisions independently.

From the point of view of hosts, there is an anonymous Big Brother, the
moment that any upstream operator blocks a wanted extension header.

(IN a way that's why QUIC runs on top of UDP ... although in the case of
QUIC, I bet it has more to do with NATs thatn with explicit firewalling)

It's to do with *any* barrier to IP layer transparency. This is a very
basic tussle in the architecture.

Brian

The list you need
is, maybe Frag and, say, IPsec at the global level? (from the pov of
most orgs).

(yeah... HbH and the like are mostly fine for the local link (e.g. MLD).

It might be productive if you suggested a more concrete direction
here. Maybe a proposed BCP suggesting the EHs that you believe should
be universally blocked and the rationalization for that and why the
problems with them can't be fixed.
Are your referring to the "transit AS" case, the "dest AS/network" case,
or both?
In any case, my comment was simply a two-liner email comment, as opposed
to full-fledged advice.
Thanks!
Regards,
_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops



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

Reply via email to