Thinking about using ASPA to protect your network from BGP route leak incidents? Before you dive in, here's what you need to know and what to look for as you plan your deployment!

Executive Briefing on ASPA

ASPA is short for Autonomous System Provider Authorization. The idea is that an AS holder publishes a list of who their upstream providers are into the global RPKI, and then ISPs around the world use that information to securely determine the plausibility of AS_PATHs and automatically mitigate route leaks. In other words: when you create an ASPA you explicitly authorize your upstreams to provide transit service for your AS, and in turn the world’s BGP routers can run an algorithm to check whether a BGP route involving your AS aligns with published ASPA objects. This all may sound simple enough, but there are a few gotchas!

ASPA’s Gotcha’s

• When you create an ASPA record, you must ensure you authorize all your providers. It might cause BGP route propagation issues if you accidentally omit one of your legitimate providers! We’ll come back to this later.
• The internals of the ASPA verification algorithm that runs on BGP routers is difficult to explain and hard to debug. (Unless you studied graph theory!) Luckily, the software running on BGP routers handles this mathematical complexity automatically, so we don't need to worry about it.
• The verification algorithm depends on knowledge of the type of business relationship between your AS and your neighbor’s AS, because the algorithm acts differently depending on whether a BGP route is received from a customer or from a settlement-free peer or from an upstream (also known as transit provider). The good news is that this characteristic makes ASPA the perfect companion to RFC 9234 deployment.
• ASPA deployment requires software upgrades to your BGP routers and RPKI validators, and using version 2 of the RPKI-To-Router (RTR) protocol. Conveniently, for most network operators this just means drop-in replacement upgrades.

Changes to RPKI-to-Router (RTR) Protocol – What’s New in Version 2?

RTR v2 is a major improvement over older versions, and not just because of ASPA support! Based on more than a decade of experience with RTR v0 and v1 (and, a fair amount of insistence from yours truly), the IETF made several well-considered refinements to the RTR protocol. The latest RTR version is an evolution, not a revolution. RTR v2 is more robust, more efficient, easier to operationalize, and easier to troubleshoot, here is why:

• Built-in race condition mitigation. All RTR v2 PDUs are transmitted in a specific order, for example, more-specific Prefix PDUs are announced before less-specific Prefix PDUs. This matters because if Prefix PDUs arrive the other way around, BGP routers might (briefly) mark a more-specific BGP route as invalid until the other PDU has arrived.
• A nice side-effect of the above is that RTR v2’s predictable PDU ordering gives router implementers the opportunity to optimize their data insertion and route convergence processes for performance.
• Management of timer control is now centralized: the RTR server can tell the clients what refresh/retry timers to use. In RTR v0 you had to manually configure refresh/retry timers on each and every router. While RTR v1 also had this feature, v1 never got widely deployed, but that’ll change with RTR v2!
• Clearing the client-side cache is far easier in RTR v2. In previous versions you’d have to log into each and every BGP router and issue a command to clear the router’s state. But in v2 this type of action can also be conducted from a centralized point, the operator can tell the server to send a “Shutdown” message to all clients force cache flush. You probably rarely need to clear the cache, but when you do it’s nice if it’s easy!
• RTR v2 produces more informative log messages on the client side because new error codes have been added to disambiguate server restart, shutdown, and transient network issues. With RTR v2 it is much easier to understand whether RTR session disruptions were caused by (planned) maintenance on the server side, or something unexpected.

I recommend everyone to take advantage of these small quality-of-life improvements to the RTR protocol. Whether you intend to deploy ASPA verification or not, RTR v2 definitely is worth the upgrade because of its improvements to RPKI ROA distribution and general operational management!

ASPA Routing Policy Considerations

An effective implementation of ASPA verification at your EBGP network perimeter is to simply reject ASPA-invalid routes and nothing more. Not importing any invalid routes received via EBGP really is all there is to it!

There is no benefit to modifying priority or preference of routes based on ASPA validation state, nor is there a need to add BGP communities based on the validity state. See the IETF’s Guidance to Avoid Carrying RPKI Validation States in BGP Path Attributes best current practice guidelines for an elaboration on why not setting BGP communities based on validation states is a good practice.
 

rtr e.f.g.h {
    min-version 2                  # RTR v2 is needed for ASPA
    tcp md5sig password s3cr3tk3y  # Protect the session
}

neighbor a.b.c.d {
    remote-as xyz
    role peer       # must specify local role for ASPA & RFC 9234
} 

# Routing policy
deny quick from ebgp ovs invalid   # reject import of ROA-invalid routes
deny quick from ebgp avs invalid   # reject import of ASPA-invalid routes

Example OpenBGPD configuration enabling both ASPA verification and RFC 9234 protection

State of current ASPA deployment

Three RIRs (namely APNIC, ARIN, and RIPE NCC) started offering functionality to create ASPA objects through their respective RPKI-management web portal around the start of 2026. Since then, a few thousand network operators have published ASPA records for their ASes. This looks like a healthy steady growth curve!

Perhaps soon enough, thanks to ASPA & OTC, big disruptive route leaks will be a thing of the past?

If you’d like to try ASPA, OpenBSD 8.0 comes with a fully fledged ASPA stack (OpenBGPD, rpki-client, and OpenRTRd) in its base installation.

Written by Job Snijders (Qrator Research Lab).