Route origin validation solved a real problem. Once a network publishes correctly scoped ROAs, routes with unauthorized origins can be marked RPKI-invalid. Networks that enforce rejection of invalids then drop them; validation alone doesn't prescribe every operator's policy. It's one of the most successful security upgrades BGP has ever had.

It also left a gap that everyone in routing knew about from the start. ROV checks the last AS in the path, the origin, and nothing else. A route leak that passes a valid announcement through networks that should never have carried it keeps the correct origin and sails straight through.

ASPA, short for Autonomous System Provider Authorization, is the piece of the RPKI designed to close that gap. This article explains what ASPA is, how verification works, what it does and doesn't catch, and what operators can do with it today.

The gap RPKI origin validation leaves

A BGP announcement carries an AS path, the list of networks the route has passed through. Origin validation checks the rightmost AS against published ROAs. If AS64500 is authorized to originate 192.0.2.0/24 and the path ends in AS64500, the route is valid, regardless of what comes before it.

That's exactly what a typical route leak looks like. A customer network learns a route from one transit provider and accidentally re-announces it to another provider. The origin is still correct, so ROV marks the route valid, but traffic now flows through a small network that was never meant to carry it, often with severe congestion or a total outage as the result.

Some deliberate attacks exploit the same gap. A forged-origin hijack announces a prefix with the legitimate origin AS placed at the end of a fake path, so ROV passes it. We covered how operators detect these after the fact in our piece on BGP route leak detection; ASPA aims to reject many of them automatically instead.

What ASPA is

ASPA is a new type of signed RPKI object. In an ASPA, a network, the customer AS, lists every AS that provides it with transit, its providers. It's signed using the same RPKI certificate infrastructure as ROAs, anchored at the Regional Internet Registries.

The idea is simple. If every network publishes who its upstream providers are, then anyone validating a route can check whether each step in the AS path is a legitimate customer-to-provider relationship. A path that goes "up" from a customer to its provider is fine. A path that goes up, then down, then back up again, is a leak.

As of October 2026, the ASPA profile and verification specification remain IETF Internet-Drafts. Deployment support depends on the exact RIR service, validator, RTR protocol version, and router release.

How ASPA verification works

ASPA verification is based on the "valley-free" model of internet routing. In normal routing, a route travels up from a customer to its provider, possibly across one peering link at the top, and then down from providers to customers. It shouldn't go back up after it has started going down. A path that does is shaped like a valley, and that valley is what a route leak looks like.

For a conventional AS_SEQUENCE displayed left to right, the nearest advertising AS is on the left and the origin is on the right. Read the customer-to-provider ascent from the origin toward the receiving network, right to left. Testing adjacent ASes in the opposite order reverses the relationship being checked.

Verification uses different procedures for customer/peer routes and provider routes, including local session roles. Results can be Valid, Invalid, or Unknown. Missing records don't automatically invalidate a route, and a Valid result isn't a cryptographic signature over the complete path.

What ASPA catches

Route leaks are the main target. The classic leak, where a multi-homed customer re-announces routes from one provider to another, creates a path where the customer appears between two providers. Whether a particular leak is classified Invalid depends on the visible AS path, session role, and available attestations. Networks applying a rejection policy can then stop its propagation.

ASPA also catches some forged-path hijacks. If an attacker places the legitimate origin at the end of a fake path, the hop between the attacker and the origin has to be consistent with the origin's ASPA. An unauthorized adjacency can provide evidence of a forged path, but detection still depends on the verification procedure and available attestations; one origin record doesn't guarantee every forged path will fail.

The protection grows with adoption. Every network that publishes an ASPA makes paths through it checkable, and every network that validates makes leaks through it less likely to spread.

What ASPA doesn't catch

ASPA verifies the relationships between ASes, not the full path cryptographically. An attacker who forges a path that's consistent with published relationships can still get through. That's what BGPsec was designed to address, by having every router sign the path as it passes along, but BGPsec has seen very little deployment because of its processing cost and the need for every hop to participate.

It also depends on accurate data. An ASPA that leaves out a real provider will cause legitimate routes through that provider to be marked invalid. Missing ASPAs reduce coverage, but evidence from other ASes can still establish that a path is invalid.

And like ROV, ASPA only helps where networks validate. Publishing ASPAs protects your routes in networks that check them; checking them protects your network from everyone else's leaks.

How ASPA fits with ROV and RFC 9234

ASPA doesn't replace origin validation; it builds on it. ROV checks the origin, ASPA checks the path shape, and together they cover far more incidents than either alone.

