Internet routers have finite Forwarding Information Base (FIB) and Routing Information Base (RIB) memory and may drop updates, close connections, or entirely crash upon exceeding their physical limitations. This observation has led to the introduction of de-aggregation attacks — an attack in which an Autonomous System (AS) introduces enough new routes into the routing ecosystem to exhaust the memory of (potentially random) target routers — more than a decade ago. As a countermeasure, networks often limit the maximum number of prefixes they may receive via each session.
My fellow researchers from the Max Planck Institute for Informatics and the Institute of Theoretical and Applied Informatics of the Polish Academy of Sciences and I recently revisited prefix de-aggregation attacks and what’s needed to detect, mitigate, and prevent them.
In this blog post, we will briefly summarize the findings from our preprint and mailing list announcement and then put them into perspective.
Why even revisit prefix de-aggregation attacks?
With per-session prefix limits in place, an AS may need hundreds or thousands of sessions to originate critical numbers of prefixes. A decade or two ago, only a few ASes even had the infrastructure footprint to fulfil this requirement. Nowadays, there are over a thousand Internet Exchange Points (IXPs), each providing access to sessions with tens or hundreds of other networks. Attackers may connect to these IXPs virtually via BGP-enabled virtual machines or physically via a Layer-2 connectivity provider, allowing them to reach hundreds of IXPs after a short time without deploying additional hardware and at a low cost.
At the same time, it is easier than ever to obtain critical numbers of prefixes. Even a new Local Internet Registry (LIR) can get a /29 IPv6 address block without justification in the RIPE region. This /29 may source more than a million unique IPv6 prefixes when using all Classless Inter-Domain Routing (CIDR) lengths up to /48 — the smallest CIDR that regularly propagates globally.
These two combined changes may render per-session max-prefix limits ineffective, potentially allowing prefix de-aggregation attacks to become viable.
How can we assess their current viability?
The harm that a full-scale de-aggregation attack could cause on the Internet outweighs any potential insights we would gain. Hence, we opted for multiple small-scale experiments that test separate yet interlocking parts of our attack model.
To get a better sense of scale, we theoretically analysed the resource requirements (for example, providers, peers, and peering LANs to connect with) for an attacker to introduce a certain number of routes into the routers of random, remote ASes.
To illustrate, Figure 1 shows the number of IPv6 sessions (y-axis) that an attacker may establish by joining a certain number of peering LANs (x-axis) and contracting a set of transit providers (see line encodings at the top).
Figure 1 shows that an attacker may establish over 1,000 IPv6 sessions with 10, 15, and 30 transit providers at 50, 37, and 20 peering LANs, respectively. While this analysis only used data from PeeringDB and EuroIX, other models and findings in our paper further rely on well-known assumptions and algorithms (such as CAIDA’s relationship inference) to estimate route propagation. All-in-all, our analyses suggested that large-scale, distributed prefix de-aggregation attacks are, in theory, feasible, even with a limited budget.
To get a better sense of practicality and spot-test for hurdles, we combined insights from:
- Deploying a small-scale testbed that remotely connected to four IXPs.
- Testing router hardware in a lab.
- Conducting route propagation and aggregation experiments from our testbed and the PEERING testbed.
- Analysing the routing information collected by RIPE RIS and Routeviews.
While we did observe some practical hurdles (for example, initial prefix limits on sessions or a few ASes that aggregate routes), we found that we could either weaken or lift them entirely. In particular, we were surprised by the willingness of some transit providers and peers to increase prefix limits without any justification from our end.
Based on our analyses, we assessed prefix de-aggregation attacks to be viable. To minimize the impact of our findings on the Internet, we ran a private disclosure campaign including eight major IXPs, all Tier-1 ASes, and seven major content providers before releasing our results to the public.
How do these attacks affect me?
Luckily, detecting prefix de-aggregation attacks is relatively simple, for example, by defining prefix-limit notification thresholds or directly monitoring the routing table size. Ideally, your providers should notice the attack and stop redistributing the related routes. However, as a de-aggregation event on 5 October 2022 showed, it may take multiple hours for this ideal scenario to occur. In the meantime, you can limit damages by filtering routes within the attack’s covering prefix or from the attack’s Origin AS.
To prevent these attacks altogether, you may configure dynamic yet tight max-prefix limits on all your sessions. While some networks rely on, for example, PeeringDB’s max-prefix recommendations for their dynamic limits, attackers may set arbitrarily high values in such databases. Hence, we suggest further limiting a session based on historical information, such as yesterday’s maximum number of prefixes. For more details, please refer to section 7 of our preprint paper.
We’d love to chat!
For us, it’s hard to gauge whether we communicated our work helpfully, how the community received it in general, and what we’d have to improve in the future. If you enjoyed this post, want to talk about our or related research, or even implemented some of our suggestions, we’d love to hear about your experience! Please email us at kirin@mpi-inf.mpg.de or ping us on Twitter (@mydamnhandle1 and @pforemski).
Lars Prehn is a PhD student in Computer Science at Max-Planck-Institut für Informatik, interested in routing, traffic engineering, and congestion control.
Pawel Foremski and Oliver Gasser contributed to this post.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
High five! Good job, lads.