ASPA Path Verification Explained

Originally published on Hashnode.

Autonomous System Provider Authorization (ASPA) is a recently proposed solution designed to detect and mitigate route leaks and improbable AS paths. ASPA utilizes the existing RPKI infrastructure to allow storing and verifying cryptographically protected AS-level relationship information. This post focuses on the AS path verification process used by ASPA.

Note: This post is based on this IETF draft from June 2023. The draft text, including address-family handling, may differ from the final RFC.

Route leak

In overview, the definition of route leak considered in ASPA is based on RFC 7908: Problem Definition and Classification of BGP Route Leaks. The route leaks defined in this RFC is mostly based on the “valley-free” principle.

A previous Cloudflare Radar post on route-leak detection summarized four common route leak types as follows:

Routes from	To provider	To peer	To customer
From provider	Type 1	Type 3	Normal
From peer	Type 4	Type 2	Normal
From customer	Normal	Normal	Normal

In essence, route leaks defined in RFC 7908 can be summarized into one principle: routes obtained from a non-customer (peer, customer, route-server) AS can only be propagated to customers.

In ASPA, the authors inherited the definition of BGP roles (e.g. customer, provider) from RFC 9234. See the RFC9234 post for more detail on RFC9234 and the OTC BGP attribute.

Local AS Role	Remote AS Role
Provider	Customer
Customer	Provider
RS	RS-Client
RS-Client	RS
Peer	Peer

Table: allowed pairs of BGP role capabilities.

ASPA TL;DR

At a high level, the ASPA mechanism has the following properties:

ASPA stores customer-to-provider information in RPKI
- One customer AS (CAS) associated with a set of provider ASes (SPAS)
ASPA is useful for verifying BGP AS_PATH attribute content
- AS_PATH that violates the “valley-free” routing principle can be detected with ASPA objects information
ASPA is incrementally deployable, benefiting early adopters

ASPA Verification Explained

Before describing how ASPA detects route leaks, it is useful to review the shape of a typical valley-free route.

A typical long BGP route that travels from one edge network to a different edge network would look like this:

The route travels three different phases:

upward: a consecutive customer-to-provider segments
peering: a single peer-to-peer segment
downward: a consecutive provider-to-customer segments

Note that in many cases, the routes may only have one or two phases, but they must be in this order. For example, one legit route could have an upward then downward phase, without a peering phase. A route leak route could be any route with reverse order of the phases, e.g. downward then upward.

In ASPA, the phases are defined into two categories:

upstream: path received from a customer or a peer or a route server
downstream: path received from a provider or sibling

ASPA verification uses different procedures for upstream and downstream paths. Each category is described below.

Upstream paths

ASPA verification for upstream paths (received from a customer or peer or route server) is relatively simple. The key principle is that a normal upstream path should only contain customer-to-provider relationships for the consecutive AS path hops.

A path is

Valid: if all hops in the AS paths are verifiable customer-to-provider, i.e. every hop on the path registers their providers on ASPA and the providers match the next hop on the path;
Unknown: one of the hops is missing ASPA information;
Invalid: one of AS has a set of provider AS (SPAS) but the next hop is not in it.

Downstream paths

The downstream paths are considerably more complex as it may have legit paths segments that travel all three phases (up, peer, down) before reaching the receiving AS. Interested readers should refer to the original IETF draft document’s section on downstream path verification for a more definitive definition. The summary below simplifies the wording to give a high-level view of the verification process.

Based on the original documentation, a downstream path is Invalid if there exist hops indexed as u and v such that

u<=v
hop(AS(u-1), AS(u))="Not Provider+"
hop(AS(v+1),AS(v))="Not Provider+"

In practical terms, this condition can be read as follows:

two hops at the location u and v and u is before v
hop u is verified to be NOT a customer-to-provider hop, i.e. peer-to-peer or provider-to-customer, i.e. a peering or downward phase
hop v is verified to be NOT a provider-to-customer hop, i.e. peer-to-peer or customer-to-provider, i.e. a peering or upward phase

