In RPKI, determining when exactly a ROA expires is not a simple question. In this post, BGP experts Doug Madory and Fastly’s Job Snijders discuss the difference between the expiration dates embedded inside ROAs and the much shorter effective expiration dates used by validators. Furthermore, we analyze how the behavior effective expiration dates change over time due to implementation differences in the chain of certificate authorities.
In our previous collaboration on RPKI, we celebrated the latest milestone of RPKI ROV (Route Origin Validation) adoption: passing the 50% mark on IPv4 routes with Route Origin Authorizations (ROA). In this post, we will be digging deeper into the mechanics of RPKI to understand how the cryptographic chain contributes to the effective expiration date of a ROA.
Within RPKI, the ROA is a cryptographically-signed record which stores the Autonomous System Number (ASN) authorized to originate an IP address range in BGP. Along with the ASN and one or more IP address prefixes, the ROA also contains an X.509 End-Entity certificate which (among other things) states the validity window: the timestamps after and before which the ROA is valid.
While the expiration dates of individual ROAs might be a year away, the effective expiration dates used by RPKI validators are typically only a few hours or days into the future. This is because these effective expiration dates are transitive, meaning they are set by the shortest expiration date of the links of the cryptographic chain.
To understand how this works, we need to dig into the “cryptographically-signed” part of the ROA mentioned at the beginning of this post.
(Free access, no subscription required)
Using Job’s rpki-client console utility, we can investigate the ROA for 151.101.8.0/22 which asserts AS54113 is authorized to originate this IPv4 prefix.
asID: 54113
IP address blocks: 151.101.8.0/22 maxlen: 22
Also, in that first block are our first dates relating to when this ROA is valid.
Signing time: Sat 11 May 2024 01:00:27 +0000
ROA not before: Sat 11 May 2024 01:00:27 +0000
ROA not after: Fri 09 Aug 2024 01:00:27 +0000
The above Signature path (also known as “Certification path”) outlines the multi-step cryptographic signature validation process that it took to get from this ROA to the “Trust Anchor” (ARIN in this case). Each link in this chain has its own expiration date, the longest set well into the distant future (the year 2025!). But it is the shortest which governs the overall signature path expiration, and thus the effective expiration date of the ROA.
Using Job’s rpki-client console utility, we can investigate the ROA for 151.101.8.0/22 which asserts AS54113 is authorized to originate this IPv4 prefix.
asID: 54113
IP address blocks: 151.101.8.0/22 maxlen: 22
Also, in that first block are our first dates relating to when this ROA is valid.
Signing time: Sat 11 May 2024 01:00:27 +0000
ROA not before: Sat 11 May 2024 01:00:27 +0000
ROA not after: Fri 09 Aug 2024 01:00:27 +0000
The above Signature path (also known as “Certification path”) outlines the multi-step cryptographic signature validation process that it took to get from this ROA to the “Trust Anchor” (ARIN in this case). Each link in this chain has its own expiration date, the longest set well into the distant future (the year 2025!). But it is the shortest which governs the overall signature path expiration, and thus the effective expiration date of the ROA.
There are three different types of files conveniently linked by the console utility: Certificate Revocation Lists (.crl), Manifests (.mft), and Certificates (.cer).
Glossary
Manifests securely declare the contents of a RPKI repository and reference the current CRL and ROAs. A given Manifest is valid until the “next Update” time. When faced with multiple valid versions of a Manifest, RPKI Validators decide which version of the Manifest to use based on a monotonically increasing serial number inside the Manifest payload.
CRLs (“Certificate Revocation Lists”) contain the list of serials of the Certificates that have been revoked by the issuing Certification Authority (CA) ahead of their scheduled expiration date. To take a ROA out of rotation, a CA would delist the ROA filename from the Manifest and add the ROA end-entity certificate’s serial number to the CRL. A CRL is valid until the embedded “next Update” time.
Certificates are used to prove the validity of public keys. RPKI Certificates are defined using the X.509 standard. Each certificate contains its own validity window, a public key, pointers to the repository’s network location, and some additional metadata. RPKI validators use the public key to validate the Manifest, CRL, and ROAs at the repository location. In turn, the certificate’s contents are protected with a cryptographic signature from an issuer higher up in the chain. In the RPKI, the “root certificate” is known as the Trust Anchor. This is a self-signed certificate which can be validated using a Trust Anchor Locator.
By following the links, we can construct the following list of expirations on that signature path:
Signature path: Fri 31 May 2024 23:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/e605f279-55f4-48ec-ba13-4845c0973a63/e605f279-55f4-48ec-ba13-4845c0973a63.crl
Fri 31 May 2024 23:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/e605f279-55f4-48ec-ba13-4845c0973a63/e605f279-55f4-48ec-ba13-4845c0973a63.mft
Mon 13 Apr 2026 22:13:58 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/e605f279-55f4-48ec-ba13-4845c0973a63.cer
Sat 01 Jun 2024 13:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/871da40f-793a-4a45-a0a9-978148321a07.crl
Sat 01 Jun 2024 13:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/871da40f-793a-4a45-a0a9-978148321a07.mft
Thu 25 Dec 2025 14:09:41 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07.cer
Wed 31 May 2024 14:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/5e4a23ea-e80a-403e-b08c-2171da2157d3.crl
Wed 31 May 2024 14:00:00 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/5e4a23ea-e80a-403e-b08c-2171da2157d3.mft
Mon 04 May 2026 15:17:49 rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3.cer
Mon 30 Sep 2024 15:17:49 rsync://rpki.arin.net/repository/arin-rpki-ta/arin-rpki-ta.crl
Mon 30 Sep 2024 15:17:49 rsync://rpki.arin.net/repository/arin-rpki-ta/arin-rpki-ta.mft
Mon 03 Nov 2025 rsync://rpki.arin.net/repository/arin-rpki-ta.cer
Signature path expires: Fri 31 May 2024 14:00:00 +0000
Why is it good to have ROAs perpetually about to expire?
A lot of the elements in the above certification path appear to have relatively short validity windows, with only a few hours or a few days of validity remaining. These short, effective expirations serve a purpose.
They help to avoid the scenario where one of the links in the cryptographic chain suffers a distribution outage, i.e., the rsync or rrdp server goes offline, preventing the retrieval of fresh information. The result would be that ROAs remain stuck in their last state.
If a misconfigured ROA had contributed to the outage, then it would require manual intervention to clear. In this scenario, the distribution outage would prevent use of the CRL to revoke a problematic ROA.
With short expirations, the misconfigured ROA will eventually expire automatically, potentially clearing the internet forwarding-path to the ROAs publication point.
Reissuance happens well before expiration
Issuers of ROAs, Manifests, CRLs, and Certificates do not idly wait around for the cryptographically signed product to expire before issuing a new version.
As an example schedule, some issuers might resign their Manifest and CRL every hour with an expiry moment eight hours into the future, and in doing so assert the data is good for another eight hours. Frequent re-issuance helps overcome transient network issues between the ROA publication point and RPKI validators deployed in ISPs’ networks.
RPKI validators will either use locally cached versions of objects until such time they become invalid, or can be replaced by successor objects from a successful synchronization with the publication point.
This behavior is analogous to DNS time-to-live (TTL) settings. Short TTLs allow DNS operators to quickly redistribute traffic when the need arises, or to ensure that a DNS record is flushed from caches to prevent an out-of-date record to direct traffic.
Analyzing the internet’s effective ROA expirations
Using rpkiviews.org, we can take a recent snapshot of the roughly 528,000 ROAs currently in use. In CSV format, the contents of a snapshot look like this:
The fifth and final column is the effective expiration dates in epoch format. If we group those timestamps into one-hour buckets and plot the counts over time, we arrive at the following graph for one snapshot, which reveals several peaks.
As the annotations show, each peak of ROA expirations corresponds to a different RIR. This visualization captures the effects of the differences in the cryptographic chains employed by each RIR.
But that was just one snapshot in time. To understand how these effective expirations change through time, let’s take a look at the animation below:
As mentioned earlier, each peak corresponds to a different RIR, and the manner in which it evolves over time depends on the software used to manage the ROAs.
Since it is hard to analyze a moving target, let’s look at a static plot of those effective expirations through time when the ROAs. In the graphs below, the x-axis is the time of the snapshot and the y-axis are the peaks of effective expirations, colored by RIR.
The graph below depicts how ROA effective expirations (y-axis) change through time (x-axis). Expirations rounded to the previous 15-minute mark. To aid in interpretation, we have marked two points in the chart (A and B). They both represent ROAs published by RIPE (blue) that expire at 23:00 UTC on April 13, 2024 (y-axis). Point A represents 2,165 ROAs with that expiration, while point B represents 15,852 ROAs and is drawn darker to reflect the larger amount of ROAs.
Point A
Point B
RIR
RIPE (blue)
RIPE (blue)
Snapshot
2024-04-10 22:56:22
2024-04-11 07:12:18
Expiration
2024-04-13 23:00:00
2024-04-13 23:00:00
Count
2,165
15,852
If we redraw the graph over several days, we can visualize how effective expirations of ROAs change over time. Each RIR exhibits its own renewal behavior based on the different software in use.
Let’s analyze a couple of these separately.
ARIN
When we isolate the effective expirations of the ROAs published by ARIN, we find two distinct behaviors. The first is a smaller (faint) population of expirations that are spread out from 8 to 24 hours in the future. In this group, the expirations are pushed out to 24 hours in the future when they approach 8 hours in the future.
The second consists of a larger population of expirations exhibiting a staircase shape. In this group, when expirations approach 24 hours in the future, they are all renewed with expirations which range from 24 to 48 hours in the future. The renewals continue as expirations approach 24 hours in the future, but never exceed the previous upper time limit creating the stair. The upper time limit for the expiration resets every 48 hours.
RIPE
Unlike ARIN, RIPE’s effective expirations are updated to a time between 8 and 18 hours in the future as they get within 8 hours of current time. RIPE expirations are never more than 24 hours into the future. This creates a tighter distribution, illustrated in the graphic below.
APNIC
The effective expirations of APNIC ROAs fall into two categories. A small number of expirations (faint lower band) are spread out from 8 to 24 hours in the future. Like the lower faint band for ARIN, these expirations are pushed out to 24 hours in the future when they approach 8 hours in the future.
Otherwise, the majority of the ROAs published by APNIC have the longest effective expirations of any RIR. They are at least five days in the future. As expirations reach five days out, they are updated to be six days out.
LACNIC
In the first half of April, the effective expirations of LACNIC’s ROAs exhibited similar behavior to RIPE, but on April 15, LACNIC changed to use Krill as an RPKI management software. After April 15, the expirations began to resemble ARINs’ 48-hour staircase shape.
AFRINIC
As AFRINIC effective expirations approach 24 hours into the future from current time, they are renewed an additional 24 hours into the future. For most ROAs, this update occurs every day at midnight UTC.
Conclusions
As you likely already know, RPKI ROV continues to be the best defense against accidental BGP hijacks and origination leaks that have been the source of numerous disruptions. Most recently, this technology celebrated a major milestone when the percentage of IPv4 routes in the global routing table with ROAs surpassed 50% on May 1, 2024 (IPv6 achieved this last year).
ROV relies on a cryptographic chain to accurately convey the information contained in the ROAs to the validators which do the work of evaluating BGP announcements as they come in. As a result, there are two expirations for ROAs to be mindful of. There is the expiration set in the ROA itself, but there is also the expiration, as seen from the validator, something we call the effective expiration, derived from the shortest expiration along the chain. Both expiration types can be monitored with open source tools such as BGPAlerter.
These short effective expirations (often only hours away) are a feature, preventing validators from getting stuck with out-of-date information in the case of an outage. What is fascinating is the difference between how each RIR handles these expirations, ranging from just hours away (RIPE) to days away (APNIC).
