RPKI Frequently Asked Questions
What is a Public Key Infrastructure (PKI)?
A PKI is an infrastructure 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.
Which RPKI model is right For me?
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 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.
What is a CA?
A CA is an entity that issues digital certificates. ARIN currently acts as a CA for its RPKI, issuing resource certificates within the ARIN region. In delegated RPKI, entities with IP addresses and Autonomous System Numbers assigned directly from ARIN can act as a 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.
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.
IF YOUR PRIVATE KEY IS LOST OR COMPROMISED, YOU MUST START THE RESOURCE CERTIFICATION PROCESS AGAIN FROM THE BEGINNING.
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 ROA?
A 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 covered by 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.
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. Signatures are verified in a trusted environment on a Hardware Security Module (HSM) designed to perform cryptographic operations.
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
What is ARIN’s Relying Party Agreement (RPA)?
ARIN’s RPA comprises a set of terms and restrictions applicable to any entity wishing to access and/or utilize ARIN’s TAL or RPKI repository.
Note: Usage of either the TAL or ARIN’s RPKI repository data is subject to 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:
- RFC 6480: An Infrastructure to Support Secure Internet Routing
- RFC 6481: A Profile for Resource Certificate Repository Structure
- RFC 6482: A Profile for Route Origin Authorizations (ROAs)
- RFC 6483: Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)
- RFC 6484: Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)
- RFC 6485: The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)
- RFC 6486: Manifests for the Resource Public Key Infrastructure (RPKI)
- RFC 6487: A Profile for X.509 PKIX Resource Certificates
- RFC 6488: Signed Object Template for the Resource Public Key Infrastructure (RPKI)
- RFC 6489: Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)
- RFC 6490: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
- RFC 6491: Resource Public Key Infrastructure (RPKI) Objects Issued by IANA
- RFC 6492: A Protocol for Provisioning Resource Certificates
To learn more about delegated RPKI requirements, such as URIs, manifests and CRLs, ARIN recommends reading the following RFCs:
- ARIN's Trust Anchor Locator (TAL)
- Hosted RPKI
- Delegated RPKI
- Route Origin Authorizations (ROAs)
- RPKI Frequently Asked Questions
- RPKI Troubleshooting
Registration Services Help Desk
7:00 AM to 7:00 PM ET