Page MenuHomeVyOS Platform
Create Task
Maniphest T9512

bgp/rpki: add ASPA (AS_PATH verification) support
Open, LowPublic
Actions

Description

Description

FRR has merged ASPA support into master (FRRouting/frr#23470, "bgpd: Add ASPA support", merged 2026-10-20, so it will be part of the release after 10.7, currently 10.9.0-dev). ASPA (Autonomous System Provider Authorization) checks the AS_PATH of received routes against the customer-to-provider records published in the RPKI. It detects route leaks and forged-origin path attacks that ROA based origin validation cannot see. VyOS already has RPKI/RTR support, but no way to use ASPA.

I would like to have this in VyOS once an FRR version with ASPA is used in the image. I am willing to prepare the vyos-1x change.

How it works in FRR (see doc/user/rpki.rst, section "ASPA AS_PATH Verification")

  • ASPA records come over the existing RTR sessions (RTR protocol version 2). No extra cache configuration is needed.
  • It is a build-time capability. FRR must be built against an rtrlib that has ASPA support, otherwise match aspa is accepted but never matches.
  • The verification direction is not derived from the neighbor, it is given in the route-map:
route-map FROM-CUSTOMER deny 10
 match aspa upstream invalid
!
route-map FROM-TRANSIT permit 10
 match aspa downstream invalid
 set local-preference 50
`upstream` is for routes from customers, lateral peers and RS-clients. `downstream` is for routes from providers and route servers. States are `valid`, `invalid`, `unknown`.
  • Revalidation after a new ASPA record needs soft-reconfiguration inbound on the peer, the same as for ROA updates.
  • Operational commands: show rpki aspa [ASNUM] [vrf NAME] [json] and show bgp [afi] [safi] aspa <upstream|downstream> <valid|invalid|unknown>. The route detail shows aspa (upstream: ..., downstream: ...).

Proposed VyOS scope

  1. Policy: new match leaf in policy route-map <name> rule <n> match, next to the existing rpki and rpki-extcommunity. For example match aspa upstream <valid|invalid|unknown> and match aspa downstream <valid|invalid|unknown>, rendered in data/templates/frr/policy.frr.j2 as match aspa <direction> <state>. The direction and the state are given with symbolic names, no raw values.
  2. Operational mode: show rpki aspa [<asn>] [vrf <name>] in op-mode-definitions/rpki.xml.in, and the aspa filter for show bgp ... .
  3. Smoketest in test_policy.py for the new match, and documentation in vyos-documentation (route-map match options, RPKI page with an example).
  4. Image: an FRR version that includes ASPA and an rtrlib with ASPA support (vyos-build, scripts/package-build/frr). The image currently builds FRR stable/10.7 against the Debian librtr-dev. The ASPA code needs a newer rtrlib than the distribution provides, so this probably needs an rtrlib package built in vyos-build as well. Until then the CLI could be added but would have no effect.

Open questions

  • Should the CLI be added only when the FRR in the image has the feature? FRR accepts the command without ASPA support in rtrlib, so a mismatch would be silent.
  • Naming of the direction: upstream/downstream as in FRR, or something aligned with other VyOS policy options.

Details

Version
rolling
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Feature (new functionality)

Event Timeline

rherold created this task.Mon, Oct 26, 8:08 AM
rherold created this object in space S1 VyOS Public.
pasik subscribed.Mon, Oct 26, 8:20 AM
rherold added a comment.Mon, Oct 26, 8:21 AM

Addition on the image side, the rtrlib part is the real blocker.

  • vyos-build (scripts/package-build/frr/package.toml) installs librtr-dev from the Debian mirror and builds FRR against it. There is no own rtrlib package in vyos-build. The base is still bookworm.
  • Debian ships upstream 0.8.0 in every suite: bookworm 0.8.0-1, trixie 0.8.0-1.1, forky/sid 0.8.0-8. The Trixie switch therefore does not change anything for ASPA.
  • Upstream rtrlib has no release with ASPA. The latest release and tag is still v0.8.0 (2021) and its tree has no ASPA code. ASPA is only on master, 69 commits after v0.8.0, with the last commits in September 2026.
  • FRR master detects it at configure time (checking whether the RTR Library supports ASPA). Upstream rtrlib master also renamed its public API with an rtr_ prefix without a version bump (see bgpd/bgp_rpki_compat.h in FRR). Without ASPA support in rtrlib the FRR build still succeeds, but match aspa never matches.

So three things are needed in the image: an FRR version with the ASPA change (after stable/10.7), an rtrlib with ASPA, and a package for it in vyos-build (from upstream master or a future release, since Debian will not provide it soon).

Because of this I would add the CLI to vyos-1x only when the image can build FRR against an rtrlib with ASPA. Otherwise the new match aspa would be accepted and silently do nothing.