In order for a resource holding organization to take part in the RPKI it must certify its resources. This means that a resource certificate is issued which includes the ASNs and IP resources held by the organization. RPKI is opt in, so you must certify your resources with the RIR that allocated the resource(s) to you: RIPE, LACNIC, APNIC, AFRINIC or ARIN.

So what exactly is a resource certificate? A resource certificate is an X509 Certificate that includes a list of the IP addresses and ASNs issued to an organization. The resources in a resource certificate must be covered by the resource set of the signing (parent) resource certificate in order to be considered valid. In this way a cryptographic hierarchy of resource certificates is created that matches the allocations of resources from the IANA to an RIR to an ISP and so on.

Technical details

What we provide

We provide a free, open source tool to help you manage your key pairs if you decide to certify your resources in the ARIN region. You might consider this tool if you don't want to use OpenSSL and the command line to manage key pairs for your organization(s). Please contact us at info@cobenian.com to obtain a free copy of the software.

Once a user has certified their resources they can then specify which Autonomous System(s) they intend to originate their IP address space from. They do this by creating a Route Origination Authorization (ROA).

The details of a ROA request are well documented on ARIN's FAQ. Fundamentally a ROA contains a single ASN and a set of prefixes. Each prefix can optionally contain a maximum length. If no maximum length is present then only an exact match of the prefix would be considered valid.

Technical details

A prefix is a start IP address and a prefix length. The end IP address can be calculated from the start IP address and prefix length. The prefix corresponds to a single CIDR block and can be drawn as a line from the start IP address to the end IP address. Here is a diagram of 192.168/16 as an example.

Consider the ROA for AS 1234 and prefix 192.168.0.0/16 with no max length or max length 16 (they mean the same thing).

• A route announcement for 192.168.0.0/16 originating from AS 1234 would have a validity state of VALID.
• A route announcement for 192.168.0.0/16 originating from AS 5678 would have a validity state of INVALID. (originated from another AS)
• A route announcement for 192.168.128.0/17 originating from AS 1234 would have a validity state of INVALID. (too specific)
• A route announcement for 192.168.128.0/19 originating from AS 1234 would have a validity state of INVALID. (too specific)
• A route announcement for 10.10.0.0/16 originating from AS 1234 would have a validity state of UNKNOWN. (resources not covered)
• A route announcement for 192.0.0.0/8 originating from AS 1234 would have a validity state of UNKNOWN. (resources not fully covered)

When the maximum length is present it turns the line into a rectangle and any match of the IP address space inside the rectangle would be considered valid. Here is a diagram of 192.168/16 with max length 18 as an example.

Again consider the ROA for AS 1234 and prefix 192.168.0.0/16 with max length 18. A route announcement in the blue shaded rectangle would be considered valid.

• A route announcement for 192.168.0.0/16 originating from AS 1234 would have a validity state of VALID.
• A route announcement for 192.168.0.0/16 originating from AS 5678 would have a validity state of INVALID. (originated from another AS)
• A route announcement for 192.168.128.0/17 originating from AS 1234 would have a validity state of VALID.
• A route announcement for 192.168.128.0/19 originating from AS 1234 would have a validity state of INVALID. (too specific)
• A route announcement for 10.10.0.0/16 originating from AS 1234 would have a validity state of UNKNOWN. (resources not covered)
• A route announcement for 192.0.0.0/8 originating from AS 1234 would have a validity state of UNKNOWN. (resources not fully covered)

less

What we provide

We provide a free, open source tool to help you sign your ROA requests that you submit to ARIN. You might consider using this tool if browser signed ROAs are not acceptable for your organization (due to your security policy or because your organization uses Internet Explorer or another unsupported browser). If you create ROAs for another RIR the ROA request signing process is not required. Please contact us at info@cobenian.com to obtain a free copy of the software.

Now that a resource holder has a resource certificate, and possibly ROAs, there needs to be a way to distribute the information to parties doing BGP routing on the Internet. The way this information is disseminated is via the RPKI repository. Each RIR publishes its own repository and Trust Anchor Locator (TAL). Parties doing BGP routing retrieve the TALs from each of the RIRs. The TALs are then used to find the repositories from the various RIRs. The TAL does not change very frequently. In contrast, the repository is re-generated at least once every day.

Technical details

What we provide

We provide a free, open source tool to help you view the contents of an RPKI repository. To view the certificates, CRLs, manifests and ROAs in a repository please visit rpki.cobenian.com

Retrieving and parsing the binary files in a repository to determine whether or not they are properly constructed and signed can be cumbersome. Therefore software has been written to perform just this task. This software is referred to as an RPKI 'validator'.

Each repository is available to be downloaded via rsync. Each file in the repository contains the rsync URI of additional files in the hierarchy. These files may reside in the same repository or they may reside in a separate repository. In RPKI it is common to retrieve files from multiple repositories and to cache them. This is the first task performed by a validator.

Once the files have been retrieved the validator checks the validity of the retrieved files. First, it checks that the files are well formed. Then it performs cryptographic verifications of the contents of the files. Certain rules must be followed in order for the different types of objects to be valid. For example, in a resource certificate all the resources must be covered by the signing, or parent, certificate. The IP addresses in a ROA must be covered by the resource certificate that signed the ROA, but the ASNs do not have to be in the signing resource certificate. The rules followed by validators are well defined in RFCs.

Currently, there are three validators. Please visit ARIN to learn more about the validators.

What we provide

We offer a free, open source tool that will allow you to run all three validators against the same repository to verify the artifacts in the repository. You might consider this tool if you manage your own Certificate Authority. This tool will help you confirm that your portion of the repository passes top down validation with all of the validators in existence today. Please contact us at info@cobenian.com to obtain a free copy of the software.

The RPKI cache can be made available to a BGP speaking router via the RPKI to router (RTR) protocol. The artifacts in the repository can then be used to check the validity of route announcements in an automated manner. The RTR protocol is being developed by the IETF and it is currently in DRAFT form. Several Cisco and Juniper routers already support the protocol however. Quagga offers support through BGP-SRx. RIPE has some documentation on router configuration.

In order to check route origination the prefix and originating AS are checked against the Route Origination Authorizations (ROAs). All ROAs should have been recently fetched because missing or stale data could impact the result of origin validation. Each route announcement will be considered to have one of three RPKI validity states:

Once the state of a route announcement has been determined it can be used to help make routing decisions based on policy.

Here is some information about RTRlib, an open-source implementation of the RPKI RTR protocol client written in C.

A future goal of BGPSec is to provide path validation. While origin validation prevents one type of problem it does not offer any guarantees about any AS other than the originating AS. BGPSec is being worked on as a possible solution to this problem. As currently proposed, BGPSec adds server certificates for routers that would be published in the RPKI and update messages would be signed by the private key associated with the server certificate. Other BGPSec enabled routers could then check that each update message was signed by a router with the appropriate private key by verifying the update message signature using the public key in the server certificate. BGPSec is currently in the process of being standardized by the IETF and all the work is currently in DRAFT form. The Secure Inter-Domain Routing (SIDR) working group of the IETF is responsible for this work and it is not covered here.

There has been some criticism of BGPSec by some parties. They generally have two primary concerns:

• BGPSec as currently defined does not prevent some forms of route leaks BGPSec no help?
• Propagation time for the repository caches becomes important and may be "slow" RPKI Sizing Estimates