Hands-on ASPA: Configuration and Lessons Learned#

Carlos Martínez (LACNIC), Guillermo Cicileo (LACNIC)

• Why: ASPA is the next deployment wave in routing security — LACNIC's own member-assembly report lists ASPA object support as its 2026 RPKI roadmap item, and the NRO's 2026 RPKI program explicitly aims to deploy ASPA — and this hands-on session connects directly to the hijack case above.
• What: A fundamentals-plus-practice session on ASPA (Autonomous System Provider Authorization, IETF sidrops drafts): a new RPKI object in which an ASN cryptographically declares its authorized upstream providers (an AS0 ASPA declares "no providers," e.g., Tier-1s or route-server-only clients). It detects forged-AS-path/origin hijacks and mitigates global route-leak propagation, reusing the existing RPKI architecture (validators, repositories, rpki-rtr) without adding router-side cryptography.
• How: ASPA formalizes valley-free routing: for each adjacent AS pair in an AS_PATH, the validator checks the customer's attestation — P (declared provider), nP (AS exists in the attestation but this neighbor is not a provider → lateral/customer hop), nA (no attestation published) — enabling both upstream and downstream path verification.
• Where applicable: Any operator already running RPKI can adopt ASPA on the same infrastructure; benefits scale with ecosystem-wide adoption, which is still early (IETF draft stage). Pairs with the case study: RPKI origin validation alone would not have stopped the AS28001 impersonation; path verification is the missing half.