Summary

  • An ASPA is an RPKI object created by an ASN holder with a signed list of authorized upstream providers.
  • The list is an authorization input. A current provider relationship requires a BGP path to be observed and checked; traffic, reachability and commercial service need further evidence.

A signed list is still a declaration

APNIC describes the creator and the object precisely. The holder of a customer ASN publishes the ASPA, and the object names the ASNs permitted to act as upstream providers. Validation can establish that the object is signed within the RPKI hierarchy and that its provider set is the holder's authorized set at that repository state.

That is stronger than an unsigned note, but narrower than a network measurement. The object does not say that every authorized provider is in use, that a session is established, or that any packet crossed the relationship. Authorization answers who may occupy a role. Observation answers who did occupy it in a particular path at a particular time.

Validation joins two evidence layers

APNIC says validators retrieve ASPAs and compare them with BGP announcements. In the upstream direction, the path can be valid, invalid or unknown depending on whether its segments represent customer-to-provider relationships. In the downstream direction, validation asks whether the path is consistent with a non-leak route.

Those results cannot be produced from the ASPA alone. They require an observed AS path, a current validated ASPA set and the correct directional algorithm. “Unknown” is meaningful too: missing authorization data is not affirmative proof that a relationship is forbidden, just as a listed provider is not proof that the relationship is currently visible.

Do not substitute ASPA for ROA or telemetry

APNIC separates the questions. A ROA authorizes an ASN to originate a prefix. An ASPA authorizes provider relationships used to assess the path beyond the origin. Neither object measures traffic volume, latency, reachability, router control or the commercial terms behind a connection.

A defensible record therefore preserves the customer ASN, provider ASN, ASPA repository and validation time. If claiming current transit, it also identifies the observed route, vantage point, AS path and observation time. If claiming service or traffic, it adds evidence appropriate to those claims.

Sources