RPKI is a public key infrastructure to help improve the security of Border Gateway Protocol (BGP) routing. Wikipedia provides some high level information on RPKI that this documentation expounds upon. There are two points of view to consider with regard to the RPKI, that of a resource holder and that of a party routing packets on the Internet.
A resource holder is any organization that has been allocated Autonomous System Numbers (ASN), IPv4 addresses or IPv6 addresses by another organization, such as a Regional Internet Registry (RIR) or Internet Service Provider (ISP). Resource holders benefit from the RPKI if they opt in to certify their resources and if parties routing packets on the Internet utilize the RPKI to make routing decisions. If an ISP routing traffic accidentally or maliciously attempted to originate space belonging to the resource holder from an AS that was not one of the AS's designated by the resource holder other ISPs would be able to detect the scenario and take appropriate action.
On the other side of the fence are the organizations that are involved in external BGP routing on the Internet. The benefits of participating in the RPKI for parties involved in BGP routing are twofold. First, it is possible to make more informed routing decisions because the resource holders have indicated the Autonomous System(s) they authorize to originate their IP resources. Second, in the future, it may be possible to perform path validation to ensure that packets travel through trusted peers by using public key material distributed with the RPKI repository and the BGPSec protocol.
This document is broken into 6 sections. Under each section there may be a sub-section labeled 'Technical details' that you may skip if you do not care about how RPKI works under the hood. There may also be a section labeled 'What we provide' which will describe any open source project provided by Cobenian that is related to the topic.
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.
In order to certify resources issued by ARIN, each organization must accept ARIN's Terms of Service and request to have its resources signed. ARIN also mandates that each organization provide the public key part of an RSA key pair because ARIN requires Route Origination Authorization (ROA) requests be signed by the private key belonging to the key pair. This acts as a form of two factor authentication and prevents ARIN employees from submitting or modifying ROAs.less
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 firstname.lastname@example.org 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.
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).
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.
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 email@example.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.
Each RIR publishes a Trust Anchor Locator (TAL) which is a small file that contains two pieces of information. First, it has the URL where the RPKI repository for that RIR can be found. Second, it contains the public key of the RIR which can be used to verify the contents of the repository.
The TAL only needs to be downloaded when an RIR changes its key pair. When performing validation however, it is important to ensure that the latest copy of the TAL has been obtained just in case the key of an RIR was ever compromised and replaced.
ARIN puts an extra burden on its users by making users who wish to download the TAL sign its Relying Party Agreement. The terms of this Relying Party Agreement stipulate that ARIN's TAL cannot be re-distributed which means that it cannot be packaged in a validator.
Periodically each RIR publishes its information in a repository which is available to be downloaded via rsync. Currently the repositories are generated at least once per day.
The details of what is in the repository are not that important to most resource holders. But here are the details for the curious. A repository contains four types of files. The files are generally laid out such that there is a directory for each resource certificate.
The CRL is associated with the resource certificate and it contains an entry for each certificate issued by this resource certificate that has been revoked.
A ROA file exists for each ROA that was signed by this resource certificate.
Finally it contains resource certificates (X509 certificates with RFC 3779 extensions) that were issued by this resource certificate. Those resource certificates contain a URI that points to another directory either in this repository or in another repository.less
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 firstname.lastname@example.org 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:
|VALID||the route announcement is fully covered by at least ROA|
|INVALID||either the AS is not authorized or the announcement was more specific than allowed by a matching ROA|
|UNKNOWN||the prefix is not fully covered by a ROA|
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:
We provide a one day intensive class that covers everything you need to know to get started with RPKI whether you are a resource holder, someone who does BGP routing or both.
We also provide professional software design, development and consulting services.
Give us a call at (703) 828-5180 or email email@example.com to find out more.