Resource Public Key Infrastructure (RPKI) FAQs & Best Practices

Skip to main text Jump to related content

Effective 29 September 2022, ARIN changed how it manages the ARIN Trust Anchor Locator (TAL). Please see our announcement for more information.

What is a Public Key Infrastructure?

A Public Key Infrastructure (PKI) is centered around creating, managing, distributing, using, storing, and revoking digital certificates.

What is a resource?

In the context of RPKI, a resource is a grouping of Internet Protocol (IP) addresses or Autonomous Systems Numbers (ASNs) that uniquely identify a computer or a network on the Internet. Routers use these numbers much like the post office uses addresses to help route mail to recipients.

What if our organization doesn’t have a public ASN assigned?

If your organization doesn’t have a public ASN assigned, your routing announcements are being handled by your upstream provider. You can sign up for Hosted RPKI services and create ROAs for your IP resources using your provider’s ASN as the Origin AS.

What is a resource certificate?

A resource certificate is an electronic file that serves as proof that a resource has been assigned to an individual or company for their use. These certificates list a collection of Internet Number Resources (IPv4 addresses, IPv6 addresses, and ASNs) that are associated with a holder of those resources. Resource certificates provide a means of third-party validation of assertions related to resource allocations using proven cryptographic algorithms. These certificates contain no identifying information about who the holder of the resources is; resource holders can prove their legitimacy using their private key to sign information such as a Route Origin Authorization (ROA) request. Relying Parties can then validate these signed objects with the corresponding public key.

What is the lifespan of an RPKI Resource Certificate?

At ARIN, RPKI Resource Certificates are set with a two-year lifespan, and they auto-renew after one year, resetting the two-year lifespan.

What is a Certificate Authority?

A Certificate Authority (CA) is an entity that issues digital certificates. ARIN currently acts as a CA for its Hosted RPKI service, issuing resource certificates for Internet Number Resources (INRs) within the ARIN region. In delegated RPKI, entities with IP addresses and Autonomous System Numbers assigned directly from ARIN are the CA to their customers.

What is a Resource Trust Anchor?

An Resource Trust Anchor (RTA) is a self-signed digital certificate containing ARIN’s public key. This certificate is downloaded by Relying Parties wishing to retrieve information from ARIN’s RPKI repository, and used to verify its validity. Before re-syncing information from ARIN’s RPKI repository, a Relying Party should:

  • Retrieve the object referenced by the URL contained in the Trust Anchor Locator (TAL)
  • Confirm that the retrieved object is a current, self-signed RPKI certificate
  • Confirm that the public key in the TAL matches the public key in the retrieved object
  • Perform other checks locally, as deemed appropriate, to ensure that you are willing to accept the entity publishing this self-signed certificate to be a trust anchor

Note: This certificate is updated when ARIN’s resource set changes.

What is a Trust Anchor Locator?

In the context of RPKI, the Trust Anchor Locator (TAL) is a file used to allow Relying Parties to retrieve the data within ARIN’s RPKI validator (via rsync or RRDP) and base routing decisions upon that data. ARIN’s TAL contains two things:

  • The URL of ARIN’s published RPKI repository
  • ARIN’s Privacy Enhanced Mail (PEM) encoded public key

Access ARIN’s TAL.

What is a repository?

Repository refers to the digital listing in which ARIN publishes ROAs, resource certificates, Certificate Revocation Lists (CRLs), and manifests. This repository is available to be downloaded via rsync or RPKI Repository Delta Protocol (RRDP), and may be automatically fetched using a validator. Relying Parties may use this data to make more informed decisions about how they route to various locations on the Internet. Relying Parties wishing to access ARIN’s RPKI repository will need to download ARIN’s TAL.

What is a manifest?

In the context of RPKI, a manifest is a signed object containing a listing of all the signed files in a CA’s RPKI repository. Manifests contain a filename and a hash of file content for each resource certificate, and the CRL, or other signed object published in the repository. Manifests allow a Relying Party (RP) to detect certain forms of attacks against their RPKI repository.

What is a Certification Revocation List?

In the context of PKIs, a Certification Revocation List (CRL) is a list of resource certificates that have been revoked, and should not be relied upon. ARIN publishes its CRL for hosted RPKI within its RPKI repository every 24 hours. A CRL is always issued by the CA that issues the corresponding certificates. A delegated RPKI participant must publish its own CRL inside the repository located at the Production Uniform Resource Identifier (URI) provided to ARIN.

Are there any constraints for Certification Revocation Lists?

Note: This applies to hosted RPKI.

The system’s Hardware Security Modules (HSMs) limit the number of revocations per organization at a given point in time to 20,000. In practical terms, this limitation means that you cannot delete more than 20,000 ROAs, as each time a ROA is deleted, a revocation is added to the CRL for that organization.

What is a Route Origin Authorization?

