Re: mitigations for the BGP vortex attack

[Tom Beecher via NANOG <nanog () lists nanog org>]

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/SU76M47AOL5742T6Q5OW2DBMRNSYU42Y/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/TORZKEMMOZ2QRJGWTJDDHEBJIEVRBJ7P/