The Scourge of Excessive AS-SETs

Summary

An AS-SET is a special object that represents a group of ASNs and forms the basis for IRR-based route filtering. However, many AS-SETs in circulation today have grown so big that they effectively whitelist much of the routing table, rendering them ineffective. According to recent analysis, there are currently 2,192 AS-SETs which expand to over 1,000 ASNs each! In this blog post, we’ll describe what an AS-SET is, its role in route filtering, and how to deal with excessively large AS-SETs.

In the last edition of Beyond Their Intended Scope, our series analyzing BGP leaks, we investigated a recent path leak by a BGP-based DDoS mitigation vendor. In it, we touched on the possibility that the size and scope of this leak may have been a product of a rarely discussed problem in the world of automated route filtering: excessively broad AS-SETs.

In this post, we’ll discuss what AS-SETs are, their role in automated route filtering, and the challenges that excessive AS-SETs cause. Finally, with the help of bgp.tools founder Ben Cartwright-Cox, we’ll look at some of the worst (i.e., most excessive) AS-SETs on the internet today.

A DDoS mitigation leak

Let’s begin by recapping what happened on April 1, 2025. As we wrote in our post:

Because this was not a mis-origination leak, RPKI Route Origin Validation (ROV) wouldn’t help here. ROV only checks the origin AS in the AS_PATH (along with the maximum prefix length) and, in this case, the origins in the leaked routes were unaltered.

Another popular mechanism that service providers use to limit disruption due to leaks is the IRR-based route filter. To employ such a route filter, a service provider imports IRR data to generate an allowlist of prefixes based on an AS-SET that can be applied to a border router’s inbound BGP session. This prefix allowlist enables the border router to drop any announcements that shouldn’t be coming from the AS, such as those generated by a routing leak like the one above.

What is an AS-SET?

In the Internet Routing Registries (IRR), an AS-SET is a special database object type that represents a group of ASNs and other AS-SETs. It’s primarily used for route filtering and policy control by ISPs and network operators.

Note: The IRR AS-SET object type is not to be confused with the unrelated BGP AS_SET construct, which has been deprecated. BGP AS_SETs appear in the AS_PATH of a BGP announcement as one or more ASNs surrounded by curly brackets {}.

Think of an AS-SET like a macro or alias for a list of ASNs. AS-SETs are intended to be a convenient way for an AS to communicate to others what customer ASes it may be providing transit for.

To build a prefix allowlist from an AS-SET, each member is recursively evaluated. If the member is an ASN, the IRR is searched for route objects (route: for IPv4 and route6: for IPv6) which contain that ASN in the origin field. Member AS-SETs are similarly recursively expanded into member ASNs, which are also expanded into their prefixes. The resulting prefix list can be loaded into the router’s running configuration to be applied on the BGP session with the neighbor in question.

Note: IRR AS-SETs can be explored on the command line with Job’s irrtree utility.

But there are some big challenges that can limit the usefulness of AS-SETs. There are no inherent quality, integrity, and authenticity controls over the contents of an AS-SET, and there are no limits to the number of AS members or AS-SETs that can be included in an AS-SET, nor on the depth of the resulting recursion. This can lead to excessively large AS-SETs. If an AS defines an AS-SET which includes the AS-SETs of some customers who contain AS-SETs, there can be a lack of awareness by the various parties of their implicit contribution to the resulting prefix list.

As we mentioned in the blog post excerpt above, the leaker in the April 1 route leak has an AS-SET in RADB called AS-VOXILITY-SET, which expands to 28,552 ASNs as depicted below!

A popular tool for building BGP filter lists based on IRR data is bgpq4. The user can specify an AS-SET, and the tool gathers the necessary data and returns an allowlist of prefixes ready to be added to a router’s configuration.

For AS-VOXILITY-SET, bgpq4 “-J” returns a Junos router configuration section that is over 900,000 lines long!

$ bgpq4 -Jl eltel AS-VOXILITY-SET | wc -l  
947346

Of those lines, we calculate that 165,472 are unrouted at the time of this writing — address space that doesn’t currently appear in the global routing table. We can use the -A option to aggregate routes, reducing the lines of configuration to only 200,000 lines, but it is still a lot.

$ bgpq4 -Al eltel AS-VOXILITY-SET | wc -l  
210325

Another issue is that AS-SET definitions can vary by source IRR (which is why it is important to indicate the authoritative source of the AS-SET in PeeringDB, for example). Note the difference in output length for the three variations of the command above when the source is set to APNIC, RIPE, and RADB. (Note: Default source for bgpq4 is NTT’s IRR mirror service.)

In an incident last year, Russian mobile operator MTS (AS8359) mistakenly propagated over 30,000 routes learned from the Hong Kong Internet Exchange (HKIX, AS4635) to its transit providers, Lumen (AS3356) and, to a lesser extent, Arelion (AS1299). The leaked routes circulated around the internet, causing traffic from faraway networks to be misdirected through MTS in Russia beginning at 07:56 UTC on March 11, 2024.