It also complements RFC 9234, which adds BGP roles and the Only to Customer attribute to BGP sessions. RFC 9234 helps networks avoid leaking routes in the first place by marking which sessions are customer, provider, or peer. ASPA lets other networks detect leaks even when the leaking network hasn't configured roles. Deploying both gives you prevention on your own sessions and detection for everyone else's.

Who should create an ASPA

Any network with its own AS number and at least one upstream provider should, eventually. If you announce your own address space over BGP, whether from dedicated servers, a colocation rack, or multiple transit connections, an ASPA is the next step after your ROAs.

Networks with no transit providers, the large backbones at the top of the hierarchy, can publish an ASPA with AS0 to state that they have no providers. That lets validators know that any path showing such a network buying transit from someone else is invalid.

If you use your hosting provider's IP space and don't run BGP yourself, ASPA isn't something you need to manage. Your provider's network is the one publishing and validating.

How to create an ASPA

Start with your RIR. ASPA objects are created in the same RPKI system as your ROAs. Some Regional Internet Registries already offer ASPA creation in their hosted RPKI portals, and others have it on their roadmaps; if you run a delegated certificate authority, check that your software supports it.

List every transit provider. Include every AS you buy transit from, in every region and for both IPv4 and IPv6. Leaving one out is the most common way to break your own routing with ASPA, since paths through that provider will start failing validation as networks begin to check.

Don't include peers. ASPA describes customer-to-provider relationships only. Settlement-free peers, including networks you reach over an internet exchange, aren't providers. Route servers at IXPs typically don't add their own AS to the path, so they don't belong in your ASPA either.

Update it when your providers change. Add a new transit provider to your ASPA before you turn the session up, and remove an old one only after it's fully gone. Treat it like ROAs: part of every routing change checklist.

How to start validating ASPA

On the validation side, you need an RPKI validator and routing software that both support ASPA. Consult the RIPE NCC ASPA guide and your software release documentation. ASPA requires compatible versions across the validator, RTR connection, and router; ordinary ROA support is insufficient, and experimental branches may differ from stable releases.

Begin in monitoring mode. Mark or log ASPA-invalid routes without rejecting them, and watch what would have been dropped. Early in deployment, invalids are more likely to be configuration mistakes than real leaks, and seeing them first avoids surprises.

Once you're confident in the results, start rejecting invalids on customer and peer sessions, where leaks are most damaging. Keep monitoring, and as more networks publish ASPAs, the share of unknowns will shrink and the protection will grow.

Wrapping up

RPKI origin validation helps participating networks reject routes whose origin AS is not authorized by a matching ROA, but it can't tell whether the path a route took makes sense. ASPA fills that gap by letting each network publish its upstream providers, so validators can spot paths that go up, down, and back up again, the signature of a route leak.

For operators, the steps mirror ROAs: create an ASPA listing every transit provider, keep it updated as your providers change, and start validating in monitoring mode before rejecting invalids. Together with ROV and RFC 9234, ASPA adds protection against route leaks, subject to adoption, accurate records, and local enforcement policy.

Thanks for reading! If you run your own BGP sessions, xTom offers IP transit alongside enterprise-grade dedicated servers and colocation, with NVMe-powered KVM VPS through V.PS, shared hosting, and general IT services for whatever else your network needs.

Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.

Frequently asked questions about ASPA

What does ASPA stand for?

ASPA stands for Autonomous System Provider Authorization. It's a signed RPKI object in which a network lists the autonomous systems that provide it with transit.

What's the difference between ASPA and RPKI ROAs?

A ROA says which AS is allowed to originate a prefix, and route origin validation checks only the origin. An ASPA says which ASes are a network's upstream providers, which lets validators check whether the whole AS path follows legitimate customer-to-provider relationships.

Does ASPA stop BGP route leaks?

It stops many of them. A customer re-announcing routes between providers is a main target. Detection depends on the path, session roles, and attestations available to the validating network.

Is ASPA the same as BGPsec?

No. BGPsec cryptographically signs the full AS path at every hop, which is expensive and requires every network to participate. ASPA only verifies provider relationships, which is lighter and can be deployed gradually.

Should I include IXP peers in my ASPA?

No. ASPA lists transit providers only. Settlement-free peers, including those reached over an internet exchange, shouldn't be included, and IXP route servers usually don't appear in the AS path at all.

What happens if I leave a provider out of my ASPA?

Routes that pass through that provider can be marked invalid by networks that validate ASPA, and may be rejected. Always list every transit provider, and update your ASPA before changing providers.