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@mork.no> wrote:

Nick Hilliard <nick@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