mitigations for the BGP vortex attack

[Martin Tonusoo via NANOG <nanog () lists nanog org>]

Hi.

I recently read an interesting research paper that I don’t think has
been shared here yet:
https://www.usenix.org/system/files/usenixsecurity25-stoeger.pdf

I would throw out two additional thoughts related to "Partial Mitigations"(6.1):

1. Usage of modern, multi-threaded routing daemons which are able to
take advantage of multi-core control plane CPUs.

2. Control plane CPU usage monitoring. BGP per-neighbor sent and
received UPDATE messages rate monitoring. For example, Junos supports
this via SNMP, telemetry or RPC.


In the "Safe BGP Communities"(6.2) paragraph the paper advises
networks to cease the support of "Lower Local Pref Below Peer"
community. As the BGP vortex forms only when both the "Lower Local
Pref Below Peer" and "Selective NOPEER" communities are present, then
perhaps alternative approach would be to cease the support of those
two communities together. In other words, both communities would still
be allowed separately, but not together. I did a brief analysis on
RIPE RIS data for NTT, GTT and Sparkle "Lower Local Pref Below Peer"
and "Selective NOPEER" type communities and the combination where both
types are attached to the prefix are rare.


Finally, I wonder if or how much the attack is amplified if the
adversary ensures(for example, using communities) that each announced
prefix has unique path attributes and thus there is an UPDATE message
per prefix.


Martin
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/SU76M47AOL5742T6Q5OW2DBMRNSYU42Y/