Public Key Infrastructure Overview
PKI uses asymmetric keys called public and private keys to encrypt and decrypt information. RPKI uses one key to encrypt the private key and the other key is used to decrypt the public key. A Certificate Authority (CA) validates the holder of these resources. RPKI uses the hierarchical trust model where the trust runs from the End Entity (EE) Certificates back up to the Root CA Certificate. RPKI uses Digital Signatures to validate they are the legitimate holders of the routing resources.
The certificate structure mirrors the way IP addresses and AS numbers are distributed. The IANA is a department within the Internet Corporation for Assigned Names and Numbers (ICANN). The ICANN distributes names and addresses to the Regional Internet Registries (RIRs). The RIRs distribute names and addresses to their members, the LIRs, and in some cases to end customers.
Figure 1 shows a map of the RIRs and their coverage area of responsibility.
Overall RPKI operation is defined by several RFCs. RPKI uses X.509 certificates (described in RFC 5280 and RFC 6818), extensions for IP addresses and AS identifiers (RFC 3779), BGP prefix origin validation (RFC 6811 and 8481), and Resource Public Key Infrastructure (RFC 6810, 8210, and RFCs 6480-6493). This allows the LIRs to obtain a resource certificate listing the AS numbers and IP addresses resources they hold; a certificate that validates their proof of ownership.
The LIRs create cryptographic attestations using the resource certificate. A cryptographic attestation shows a valid claim to the route announcements they make with the prefixes they hold. Figure 2 shows the general content of the X.509 certificate.
RPKI calls these attestations Route Origination Authorizations (ROAs). ROAs describe the holder’s intentions including originating AS number, an IPv4 address or IPv6 prefix, and optionally, the maximum prefix length. If the ROA does not include a maximum length, then the ASN is authorized only to advertise the exact prefix: anything more specific is considered invalid. Using the maximum prefix length is a way to prevent route hijacking through a more specific announcement.
We recommend you be conservative in using maximum length in ROAs. For example, if a prefix has only a few sub-prefix announcements, use multiple ROAs for the announcements, instead of one ROA with a long maximum length.
For example, if, instead of 10.0.0.0/16 and maximum prefix length /24, the resource holder issues 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed against 10.66.6.0/24.
RPKI uses Rsync and RRDP publication protocols to distribute RPKI certificates. This allows you to use the RPKI data to retrieve certificates from the RIRs and store them locally in your cache.
Routers then retrieve the entire RPKI database from the caches using the RPKI-to-router (RPKI-RTR) protocol. The protocol uses a form of serial number logic to check for changes to the database. This means that routers need to download the full database only once, and then check periodically to see if any ROAs have changed.
Figure 3 shows the process of passing these certificates from IANA through a Security Industry Authority (SIA) to the ROA. The ISP adds the IP address, prefix length, and ASN as appropriate.
How Routers Process RPKI Data
It is up to the network operator on how to use RPKI data. The border routers of an AS number should enforce these decisions. The router checks each of received BGP routes against the received ROAs and sets each route’s validation state to one of the following possible states:
VALID—A matching or covering ROA was found with a matching AS number. A covering ROA is one that matches the AS number and falls in between the prefix length and maximum prefix length. For example, the ROA 10.0.0.0/16 with maximum prefix length /24 covers 10.0.0.0/22
INVALID—A matching or covering ROA was found, but the AS number did not match, or the mask exceeded the defined maximum length.
UNKNOWN or NOT FOUND—No matching or covering ROA was found. This scenario could be because the owner did not create an RPKI statement, or the ROA certificate has expired, but there are other possible causes.
Based on the route’s validation state, each operator decides how to proceed according to their local policy. Junos OS accomplishes this using a routing policy. Ideally, one policy might drop any routes with a state of INVALID, but this action is not mandatory.
Figure 4 shows the overall flow from the global RPKI level through the cache to the individual router.
RPKI Cache Server
Origin validation using RPKI requires three components:
The ROA entries from the RPKI databases
A router to enforce decisions based on these ROAs and its operator’s policy
The RPKI cache server (also referred to as the RPKI Validator).
The cache server queries all the distributed (RIRs) RPKI databases to collect all the ROAs and validates each entry’s signature. The cache server then replies to the router’s query by forwarding all ROAs in the validated cache to the router. The router does not decrypt the certificates because this is the task of the validator.