What You Need to Know About ARIN’s Test of RPKI Infrastructure

On Friday, 5 August 2022, ARIN announced a forthcoming RPKI infrastructure test. At some point in September, both RSYNC and RRDP access to the RPKI repository will be unavailable for 60 minutes. The exact date and time when this will happen will not be announced to ensure that the unavailability will not be predictable.

This is not the first time ARIN has conducted testing. In July 2021, ARIN removed external access to its repository services for 30 minutes.

While testing on a production environment can cause concern for network operators, this exercise bears very little risk as RPKI has been designed with a couple of failsafe mechanisms.

One safety mechanism is that when routes do not have any matching Validated ROA Payloads (VRPs), they will be tagged as NotFound. During this 60-minute window, routes received can still be propagated to other peers. This is documented in RFC 7115/BCP-185, which states that RPKI-validated routing announcements should be preferred, without rejecting those that could not be validated.

Additionally, in the absence of RPKI data for route validity, BGP speakers can still fall back on IRR filtering to prevent any illegitimate BGP announcements.

This said, it is quite unlikely that BGP announcements will be tagged as NotFound during this timeout period as Relying Parties (RPs) normally keep a local cache of the complete set of signed objects, which are then used to perform validation of a route [RFC6483]. When running the validation process, RPs will first validate the signature on the manifest files (MFTs) and check the certificate revocation lists (CRLS) to see if there has been any revocation. Both MFTs and CRLs usually have a validity period of 2-3 days and are refreshed daily by the RIRs’ certificate authority (CA). In the absence of any new CRLs and MFTs, the validator will use the most recent and valid ones.

What could possibly go wrong?

In the not-so-unlikely event of a BGP prefix hijack – whether intentionally or maliciously (e.g. a prefix advertised by a rogue ASN using a shorter path) – and traffic is redirected, the victim may advertise more specific prefixes and also create a ROA to protect the announcements. If this event occurs during this 60-minute downtime window, ROAs created on the ARIN portal would not be accessible immediately and this can delay the hijack mitigating measures.

Will validation on delegated repositories be affected?

TL;DR Yes. RPKI is built using a chain of trust and with delegated RPKI, ROAs and other RPKI-signed objects are published in the repository of the organization running the delegated certificate authority (CA). However, there is always a link back to the parent CA (in this case ARIN) and in a top-down validation process, the validator starts with the trust anchor (ARIN Tal) which will not be accessible. In this scenario, the validator will rely on its cache to perform the validation on BGP announcements. If the RP has no in-built cache to perform the validation, routing announcements will simply be tagged as NotFound.

Recommendations for the MANRS Community

As more operators embrace RPKI, dependency on RPKI services will become more critical. MANRS encourages RIRs and delegated RPKI operators to continuously monitor the availability and performance of their RPKI infrastructure and to implement security mechanisms that would help increase the overall resilience of the ecosystem. We have several resources and training materials available to help, and ARIN’s RPKI site also has a lot of information to guide you.