Routinator, our RPKI validation software, now sees more than 1000 Autonomous System Provider Authorization (ASPA) objects in the wild.
-
@alexband I don't find the support for it in FRRouting, do you have a link ? I tried grepping through the source, I see support for RPKI, but nothing for ASPA...
@asl Hmm, indeed. I may have remembered incorrectly... 🧐
-
Routinator, our RPKI validation software, now sees more than 1000 Autonomous System Provider Authorization (ASPA) objects in the wild. These are published by operators to detect and prevent BGP route leaks.
ASPAs can be created in the hosted RPKI services of the RIPE NCC and ARIN, as well as our open-source RPKI Certification Authority software, Krill.
Open-source routing projects such as BIRD, OpenBGPD and FRRouting already offer support for ASPA, while major commercial vendor support is expected later this year.
#OpenSource #OpenStandards #IETF #RPKI #BGP #RoutingSecurity
@alexband ....and updated my lab with the newest #Routinator version and added --enable-aspa to my containerlab config
-
@alexband ....and updated my lab with the newest #Routinator version and added --enable-aspa to my containerlab config
@wtremmel @alexband @nlnetlabs I think we can flip that switch into a `—disable-aspa` in the next release.
-
@alexband I have yet to see how RPKI / ASPA / ROA can actually prevent route leaks.
I absolutely agree that they can help detect and mitigate route leaks AS LONG AS peers are using information published via RPKI / ROA.
Much like SPF can’t prevent spam. While SPF does make it easier to detect and filter spam.
Preventing is proactive and decidedly different than reactively detecting and mitigating (filtering).
@drscriptt @alexband The short form is that some downstream AS can't necessarily detect that routes have passed through inappropriate ASes from a valley-free perspective without some hints about what that relationship is. BGP is quite happy to make sure the routes are loop free without caring what your business relationship is.
If your point is "where's the incentive to register your relationship", that's a different problem.
-
@drscriptt @alexband The short form is that some downstream AS can't necessarily detect that routes have passed through inappropriate ASes from a valley-free perspective without some hints about what that relationship is. BGP is quite happy to make sure the routes are loop free without caring what your business relationship is.
If your point is "where's the incentive to register your relationship", that's a different problem.
-
@drscriptt @jhaas I remember launching #RPKI in 2011. It took years of publishing ROAs, learning from mistakes and fixing bad quality ROAs before the operator community got to the point where they felt comfortable dropping invalid routes.
ASPA will be the same, although perhaps a bit quicker because of the huge installed base of (ASPA capable) validators: https://rov-measurements.nlnetlabs.net/stats/
-
@drscriptt @alexband Publication has the benefit of proxy enforcement. A number of service providers gained the benefits of origin validation when they themselves weren't participating in dropping stuff locally.
If you want to gripe that any AS can raw-dog updates generated by bash scripts and filter nothing, weird flex I guess?
-
@drscriptt @jhaas I remember launching #RPKI in 2011. It took years of publishing ROAs, learning from mistakes and fixing bad quality ROAs before the operator community got to the point where they felt comfortable dropping invalid routes.
ASPA will be the same, although perhaps a bit quicker because of the huge installed base of (ASPA capable) validators: https://rov-measurements.nlnetlabs.net/stats/
@alexband @drscriptt I have fears of subtle bugs in the validation algorithm, but expect that like OV ASPA will be deployed in soft mode for a while. The industry showed how to handle the incremental deployment well.
Shorter term, CPU churn from ASPA updates in RPKI-RTR will be... fun.
-
@alexband @drscriptt I have fears of subtle bugs in the validation algorithm, but expect that like OV ASPA will be deployed in soft mode for a while. The industry showed how to handle the incremental deployment well.
Shorter term, CPU churn from ASPA updates in RPKI-RTR will be... fun.
@jhaas @drscriptt Meanwhile, as more #RPKI invalid #BGP routes are dropped, we are working on making the invisible visible again with Rotonda. https://ripe91.ripe.net/programme/meeting-plan/sessions/15/CLRNRY/
-
@jhaas @drscriptt Meanwhile, as more #RPKI invalid #BGP routes are dropped, we are working on making the invisible visible again with Rotonda. https://ripe91.ripe.net/programme/meeting-plan/sessions/15/CLRNRY/
@alexband This is now the second open tab for me to find time to watch from -91. I need to find the time to start attending the sessions.
-
@drscriptt @jhaas I remember launching #RPKI in 2011. It took years of publishing ROAs, learning from mistakes and fixing bad quality ROAs before the operator community got to the point where they felt comfortable dropping invalid routes.
ASPA will be the same, although perhaps a bit quicker because of the huge installed base of (ASPA capable) validators: https://rov-measurements.nlnetlabs.net/stats/
-
@drscriptt @jhaas @alexband what would stopping a leak look like to you?
We’ve already seen a number of route leaks stopped or majorly suppressed by ROA validation, and ROA validation is far less capable in this regard than ASPA.
-
@drscriptt @jhaas @alexband what would stopping a leak look like to you?
We’ve already seen a number of route leaks stopped or majorly suppressed by ROA validation, and ROA validation is far less capable in this regard than ASPA.
@erincandescent @jhaas @alexband my message is about preventing advertisement vs accepting said advertisement.
You can’t prevent someone from doing something. But you can not be part of their actions.
-
@drscriptt @jhaas @alexband what would stopping a leak look like to you?
We’ve already seen a number of route leaks stopped or majorly suppressed by ROA validation, and ROA validation is far less capable in this regard than ASPA.
@erincandescent @jhaas @alexband I can’t prevent you from advertising prefixes to me.
I can filter / not accept the unwelcomed prefix(es) from you.
-
S skorpy@chaos.social shared this topic