A Route Origin Authorization (ROA) is a cryptographically signed object that states which Autonomous System (AS) is authorized to originate a particular prefix or set of prefixes. ROAs may only be generated for Internet Number Resources listed on your resource certificate. A ROA is composed of:

  • An Origin AS
  • A prefix and max length
  • A ROA name (optional)

What is the lifespan of a ROA?

RPKI Route Origin Authorizations are created with a 90-day lifespan. They auto-renew after 80 days, resetting the 90-day lifespan.

What is Relying Party software?

Relying Party (RP) software (otherwise known as a ‘validator’) is a program used to fetch ARIN’s RPKI repository data, validate its contents, and store the information in its cache. This data can be used by network operators to make more informed routing decisions.

We provide a list of validators that ARIN has tested and that you can use.

What is a Hardware Security Module?

A Hardware Security Module (HSM) is a secure cryptographic processor that manages digital keys and certificates used in ARIN’s RPKI as well as other forms of public key cryptography.

Does ARIN have plans to require resource holders to use RPKI?

There is no ARIN policy that requires the use of RPKI. RPKI is an opt-in feature with ARIN. However, a growing number of service providers require you to make ROAs for your resources before finalizing a business agreement.

Which RPKI model is right for me?

Hosted RPKI

Hosted RPKI: Easiest to use; Recommended for most organizations just getting started with RPKI. Nearly 98% of ARIN RPKI participants use Hosted RPKI.

Delegated RPKI

Delegated RPKI: Highest responsibility and uptime requirement; Only for organizations with an in-depth knowledge of RPKI and resources to run a Certificate Authority (CA) and a publication server, or other have other individual needs.

Hybrid RPKI

ARIN Publication Service - ‘Hybrid’ RPKI: Suggested for use if your organization wishes to keep control of the Certificate Authority (CA) but decides to not maintain a repository and run the publication server.

How do I access my resource certificate once it has been generated?

Once a resource certificate has been generated for you, you can access it from ARIN Online.

Is the customer responsible for maintaining the certificate?

If a customer is using ARIN’s Hosted RPKI product, ARIN will automatically renew the existing hosted certificate. Existing ROAs are not impacted by this renewal.

If a customer is using ARIN’s Delegated RPKI product, the customer is directly responsible for rolling the certificate using the UP/DOWN protocol. Their ROAs will behave similarly with respect to the renewed certificate.

Do Re-rolls on an RPKI certificate extend the certificate’s expiration date?

No, it only changes the resources listed on the certificate.

What is a Route Origin Authorization Request?

A Route Origin Authorization (ROA) Request is a request for ARIN to generate a ROA for you.

After providing the required information, this request is then submitted to ARIN. ARIN will generate and publish the ROA to ARIN’s RPKI repository.

Note: Once an RPKI user has received a resource certificate from ARIN, ROA Requests may be submitted either through ARIN Online or programmatically via REST.

If I create a new ROA, when will it be published?

When ROAs are created, they are put into the repository immediately. The ARIN repository is published every five minutes.

All of the components in the RPKI ecosystem have different timers associated with them. Users should expect it to take between 30 and 60 minutes after the ROA is generated before their ROA impacts routing on the Internet.

If I remove a ROA, will all ROAs with the same name will be removed?

No. When using the ARIN Online interface, only one ROA can be removed at a time.

The ARIN API requires a unique identifier (“ROA Handle”) to remove a ROA. Refer to the ARIN RESTful Methods documentation for additional details.

Can I create a duplicate ROA?

No. ARIN’s auto-renew process deprecated the need for duplicate ROAs. Likewise, ROAs can no longer overlap.

For example, an existing ROA containing a /16 prefix and a maxLength of a /24 will prevent the creation of another ROA with any prefix within that /16 block and the same Origin AS.

How do I know if my ROAs are set to auto-renew?

To confirm your ROAs are set to auto-renew:

  1. Select Routing Security in the left-hand navigation menu in ARIN Online.
  2. Select Manage RPKI for an eligible Org ID.
  3. Select the ROAs tab.
  4. Select the Manage ROA button.
  5. Confirm Auto-renewing is ‘Yes’ in the ROA Details table.

Note: All ROAs created using ARIN Online after the feature release on 13 May 2023 are set to auto-renew. All ROAs in the RPKI repository created using ARIN Online were converted to auto-renew.

I used ARIN’s API instead of ARIN Online to create my ROAs. Do my ROAs still auto-renew?

ROAs created using the API call released on 13 May 2023 will auto-renew

ROAs created with the legacy API released in 2014 do not auto-renew. You must create new ROAs using the ARIN Online interface or the current API to take advantage of the auto-renew feature.

Can I remove multiple ROAs at the same time?

Yes, by using the new RESTful interface via Reg-RWS. This functionality is not available in the ARIN Online web interface.

Is there a limit on the number of ROAs I can create?

We have tested up to 100,000 ROAs per organization without issue.

How do I originate my resources out of multiple Autonomous Systems?

Each Route Origin Authorization (ROA) includes exactly one Origin AS number. Individual ROAs are necessary to authorize multiple Origin ASNs.

How do I confirm that a recently acquired number resource has been added to my organization’s RPKI resource certificate?

To confirm that your number resources have been added to your RPKI certificate:

  1. Select Routing Security from the left-hand menu on ARIN Online.
  2. Select Manage RPKI for the net resource’s Org ID.
  3. Select Certified Resources.

The RPKI: Certified Resources page lists all ASN and net resources covered by your organization’s RPKI certificate. If you find a resource is missing, open an Ask ARIN ticket for assistance.

How can I test RPKI without affecting my production data?

ARIN has implemented an RPKI instance within its Operational Test and Evaluation (OT&E) environment, which offers the opportunity to experiment with different facets of RPKI and ROA Requests in an environment with a production-like repository and UI, without any impact on production data.

I want to transfer Internet Number Resources currently covered under an ARIN RPKI certificate to another party. What do I need to do to prepare for this?

Upon completion of a transfer, any Internet Number Resources being transferred to another organization will be removed from the current ARIN RPKI certificate along with any ROAs associated with those resources. Any remaining Internet Number Resources will be automatically rerolled and their associated ROAs retained.

However, if you are the Recipient of a transfer of Internet Number Resources, and you have an ARIN RPKI certificate issued by ARIN, you will need to submit an Ask ARIN ticket and let us know you’d like the newly transferred Internet Number Resources to be certified.

If I transfer all of my Internet Number Resources that are under agreement, what consequences are there?

If you transfer the entirety of your Internet Number Resources (all IPs and all ASNs) out of your organization, your current RPKI certificate will be removed. After your certificate is removed, any ROAs referencing those resources will be deleted from the RPKI repository. If you acquire new Internet Number Resources in the future, you will have to begin the process of signing up for and setting up RPKI to cover the new resources.

How do I change between a hosted and delegated RPKI deployment?

If your want to change your organization’s RPKI deployment between hosted and delegated, you must contact ARIN’s Registration Services Department for assistance.

Registration Services
Hours: 7 AM to 7 PM ET
Phone: +1.703.227.0660
Fax: +1.703.997.8844
Tips for Calling the Registration Services Help Desk
To open a ticket, visit Ask Arin in your ARIN Online account

What is a Certification Practice Statement?

A Certification Practice Statement (CPS) is a document that explains certificate policies and Certification Authority CA operational procedures. ARIN has published a CPS describing the practices of the ARIN Certificate Authority. The CPS describes the participants, certificate types, processes, and management within ARIN’s RPKI, as well as related business and legal issues. This document may be accessed here.

What is ARIN’s Relying Party Agreement?

ARIN’s Relying Party Agreement (RPA) comprises a set of terms and restrictions applicable to any entity wishing to utilize ARIN’s RPKI services.

Access the RPA.

Which Internet Engineering Task Force (IETF) Requests for Comments (RFCs) relate to RPKI?

To learn more about RPKIs functions and origin, ARIN recommends reading the following RFCs:

To learn more about delegated RPKI requirements, such as URIs, manifests and CRLs, ARIN recommends reading the following RFCs:

What Best Practices does ARIN suggest for RPKI Management?


Best Practices

Limit the number of prefixes you enter into a single Route Origin Authorization (ROA).

If you create a ROA with multiple prefixes, they all share the same fate. If there are changes in your resources, and the ROA includes prefixes involved in an outbound transfer, the ROA will fail the cryptographic check and will be removed from the RPKI repository. This could lead to multiple prefixes being marked as RPKI invalid, potentially causing a detrimental impact on your connectivity.

More information can be found in RFC 9455: Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes

Limit the use of the maxLength variables in Your ROAs.

If you create a ROA for a /16 block with a maxLength of /24, you are indicating that every potential prefix from the aggregate /16 down to the longest matching /24 originating from the specified AS should be treated as authentic. This includes 511 prefixes: all /24s, all /23s, all /22s, and so on. Liberal use of maxLength in ROAs exposes you to a Forged-Origin sub-Prefix Hijack.

More information can be found in RFC 9319: The Use of maxLength in the Resource Public Key Infrastructure (RPKI).

Create exact matching ROAs for prefixes announced to the Internet, nothing more.

If you have a /16 of IPv4 space or a /32 of IPv6 space, chances are you are not announcing every /24 or /48 subnet. Creating ROAs that exactly match your announcements should reduce the number of ROAs you create, which not only saves time but also limits your exposure to hijacks resulting from misconfiguration or nefarious announcements.

Create ROAs for the most specific prefixes first, and work back to your aggregates.

Suppose you are announcing a /16 aggregate and a subset of /24s within the aggregate block. If you create a ROA for only the /16 aggregate, all the /24 announcements will be marked as RPKI invalid. In other words, go backwards (/24, /23, /22, …, /16).