RPKI Frequently Asked Questions

Skip to main text Jump to related content

Effective 26 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 (PKI)?

A Public Key Infruatructure (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 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.

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

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

Why does ARIN only need my public key to create a resource certificate for me?

ARIN uses the organization and Internet number resource data linked to your ARIN Online account to create a certificate file as a convenience. The only information ARIN cannot automatically fill in is the public key of your ROA Request Generation Key Pair.

Is the customer responsible for maintaining the certificate?

If a customer is using ARIN’s Hosted RPKI product, ARIN staff is responsible for rerolling the existing hosted certificate. Existing ROAs are not impacted by this reroll.

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 rerolled certificate.

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

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

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

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] (https://www.arin.net/resources/manage/regrws/methods/#route-origin-authorizations-roas) for additional details.

Which RPKI model is right For me?

Hosted RPKI

Hosted RPKI is an infrastructure in which ARIN hosts a Certificate Authority (CA) and signs all ROAs for resources within the ARIN region. Only direct resource holders can participate in RPKI. Any downstream organization must have their upstream provider submit ROA Requests on their behalf.

Hosted RPKI requires that ARIN hosts the private key of your ROA Request Generation Key Pair. Hosted RPKI’s benefits include:

  • Ease of use
  • Little to no coding required from participants
  • Certificate Authority functionality work taken care of by ARIN
  • Data security via a Hardware Security Module (HSM)
  • Functioning repository provided by ARIN

Delegated RPKI

Delegated RPKI refers to an infrastructure in which ARIN allows direct resource holders to host their own CA and sign ROAs on their own. Resources then are linked to ARIN’s RPKI repository. This hierarchical system of verification allows customers of direct Internet number resource holders to participate in RPKI, using their resource provider as a CA.

Delegated RPKI does NOT require ARIN to host the private key of your Delegated RPKI Key Pair, and allows you to, in turn, offer either Hosted or Delegated RPKI resources to your customers.

I want to transfer Internet number resources to another party which are currently covered under an ARIN RPKI certificate. 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.

Note: If an orgnization wishes to change between a hosted an delegated RPKI deployment, they 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 with the team go to Ask Arin

What is a Certificate Authority (CA)?

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 (INR’s) 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 public key?

A public key is the part of a key pair that may be distributed safely to others. It is mathematically paired with the private key that was generated alongside it. This key is provided to ARIN when the user signs up to participate in RPKI, and is used to cryptographically verify ROA Requests which have been signed by the corresponding private key.

What is a private key?

A private key is the part of the key pair that must be securely stored, and must NOT be distributed. RPKI participants use private keys to sign ROA Requests. When a block of data is signed using a resource holder’s private key, their public key can be used to verify that data.

Note: Private keys must be kept private, and must not be shared with anyone outside your organization. Should another entity have access to your private key, that entity would be able to effectively represent itself as your organization, voiding the security RPKI is designed to maintain.


What is a Hardware Security Module (HSM)?

An 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. ARIN uses an HSM and ROA Request Generation Key Pairs in order to establish nonrepudiation. Nonrepudiation refers to the inability for a party (in this case, an ARIN customer) to dispute or deny having performed an action (in this case, submitting a ROA Request). Any ROA Request received by ARIN is logged and traceable to the customer who initiated it.

Why must I create a key pair to use RPKI?

Within hosted RPKI, A ROA Request Generation Key Pair allows you to sign your ROA Requests in a way that enables ARIN to verify that they came from the correct organization and have not been tampered with. ROA Request signature verification takes place in a trusted environment on an HSM designed specifically for performing cryptographic operations. ARIN’s HSM has been configured to only accept ROA Requests signed with a private key that corresponds with a public key linked to the customer submitting the request. No one else can create ROAs on your behalf.

Within delegated RPKI, a Delegated RPKI Key Pair is required as a way of verifying the identity of the delegated RPKI participant. The public key of this key pair is given to ARIN, along with your publication URI in order to obtain a delegated resource certificate. The private key of this key pair is not distributed, but rather used to sign certificates and ROAs for the customers of a delegated RPKI participant.

Note: It is your responsibility to keep your private key a secret. If you have reason to believe that your private key has been compromised, visit the troubleshooting information about lost keys.

Why doesn’t ARIN generate a ROA Request generation or delegated RPKI key pair for me?

ARIN will never have access to your private key for security purposes. Your private key should not be handled or seen by anyone other than you.

How do I create a Key Pair?

Visit Generating a ROA Request Key Pair for instructions.

What is a Route Origin Authorization (ROA)?

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:

  • A ROA name
  • An ASN
  • A validity date range
  • One or more IP Addresses (along with a CIDR block designation and an optional max length).

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

Note: This applies to hosted RPKI.

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

What is a ROA Request?

A ROA Request is a request for ARIN to generate a ROA for you.

After providing the required information, a ROA Request must be signed with your private key. This request is then submitted to ARIN. ARIN will generate and sign the ROA, and publish it 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.

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

Each Route Origin Authorization (ROA) includes exactly one ASN. Multiple ASNs may be authorized, but each one requires a separate ROA.

Why are there two ways to submit a ROA Request?

You are required to sign each ROA Request with your private key and paste the signed request into your browser. To help make this process easier, ARIN Online users are presented with a convenient HTML5 form, which will load your private key and sign your ROA Request for you. Only certain browsers support this feature. Please see the following section for more information.

Why does ARIN require specific browser versions to sign a ROA Request in browser?

In order to sign your ROA Request and load your private key within your browser, ARIN uses the HTML5 file API. Your key is not transmitted over the network. ARIN’s in-browser ROA Request signing function only supports Firefox version 3.6 or later, and Chrome version 6 or later.

Why do I have to sign my ROA Requests?

To prevent unauthorized tampering or forgery, you must sign each ROA Request with the private key associated with the ROA Request Generation Key Pair that you generated when registering for RPKI participation.

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

If you receive a closed ticket before the time a repository is published, it will be in that release.

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

No, ROAs are deleted based on the basis of a unique identifier and not the customer-specified “ROA Name.” This unique identifier is referred to as the roaHandle in the ARIN RESTful (Reg-RWS) documentation. (The roaHandle is returned in the ROA Spec Payload).

Can I remove multiple ROAs at the same time?

Currently, there is no mechanism to do this via ARIN Online or via Reg-RWS.

What is a validator?

A validator is a program used to fetch a published repository, validate its contents, and output the results. The results are then used to make informed routing decisions.

We provide a list of validators that you can use.

What is a Certification Practice Statement (CPS)?

A CPS is a document that explains certificate policies and 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 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 Trust Anchor Locator (TAL).

How often does ARIN update the repository?

ARIN currently generates a new repository every few minutes.

What is a CRL?

In the context of PKIs, a CRL (Certificate Revocation List) 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 which 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 CRLs?

Note: This applies to hosted RPKI.

The system 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 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 Relying Party (RP)?

An RP is any entity that uses ARIN’s RPKI repository data to help them make informed routing decisions.

What is a Resource Trust Anchor (RTA)?

An 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 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 TAL?

In the context of RPKI, the 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 PEM-encoded public key

Access ARIN’s TAL.

What is ARIN’s Relying Party Agreement (RPA)?

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

Access the RPA.

How can I test RPKI without affecting my production data?

ARIN has implemented an RPKI instance within its Operational Test and Evaluation environment (OT&E), 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.

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

To learn more about RPKI’s 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: