{"id":34242,"date":"2026-09-09T16:07:22","date_gmt":"2026-09-09T16:07:22","guid":{"rendered":"https:\/\/blog.lacnic.net\/?p=34242"},"modified":"2026-09-09T16:17:26","modified_gmt":"2026-09-09T16:17:26","slug":"rpki-aspa","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/en\/rpki-aspa\/","title":{"rendered":"An Introduction to ASPA"},"content":{"rendered":"\n

By Carlos Mart\u00ednez<\/a>, Chief Technology Strategist at LACNIC<\/p>\n\n\n\n

<\/a>RPKI adoption in the region has grown steadily over the last few years, but a recurring misconception has emerged: people often talk about RPKI as if it were a single feature that can simply be turned on or off. In reality, RPKI comprises several components. ASPA, its most recent addition, is easier to understand once those components and their distinct roles are clear.<\/p>\n\n\n\n

Three Pieces That Shouldn’t Be Confused<\/h2>\n\n\n\n

RPKI<\/strong> is the public key infrastructure that associates numbering resources with certificates, following the actual delegation chain of those resources (RFC 6480). On its own, it does not make any routing decisions: it is the underlying framework upon which objects are signed, i.e., verifiable assertions about those resources.<\/p>\n\n\n\n

An ROA<\/strong> is one such object (RFC 9582). In an ROA, the holder of a block of IP addresses declares which AS is authorized to originate that prefix in BGP. It is a published assertion and has no effect by itself.<\/p>\n\n\n\n

ROV<\/strong> is the procedure the operator runs on its routers (RFC 6811). It compares each received BGP announcement against validated ROAs and classifies it as Valid, Invalid or NotFound. What to do with that result is a local policy decision.<\/p>\n\n\n\n

This distinction has a practical consequence: publishing ROAs protects your own prefixes from those who use ROV; using ROV protects your own network from invalid announcement from third parties. These are different actions, with different beneficiaries, and none of them involves the other.<\/p>\n\n\n\n

<\/a>What Origin Validation (ROV) Can’t See<\/h2>\n\n\n\n

ROV answers only one question: Is the AS originating this prefix authorized to do so? This is enough to detect classic origin hijacking, and it’s reason enough to deploy it.<\/p>\n\n\n\n

However, ROV looks at the origin and says nothing about the rest of the AS_PATH. This means that there are two problems it cannot prevent.<\/p>\n\n\n\n

The first problem is a route leak<\/strong>: the propagation of an announcement beyond its intended scope (RFC 7908), typically a multihomed AS that re-announces to one provider what it learned from another. Because the origin is legitimate and the ROA matches, ROV classifies the announcement as Valid. The problem is not the origin but the path.<\/p>\n\n\n\n

The second problem is hijacking with a spoofed origin<\/strong>. An attacker does not need to announce the prefix with their own AS; instead, they can prepend the legitimate AS to the AS_PATH and announce it as though they learned it from that AS. The announcement displays the authorized origin, satisfies the ROA, and is classified as Valid. By design, ROV cannot distinguish this forged path from a legitimate one.<\/p>\n\n\n\n

This is not an implementation flaw. ROV validates the origin, not the path.<\/p>\n\n\n\n

<\/a>What Does ASPA Bring to the Table?<\/h2>\n\n\n\n

ASPA targets precisely that blind spot. The holder of an AS publishes a signed object listing the ASes authorized to act as its transit providers: the same type of assertion as an ROA, but about peering relationships instead of prefix origination.<\/p>\n\n\n\n

With a sufficient number of published ASPAs, an operator can verify whether each hop in the AS_PATH corresponds to an authorized client-provider relationship. The path no longer needs to be taken at face value; instead, it is checked against assertions signed by the holders of each AS.<\/p>\n\n\n\n

Verification relies on the shape of a legitimate path. The path ascends through a consecutive sequence of customer-to-provider hops, may optionally cross a peer-to-peer hop, and then descends through a provider-to-customer hop sequence. These two segments are known as the up-ramp and the down-ramp.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Structure of a legitimate AS_PATH. The arrows represent client-provider relationships, not the direction in which the announcement is propagated.<\/em><\/p>\n\n\n\n

The process examines the received path and evaluates whether it matches the expected shape based on a criterion that depends on who sent the route: if the route comes from a client or peer, the path should contain no down-ramp; in this case, a down-ramp indicates a route leak. The result can be Valid, Invalid or Unknown, where Unknown means that ASPA lacks the information needed to reach a decision.<\/p>\n\n\n\n

It’s important not to mix the terminology: where ROV says NotFound, ASPA says Unknown. An announcement may be perfectly Valid for ROV but Invalid for ASPA, and that is exactly the case that ASPA was designed to address.<\/p>\n\n\n\n

<\/a>Where Does ASPA Stand Today?<\/h2>\n\n\n\n

Given that there is quite a bit of confusion out there, it is worth highlighting that ASPA is not yet an RFC<\/strong>. The two core documents are still Internet Drafts within the IETF SIDROPS Working Group. Implementations already exist\u2014FORT, Routinator, and rpki-client process ASPA objects\u2014and a growing number of RIRs allow them to be published, but the details may still change, particularly with regard to the validation algorithm.<\/p>\n\n\n\n

Coverage is logically still quite low: at the start of 2026, published ASPAs represented considerably less than one percent of the global ASN space. Today, the vast majority of paths would lead to Unknown. This is the same curve followed by ROAs a decade ago.<\/p>\n\n\n\n

Even while standardization continues at the IETF, the growing number of operators publishing ASPAs demonstrates strong interest on the part of the operators community.<\/p>\n\n\n\n

For operators evaluating their options, the order of priorities has not changed: publishing correct ROAs for their own prefixes and deploying ROV remain the first step. Rather than replacing that work, ASPA builds upon it.<\/p>\n\n\n\n

<\/a>References<\/h2>\n\n\n\n