[PATCH] Nest: correct aspa_check() implementation
Maria Matejka
maria.matejka at nic.cz
Sun Mar 15 19:22:17 CET 2026
Hello Evann!
Thank you for the patch! I have checked it thoroughly and it looks right.
> 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.
>
> [...]
>
> Given this issue, I tried to implement a patch. [...]
I have split your patch, and accepted the part where the test cases are
added. After some back and forth, I decided to fix the function in a
different way, keeping the logic of apex indices. I'm not totally
opposing rewriting the function completely, but we have some more plans
with that function (e.g. giving the up-ramp and down-ramp path chunks
back to the user), and the apex indices approach is more suitable for
that.
You may see my fix in the branch `355-aspa-minimal-fix`, where I also
added some additional commits, most notably the commit documenting
how the `aspa_check()` function is designed and why. Please note that
the branch may get rebased before merging into master.
Side note: I have had a long beef with the authors of the draft about
the wording and overall structure, and I'm very happy that you happened
to implement this by the draft in a way which is not totally confusing.
I have pushed your rewrite to the branch `355-aspa-downstream-fix-evann-dreumont`,
so that it doesn't get lost if we happen to change our minds later,
and also to prove that the rewrites of the draft were for good.
> 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.
You could have been much harsher on me for not implementing part of my
own test cases back into BIRD, tbh.
> 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.
It was indeed incorrect, and again, it was me sending this (or similar)
testcase to Sriram with an incorrect outcome, and after somebody pointed
out that it's incorrect, I didn't follow up and fix that back in BIRD.
Last but not least, sorry for me being silent. There has been an awful
lot on my table recently, including fast-coding a CoAP endpoint for
upcoming BIRD API, replicating and fixing some more crashes in BIRD 3,
doing a lot of code reviews, and some crazy stuff better for a pub than
a public mailing-list.
With that, thank you again for your patch, checks, effort and everything.
Have a great day and happy routing!
--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20260315/b83b2d20/attachment.htm>
More information about the Bird-users
mailing list