The leaker in that incident used an AS-SET called AS-MTU, which expands to 38,394 ASNs! And there are other problems, such as the fact that AS-MTU has AS-MWS as a member, which in turn has AS-MTU as a member.

The routes contained in AS-MTU represent 1.8 billion unique IPv4 addresses out of the total possible 3 billion addresses currently in the IPv4 routing table.

The expanded prefix list defined by AS-MTU includes a variety of improbable and unhelpful entries. For example, here’s just a sample of the prefixes that this Russian mobile operator is supposedly fine to provide transit for.

Any transit provider using these AS-SETs to build allowlists on router interfaces would be hindering their ability to stop the propagation of most leaked routes while paying a high price for the privilege in terms of computational resources on the routers. In many cases, they are simply not practical to deploy.

The world’s largest (and most problematic) AS-SETs

Ben Cartwright-Cox of bgp.tools, was kind enough to run through the data to identify the largest (and most problematic) AS-SETs in IRR data. According to his analysis, there are currently 2,192 AS-SETs which expand to over 1,000 ASNs each! Here’s the top five largest AS-SETs by member ASN count.

The observant reader might notice that these ASN counts exceed the number of ASNs in the global routing table (~90k) and might ask where the unrouted ASNs are coming from?

Well, they come from the myriad of downstream nested AS-SETs, and to illustrate this phenomenon, Ben wrote a script to traverse the nesting from an excessive AS-SET to one of its component unrouted ASNs, and the journey is wild.

The AS-SET AS-XUA-UA from RIPE expands to almost 90,000 ASNs, including many unrouted ones.

The path from this AS-SET to a component unrouted ASN is as follows:

This circuitous sequence of AS-SETs begins in Ukraine and includes, among other countries, Bulgaria (Balkan-IX), the Netherlands (NL-IX), Russia (TTK), China (CN2), South Africa (WOLCOMM), China again (CTGNet), and Russia again (Rostelecom), before landing on AS201030, the unrouted AS of ”Public corporation for organisation of air traffic intheRussian Federation.” Phew!

What’s the problem? Lots of pain for little gain

These excessively large AS-SETs are problematic for multiple reasons.

By being so broad, they are unlikely to do much good in the event of a routing leak. Because we don’t know the filter policies of the upstreams of the previously mentioned leakers, we can’t be sure how much their excessive AS-SETs exacerbated those leaks — but they certainly didn’t help!

Additionally, this level of ineffectiveness comes at a significant computational cost. The router configurations resulting from such AS-SETs eat up precious memory and processing resources on core internet routers. These devices update their configurations throughout the day, adding millions of lines of waste, over and over. Multiple engineers at major cloud operators or backbone telecoms have shared that they have had to write custom software to deal with the excessive AS-SETs that they encounter.

The problem of excessive AS-SETs is a case of the tragedy of the commons. The Internet Routing Registries (IRR) are shared resources without a central overseer to clean up the pollution and the “costs” of the pollution don’t accrue to the “polluters.” Moreover, the ability to nest AS-SETs within AS-SETs without bounds or permission can mean that there can often be little awareness by any of the entities contributing to the problem. It is also reminiscent of my previous analysis on excessive AS Path prepending, in the respect that any routing mechanism allowed to grow unchecked, will do so.

What’s the solution?

Owners of AS-SET objects need to review any AS-SETs they define and ensure that they contain the minimum amount of ASes and AS-SETs to facilitate the creation of effective allowlists. Ideally, AS-SET recursion is avoided where possible or at least kept to a minimum. The downside of this “solution” is that it requires full and cognizant cooperation of all AS-SET holders, which is unrealistic in the global Internet routing system. Furthermore, to avoid inadvertent naming collisions as much as possible, ISPs should follow the hierarchical naming practice when creating new AS-SETs. Multiple RIRs already mandate new AS-SETs to follow the hierarchical convention.

What are longer-term solutions?

Lacking any cryptographic assurances, IRR AS-SETs perhaps are a technological dead end which in the years to come we’ll collectively recognize as an unnecessary risk to business.

Ultimately, the issue of BGP route leaks needs to be addressed through something better than unwieldy self-asserted allowlists. Instead, the industry should use a combination of in-band BGP signaling, such as described in RFC 9234, RPKI-based signaling using ASPA verification (work-in-progress), and perhaps future RPKI extensions such as Signed Prefix Lists (work-in-progress). IRR-based AS-SETs simply lack a degree of precision and contextual awareness to mitigate route leaks at scale; it would be more fruitful to use an intersection of in-band and out-of-band signals to ascertain whether a given BGP route announcement is a leak or not.

Special thanks to Ben Cartwright-Cox of bgp.tools for his analysis using AS-SET data from his service. Also, a big thanks to Tony Tauber (Comcast), Aaron Weintraub (Cogent), and Anees Shaikh (Google) for their feedback and suggestions.