An Introduction to ASPA – Validating AS-Paths with the help of RPKI#

Max Stucchi - SwiNOG

• Why: ROAs validate only the origin AS; path manipulation and hijacks above the origin remain invisible. BGPSec is standardized but has no full implementations ("the future"). ASPA is the path-validation building block that is actually becoming deployable now — this is routing security's current frontier, and the talk is an honest adoption-stage briefing.
• What: ASPA (Autonomous System Provider Authorisation): a signed RPKI object listing an ASN's authorized upstreams. Still IETF draft, expected to become RFCs soon; creatable today on RIPE NCC, ARIN, and APNIC (end of Q2 2026) hosted RPKI and via Krill for delegated setups; served via RPKI-RTR v2 (RFC8210-bis draft). Path validation available in BIRD and OpenBGPd (Cisco IOS-XR in testing; Arista expected end of June); Routinator and rpki-client support ASPA objects. AS0 attestation marks "no upstream" (for Tier 1s, IXP route servers, route collectors). Validation fails open by design — absence of an ASPA means "No Attestation," not invalid. Also rounds up the wider object set (BGPSec, RPKI Signed Checklists).
• How: ASPAs build a provider-authorization graph; validators check each AS-pair for "Not Provider" relationships. A clean path shows no violations; hijacks and route leaks (valleys) surface as Not Provider hits. Tools to start: an online ASPA path viewer (oskar456.github.io/aspa.html) and BGPalerter for monitoring your own announcements. Recommended rollout: create ROAs and ASPAs, run at least two relying parties, and log before you filter.
• Where applicable: Any BGP-speaking operator — a general technique, no scale dependency. The constraint is adoption: with <1,000 ASPA objects worldwide, validation coverage is still sparse, so this is early-adopter territory for the next year or two.