Summary

  • LACNIC says members that hold an ASN can configure and publish Autonomous System Provider Authorization (ASPA) objects directly through MiLACNIC. The notice establishes that the member-facing capability has been implemented; it gives no count of users or published objects.
  • ASPA records an AS holder’s authorization of transit providers. LACNIC says the information can support path validation, but its announcement reports no validator receipt, router policy or measured routing outcome.

Analysis

LACNIC has moved ASPA creation into the same member portal used to manage its services. The practical change is an additional control surface: an eligible member can enter provider information and publish an object without using a separate path described in the announcement. LACNIC says the feature is available to members that hold an ASN.

That is a specific implementation milestone, but it answers only the first question in a longer security chain. An ASPA expresses which autonomous systems an AS holder authorizes as transit providers. A relying-party validator must then retrieve and validate the object; routing software must consume the resulting data; and an operator must choose what its local policy does with a path assessment. The portal notice documents the first step. It does not document the later ones.

LACNIC describes ASPA as complementary to ROAs and route-origin validation. A ROA concerns which AS may originate a prefix. ASPA carries provider-relationship information that can help a validator assess portions of an AS_PATH. Conflating the two would turn a useful addition into an overstated security claim: publication is an attestation, not an automatic router action.

The standards record also remains active. The IETF Datatracker lists the ASPA profile as revision 29 and the verification procedure as revision 28, both Internet-Drafts in the SIDROPS working group. Their working-group state is “Waiting for Write-Up”; neither page shows an issued RFC. LACNIC’s September explainer likewise describes adoption as early and says operators need both to publish objects and use them operationally.

The open measurement question is therefore not whether MiLACNIC now exposes the feature. LACNIC says it does. The missing evidence is how many eligible ASNs have published, whether those objects are visible and accepted by relying-party software, and whether any operator has enabled path-validation policy. Until those receipts are published, the portal release is evidence of access—not of regional deployment or a change in route handling.

Sources