Network operators expect Resource Public Key Infrastructure (RPKI) cryptographic software to be secure by default. Even though this has not always been the case, 2020 has seen a number of improvements in the RPKI software ecosystem.
Before getting to these, I want to remind you to upgrade to the latest version of your favourite RPKI client.
The issue with securing RPKI
RPKI validators periodically fetch fresh RPKI data via the Internet. It doesn’t matter which fetch protocol is being used because RPKI security relies solely on the concept of X.509 Object Security.
Each file in the RPKI contains one object. This begs the question: how do you know whether files are missing to begin with? After all, missing .roa files might be part of an orchestrated malicious attack scenario, or more innocent causes such as when a CA operator makes a mistake. For example in April 2020, one RIR inadvertently deleted ~ 2,600 .roa files from their publication point. Whatever the reason for the absence of .roa files, a validator has to safeguard the operator.
It is important to realize any party ‘in the middle (be it a Content Delivery Network (CDN), or an attacker impersonating a publication point) can easily end up hiding Route Origin Authorization (ROA) files. Neither the rsync protocol nor the RPKI Repository Delta Protocol (RRDP) have authentication built-in.
When it comes to X.509 validation, it’s important for software to confirm whether all RPKI certificates and files are accounted for (present), current (not expired), and valid (not malformed). When RPKI information is expired and/or incomplete, the data is unsuitable to be used in Border Gateway Protocol (BGP) routing decision making.
A X.509 framework by itself does not have any kind of catalogue feature to establish whether a bundle of objects is a complete set. To overcome this, the RPKI technology stack has a core component called ‘manifests’ (RFC 6486), which allows validation software to detect and react sanely to RPKI data integrity issues.
How do manifests work?
The idea of using manifests in RPKI works in a similar way as they do in international cargo shipping: where the receiver of the goods also receives a list (manifest), detailing all sent items and their quantities, thus allowing them to inspect whether the sender forgot to include something, or if some of the goods were lost or stolen in transit. Where shipping manifests are signed using ink and stamps, in RPKI they are signed with cryptographic signatures.
Every RPKI manifest exists to protect both IP resource holders as the issuing Certificate Authority (CA), and the consumer of RPKI information (the Relying Party (RP). Manifests combined with strict X.509 handling are the only mechanisms to verify a publication point’s completeness and integrity.
The data structure of ROAs allow only a single-origin ASN per .roa file. Here’s an example of a decoded .roa file (APNIC’s own IP space!). This means network operators who wish to grant permission to originate parts of a prefix to multiple ASNs, have to create multiple separate .roa files — each .roa file will reference one ASN. As such, the IP block resource holder’s routing intentions can only be considered when the full bundle of .roa files is available.
If one or more .roa files are missing, authorization for one or more more-specific customer prefixes may be lacking, causing such prefixes to become RPKI invalid and, consequently, be rejected on all major EBGP borders.
Logically, when an RPKI validator detects that one or more .roa files are missing (which according to a valid current manifest should be present), the remaining .roa files at the publication point become useless as they represent an incomplete overview of routing intentions. Even worse, those files morph from useless to dangerous when they are injected as Validated ROA Payloads (VRPs) into the operator’s routing system: destinations in the Default-Free Zone could become unreachable!
Upgrade your validator!
As of the moment of writing, all widely-used RPKI validators have released improved versions of their software.
How fast can the industry react?
Feb 2020 — real-world examples shared through SIDROPS
Mar 2020 — First responder, OpenBSD, patches rpki-client 6.6
May 2020 — NIC.MX releases FORT 1.2.1
Oct 2020 — NLNetLabs releases Routinator 0.8.0
Oct 2020 — RIPE NCC releases RPKI Validator 3.2
Oct 2020 — Cloudflare releases OctoRPKI 1.2.0
All validators now confirm whether all files listed on an RPKI manifest are accounted for; if anything is missing the RPKI publication point is considered untrusted and related BGP routes will be marked as not-found. This behaviour improves the robustness of RPKI in the global Internet routing system.
In short: upgrade to the latest version of your favourite RPKI client now for smooth sailing!
Adapted from original post that appeared on sobornost.net.
Job Snijders is an IP Development Engineer at NTT.
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.