Skip to content

PATTERN Cited by 1 source

ASPA for path validation

ASPA for path validation is the BGP-security pattern of using Autonomous System Provider Authorization objects — RPKI-signed, published by each AS holder, enumerating their authorized upstream providers — to detect and reject route leaks at any BGP vantage point on the Internet.

The pattern

  1. Publish: each AS signs an ASPA object listing its authorized upstream providers (or AS0 for transit-free Tier-1s).
  2. Distribute: ASPA objects live in RPKI and are fetched by relying-party software on a regular cadence.
  3. Validate: during BGP best-path selection, for each received path the router walks the upflow transitions (customer-to-provider) and verifies each is declared in the downstream AS's ASPA.
  4. Enforce: invalid paths are rejected (or marked for lower preference, depending on policy).

Worked example from the Venezuela post

Given AS6762 (Sparkle) is a Tier-1 network, if it publishes an ASPA with AS0 as its upstream:

  • AS8048 leaks to AS52320 a path 52320, 8048, ..., 6762, ..., 21980.
  • AS52320 validates: is 8048 → 6762 a customer-to-provider transition allowed by AS6762's ASPA? AS6762's ASPA says its upstreams are AS0 (none). AS8048 cannot be AS6762's upstream → invalid path.
  • AS52320 rejects the leak.

The leak would be rejected regardless of whether AS8048 updates its export policy.

Why it beats operator-side filters

  • Declarative, signed: ASPA is a cryptographically- signed statement of authorized upstreams. Operators don't maintain separate Tier-1 ASN lists.
  • Global reach: any AS on the Internet can validate ASPA. Leaks are caught at every vantage point, not just the immediate next-hop neighbor.
  • Extensible: works for non-Tier-1 leaks too. Operator- side tools like Peerlock primarily catch Tier-1-in-path leaks; ASPA catches arbitrary violations.

Complementary to OTC

RFC 9234 OTC is session-local and enforced in BGP itself; ASPA is out-of-band and validated from signed data. Both together are the stated Cloudflare preference.

Adoption status

Draft standard in IETF SIDROPS (draft-ietf-sidrops-aspa-verification); RIPE released ASPA object creation in late 2025. Still in the "early adopter" phase at the time of the 2026-01-08 Cloudflare post.

Seen in

Last updated · 200 distilled / 1,178 read