NLnet Labs recently launched their first version of JDR, a tool for checking anything in the Resource Public Key Infrastructure (RPKI). While not yet 100% feature complete, JDR offers useful insights to operators and implementors. In this article, I’ll talk about the mechanics and goals of the tool and call for feedback to help guide its further development!
The what and why
Working with RPKI can be quite a complex endeavour. Implementing Relying Party (RP) or Certificate Authority (CA) software requires knowledge and understanding of a significant number of RFCs. The end user deploying and running such software is usually spared this deep-dive into the land of standards. That is, as long as everything works as expected.
Once things do not work as expected, finding the cause can be challenging as there are so many (moving) parts involved. The RPKI is a distributed repository with possible delegations containing objects created with different pieces of software, transported via one of several ways, and interpreted by a plethora of libraries and software. And while most software will try to offer concise logging to the user in case of any unexpected situation or error, troubleshooting is seldom a focus for this software.
Read: RPKIVIZ: Visualizing the RPKI
Enter JDR. Just like RP software, JDR interprets certificates and signed objects in the RPKI, but instead of producing a set of Verified ROA Payloads (VRPs) to be fed to a router, it annotates everything that could somehow cause trouble. It will go out of its way to try to decode and parse objects. Even if a file is clearly violating the standards and should be rejected by RP software, JDR will try to process it and present as much troubleshooting information to the end user afterwards.
To accommodate for such flexibility and verbosity, we developed an ASN.1 decoder and parser allowing us to annotate files on the ASN.1 tag level. As seen in the screenshot below (Figure 1), it will annotate tags that are incorrect for whatever reason. That could be an encoding issue (as of this moment, all objects in the RPKI must be DER encoded), or something not in line with any of the many RFCs (X.509 or RPKI-specific). Moreover, tags get their definition name attached to them, so users can quickly jump to the encapContentInfo, for example.
The hosted tool is built around this core part. Every 10 minutes, the RPKI repository is fetched, and all files are processed. The web interface then allows exploration of the processed data by searching for resources, or via the repository overview.
Search for resources
Using the input box on top of the search page, users can search for ASNs and IP prefixes that appear on Resource Origin Authorizations (ROAs). Any matching ROAs will be presented in a graphical tree (Figure 2) showing the path from the Regional Internet Registry (RIR) to ROA, offering the possibility to check all the intermediate files (certificates and manifests) in detail. By clicking on the nodes/filenames in the graph, the detail view will show object related information and the annotated ASN.1 tree.
In addition to searching for resources, users can search on (part of) a filename directly. This is useful when your RP software complains about a specific file but you are not sure what is wrong.
Explore RPKI delegations and troubleshoot errors at a glance
To see if anything is wrong somewhere in the distributed repository at a glance, or to simply explore RPKI delegations, the repository overview page (Figure 3) offers a graphical tree representation from the five RIRs to all delegations. Some nodes may show a red number, indicating problems in that repository itself, or in any of its children.
Icons next to the nodes may indicate possible problems on the network level, based on continuous RIPE Atlas-based measurements. Below the graph an overview of the more severe problems per repository is listed. Note that this overview does not include all the (non-breaking) ASN.1 issues the library annotates.
While the repository overview and the resource search page are the only ways to navigate through the processed data, we hope most of what you’re looking for can be found. But if not…
What’s next in JDR?
I’ve mentioned this tool is not yet feature complete, but by presenting it I hope the community can help us at NLnet Labs extend and prioritize our wish list and roadmap. Two things on that list that are currently being implemented are:
- Time-related validity checks (is this object already valid, or perhaps passed its due date?).
- Revocation checks (is this certificate listed on a valid CRL?).
It’s important to reiterate and emphasize that JDR does not reflect the actual set of valid VRPs that you should feed to your routers, not only because of missing validity checks, but because the main goal of JDR is to provide information on mishaps instead of hiding them.
Another feature on the wish list is RPKI Repository Delta Protocol (RRDP) support. Currently, the RPKI repositories are synced using rsync, but maintaining a copy via RRDP enables comparisons between the two and will add another dimension of troubleshooting insights.
Beside what we can come up with ourselves, we’d like to hear what you think is crucial in a tool like this. Whether it’s a missing validity check, a specific form of diagnostics, or a way to improve navigation in the interface, please let us know and help use make JDR as valuable for the community as possible. Bugs and feature requests can go in the GitHub repo, or feel free to reach out on the RPKI mailing list for other types of discussions.
Soon: JDR.jl, the underlying library
If you’ve checked the name of the GitHub repository, you might wonder why it is named JDR-web. This is to distinguish the web-based version of the tool, as presented in this blog post, from the underlying library powering it.
That library, JDR.jl, will be published in the near future as well. Developed in the Julia language, it allows operators to do interactive troubleshooting in their terminals, researchers to do iterative data exploration in notebooks such as Jupyter Lab, and likely even more cool use cases. More on that soon!
This work is partly funded by the 2019 RIPE NCC Community Projects Fund. We would like to thank the RIPE NCC for enabling us to realize this idea, and to hopefully see it flourish into a worthwhile addition to the RPKI ecosystem in the coming years.
Adapted from original post which appeared on NLnet Labs Blog.
Luuk Hendriks is a research engineer at NLnet Labs, focusing on measurements and analyses of core Internet protocols.
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.