With the RIPE NCC recently introducing ROV on their own network (AS3333), APNIC is publishing their recent blog explainer together with an update on how the deployment has progressed.
Route Origin Validation (ROV) is a mechanism by which route advertisements can be authenticated as originating from an expected Autonomous System (AS).
The RIPE NCC is very invested in Resource Public Key Infrastructure (RPKI) and runs a Trust Anchor (one of the root certificate authorities (CAs). It also hosts a platform for maintaining Route Origin Authorizations (ROAs). The NCC also offers a publication server accessible over rsync and RRDP.
The only thing that had been missing was operational experience of running RPKI ROV on RIPE NCC’s own network and rejecting RPKI invalid BGP announcements.
So on 19 April, the RIPE NCC began running ROV on AS3333.
The deployment
After 12 weeks of rejecting RPKI invalid BGP announcements, things appear to be running smoothly. The RIPE NCC has not received any complaints from its members, and has received positive feedback. It’s also assisted several members to create their own ROAs.
The key concern was that there may be some kind of widespread denial of access to the RIPE NCC’s services, but this simply hasn’t been seen. More than anything else, from the RIPE NCC’s perspective, this was a great educational opportunity.
Why didn’t the RIPE NCC do this before?
The reason for this is that, for a long time, it’s been considered harmful to drop routes from any RIPE NCC member who created a Route Origin Authorization (ROA) that doesn’t match the reality in BGP.
This is because when someone creates a ROA, stating their routing intentions (prefix Y will be originated by ASN Z), that ROA will be seen as an authoritative source over what is seen in BGP for operators who are performing RPKI ROV ‘invalid == reject’. So if someone makes a typo in the origin AS number, or gives the wrong prefix or Max Length, the ROA won’t match with what’s seen in BGP and the route will get dropped. From the outside, other operators cannot see if it was a typo in a ROA or a hijack.
And, in addition to this, there’s also been the broader problem of a general lack of knowledge out there about how to create correct ROAs.
So why do this now?
Over the past year, there’s been a lot of change. Not only is there now more, and good documentation on how to create and maintain ROAs, but what’s more, the landscape of parties who perform ROV invalid == reject has also dramatically changed. This means some of the RIPE NCC’s upstream providers and Internet Exchanges already drop RPKI invalid BGP announcements, and some don’t.
Read: RPKI ReadTheDocs
This resulted in a case, just last year, where an NCC member was hijacked and couldn’t reach the NCC website. When RPKI ROV for AS3333 on the AMS-IX route server was enabled, the member could reach the RIPE NCC again.
In light of all this, after internal discussion and discussion on the Routing Working Group mailing list, there was consensus to move forward.
Mismatch alerts in RPKI Dashboard
The RIPE NCC improved its RPKI Dashboard UI so that an NCC member or end user who is about to create a ROA that doesn’t match what the NCC sees in BGP, gets an alert before publishing that ROA. The NCC’s operations team is keeping a close watch on monitoring and the Registry Services team has been briefed.
On 7 April, the NCC saw 697 routes that were labelled as ‘invalid’ from RIPE NCC member or end user prefixes from 215 organizations. The NCC reached out to these organizations and made them aware of these RPKI invalid BGP announcements.
The RIPE NCC has decided not to build a ‘back door’ for the LIR Portal, nor do they plan to adjust any ROA on behalf of a member or end user. The only way to regain access to the NCC is to come from another network that has an RPKI valid or unknown announcement.
Please note that K-Root (AS25152) is not part of AS3333.
Summing up
The team at RIPE NCC are very excited to reach this milestone and what can be learned from it. The NCC team is looking forward to putting this experience to use improving RPKI for the good of the Internet. I want to thank the Routing WG community and chairs for their support. Please contact the RIPE NCC at rpki@ripe.net if you have any questions.
Nathalie Trenaman is a trainer and IPv6 Program Manager at RIPE NCC.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.