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

[David Farmer <[e-mail]>]

On Sun, May 21, 2023 at 4:29 PM Brian E Carpenter <
[e-mail]> wrote:

> On 21-May-23 21:33, Fernando Gont wrote:
> > 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.
>

While "permissionless innovation" remains important. However, particularly
over the last 25 years, we also think "security" and "privacy" are at least
equally important and can not be sacrificed to "permissionless innovation."
That being said, we MUST balance these multiple priorities. which means we
can not completely sacrifice "permissionless innovation" to "security" and
"privacy" either.

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

We need to be careful not to speak in absolutes here; it is neither
appropriate to allow or require all possible EHs nor deny or prohibit all
possible EHs. Fernando has admitted at least some EHs are necessary, and
Tom's Draft defines where certain invalid or impracticably large EH
constructs can and should be dropped. There needs to be sufficient nuance
and practicality involved in the conversation; It is unhelpful to
portray opposing arguments as extreme strawmen.

1. Certain EH constructs SHOULD never be allowed; we need reasonable and
practical limits; I think Tom's draft makes significant progress here.
2. Certain EHs SHOULD be allowed in certain places and SHOULD NOT be
allowed in others; this thread is at least a good starting point for some
recommendations along these lines.
3. Certain EHs almost always need to be allowed; these need to be
enumerated similarly to RFC 4890 for ICMPv6.

Dropping EHs just because they are unknown, especially by transit
providers, probably isn't appropriate in most situations. Dropping unknown
EHs by a host or by a middlebox very close to the host could be
appropriate, at least in some situations. Nevertheless, that doesn't mean
there are no EHs that it is appropriate for transit providers to drop.


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


So, a default deny inbound policy is fairly well accepted for client hosts
behind a stateful firewall and/or NAT. This doesn't mean communication
between two such clients is impossible, but that such communication needs
to be directly or indirectly mediated through a third-party server, often
referred to as firewall traversal. Similarly, we should think about
techniques for hosts wanting the communicate using EHs that are not allowed
on the network path between them. Maybe call this EH traversal, and it
likely involves a tunnel or encapsulating the packet with the unknown EHs
between the two hosts. I'll note that adding EHs in flight is not allowed,
and a common technique is to add a new IPv6 header with the new EHs
encapsulating the old packet.

Thanks

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================