On 22 Sep 2024, at 23:14, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sat, Sep 14, 2024 at 4:18 PM Lancheng via NANOG <nanog@nanog.org> wrote:
Hi Mike,
Hurricane Electric now uses ASPA to do hop by hop checking of AS paths when deciding which routes to accept when building prefix filters.
Here is an example of a route failing the ASPA check.
44.31.69.0/24,rejected,AS path 4635 9002 945 7480 38254 38254 38254 38254 38254 ASPA record exists for 7480 and 945 is not listed as a provider. 44.31.73.0/24,rejected,AS path 4635 9002 945 7480 ASPA record exists for 7480 and 945 is not listed as a provider.
Thank you for doing and sharing this work. I am interested in this ASPA-invalid example and have a few questions.
Q1: Has this example been sent to the network operator of AS 7480? A confirmation from 7480 would help us understand the reasons behind, e.g., a route leak or forgetting list 945 as a provider in the ASPA.
Q2: I would like to do some ASPA-based verification analysis as well. I do not operate a network or a router, so I need to download ASPA data from public sources by myself. Do you know where I can download ASPA objects and the payload?
I'm sure Job will be able to give much better or more accurate guidance regarding ASPA software, protocols, and terminology.
I copies this email to Job as well :-)
(am not job, but)
I'd expect that the ASPA objects are just part of the global RPKI, that if you run a (to quote job) rpki-client instance you can just have it download 'all the data' and then do whatever poking at it you want.
From rpki-client, if you grab the easily processable rpki-client.json one has the correct and valid view of that current snapshot of the RPKI. The other artefacts are not processes/validated. Note that with http://www.rpkiviews.org we are collecting these in an archive for research purposes also allowing one to go 'back in time' to check if the state has changed since. Greets, Jeroen