Introducing JDR: Explore, Inspect and Troubleshoot the RPKI

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 these softwares.

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.

Go to JDR

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 can be seen in the screenshot below, 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 (X509 or RPKI-specific). Moreover, tags get their definition name attached to them, so one 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, one can search for AS numbers and IP prefixes that appear on ROAs. Any matching ROAs will be presented in a graphical tree showing the path from 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, one can search on (part of) a filename directly. This can be useful when your RP software complains about a specific file but you are not sure what is wrong with it.

The Repository Overview

To see if anything is wrong somewhere in the distributed repository at a glance, or to simply explore RPKI delegations, the repository overview page 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 might be looking for can be found. But if not ...

What's Next in JDR?

We mentioned this tool is not yet feature complete, but by presenting it we hope the community can help us extend and prioritise 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?) and revocation checks (is this certificate listed on a valid CRL?). It's good to reiterate and emphasise that JDR does not reflect what the actual set of valid VRPs is that you should feed to your routers: not only because of such missing validity checks, but moreover because the main goal of JDR is to provide info on mishaps instead of hiding them.

Another feature on the wish-list is RRDP support. Currently, the RPKI repositories are synced using rsync, but maintaining a copy via RRDP enables for comparisons between the two and will add another dimension of troubleshooting insights.

But besides 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!

Thank You RIPE NCC!

This work is partly funded by the RIPE NCC Community Projects Fund of 2019. We would like to thank the RIPE NCC for enabling us to realise this idea, and to hopefully see it flourish into a worthwhile addition to the RPKI ecosystem in the coming years.

_______

This article was originally published on the NLnet Labs blog on 18 November 2020.