ASPA in the RPKI Dashboard#

Tim Bruijnzeels, RIPE

• Why: ASPA is the mechanism operators will be asked to deploy after ROV; this is the clearest available explanation of its verification semantics — what it catches, what it deliberately tolerates, and how it fails.
• What: A worked tutorial of ASPA (AS Provider Authorisations): objects like ROAs, signed by the customer-AS holder, authorizing one or more provider ASes. Routes learned from customers are invalid if a hop is proven "Not Provider"; the system supports partial deployment (no attestation = fail open, as does an RPKI validation problem itself), and it detects valley-free violations by constructing the longest UP ramp (customer→provider from the origin) and DOWN ramp (provider→customer from the receiver) and rejecting paths with a gap — i.e., route leaks — regardless of whether the cause is accident, leak, or spoofing.
• How: Object structure and path-verification logic presented through concrete examples (spoofed-origin and leaked-path cases), matching what the RIPE RPKI Dashboard now surfaces.
• Where applicable: Protocol-level and vendor-neutral; broadly applicable. Deployment is early (ARIN brought ASPA online for its own services 20 January 2026, per the ARIN update in the same program), so this is the right time to learn the semantics before it lands in dashboards you use.