On a quick first read, this seems like very much one of those things that is theoretically possible, but highly implausible in the real word. 1. This would be a lot of money for an attacker to spend, connecting to 3 specific ASNs, just to slow down convergence. 2. p3619 : "Then each new prefix will be propagated in parallel." Not really. Even if you assume the AS A sent a single UPDATE with 1 NLRI for each prefix, ASes B C D are going to aggregate multiple NLRI changes in a single UPDATE message to each other. This isn't going to cause the amplification claimed. 3. p3620, 5.1 Experiment Infrastructure Their virtualized test setup is many orders of magnitude less powerful than the actual hardware run by the ASNs that would theoretically be susceptible to this. The software run on this hardware is also WAY more optimized than FRR and BIRD are , especially at massive BGP scale that they run. 4. p3622, 5.3 BGP Vortices Delay Network Convergence, Methodology This methodology is bad. "I wanted X seconds to see" is meaningless. In a controlled environment, you can set things up to see exactly how long convergence takes. You don't need to handwave it. The real DFZ sees almost constant update splashing and oscillations similar to this 24/7/365, none of it malicious. And it has for years. On Mon, Oct 6, 2025 at 6:32 AM Martin Tonusoo via NANOG < nanog@lists.nanog.org> wrote:
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/SU76M47A...