Summary

  • An ASPA is a signed RPKI object in which a customer AS authorizes a set of provider ASes. Its scope is a relationship claim used by a path-verification algorithm, not a cryptographic attestation of every hop in a received route.
  • ASPA verification can return Valid, Invalid or Unknown from the validated objects available to a relying party and the route’s propagation context. Those outcomes do not replace Route Origin Validation, establish real-world identity, or prescribe one universal routing action.
  • Operators need an observation and completeness ledger that separates object validity, the declared provider set, cache time, session role, verification result, local policy action and unresolved uncertainty.

The most dangerous word in a route-security dashboard may be “Valid”. It sounds complete. In ASPA verification it is deliberately narrower: the observed AS path is consistent with the customer-provider authorizations that the algorithm can evaluate in the relevant direction. That conclusion can be useful without being a signed biography of the route.

The current ASPA profile, still an Internet-Draft, defines a digitally signed object issued under the Resource Public Key Infrastructure. The holder of a customer AS identifier names one or more AS identifiers as authorized providers. The profile expects all providers to be listed and one ASPA object to represent a customer AS. A relying party validates the object before using its payload.

That structure answers a specific question: has the customer AS authorized this provider AS in the published RPKI data? It does not state which prefix is being announced. Route Origin Validation, using ROAs, addresses origin authorization. The ASPA verification draft treats the controls as complementary because a plausible origin and a plausible propagation path are different properties.

Nor does the signature authenticate a real-world organization. RFC 9255 makes the RPKI boundary explicit: its “I” does not stand for identity. A valid object supports a resource-authorization conclusion. It does not prove that two companies signed a current commercial agreement, that an engineer entered the correct relationship, or that traffic is presently exchanged on a particular link.

Completeness is the next boundary. The verification draft expects a customer AS to register all provider ASes and relevant non-transparent route-server ASes. If a legitimate provider is omitted, the published set is incomplete. As deployment expands, a path through that provider can be classified Invalid even though the operational relationship is genuine. The cryptography can be sound while the maintained declaration is wrong.

The algorithm preserves that uncertainty. At the relationship level, available data can support Provider+, Not Provider+ or No Attestation. At the path level, the result can be Valid, Invalid or Unknown. Unknown is not a softer spelling of Invalid: it can mean that the available attestations do not support a conclusive determination. Treating it as proof of a leak would invent evidence the system does not contain.

Valid is not universal safety either. It does not prove that every AS in the path signed the route, that the origin was authorized, that all route-server transformations were transparent, or that local export policy was followed. BGPsec and ASPA have different evidence semantics. ASPA checks relationship consistency from independently published provider authorizations; it is not a replacement name for hop-by-hop path signing.

Order matters. RFC 9774 deprecates AS_SET and AS_CONFED_SET because unordered collections weaken the meaning of AS_PATH. The ASPA verification procedure cannot recover customer-provider direction from an unordered set and treats an AS_SET-bearing path as invalid for its checks. This is an input-semantics limit, not evidence that every ordinary ordered path is fully attested.

BGP Roles supply another contextual layer. RFC 9234 defines roles such as customer, provider, peer and route server for route-leak prevention. Session role helps determine which propagation pattern should be permitted. Yet a negotiated capability is not a universal commercial record, and the ASPA result remains one observation applied by a receiving operator.

This is why operational policy stays local. The verification draft does not command every network to reject every Invalid route or prefer every Valid route in the same way. An operator must decide how the result interacts with reachability, deployment coverage, exceptions and other security signals. That decision should be explicit and versioned rather than hidden behind a coloured badge.

A useful ledger has six linked but distinct records. First is the ASPA object: customer AS, provider set, certificate lineage and validity. Second is completeness evidence: who reviewed the provider inventory, against which contracts and topology records, and when. Third is the relying-party observation: validator identity, retrieval time and validated payload hash. Fourth is route context: ordered path, session role, route-server handling and observation point. Fifth is the algorithmic outcome and its reason. Sixth is the operator action, owner, exception and expiry.

Time cannot be collapsed across those records. A provider added on Friday, an ASPA updated on Saturday and a validator refreshed on Sunday describe three different states. An incident review must use the objects and observations available when the route was accepted, not only the corrected declaration visible afterward.

The drafts cited here may change before becoming RFCs, and no named operator or incident is alleged. The durable governance lesson is already clear: an ASPA is a scoped provider authorization. Preserve its validation, completeness and use as separate evidence, and a path result becomes a defensible input rather than an oversized claim.

Sources