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 12:05 PM Fernando Gont <[e-mail]> wrote:
>
> Hi, Ole,
>
> On 22/5/23 15:36, Ole Troan wrote:
> [...]>>
> >> 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?
>
> No, I certainly wasn't. -- I was just arguing about filtering at e.g. an
> Enterprise edge.
>
> As for transit networks... it's tricky. In a lof of cases, the dropping
> of such packets doesn't have to do with trying to protect the
> destination AS, but rather because EHs may result in e.g. performance
> issues when the transit AS tries to protect e.g. their own
> infrastructure (see RFC9098). In such scenarios, I'm not sure there are
> many alternatives to just dropping the offending packets (even if
> undesirable).

Fernando,

I don't understand what the performance issue is here or why EH would
adversely affect transit network infrastructure. RFC8200 allows
intermediate nodes to ignore all extension headers including HBH
Options, so, IMO, in a transit network the best behavior for routers
is to ignore *all* EH and just forward packets on to their
destination. The one adverse effect might be that EH impacts ECMP to
cause inconsistent routing within a flow, but that could only affect
end-to-end performance that the application sees and not harm the
infrastructure (and in that case, the host would probably only see
performance issue if  was inconsistently sending extension headers for
packets in a flow).

Tom

>
>
> > 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.
>
> FWIW, I don't think anyone wants to block them, but rather to provide
> guidance about what's sensible to do. e.g., what to do with EHs at the
> Enterprise trust boundary is a usual question from Enterprise folks.
>
>
>
> > 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.
>
> Agreed on this.
>
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494