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

[Tom Herbert <[e-mail]>]

On Mon, May 22, 2023 at 7:37 AM Ole Troan
<otroan=[e-mail]> wrote:
>
> Tom,
>
> > The problem is in public networks where the service provider acts as
> > "anonymous big brother" to enforce its concept of security to
> > "protect" the users. While I'm sure they'd like us to think that they
> > are acting for the benefit of the users and it's for the "good of the
> > Internet", the reality is that having a patchwork of random security
> > policies across the Internet is counterproductive, and, frankly, some
> > of these policies are driven more by localized business interests
> > rather than the users' best interests.
> >
> > As a host and networking stack developer, I view the network and these
> > arbitrary inconsistent security policies as the problem not as the
> > solution to application and host security. The best tool developers
> > have is to encrypt as much of the packet as possible to keep network
> > providers from meddling in protocol layers they shouldn't be, but
> > unfortunately that isn't applicable to all protocols like EH for
> > instance (although, given that IPsec was on Fernando's approved list
> > of extension headers, I suppose we could hide all the extension
> > headers we want in IPsec :-) )
>
> I don’t think Fernando has argued the case that some EHs should be filtered in public transit networks?
> In the whole I think it’s not a good idea that the IETF has some working groups working hard at defining new protocols and other working groups working hard at defining policies to block them.
>
> For public transit networks, the IETF could work on describing ‘what is Internet access’. The production declaration if you like. And then regulation  could be used to enforce that. We’d need encryption too I’m sure.
>
> Now for EHs in general. Their functionality of providing a separate signalling channel independent of the application… it might be time that we accept that this was a bad idea. Which deployment status has confirmed.

Ole,

I don't necessarily agree with that. We are seeing traction with
extension headers like routing header (e.g. segment routing) and
hop-by-hop options (like IOAM). Ostensibly, such extension headers are
meant to only be used in a limited domain as opposed to the open
Internet. There are three problems with the "limited domain" argument:
1) There is no normative definition of a limited domain 2) Even if
there was a normative definition, I think there would be substantial
pushback in bifurcating the protocol suite to have one set of
protocols for limited domains and another defined for general
Internet. 3) The lines between a limited domain and the open Internet
will inevitably be blurred anyway.

For the last point, consider that it is common for large networks to
host servers for content providers like Facebook or YouTube.
Conceivably, one could envision a HBH option that allows the provider
to provide fine grained QoS for their customers reaching those servers
(like draft-herbert-fast). How would this be viewed in using HBH in a
limited domain? Or extrapolating this scenario, suppose two providers
partner and want to share such signaling. How does this work in light
of limited domains? I would assume as long as transit networks don't
drop packets with EH it should work (hopefully without having to
tunnel packets across the Internet).

Tom

>
>
> Best regards,
> Ole