This document explains how to use ASPA, and how to use it in BIRD, without getting too deep into the theory and preciseness which the normative documents need.
Relevant ASPA drafts:
Categorization
Before we dive into actual ASPA, we need to categorize relationships between networks. The can be, in regular cases, sorted into three broad categories. These are also defined in RFC 9234 (BGP Roles), Sec. 3.1
My Customer is a network which usually gets all available routes from me, and I’m forwarding all traffic from them. That is often connected with a legal agreement and some payments. On the other hand, I’m only going to propagate their own routes, and routes of their customers, transitively.
My Provider is the opposite. They get only my routes (and routes of my customers, transitively), and they forward all traffic for me, often in exchange for some money.
My Peer is neither of these. It’s a bilateral agreement to mutually exchange local traffic. I expect my peers to forward my traffic only to them and their customers (transitively), and I’m going to forward their traffic to me and my customers only. There is often no additional payment, apart from maintaining the link itself.
Only To Customer (OTC) Attribute
Together with the BGP Role, the BGP speaker (e.g. BIRD) also adds the OTC attribute to each route which is advertised to a Customer or Peer. That attribute then prevents the route from ever being propagated anywhere else than to Customers. Check RFC 9234 for the exact rules, it’s a little bit more complex.
This attribute should be able to mitigate a lot of route leaks by itself. Yet, it’s not a complete solution:
- ASPA is an additional level of checking, which is out of band and cryptographically signed. That brings a higher level of confidence than a route attribute.
- Publishing ASPA records needs no router support. One can do that without ever verifying ASPA in their own network.
- There is also no OTC while the route is being sent up the Provider chain, and therefore the providers can’t rely on the sole absence of OTC that the route is valid to propagate further.
AS Path Verification
The major reason for path verification is validation of routes received from customers. But the customers also announce routes of their customers, transitively.
The providers wish to only accept routes from their customer cone. If any of their customers sends the whole internet routing table received from their other provider, that is a route leak. While the leak may technically still forward data, its bandwidth may easily get overwhelmed and the traffic gets effectively blackholed.
It is hard though to keep track of all the customer cones, from the perspective of providers. There are many changes which would have to propagate.
It is even worse on peering. One wants to accept only the customer cone of their peer. If their peer accidentally sends the whole internet, they become a free provider, and again, a possible black hole.
After experimenting with various proposals, ASPA became the chosen technology by IETF. Customers simply publish signed lists of their providers. Only networks on that list are allowed to propagate my routes anywhere.
Who is my Provider?
Anybody who may, in any circumstance, even exceptionally, propagate my routes to the whole Internet, is my provider. Or, in other words, networks not on my provider list, if they have a BGP adjacency with me, are only allowed to propagate my routes to their customers. Not to their peers or providers.
Specifically, if somebody has a backup link, a DDoS Proxy visible in BGP, or anything else which may play the provider role in some specific circumstance, it is a provider.
The ASPA tables need to be downloaded to all the routers. It may take hours. One should not expect ASPA records to update quickly.
ASPA Principles
The semantics of ASPA expects that each route’s lifetime has three phases (which may each consist of zero hops).
- The route is exported from customers to providers (this is called up-ramp).
- A single lateral hop between peers.
- The route is exported from providers to customers (this is called down-ramp).
The algorithm then detects the up-ramp and down-ramp inside the supplied AS Path. While the ASPA verification draft defines two separate algorithms, these can be described as one.
At the BIRD website, we added an ASPA simulator, so that you may see the verification detailed.
Finding the Ramps
First, the AS Path on input may be stuffed, i.e. have consecutive segments of the same ASN. These shall be all reduced to one ASN. The result is called Compressed AS Path.
Two sub-segments of the Compressed AS Path (Path) are now created which are trying to match the path to the expected route lifetime.
- The Valid UpRamp is the longest suffix of the Path which is actively covered by ASPA attestations, an therefore definitely a real-world up-ramp.
- The Unknown UpRamp is the longest suffix which could be covered but some ASNs on the path have no provider list. This may be a real-world up-ramp but nobody knows for sure.
In other words, we walk from the end of the path (originator) to the beginning and ask whether the previous ASN can be a Provider. As long as it is attested by ASPA, we include that to the Valid UpRamp. Then we continue including into the Unknown UpRamp until we find an ASN which has published its ASPA but the previous ASN is not included.
Side note: The Valid ramp is always a suffix of the Unknown ramp.
We may also need two more sub-segments: Valid DownRamp and Unknown DownRamp which are created by the same algorithm but walking the Path in the other direction, i.e. from the beginning to the end.
There is a common misconception that if AS X attested Y as their provider and Y has no ASPA, X is therefore not a provider of Y. That is not true. When determining the ramps, we always check ASPA only in one direction and ignore the other. There may be Mutual Transit situations where one AS has an ASPA while the other one has not.
Now we can determine the result by checking which segments are needed to cover the whole AS Path.
Applying the UpRamp
Customers are the most restricted category. We only accept routes with an up-ramp.
The AS Path on a route from a Customer is:
- Valid if it is completely covered by the Valid UpRamp.
- Unknown if it is completely covered only by the Unknown UpRamp.
- Invalid if it is covered by none of these.
Also, the local ASN is expected to eventually become a part of the up-ramp. It is therefore desirable to prepend local ASN to the AS Path for the purpose of the verification, to check the up-ramp completely, in the state which is going to be seen by our neighboring networks when the route is exported. This approach helps to detect possible misconfigurations at our customers as soon as possible, and prevent propagating garbage.
The same approach is applied to routes from Peers, with the only difference that we actually do not prepend the local ASN, as that would represent the single lateral hop between peers.
In BIRD, this algorithm is invoked by aspa_check_upstream(aspa_table), or aspa_check(aspa_table, path, true). To achieve full checking, it is possible to run aspa_check(aspa_table, path.prepend(local_asn), true).
Using the DownRamp
For routes received from a Provider, we are in a different situation. The path may contain not only an up-ramp and a lateral hop, but also potentially a down-ramp. The local ASN is expected to eventually become a part of the down-ramp. With the same argument as with Customers, it is desirable to prepend the local ASN to the AS Path for the purpose of the verification, to check in this case for our misconfiguration.
With that, the AS Path on a route from a Provider is:
- Valid if the Valid UpRamp together with Valid DownRamp cover the path completely.
- Unknown if the Unknown UpRamp together with Unknown DownRamp cover the path completely.
- Invalid otherwise.
In BIRD, this algorithm is invoked by aspa_check_upstream(aspa_table), or aspa_check(aspa_table, path, false). To achieve full checking, it is possible to run aspa_check(aspa_table, path.prepend(local_asn), false).
It is possible that the ramps overlap, and there is no problem with that. As long as all ASNs in the path are covered, it’s OK. These situations regularly happen when two ASNs are in the Mutual Transit situation where each of them is willing to behave as a provider to the other one.
Difference from the Draft
The ASPA verification draft does not stipulate prepending the local ASN. Instead, it mandates the enforce first AS option and recommends checking the local relationship out-of-band. The BIRD team considers it easier to just prepend and have the whole result at one place.
The prepending is indeed problematic if the actual network is a complex mesh of multiple ASNs. The verifying router must therefore be aware of the ASN which is going to be prepended on export. In such complex scenarios, it may be handy to run ASPA verification on export so that the network operator is, at least, informed at the last possible step, that they are exporting garbage. This draft is, sadly, not yet even adopted by the working group.
Common Caveats
On paper, the draft looks precise and the technology promising. Yet, there are several corner cases which one should think about before actually deploying ASPA or publishing their records.
Merging and splitting networks
Whenever a node is changing its ASN, extra care has to be taken with the routes passing through that node, and identify how the relationships change, to not render any routes invalid. That analysis shall be done upfront, as ASPA may need to be updated.
The safe option is, when merging and splitting networks or operating multiple ASNs in complicated topologies, to simply mark each other as a provider, creating a so-called Mutual Transit relationship. Later, when the network situation settles down, one can re-analyze and strip the providers which become unnecessary.
Missing Legitimate Provider
Publishing an ASPA record where one or more legitimate providers are missing, is possibly the most imaginable operator error in the process. One does a typo and a whole bunch of routes suddenly seems to be invalid.
To mitigate this issue, one can simulate parts of their network and their neighbors, and dry run ASPA checks for all routes imported and exported, before updating their ASPA record.
Also one can simply run the full verification procedure with prepending, and immediately see the invalid routes locally, if everything slips unnoticed through the testing. This is the primary reason why the BIRD team recommends to run the full verification with prepending, contrary to what is stipulated by the draft.
Provider not verifying ASPA
At least in the times of scarce adoption, one may expect that almost no network would verify ASPA. It is therefore perfectly possible that a Provider sends Invalid routes to their customers, because these leaks came out best from the BGP best route selection algorithm.
As long as there are valid routes available from elsewhere, there is no problem. But often with a route from far away, the only available routes would be from a Provider. If all of these are Invalid, the draft stipulates to drop them anyway.
While these may indeed be a result of an illicit leak, it is much more probable, at least for now, that the route actually works, traffic is delivered and nobody really cares unless we check ASPA.
In these situations, you may ask yourself whether it’s better to have clean routing, or to have happy eyeballs. From our perspective, we believe that keeping the reachability is a significantly better option. Therefore, our recommendation is to only depreference invalid routes if received from a Provider.
There is a real threat in eagerly dropping Downstream Invalids. Whenever you do this, your customers may see some networks become unreachable. And if a non-technical customer of a remote network reaches out to that network, they may find out quite soon that the culprit is a route leak.
In such situations, operators may be motivated to promote their leakers to providers to make ASPA happy, and in turn let these leakers easily hijack their routes later on. While the draft stipulates the same SHOULD for dropping ASPA-invalid routes anywhere, the BIRD team strongly recommends to not drop ASPA-invalid routes received from a provider who does not verify paths by ASPA.
Transit via Route Server
For peering, there are various internet exchange points which are facilitating multiple peerings at once. Instead of having to set up hundreds of separate BGP connections, one may, in the IXP, use the local route server services to exchange routes with all other local networks, becoming a Peer to all of them.
That would be nice if that was the case in the real world. But in addition to peering, route servers are also often used to aggregate transit services. This route server deployment is not a peering per se, and therefore one should not use the roles defined in RFC 9234 for route servers. In fact, the routes received from such a route server are a mix of routes from a provider, and routes from peers, and need to be handled appropriately.
Some networks are also offering transit via an IXP, which makes the links to regular IXPs really messy. That messes up the whole notion of an IXP being a peering provider, and lots of relationships become complex.
To better illustrate the situation, let’s show an example. Blue lines are peerings, red and green are provider/customer.
Network 65540 is providing transit via route server to network 65541. Networks 65542 and 65543 are just peers (of each other and also of 65540 and 65541). There is also a remote network 65544 which happens to be peering with 65540 elsewhere, and also use a customer of 65542 as their provider.
Network 65540 exports a route R with AS Path 65540 65544.
Network 65542 exports a route Q with AS Path 65542 65549 65544.
By best route selection at the route server, route R is best. With that, all route server clients get route R. That is OK for network 65541, they got a route from their provider. For everybody else, the network 65540 has just leaked a route learned via peering elsewhere, to another peering.
A regular route server configuration partially guards against this. The classic way is a multi-table BIRD setup where every client of the route server gets their own separate routing table. A lightweight approach is a single-table setup with the secondary option which modifies BGP behavior to export first route which passes the filter.
But to configure well where to export which route, the peers have to mark them properly by no-export large communities (RFC 8195), which may not be always the case. One needs to run ASPA checks on the route server to ensure that things go well.
ASPA, BGP Roles and OTC on Route Servers
For any IXP where all peers are real peers, this chapter is simple. All BGP roles should be set to “route server”, BIRD would then set the OTC attribute to all routes, and everything is fine. ASPA should be checked in the Upstream variant, and Invalids should be dropped.
Whenever this is violated so that peers aren’t purely peers, it becomes messy very fast. The easiest way out is to deploy another route server which would do the provider-customer brokering, and keep the peering in its own route server.
If that is not an option, the route server needs to run both variants of ASPA check for routes received from the provider-peer, and mark each route whether it’s peering-eligible (i.e. Upstream Valid/Unknown), or it’s provider-only, i.e. Upstream Invalid but Downstream Valid or Unknown. Then, they need to know which networks are customers of which provider, and filter the routes accordingly.
In the mixed route server scenario, it is also impossible to set BGP roles to the provider-peers and customer-peers. Yet, it would be a reasonable idea to check and attach the OTC attribute manually in filters.
Route servers in IXPs may actually do quite a lot of heavy lifting in this area. If a network is peering in multiple IXPs and they accidentally leak between them, this would greatly reduce the impact. Sadly, the current implementation of OTC in BIRD does not allow for keeping the OTC-Invalid routes for inspection. There is a fix on the way though, and we expect to release it with BIRD 2.20.0 and 3.4.0, hopefully around the beginning of September 2026.
Complex relationships
All relationships, even if incredibly complicated, may be at some point in time categorized into a combination of the Customer, Provider and Peer.
This is especially true for large networks interconnecting in multiple locations. One network may be a provider of the other in one place, a customer in another place, and they may even also peer in some IXP.
Some links, most often backup links, also bring time variance into play. In a scenario of two local ISPs in a rural area, they may decide to reduce costs so that each of them maintains one uplink to a transit, and they have also a mutual backup link between them. Normally, this is a peering, allowing their customers to interconnect locally. Yet, as soon as one uplink breaks, this backup link becomes a provider-customer link in the appropriate direction.
In these cases, the networks are in a Mutual Transit situation, and they shall both attest the other one as a Provider in ASPA.
Suggested Deployment Order
Based on the mentioned caveats, we suggest to deploy ASPA in the following order.
First, one should deploy ASPA verification without actually dropping invalids. This allows to see what is happening in the network, without disrupting traffic, and also to inform customers and peers if they are sending ASPA invalid routes.
Second, one should add locally the desired ASPA record for their own network, without publishing, and verify that nothing has gone wrong. This allows for testing without disruption. It is also recommended to check publicly available looking glasses for their routes and verify that these AS Paths don’t become invalid when publishing their ASPA record.
Third, one should switch the verification to drop invalids received from customers and peers, so that they don’t send garbage.
After that, the network is probably ready, and they should publish their ASPA record.
We recommend to start dropping invalids received from providers only after at least one of the providers provably started dropping invalids as well, to prevent unnecessary blackholing where traffic actually works.
If it is not feasible to deploy the ASPA verification on border routers, it is possible to deploy it on a route reflector.
Conclusion
The ASPA itself is not too complicated and it is not too hard to deploy. We recommend to enable ASPA verification early, with the modifications outlined in this article. All the BIRD Support customers are invited to ask for help with deployment at the usual support e-mail.
We care about our users and the operational reality. We prefer to speak openly about possible traps before people run into them. You have been informed.
AI/LLM Disclosure
This blog post was keyboard-written by the ten fingers of Maria’s hands. Then, Gemma 4 (31b) was repeatedly asked to review the text, before showing this text to the team for proofreading.
To create the images, Gemma 4 (31b) was asked to generate simple SVG graphics, which it did, but it failed to align the items nicely, even after repeated prompting and refinig. Then, ten fingers of Maria’s hands used Vim to fix the SVG files, together with some impromptu coordinate calculations.
The overall energy and time balance is unclear.