I still remember the mad scramble we had to fix CVE-2023-4481 across our entire network. This class of bugs is going to be an absolute nightmare to deal with, and because of the way BGP has been designed & implemented, it is going to take a _long_ time to fix these kinds of behaviors.
I was developping BGP feature in a telco vendor though it's decades ago.
Still think BGP is too complex and people keeping add new features and vendors keeping implement it based on RFC standard or draft.
And it seems BGP will never be deprecated so this sort of bugs will continue be found again and again...
HGC Global Communications Limited, formerly known as Hutchison Global Communications Limited (abb. HGC), is an internet service provider of Hong Kong.
Our IOS XR chassis' have gotten some of these packets. Corresponding with high bgp route advertisements. No idea what equipment upstream uses tbh.
Makes me wonder if the BGP protocol is properly fuzzed. Perhaps its one of those things that everyone is scared to try to knock over given it's so important.
I suppose it would be easy to write a fuzzer for bgp but very hard to diagnose crashes?
Is it just me or BGP is something I never learnt about until I heard about it causing issues? It seems it's essential to the internet, just like TCP/IP, but nevertheless I learnt about the latter in the university, during my career, I read many books about TCP/IP... but nothing about BGP (not in the university, not at work, not in books, nothing).
I can "play" with TCP/IP at home in dummy projects and learn more about it... but I have no idea how to "play" with BGP. In that regard, how does one learn about it at home?
It appears to this reader that BGP would be a lot more stable if the various hardware vendors agreed on a standard for handling these types of things.
Is the real issue that each vendor wants lock-in, so won't standardise?
DISCLAIMER: My understanding of BGP is hollow and shallow, I am not an expert.
Given the impact of such bugs, I'm surprised there isn't a consortium with an interoperability test suite. Or maybe there is, and this specific issue isn't in the test suite. In which case, I'm surprised test cases aren't generated with a fuzzer and/or machine-generated full exploration of possible packet errors. I mean, it's fine if the suite takes hours or even days to run.
I guess the author of the article here has written a fuzzer with some coverage, and has come across similar issues before. Astonishing that the vendors don't pick up on this work hungrily.
Several vendors had this bug in the past https://www.kb.cert.org/vuls/id/347067
CVE-2023-4481 (Juniper) CVE-2023-38802 (FRR) CVE-2023-38283 (OpenBGPd) CVE-2023-40457 (EXOS)
Arista was not affected then.
Has there ever been anything so byzantine in scale and accidental complexity as internet plumbing.
> At 7AM (UTC) on Wednesday May 20th 2025
May 20th was a Tuesday, just sayin'
Does multicast over the Internet even work?
I thought BGP was only for private networks.
Well surprise, people cheat because an academic degree is yet another checkbox to be ticked in the ever more grueling list of tasks needed to be done to acquire a job that has even a remote chance of paying a living wage.
Fix that, so that only those actually interested in academia per se and not just because they need a checkbox to tick remain, and the problem with cheating in academia will collapse.
The standard approach is be liberal in what you accept and be specific in what you emit.
You could
1) Filter the broken message
2) Drop the broken message
3) Ignore the broken attributes but pass them on
4) Break with the broken attributes
To me, only 4 (Arista) is the really unacceptable behaviour. 3 (Juniper) isn't desirable but it's not a devastating behaviour.
EDIT: Actually rereading it, Arista did 2 rather than 4. I think it just closed the connection as being invalid rather than completely crash. That's arguably acceptable, but not great for the users.