[PATCH] Nest: correct aspa_check() implementation

[Alarig Le Lay]

Hello Ondřej,

If you need some help to have a patched package for the next RIPE
meeting, don’t hesitate to ping me :)
I’m the gentoo maintainer, but I also played with deb and rpm packages
for other projects, to it should be doable.

On Fri 13 Mar 2026 11:58:43 GMT, Ondřej Caletka wrote:
> Hello Evann,
> 
> I would like to share that I tried your patch and it seems to be working 
> very well. Just looking at the numbers from unpatched BIRD 3.2.0:
> 
> bird> show route where invalid_aspa=1 count
> 1825 of 3100872 routes for 1033635 networks in table master4
> 897 of 717964 routes for 239333 networks in table master6
> 
> And the numbers from patched version 2.18:
> 
> bird> show route all where invalid_aspa=1 count
> 116 of 3100875 routes for 1033636 networks in table master4
> 108 of 717949 routes for 239328 networks in table master6
> 
> It is obvious that there is a dramatic drop of invalid paths. In my 
> setup there are now only 29 unique paths that are invalid, which seems 
> reasonable. I checked each one manually using a web-based validator I 
> botched together and they seem to all have problem with APSA data, so 
> dropping them is a good thing.
> 
> One example of broken path is this:
> https://oskar456.github.io/aspa.html#path=3333-12859-215551-30893-13214-35634
> 
> Thanks for the patch and I hope it will make it to a release soon :)
> 
> --
> Best regards,
> 
> Ondřej Caletka
> 
> 
> On 08/02/2026 02:39, Evann DREUMONT via Bird-users wrote:
> > Hello,
> > 
> > Earlier this week, while building a BGP lab I've discovered a weird behavior with aspa_check() that was rejecting routes that should be correct. It seems to be the same bug as https://trubka.network.cz/pipermail/bird-users/2026-February/018611.html.
> > 
> > I discover that the previous implementation of the verification algorithm was not fully compliant with the current internet draft (draft-ietf-sidrops-aspa-verification-24) and could incorrectly filter routes when the up-ramp and down-ramp apex were apart by exactly one hop. In practice, this caused legitimate routes to be dropped, such as routes involving Tier-1 peering while having an AS0 ASPA record.
> > 
> > One of my test sample was the following AS_PATH: 10846, 7018, 174, 29075, 208627 with the following ASPA records:
> > - AS208627 => AS29075
> > - AS174    => 0
> > - AS7018   => 0
> > - AS10846  => 7018
> > If you manually compute the upstream and downstream bounds, you get
> > - max_down = 5 - 3 + 1 = 3
> > - min_down = 5 - 4 + 1 = 2
> > - max_up = 2
> > - min_up = 2
> > Using the downstream algorithm:
> > - max_up + max_down = 5 >= N, so the route is not invalid and we continue
> > - min_up + min_down = 4 < N, so the route is unknown
> > If you draw this on paper, it makes sense. However, BIRD reports this route as invalid, which is unexpected.
> > 
> > Given this issue, I tried to implement a patch. With a bit of help of Alarig, I managed to get a working version that still passes the existing unit tests (except one) as well as our corner case. While I tried to understand the initial logic, it was quite hard to follow. Therefore, I tried, as much as possible, to follow the algorithm from the I.D. Something not trivial since the AS_PATH is reversed compared to the draft.
> > 
> > This patch also contains few documentation comments. While I am not usually a big fan of comments, I think these are needed to highlight the differences between our implementation and the algorithm specified in the Internet-Draft.
> > 
> > To improve unit test coverage, I have added the missing test cases from the official list (https://raw.githubusercontent.com/ksriram25/IETF/main/ASPA_path_verification_examples.pdf). They all passed successfully.
> > 
> > However, one of the existing custom unit tests did not pass.  In this test, the path consists of two ASes: 65544, 65541. AS65544 declare an AS0 ASPA and AS65541 declare AS65545 as a provider.
> > The test expects the route to be invalid. However, I believe this expectation is incorrect. Manual computation gives:
> > - min_up = 1
> > - max_up = 1
> > - max_down = 2 - 2 + 1 = 1
> > - min_down = 2 - 2 + 1 = 1
> > Using the downstream algorithm:
> > - max_up + max_down = 2 >= N, so the route is not invalid and we continue
> > - min_up + min_down = 2 >= N, so the route is not unknown, and therefore the route is valid.
> > This actually makes sense: although there is no explicit valid ASPA, from a downstream perspective, this can be interpreted as a peering relationship between AS65544 and AS65541 (with the up-ramp and down-ramp apexes separated by exactly one hop), and the route should therefore be considered valid (see: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-24#section-5.1).
> > 
> > Don't hesitate to discuss the patch if needed,
> > 
> > --
> > Evann
>