Route Servers (RSes) play a critical role in interdomain connectivity by enabling the efficient exchange of routes among hundreds of networks. At large Internet Exchange Points (IXPs), this model supports traffic exchange at a multi-terabit scale. This makes their routing policies particularly important, as misconfigurations can propagate incorrect routes across many networks.
This post examines how RS filtering works in practice, identifies a blind spot in current approaches, and discusses its operational impact.
How route server filtering is implemented
RS filtering combines several mechanisms intended to prevent the propagation of incorrect announcements.
Basic checks typically include controls such as filtering bogon prefixes or applying AS-PATH constraints. These mechanisms mitigate common misconfigurations and are applied on ingress to each BGP session.
More advanced validation based on both Resource Public Key Infrastructure (RPKI) and Internet Routing Registry (IRR) is then applied. However, with no operational standard governing how these checks are applied, IXPs can decide to perform them on ingress, egress, or split across both directions.
A common operational model works as follows. When an UPDATE reaches the RS:
- RPKI validation is applied first.
- INVALID routes are rejected.
- NotFound routes proceed to IRR-based filtering, which applies a stricter validation with two outcomes — valid or invalid.
In practice, when RPKI returns NotFound, the validation decision depends entirely on IRR-derived policy.
How IRR-based filtering works
IRR filtering relies on AS-SET objects, which represent collections of Autonomous System Numbers (ASNs). Operators use them to define which downstream ASes they may provide transit.
IRR-based filters are automatically generated using tools such as BGPQ4. The process is straightforward, as illustrated in Figure 1:
- The IXP operator provides the AS-SET name as input. In the example, AS64505:Customers.
- BGPQ4 expands the AS-SET into a list of ASNs, in this case [64505, 64509, 64496].
- For each ASN, route objects are retrieved from selected IRR databases, producing the prefix list [1.1.1.0/24, 2.2.2.0/24].
- The prefix list is then compiled into a filter associated with AS64505’s session.
The resulting filter acts as a prefix whitelist. When a route is received from AS64505, the RS checks whether the prefix appears in the list. If it does, the route is accepted; otherwise, it is rejected.
Where the blind spot appears
The issue is that AS-SET-based filtering reduces authorization to a single question: Does the prefix appear in the list generated from the member’s AS-SET?
During the AS-SET expansion, the binding between the prefix and the authorized ASN may be lost. In practice, the RS checks only whether the prefix is in the filter, not whether the origin AS is authorized to announce it.
This means that, under certain conditions, an invalid announcement may still be accepted.
As seen in Figure 2, if an unrelated AS64652 announces a prefix belonging to AS64509 via AS64505, the RS accepts the announcement because the prefix exists in the allowlist and the update arrives via the AS64505’s session. Since prefix ownership is not validated, the hijacked route is treated as valid and may be propagated.
Why AS-SET quality make this worse
The impact of this blind spot depends in part on the quality of IRR data. Many AS-SETs are poorly maintained and may accumulate unallocated, private, or inactive ASNs.
As a result, AS-SETs can become large and noisy, expanding prefix filters and increasing the likelihood that unrelated prefixes appear in the whitelist of a member.
Table 1 shows the largest AS-SETs ranked by the number of ASNs. All contain more than 103,000 ASNs, approaching the total allocated ASNs (around 130,000) and exceeding the number of active ones (around 77,000). In IRR data, these AS-SETs are associated with millions of IPv4 and IPv6 prefixes, significantly expanding RS filter prefix sets.
| AS-SET | ASes | IPv4 | IPv6 |
| AS39533:AS-PEERS | 104,491 | 2,232,229 | 955,918 |
| AS214292:AS-DECIX-L3-SERVICES-CUSTOMERS | 104,266 | 2,231,371 | 955,732 |
| AS-ST1-IXPS | 104,059 | 2,230,016 | 955,623 |
| AS3326:AS-PEERS-DEE | 103,864 | 2,229,607 | 955,575 |
| AS-CLOUD-IX-PRO | 103,856 | 2,229,582 | 955,555 |
| AS-MERKEL-PEERS | 103,856 | 2,229,594 | 955,567 |
| AS12732:AS-UPSTREAMS | 103,843 | 2,229,584 | 955,554 |
| AS39533:AS-SET:AS6695 | 103,842 | 2,229,580 | 955,553 |
| AS6695:AS-DECIX-FRA | 103,842 | 2,229,580 | 955,553 |
| AS-DECIX | 103,842 | 2,229,580 | 955,553 |
Data analysis
We analysed RS data from AMS-IX and NAMEX to determine whether this blind spot appears in operational data.
For the blind spot to occur, an invalid announcement must satisfy the following conditions:
- A Route Origin Authorization (ROA) must not cover the prefix. Otherwise, the announcement would be rejected by RPKI validation. We found 32% of entries in the NotFound state.
- The route must reach the route server, and no intermediate AS should filter it. We observed that 9% of entries were already invalid when they reached the RS.
- The route must arrive through an authorized session to appear in the whitelist. We found that 52% of entries arrived via authorized members, with 28% visible through multiple members.
- The origin AS does not need to appear in the member’s AS-SET, as RSes perform prefix-level filtering. In our data, 5.4% of accepted announcements had an origin AS not present in the AS-SET.
- The prefix must exist in a route object associated with an ASN in the AS-SET. Given the scale shown in Table 1, this condition is highly likely, allowing the prefix to be included during filter generation.
| Step | Announcements | Unique prefixes | Unique origins |
| Initial data | 492,543 | 288,314 | 38,246 |
| Public ASN | 492,418 | 288,223 | 38,201 |
| RPKI unknown | 158,134 | 98,284 | 18,937 |
| AS-SET Valid | 64,901 | 45,592 | 10,723 |
| Blind spot | 1,426 | 1,343 | 513 |
| High-level analysis | |||
| Cust-Prov | 807 | 750 | 285 |
| Siblings | 104 | 97 | 36 |
| AS-PATH | 34 | 30 | 19 |
| Supernet | 242 | 242 | 68 |
| Allocation | 38 | 36 | 26 |
| No relationship | 201 | 188 | 79 |
Observed cases: Starting from approximately 492,000 announcements, we identified 1,426 cases matching the blind spot, covering 1,343 unique prefixes from 513 origin ASes (Table 2). In these cases, the RS accepted the routes even though the origin AS has no route object authorizing the prefix.
Not all cases represent attacks and may reflect business relationships. Analysing the relationship between the origin AS and the prefix, we found that 56% of cases, the origin AS has a customer-provider relationship with the prefix owner, while 17%, it held a route object for a covering prefix. In the end, 201 announcements showed no clear relationship and may require operator attention.
Impact on legitimate announcements
AS-SET-based filtering also affects legitimate routes, which are cases in which a route object authorized the origin AS.
We found that 65.6% of valid announcements were filtered because the prefix was missing from the AS-SET-derived prefix list. In many cases, all announcements for the prefixes were filtered, resulting in loss of connectivity through the IXP.
We also observed 446 Multiple Origin AS (MOAS) cases. In eight of them, both legitimate and unauthorized origins announced the same prefix, and the RS consistently selected and propagated the illegitimate path.
Is this limited to a few IXPs?
To determine whether this behaviour was limited to the two IXPs analysed, we extended the study to IXPs worldwide (Table 3). For each IXP, we examined whether IRR filtering relied on AS-SET expansion and whether prefixes matching the blind spot conditions were visible in the RS outputs.
Among 26 IXPs analysed, 22 appeared to propagate blind spot prefixes, while only four did not, suggesting that this behaviour may be widespread in RS filtering models.
| IXP | AS-SET usage | Looking glass check | Blind spot mitigated |
| AMSIX | ✓ | ✓ | ✗ |
| BCIX | ✓ | ✓ | ✗ |
| BIX | ✓ | ✓ | ✗ |
| BNIX | ✓ | ✓ | ✗ |
| CIX | ✓ | ✓ | ✗ |
| DECIX | ✓ | ✗ | ✓ |
| FRANCE-IX | ✓ | ✓ | ✗ |
| GRIX | ✓ | ✓ | ✗ |
| GIGAPIX | ✓ | ✓ | ✗ |
| IX Australia | ✓ | ✓ | ✗ |
| IX.br | ✓ | ✓ | ✗ |
| INEX | ✓ | ✓ | ✗ |
| LINX | ✓ | ✓ | ✗ |
| LONAP | ✓ | ✓ | ✗ |
| MINAP | ✓ | ✓ | ✗ |
| MEGAPORT | ✓ | ✓ | ✗ |
| MSK-IX | ✓ | ✓ | ✗ |
| NAMEX | ✓ | ✓ | ✗ |
| NETNOD | ✓ | ✓ | ✗ |
| NLIX | ✓ | ✓ | ✗ |
| SGIX | ✓ | ✓ | ✗ |
| SIX | ✓ | ✗ | ✓ |
| STUTTGART | ✓ | ✓ | ✗ |
| SWISSIX | ✓ | ✗ | ✓ |
| TOP-IX | ✓ | ✓ | ✗ |
| UAE-IX | ✓ | ✗ | ✓ |
Operational recommendations
Both network and IXP operators can take steps to mitigate this issue.
For network operators:
- Create ROAs for all routable prefixes. The blind spot only affects prefixes in the RPKI NotFound state.
- Use authoritative IRR databases and maintain accurate IRR data.
- Regularly update AS-SET objects and remove unallocated, private, and inactive ASNs. (The ten largest AS-SETs could reduce their size by roughly 25%, as shown in Table 4)
| AS-SET | ASes (before) | ASes (after) | IPv4 | IPv6 |
| AS39533:AS-PEERS | 104,491 | 77,289 | 2,171,351 | 906,575 |
| AS214292:AS-DECIX-L3-SERVICES-CUSTOMERS | 104,266 | 77,252 | 2,170,569 | 906,409 |
| AS-ST1-IXPS | 104,059 | 77,134 | 2,169,482 | 906,306 |
| AS3326:AS-PEERS-DEE | 103,864 | 77,009 | 2,169,119 | 906,259 |
| AS-CLOUD-IX-PRO | 103,856 | 77,002 | 2,169,105 | 906,252 |
| AS-MERKEL-PEERS | 103,856 | 77,001 | 2,169,104 | 906,252 |
| AS12732:AS-UPSTREAMS | 103,843 | 77,002 | 2,169,108 | 906,253 |
| AS39533:AS-SET:AS6695 | 103,842 | 77,001 | 2,169,104 | 906,252 |
| AS6695:AS-DECIX-FRA | 103,842 | 77,001 | 2,169,104 | 906,252 |
| AS-DECIX | 103,842 | 77,001 | 2,169,104 | 906,252 |
For IXPs operators:
- Verify whether IRR filtering enforces prefix-to-origin validation
- Inspect the RS RIB for routes where the origin AS has no corresponding route object.
If such cases exist, the mitigation is straightforward: Preserve the ownership information. In practice, this means adding a step that checks whether the origin AS is authorized to originate the prefix according to IRR route objects, rather than relying solely on prefix lists generated from AS-SET expansion.
This shifts validation from ‘the prefix appears in the filter’ to ‘the origin AS is authorized to announce the prefix.’
Takeaways
- RS filtering practices vary across IXPs and lack a common standard.
- AS-SET-based filtering may lose the binding between prefixes and authorized ASNs.
- Large and poorly maintained AS-SETs increase the likelihood of incorrect route acceptance.
- The blind spot occurs in real operational data.
- Legitimate routes may also be filtered, causing connectivity issues.
- The issue is widespread across IXPs worldwide
For readers interested in detailed results, we encourage you to watch our APRICOT 2026 presentation below, view the slides (PDF), and look out for our paper, which will be published soon.
Stefano Servillo is a PhD student at the University of Rome ‘La Sapienza’. His work focuses on Internet security at IXPs.
I would like to thank my co-authors Pietro Spadaccino (University of Rome ‘La Sapienza’), Francesca Cuomo (University of Rome ‘La Sapienza’), Stavros Konstantaras (AMS-IX), and Flavio Luciani (NAMEX). I also thank NAMEX and AMS-IX for providing access to the RIB data used in this analysis.
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.