A valid route origin says little about the relationships represented by the rest of an AS_PATH. A prefix can originate from an authorized AS and still travel through a sequence that conflicts with expected customer-to-provider structure. Autonomous System Provider Authorization, or ASPA, adds a signed RPKI object for that second problem.

As of September 2026, ASPA is still specified in active IETF Internet-Drafts rather than a published RFC. The current ASPA profile draft defines the signed object, while the current verification draft defines procedures for applying validated ASPA data to BGP AS_PATHs. That status matters operationally: fields and procedures remain subject to change until the specifications complete the standards process.

The customer signs its provider set

An ASPA object is issued by the holder of a Customer AS identifier. Its payload names one or more Provider ASes that the customer authorizes to provide transit. The object uses the RPKI signed-object framework, so validation ties the attestation to an RPKI certificate containing the Customer AS identifier.

The direction is deliberate:

Customer AS 64520
      |
      +---- authorizes ----> Provider AS 64510
      |
      +---- authorizes ----> Provider AS 64500

The customer is not signing an arbitrary map of Internet topology. It is making a narrow statement about its own provider relationships. If the customer has several transit providers, the profile calls for all of them to appear in the provider set. Non-transparent route-server ASes used by the customer are also included; transparent route servers that do not insert their ASN into AS_PATH are treated differently.

An AS with no transit providers can use the AS 0 form described by the drafts. That form states the absence of Provider AS relationships rather than authorizing AS 0 as a real transit network.

Authorization is evaluated as an ordered pair

The verification draft reduces validated ASPA data to a useful primitive: for two distinct ASes, check whether the second AS is an attested provider of the first.

Conceptually:

authorized(customer, provider)

ASPA exists and lists provider  -> Provider+
ASPA exists but omits provider  -> Not Provider+
no valid ASPA for customer      -> No Attestation

These outcomes are not interchangeable. Not Provider+ is negative information from an available attestation. No Attestation means the verifier lacks a valid ASPA statement for that Customer AS. Treating missing data as a negative assertion would create false conclusions during partial deployment.

This distinction allows ASPA verification to operate while coverage is incomplete. A path can contain enough signed relationship data to expose a contradiction, or it can contain gaps that force an indeterminate result.

AS_PATH verification looks for a valid valley shape

The current verification draft models a compressed AS_PATH using an up-ramp and a down-ramp. On the up-ramp, consecutive hops move from customer toward provider. On the down-ramp, the same relationship is evaluated in the opposite traversal direction. The two ramps may meet at an apex or across a single lateral hop.

Validated ASPA pairs establish bounds on those ramps. If the available attestations prove that the two bounds cannot cover the path shape permitted by the procedure, the AS_PATH is Invalid. If missing attestations leave more than one possible interpretation, the result can be Unknown. Otherwise, the procedure yields Valid.

The result is about the relationship structure visible in AS_PATH. It is not a cryptographic signature over every BGP UPDATE and does not prove that each AS actually forwarded the route according to policy.

ASPA and origin validation cover different assertions

Route Origin Authorization data binds a prefix to ASes permitted to originate it. ASPA data binds a Customer AS to ASes it authorizes as providers. The signed statements therefore answer different routing-security questions.

A route leak can preserve a legitimate origin. In that case, Route Origin Validation can still report a valid origin while ASPA-based path checks detect relationship structure that is inconsistent with the available provider attestations.

The reverse distinction also matters. Provider relationships do not authorize a prefix origin. ASPA is not a substitute for ROAs or Route Origin Validation. Deploying both supplies signed information about two separate parts of the routing decision: origin authorization and provider relationships along the path.

ASPA also differs from BGP Roles and OTC

BGP Roles and the Only to Customer attribute from RFC 9234 carry relationship and propagation context in BGP itself. ASPA places provider authorization in RPKI and allows a verifier to compare AS_PATH structure with validated attestations.

The controls can therefore address related route-leak problems from different positions. OTC can mark a propagation boundary as a route moves between participating routers. ASPA verification can inspect relationships represented by AS_PATH using externally validated RPKI data.

Neither mechanism makes arbitrary routing policy globally visible. Commercial relationships can be more complex than a simple customer-provider label, and local policy still determines route acceptance and export beyond the checks defined by a protocol.

Stale provider data can create bad outcomes

The security value of ASPA depends on accurate registration. If a Customer AS omits a real provider, a path containing that relationship can later appear inconsistent with the signed provider set. If the customer lists an AS that is not actually its provider, detection power is reduced because the attestation permits a relationship that should not be accepted as evidence of a customer-to-provider hop.

Provider changes therefore have a control-plane data lifecycle. Adding, removing, or migrating transit relationships requires corresponding ASPA maintenance. The current verification draft also discusses AS migration cases in which both a globally configured ASN and a legacy ASN can need temporary representation in customer ASPA data.

Cryptographic validity does not repair incorrect operational content. A correctly signed but stale object faithfully authenticates the stale statement.

The security claim remains bounded

ASPA provides signed authorization for provider relationships and a basis for structured AS_PATH verification. Its strongest claim is not that a BGP path is universally trustworthy. The verifier sees attestations for participating Customer ASes, gaps for ASes without valid ASPA data, and only the AS_PATH presented in the route.

The current drafts also describe cases in which provider-side path manipulation may escape detection. That limit follows from the model: ASPA authenticates customer assertions about providers; it does not convert AS_PATH into an end-to-end signed sequence.

Used with those boundaries intact, ASPA extends RPKI beyond prefix-origin authorization. It adds a cryptographically verifiable provider relation that can make specific route leaks and path inconsistencies visible to BGP policy without pretending to encode every interdomain agreement.

Cybersecurity RPKI BGP Routing Security ASPA