Let’s talk malformed AS_PATHs. Unless you’re enforcing the “First AS” of received routes, you’re vulnerable to hijacks that not even ASPA validation can prevent.

Read more here, and enforce the First AS in BGP.
https://blog.cloudflare.com/enforce-first-as-bgp/

Enforcing the First AS in BGP AS PATHs

BGP is vulnerable to routing hijacks and path leaks that negatively impact traffic on the Internet. RPKI helps solve some of these problems, but for some forged paths, we need to rely on a simpler mechanism: First AS enforcement in BGP.

The Cloudflare Blog

@next_hopself FRRouting defaults to enforce-first-as since version 9.1:
https://github.com/FRRouting/frr/blob/da2c34a0d0cbe213599a6ec937140e2a62f20a5a/bgpd/bgp_vty.c#L130-L133

but check your configs, if you upgraded an old config you might have the "no" form due to the compatibility logic :)

[ed.: didn't see it's linked in the article, ohwell]

frr/bgpd/bgp_vty.c at da2c34a0d0cbe213599a6ec937140e2a62f20a5a · FRRouting/frr

The FRRouting Protocol Suite. Contribute to FRRouting/frr development by creating an account on GitHub.

GitHub
@equinox yep I made sure to link the relevant patch in the blog, but thanks! :)

@next_hopself in my defense, I posted this a few minutes before having to get off a train, bit of a rush. Anyway, oops 😅

Fun list to look at, though, with the defaults changes. The way it works is that hitting a "frr version" or "frr profile" statement flips the load-side defaults. But it's always shown/stored with the current version. Hence an old version can get a "no bgp enforce-first-as" if you load&save it. (automated configs only get the load side of course.)

@next_hopself this does also mean if your automation template has "frr version 8.4" in it, you get no enforce-first-as, even on newer versions, because that was the default back then (and what your template claims to target)