JunOS/FRR/Nokia et al BGP critical issue

Tue Sep 5 13:27:46 UTC 2023

>
> But there's obviously not been enough thought applied to realize that
> optional transitive attributes must be considered evil by default. They
> can only be used after extremely careful parsing.
>
> ...

> I was hoping we'd moved past that point in the software development
> history.
>

There have been plenty of nerd debates about the evilness of optional
transitive attributes. Talk to any of the folks from IETF who have worked
on the BGP RFCs.

This isn't a 'software development problem', nor is this current thing some
new, unknown 'vulnerability'.

BGP speakers closing a session with this specific attribute is exactly what
RFC4271 says it's supposed to do. Not closing the session and handling it
differently depending on the problem is doing exactly what RFC7606 says
it's supposed to do. I haven't looked at every vendor in the original post
here, but I don't recall seeing any of them doing something against spec.

On Fri, Sep 1, 2023 at 5:54 AM Bjørn Mork <bjorn at mork.no> wrote:

> Nick Hilliard <nick at foobar.org> writes:
> > Bjørn Mork wrote on 01/09/2023 08:17:
> >> Sounds familiar.
> >>
> https://supportportal.juniper.net/s/article/BGP-Malformed-AS-4-Byte-Transitive-Attributes-Drop-BGP-Sessions?language=en_US
> >> You'd think a lot of thought has gone into error handling for
> >> optional
> >> transitive attributes since then, but...
> >
> > A good deal of thought has gone into the problem, and this is where
> > rfc7606 came from. Treat-as-withdraw for the NLRI in question is the
> > default option with this approach, and should be deployed universally.
>
> Yes.
>
> But there's obviously not been enough thought applied to realize that
> optional transitive attributes must be considered evil by default. They
> can only be used after extremely careful parsing.
>
> This is the BGP version of
>
>  select * from mytable where field = $unvalidated_user_input;
>
> I was hoping we'd moved past that point in the software development
> history.
>
>
> Bjørn
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230905/75e3596b/attachment.html>