RPKI and AS3333 or “How We Eat Our Own Dog Food”

At the RIPE NCC, we are very invested in Resource Public Key Infrastructure (RPKI). We run a Trust Anchor (one of the root certificate authorities (CAs)), we host a platform for maintaining ROAs, and we offer a publication server accessible over rsync and RRDP. The only thing we’ve been missing so far is operational experience of running RPKI Route Origin Validation on our own network, AS3333, and rejecting RPKI invalid BGP announcements.

Why Didn't We Do This Before?

The reason for this is that, for a long time, it’s been considered harmful to drop routes from any member who created a 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 Route Origin Validation “invalid == reject”. So if someone makes a typo in the origin AS number, or gives the wrong prefix or MaxLength, 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, we’ve seen 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 our upstream providers and Internet Exchange already drop RPKI invalid BGP announcements, and some don’t.

This resulted in a case, just last year, where a member was hijacked and couldn’t reach our website. When we enabled RPKI ROV for AS3333 on the AMS-IX route server, the member could reach us again.

In light of all this, after internal discussion and discussion on the Routing Working Group mailing list, we have reached consensus to move forward. We will enable RPKI ROV on Monday 19 April 2021. Announcements on appropriate mailing lists to follow very shortly!

Mismatch Alerts in RPKI Dashboard

We've improved our RPKI Dashboard UI so that a member or End User who is about to create a ROA that doesn't match what we see in BGP gets an alert before publishing that ROA. Our operations team will of course keep a close watch on monitoring and our Registry Services team has been briefed.

On 7 April, we saw 697 routes that are labeled as “invalid” from RIPE NCC member or End User prefixes from 215 organisations. We've reached out to these organisations and made them aware of these RPKI invalid BGP announcements.

We have decided not to build a “back door” for the LIR Portal, nor will we as RIPE NCC adjust any ROA on behalf of a member or End User. The only way to regain access to the RIPE 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

We are very excited to reach this milestone, as we believe we will gain great benefit from hands-on experience to improve RPKI for the good of the Internet. I want to thank the Routing WG community and chairs for their support. Please contact us at rpki@ripe.net in case you have any questions.