ASPA Explained: Validating the BGP AS-Path

RPKI Route Origin Validation checks only the last ASN of a route's path - the origin. It cannot tell whether the networks in between are legitimate. Two kinds of incidents slip through:

• Route leaks: a network re-announces routes it should have kept to itself, for example passing routes learned from one transit provider on to another. The origin is still correct, so the leaked route is RPKI-valid. See route leak vs hijack.
• Forged paths: an attacker announces someone else's prefix with the real origin AS appended to the path, so the route passes ROV while traffic flows to the attacker.

Both are detectable if you know which networks are allowed to carry whose routes upward. That is exactly what ASPA publishes.

An ASPA is a signed object in the RPKI, issued by the holder of an ASN under the same certificate hierarchy that is used for ROAs. Its format is specified in the IETF SIDROPS working group's ASPA profile document, which at the time of writing is still an Internet-Draft, not an RFC. It has two parts:

A customer should have a single ASPA that lists all of its providers, not one object per provider. The special provider set containing only AS0 means "I have no providers": the network is transit-free (and is not a client of a non-transparent route server), so no AS may ever appear above it in a path. AS0 may not be combined with other providers in the same object.

Peers are not listed. ASPA only describes customer-to-provider relationships; settlement-free peering links are inferred by the verification procedure, not declared.

Path verification is specified in the companion ASPA verification document of the same working group, also still an Internet-Draft at the time of writing. Its building block is a hop check between two adjacent ASes in the path, read from the origin outward. For a pair (A, B), where B appears directly after A on the way from the origin to the receiver:

The receiving router then applies one of two procedures, depending on where the route came from:

• Upstream verification - for routes received from a customer or a lateral peer (and in some route-server setups). Such a route should have travelled only upward: every hop from the origin to the neighbor must be customer-to-provider. If any hop is Not Provider+, the path is Invalid; if all are Provider+, it is Valid; otherwise it is Unknown.
• Downstream verification - for routes received from a provider. The path may go up, cross at most one peering link at the top, and then come down. It is Invalid only if no valley-free reading of the path is possible with the published ASPAs; Unknown if missing ASPAs leave the question open; Valid if the attestations confirm it.

The result is one of three states: Valid, Invalid or Unknown. The intended policy mirrors ROV: reject Invalid, accept the rest. Unknown is common while adoption is partial and does not make a route suspicious on its own.

AS64496 originates a prefix and buys transit from AS64501. AS64500 is multihomed: it is a customer of both AS64501 and AS64503. AS64501 buys transit from AS64505. All four publish ASPAs:

AS64500 learns the route to AS64496's prefix from its provider AS64501 and, because of a missing export filter, announces it to its other provider AS64503. AS64503 receives it from a customer with the path:

64500 64501 64496

AS64503 runs upstream verification, reading from the origin:

1. AS64496 to AS64501: AS64501 is in AS64496's provider set. Provider+.
2. AS64501 to AS64500: AS64500 is not in AS64501's provider set. Not Provider+.

One Not Provider+ hop in a route from a customer makes the path Invalid, and AS64503 drops it. The leak is caught by AS64501's ASPA - the provider the leaker learned the route from - not by the leaker's. That is why publishing an ASPA protects more than your own prefixes: it also lets verifying networks catch your customers leaking the routes you send them to their other providers.

If AS64501 had not published an ASPA, the second hop would be No Attestation and the result Unknown: the route would be accepted. Coverage grows with every network that publishes.

ASPA has limits worth knowing:

• It does not replace ROV. ASPA says nothing about who may originate a prefix; ROAs still do that.
• It cannot validate peering links, because peers are not declared. A leak between two peers can only be detected through the ASPAs of the networks around them.
• A determined attacker can still forge a path made only of real, authorized customer-provider links. ASPA narrows the space of believable fake paths; it does not sign the path hop by hop the way BGPsec does.
• Its value depends on adoption, both of published ASPAs and of routers that verify them.

ASPA is a newer IETF development: at the time of writing, both the profile and the verification procedure are still Internet-Drafts in the SIDROPS working group. Publication support in the RIRs' hosted RPKI services, in validators, and in router software (which receives ASPA data through version 2 of the RPKI-to-Router protocol, itself still a draft) has been arriving step by step, so check what your RIR and your vendors support today. The number of networks with a published ASPA is still small but growing; the BGP statistics page shows current adoption.

Publishing is low-risk as long as the object is complete:

1. List every network you buy transit from, including backup, standby (for example a DDoS mitigation provider) and soon-to-be-connected providers, and any non-transparent route server you are a client of. A missing provider makes your legitimate routes through it invalid to verifying routers.
2. If you have no providers at all, publish an ASPA with AS0 as the only provider.
3. Create the object in your RIR's hosted RPKI where ASPA is supported, or in your delegated RPKI setup.
4. Verify the result with an ASPA check of your own ASN, and update the object before every change of transit provider.