{"id":26334,"date":"2024-06-17T19:59:52","date_gmt":"2024-06-17T19:59:52","guid":{"rendered":"https:\/\/blog.lacnic.net\/?p=26334"},"modified":"2024-06-17T20:13:03","modified_gmt":"2024-06-17T20:13:03","slug":"times-up-how-rpki-roas-perpetually-are-about-to-expire","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/en\/times-up-how-rpki-roas-perpetually-are-about-to-expire\/","title":{"rendered":"Time\u2019s Up! How RPKI ROAs Perpetually Are About to Expire"},"content":{"rendered":"\n

Written by Doug Madory<\/strong><\/a>  &  Job Snijders<\/strong><\/a>,<\/p>\n\n\n\n

This was originally published on the <\/em>Kentik Blog<\/a><\/p>\n\n\n\n

Summary<\/h3>\n\n\n\n

In RPKI, determining when exactly a ROA expires is not a simple question. In this post, BGP experts Doug Madory and Fastly\u2019s 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.<\/p>\n\n\n\n

\n\n\n\n

In our previous collaboration on RPKI<\/a>, we celebrated the latest milestone of RPKI ROV (Route Origin Validation) adoption: passing the 50% mark on IPv4 routes with Route Origin Authorizations (ROA<\/a>). 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.<\/p>\n\n\n\n

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<\/a> which (among other things) states the validity window:<\/em> the timestamps after and before which the ROA is valid.<\/p>\n\n\n\n

While the expiration dates of individual ROAs might be a year away, the effective<\/em> 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.<\/p>\n\n\n

Additional reading:<\/div><\/div><\/div>
RPKI ROV Deployment Reaches Major Milestone<\/a><\/div><\/div><\/section>\n\n\n

How does this work?<\/h2>\n\n\n\n

To understand how this works, we need to dig into the \u201ccryptographically-signed\u201d part of the ROA mentioned at the beginning of this post.<\/p>\n\n\n\n

Using Job\u2019s rpki-client console utility<\/a>, we can investigate the ROA for 151.101.8.0\/22 which asserts AS54113 is authorized to originate this IPv4 prefix.<\/p>\n\n\n\n

asID: 54113\nIP address blocks: 151.101.8.0\/22 maxlen: 22<\/code><\/pre>\n\n\n\n
Also, in that first block are our first dates relating to when this ROA is valid.<\/p>\n\n\n\n
Signing time:             Sat 11 May 2024 01:00:27 +0000\nROA not before:           Sat 11 May 2024 01:00:27 +0000\nROA not after:            Fri 09 Aug 2024 01:00:27 +0000<\/code><\/pre>\n\n\n\n
Validation:               OK\nSignature path:           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\n                          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\n                          rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/5e4a23ea-e80a-403e-b08c-2171da2157d3\/871da40f-793a-4a45-a0a9-978148321a07\/e605f279-55f4-48ec-ba13-4845c0973a63.cer\n                          rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/5e4a23ea-e80a-403e-b08c-2171da2157d3\/871da40f-793a-4a45-a0a9-978148321a07\/871da40f-793a-4a45-a0a9-978148321a07.crl\n                          rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/5e4a23ea-e80a-403e-b08c-2171da2157d3\/871da40f-793a-4a45-a0a9-978148321a07\/871da40f-793a-4a45-a0a9-978148321a07.mft\n                          rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/5e4a23ea-e80a-403e-b08c-2171da2157d3\/871da40f-793a-4a45-a0a9-978148321a07.cer\n                          rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/5e4a23ea-e80a-403e-b08c-2171da2157d3\/5e4a23ea-e80a-403e-b08c-2171da2157d3.crl\n                          rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/5e4a23ea-e80a-403e-b08c-2171da2157d3\/5e4a23ea-e80a-403e-b08c-2171da2157d3.mft\n                          rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/5e4a23ea-e80a-403e-b08c-2171da2157d3.cer\n                          rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/arin-rpki-ta.crl\n                          rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/arin-rpki-ta.mft\n                          rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta.cer\nSignature path expires:   Fri 31 May 2024 14:00:00 +0000<\/code><\/pre>\n\n\n\n
The above Signature path<\/em> (also known as \u201cCertification path<\/a>\u201d) outlines the multi-step cryptographic signature validation process that it took to get from this ROA to the \u201cTrust Anchor\u201d (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.<\/p>\n\n\n\n
There are three different types of files conveniently linked by the console utility: Certificate Revocation Lists (.crl), Manifests (.mft), and Certificates (.cer).<\/p>\n\n\n\n
Glossary 

Manifests<\/em> securely declare the contents of a RPKI repository and reference the current CRL and ROAs. A given Manifest is valid until the \u201cnext Update\u201d 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<\/em> (\u201cCertificate 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\u2019s serial number to the CRL. A CRL is valid until the embedded \u201cnext Update\u201d time.

Certificates<\/em> are used to prove the validity of public keys. RPKI Certificates are defined using the X.509<\/a> standard. Each certificate contains its own validity window, a public key, pointers to the repository\u2019s 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\u2019s contents are protected with a cryptographic signature from an issuer higher up in the chain. In the RPKI, the \u201croot certificate\u201d is known as the Trust Anchor<\/em>. This is a self-signed certificate which can be validated using a Trust Anchor Locator<\/em>.<\/p>\n\n\n\n
By following the links, we can construct the following list of expirations on that signature path:<\/p>\n\n\n\n
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\n                          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\n                          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\n                          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\n                          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\n                          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\n                          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\n                          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\n                          Mon 04 May 2026 15:17:49 rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/5e4a23ea-e80a-403e-b08c-2171da2157d3.cer\n                          Mon 30 Sep 2024 15:17:49 rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/arin-rpki-ta.crl\n                          Mon 30 Sep 2024 15:17:49 rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta\/arin-rpki-ta.mft\n                          Mon 03 Nov 2025 rsync:\/\/rpki.arin.net\/repository\/arin-rpki-ta.cer\nSignature path expires:   Fri 31 May 2024 14:00:00 +0000<\/code><\/pre>\n\n\n\n
Why is it good to have ROAs perpetually about to expire?<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
With short expirations, the misconfigured ROA will eventually expire automatically, potentially clearing the internet forwarding-path to the ROAs publication point.<\/p>\n\n\n\n
<\/a>Reissuance happens well before expiration<\/h2>\n\n\n\n
Issuers of ROAs, Manifests, CRLs, and Certificates do not idly wait around for the cryptographically signed product to expire before issuing a new version.<\/p>\n\n\n\n
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\u2019 networks.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
<\/a>Analyzing the internet\u2019s effective ROA expirations<\/h2>\n\n\n\n
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:<\/p>\n\n\n\n
ASN,IP Prefix,Max Length,Trust Anchor,Expires\nAS13335,1.0.0.0\/24,24,apnic,1712499475\nAS38803,1.0.4.0\/24,24,apnic,1712532668\nAS38803,1.0.4.0\/22,22,apnic,1712532668\nAS38803,1.0.5.0\/24,24,apnic,1712532668\nAS38803,1.0.6.0\/24,24,apnic,1712532668\nAS38803,1.0.7.0\/24,24,apnic,1712532668\nAS18144,1.0.64.0\/18,18,apnic,1712358404\nAS13335,1.1.1.0\/24,24,apnic,1712499475\nAS4134,1.1.4.0\/22,22,apnic,1712508843<\/code><\/pre>\n\n\n\n
The fifth and final column is the effective expiration dates in epoch format<\/a>. 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.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
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.<\/p>\n\n\n\n
But that was just one snapshot in time. To understand how these effective expirations change through time, let\u2019s take a look at the animation below:<\/p>\n\n\n\n
\n