Summary

  • ASPA adds signed customer-to-provider evidence to the RPKI, extending assurance beyond route origin authorization.
  • Publication and enforcement are separate states: a router must receive validator data, interpret the session role and apply an explicit action to Invalid paths.
  • Partial deployment makes Unknown a necessary operational state, not a synonym for Valid or Invalid.

The signed object arrives before the protection

A network engineer opens the RPKI dashboard and sees the new ASPA. The authorized providers are correct, the object is signed, and the repository is reachable. The same deliberately invalid customer path is then announced to a production edge. It remains installed because the production import policy does not consume the validator's ASPA result.

Nothing about that result disproves the ASPA. The object has done its job: it states which upstream relationships the ASN holder authorizes. The test instead isolates the missing production control: the router's import policy is not acting on the validator result.

APNIC describes ASPA as a signed list of authorized upstream providers. That gives operators path evidence that ROAs do not provide. A ROA can establish that an origin is authorized for a prefix while saying nothing about whether the AS path follows authorized provider relationships.

The current IETF work therefore defines verification procedures, not a magic property of publication. Evaluation varies with whether a route arrives from a customer, peer, provider, route-server client or sibling. The operational question is not merely whether an ASPA exists. It is which decision the receiving router made from the evidence available at that instant.

Unknown must remain visible

Incremental deployment means many paths contain hops for which no ASPA exists. RIPE's operational guidance treats this as Unknown and recommends accepting it during partial deployment. Aggressively dropping every unknown path would turn an incomplete evidence system into an availability hazard.

That safety property creates a reporting obligation. An operator cannot describe all accepted paths as validated. Valid means the available attestations support the path. Invalid means available evidence contradicts it. Unknown means the system cannot reach either conclusion. Conflating these states hides both exposure and the reason enforcement is safe to introduce gradually.

ASPA is also not a complete policy language. The IETF draft notes that it cannot prevent every locally initiated leak and recommends the Only-to-Customer attribute as a complement. Nor does a cryptographic path result prove packet delivery, traffic engineering intent or the commercial truth of a relationship.