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 :-)
Best,
Lancheng
Hi Lancheng and Mike,
This is TsungYi, the AS7480 operator. I will look into this issue and
share the reason here shortly.
Thank you!
Best regards,
TsungYi Yu
AS7480
(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