ROA adoption barriers to practical planning tools: Reflections from ARIN 57

Beginning in October 2025, CAIDA and Internet2 - with support from the National Science Foundation (NSF) (award number OAC-2530871) - began developing a set of tools to help network operators improve routing security and better understand their routing policy. These efforts are focused primarily on the needs of the research and education ecosystem, but several of the tools can help network operators more broadly.

I recently had the opportunity to present this work at ARIN 57, ARIN's Public Policy and Members Meeting, in a keynote session on Demystifying RPKI: Exploring Tools to Simplify ROA Planning and Visualize Validation.

This was my second time presenting at ARIN. Two years earlier, at ARIN 52, I delivered a keynote on barriers to Resource Public Key Infrastructure (RPKI) Route Origin Authorization (ROA) adoption in the United States research and education community. It was gratifying to return to ARIN 57 to demonstrate tools we have since developed to help lower those barriers.

ROAs are created infrequently

Over the last five years, through my role at Internet2, I have worked with many community members to help them plan their RPKI ROAs. Internet2 had developed internal tools to support that work and to help us provide guidance on ROA requirements, but we had not yet built a user-facing tool.

In working with operators over that period, a consistent pattern emerged: Even those with solid BGP knowledge tend to create ROAs infrequently, and so don't develop deep familiarity with how they behave. As a result, there is often confusion around how ROAs are evaluated, particularly in cases such as covering prefixes and max length. These are not concepts operators encounter regularly in day-to-day routing operations, which makes careful planning essential.

Now, through the NSF-funded Routing Operations Observational Technology: Building to Enable Education and Research (ROOTBEER) project, CAIDA and Internet2 have taken what we have learned from those years of ROA-planning assistance and turned it into a tool that helps operators better understand the factors they should consider when creating ROAs.

Identifying potential route announcements to accommodate

The RPKI ROA Planner gathers historical and current routing data from RIPEstat and RouteViews, along with IRR route objects, to identify potential route announcements that a ROA may need to accommodate. During my ARIN presentation, I described how this additional context can make the ROA planning process easier and less error-prone.

One of the recurring challenges we observed is that operators are often working with incomplete or overly narrow views of their routing activity. Deciding which historical announcements to account for is not straightforward - for example, whether to include older or infrequent announcements - and different choices can materially affect the resulting ROAs. The ROA Planner exposes this data and allows operators to selectively include or exclude it, helping them make more informed decisions about what should be covered.

There are many situations where the currently observed Internet route may not represent every way a network's IP address space is announced. Networks may host special events, use off-site backup facilities, or employ services such as Distributed Denial-of-Service (DDoS) scrubbing, all of which can result in intermittent route announcements. A ROA based only on the currently visible route could unintentionally cause those announcements to be evaluated as RPKI Invalid. The ROA Planner gathers additional information to bring these possibilities to the operator's attention.

Guidance, not ground truth

In practice, these challenges are compounded by the fact that ROA evaluation does not always align with operators' intuition from longest-prefix match routing. For example, a covering ROA may still result in Invalid outcomes if max length is not set appropriately. This makes it easy to create ROAs that appear correct at first glance but behave unexpectedly once deployed.

The ROA Planner also helps guide the creation process itself. For instance, when presented with candidate ROAs, it can indicate a logical order in which they should be created. It also helps highlight less suitable starting points - such as creating a ROA that only covers an aggregate prefix while leaving more specific announcements invalid - prompting operators to refine their approach before deployment.

As I noted during the presentation, the RPKI ROA Planner is not foolproof. But it does collect relevant information in one place, helping operators reduce the risk of creating ROAs that are not fit for purpose.

As with any tooling based on observed data, its output should be treated as guidance rather than ground truth. It is still important for operators to validate the results against their own knowledge of their network, particularly as unusual announcements or incomplete data can lead to misleading conclusions. The goal is not to automate ROA creation, but to enable better-informed decisions.

Routing security planning tools for the operator community

In addition to the ROA Planner, I also demonstrated the Partial RPKI ASPA Planner. The ASPA Planner uses routing information from RIPEstat and Autonomous System relationship data from CAIDA to help operators identify likely service providers. It is a 'partial' planner because it has known limitations: accurately determining service-provider relationships is not possible for every network. In our experience, the ASPA Planner works reasonably well for networks near or at the edge of the Internet, where provider relationships are often simpler.

While ROOTBEER is focused on the research and education community, we believe some of the lessons and tools may be useful to the broader operator community as RPKI and ASPA deployment continue to mature. All the tools developed through the ROOTBEER project are available online.

Steven Wallace has been an active member of the advanced network community for over 30 years and currently serves as Director of Routing Integrity at Internet2

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.