RPKI Best Practices and Lessons Learned

RPKI Best Practices and Lessons Learned

By Sofía Silva Berenguer - RPKI Program Manager, NRO

This blog post is the sixth installment in the NRO RPKI Program series. Read the previous posts here. This post was originally published by the NRO.

This document describes Resource Public Key Infrastructure-related best practices and lessons learned. It provides general recommendations aimed at supporting the implementation and operation of RPKI in diverse environments.

These insights are drawn from practical experience and collaborative discussions but are not intended to be prescriptive. Operators and stakeholders should adapt the guidance according to their specific technical, organizational, and policy contexts.

The recommendations presented here should be viewed as a starting point for informed decision-making rather than a definitive or one-size-fits-all approach.

Best Practices for Route Origin Authorization (ROA) Creation

Ready to enable RPKI for your organization and wondering whether you should select Hosted RPKI or Delegated RPKI?

If you're just getting started with RPKI, use Hosted RPKI.

Using Delegated RPKI?

If you are using Delegated RPKI (sometimes called self-hosted), it is highly recommended to use an RPKI publication server provided by your parent Certification Authority (CA), if available, to simplify operations.

Note: Publication as a service is available to Members of ARIN, APNIC, and the RIPE NCC.

What prefixes should I create ROAs for?

Ideally, you should create ROAs that exactly match what you are announcing in the Border Gateway Protocol (BGP) and nothing more (see the ARIN RPKI FAQ, RIPE MANRS Implementation Guide, and APNIC Academy RPKI Deployment training).

However, there may be circumstances in which it is necessary to create ROAs for space that is not currently visible on the BGP. For instance, black-holing services for mitigation of Distributed Denial of Service (DDoS) attacks may require the creation of specific ROAs that may not match what you are announcing in the BGP.

What value should I enter in the maxLength field?

maxLength is an optional field in a ROA that represents the maximum length of the IP prefix that the origin Autonomous System (AS) is authorized to advertise.

Ideally, you should use a maxLength value that will make the ROA being created cover the prefixes announced in the BGP and nothing more. The use of maxLength is considered harmful if you don't also announce each most specific prefix thus allowed. Liberal use of maxLength in ROAs exposes you to a forged-origin sub-prefix hijack.

See RFC 9319 for more information on the use of maxLength.

How should I create ROAs for overlapping prefixes?

If you are announcing overlapping prefixes in the BGP, you should create ROAs for the most specific prefixes first, and work back to your aggregates.

My organization does not have a public AS Number (ASN). Our prefixes are originated by our upstream provider.

If your prefixes are originated by your upstream provider, you can use hosted RPKI services and create ROAs using your upstream provider's ASN as the Origin AS.

How do I verify the impact of the ROA I just created?

After creating a ROA, it is recommended to verify that your prefixes have been properly signed and that no BGP routes have been invalidated. To do this, use a validator, NTT monitor, BGPmon, LACNIC's origin validation tool, or equivalent tool (see APNIC Academy RPKI Deployment training and the LACNIC RPKI FAQ).

Best Practices for Deploying Route Origin Validation (ROV)

How should I approach the deployment of ROV in my network?

If you are just getting started with ROV, you can begin cautiously by monitoring route validity statuses. Validate the BGP announcements from your customers against RPKI ROAs.

You can then start tagging BGP announcements, optionally modifying preference values, and start communicating to your customers that you will soon begin dropping invalid BGP announcements. Once you are confident enough about your set-up, you can start dropping invalids.

It's recommended to use multiple RPKI validators.

All routers that support ROV allow you to specify multiple RPKI validators for redundancy. It is recommended that you run multiple instances, preferably from independent publishers and on separate subnets. This way you rely on multiple caches (see APNIC Academy RPKI Deployment training, and the RPKI FAQ on ReadTheDocs).

AS0 ROAs for unallocated space.

Some Regional Internet Registries (RIRs) have AS0 Trust Anchors (TAs) for unallocated space (APNIC and LACNIC as of July 2025). It is strongly recommended that these TAs are used for advisory and/or alerting purposes only, and not for automatic filtering, due to potential risks.

See RFC 7115 for more information about how to deploy and operate ROV.

Share your feedback

The RPKI best practices and lessons learned described in this post have been consolidated from different sources. We welcome input from the technical community to help improve the relevance and clarity of this document. If you have any comments, questions, or suggestions, please don't hesitate to get in touch. You can share your feedback by emailing us at rpki_program [at] nro.net

Your contributions are valuable and will help ensure that future updates reflect a broad range of operational perspectives and evolving best practices.

Learn more about ARIN's RPKI services at arin.net/RPKI.

Any views, positions, statements, or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness, or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions, or errors contained in a guest blog post.

Recent blogs categorized under: RPKI

• ARIN Deep Dive: Live RPKI Training in Montreal
• Advancing RPKI: NRO RPKI Program in 2025 for Trust, Transparency, and User Experience
• The Invisible War: Why Securing the Internet Is Everyone's Responsibility
• The End of Origin AS Is Near