In summary, the path would be ASPA Invalid, if it contains a downward or peering then later a upward or peering. The AS relationship would look like the following figure, where u and v could be the same ASN. As long as this pattern appears somewhere in the path, it violates the “valley-free” routing and thus is considered as route leak.

graph LR
  UProvider["u-1"] -->|"provider-to-customer"| U["u"]
  UPeer["u-1"] -->|"peer-to-peer"| U
  U -.-> V["v"]
  V -->|"customer-to-provider"| VProvider["v+1"]
  V -->|"peer-to-peer"| VPeer["v+1"]

The Unknown and Valid definitions are then straightforward:

Unknown: the path is NOT Invalid and there are hops that miss ASPA information
Valid: the path is NOT Invalid and NOT Unknown

Note: The ASPA document allows different verification algorithms, as long as they produce results equivalent to the specified process.

ASPA vs RFC9234

ASPA and RFC 9234 both aim to prevent or mitigate route leaks, but they use different mechanisms. The table below summarizes the main differences.

	ASPA	RFC9234
By whom	Customer AS (owner) only	BGP sessions, providers
Content security	Cryptographically signed	Secured by BGP session; OTC attributes can be forged
Where to detect/filter	Any AS	Neighbors or ASes that receive OTC attribute
Prevent forged path?	Yes	No
Deployment timing	Initial objects had already appeared; general deployment was expected in 2025 or later (Job Snijders / MANRS)	Initial deployment had appeared; general deployment remained unclear

How to view ASPA objects on RPKI today?

Although still in the draft phase, ASPA support has already been added to popular routing software like routinator and OpenBGPd. BGPKIT monocle also supports reading ASPA objects from RPKI repositories through the monocle rpki read-aspa command. The following steps show how to inspect currently published ASPA objects.

Install BGPKIT monocle

BGPKIT monocle is a Rust-based BGP data processing command-line tool. Install the Rust toolchain using the instructions at https://rustup.rs/.

Then install monocle:

cargo install monocle

Download the recent RPKI archive

The RPKI repository archive used here comes from Job Snijders’ RPKIViews project. The example below downloads one archive from josephine.sobornost.net (about 260 MB).

cd /tmp
wget http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2023/06/25/rpki-20230625T173535Z.tgz
tar xzf rpki-20230625T173535Z.tgz

Find and view ASPA objects

The ASPA objects are stored as files with the suffix .asa in the RPKI repository. You can use find command to search across the untarred repo file from the previous step:

➜  rpki-20230625T173535Z find . -name "*.asa"
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148808.asa
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148809.asa
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148810.asa
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148804.asa
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148805.asa
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148807.asa
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148806.asa
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148802.asa
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148803.asa
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148801.asa
./data/rpki.sub.apnic.net/repository/A914BC7A0000/0/AS148800.asa
./data/rpki.cc/repo/MythicalKitten/9/AS60310.asa
./data/rpki.cc/repo/MythicalKitten/0/AS203635.asa
...

Use monocle rpki read-aspa to inspect an ASPA object. For example:

➜  rpki-20230625T173535Z monocle rpki read-aspa ./data/rpki.cc/repo/MythicalKitten/9/AS60310.asa

| asn   | afi_limit | allowed_upstream |
|-------|-----------|------------------|
| 60310 | none      | 924              |
|       |           | 6939             |
|       |           | 48581            |
|       |           | 50224            |
|       |           | 52210            |
|       |           | 204857           |
➜  rpki-20230625T173535Z monocle rpki read-aspa ./data/rpki.co/repo/Mlgt/0/AS204508.asa

| asn    | afi_limit | allowed_upstream |
|--------|-----------|------------------|
| 204508 | none      | 6939             |
|        |           | 7721             |
|        |           | 29632            |
|        |           | 34872            |
|        |           | 34927            |
|        |           | 38230            |
|        |           | 41051            |
|        |           | 50058            |
|        |           | 60326            |
|        |           | 200105           |
|        |           | 208753           |
|        |           | 210633           |
|        |           | 211411           |
|        |           | 212271           |
|        |           | 212895           |

BGPKIT is experimenting with library support for ASPA to support measurement and research use cases. Feedback and feature requests are welcome at [email protected].