RPKI leverages the X.509 certificate/public key infrastructure system that is also used with TLS/SSL to authenticate and encrypt HTTP sessions, email, et cetera. The use of X.509 certificates is specified in RFC 5280 and RFC 3779 adds extensions for IPv4 and IPv6 prefixes and AS numbers. The RIRs issue these certificates when a resource is given out. Certificates are typically renewed every year, and unlike the certificates used for HTTPS, there’s no identifying information in them. Each RIR uses a self-signed root certificate to sign the certificates they give out.
Holders of address space in turn generate Route Origination Authorizations (ROAs) that associate an address prefix with an AS number, giving that AS permission to originate the prefix in question. The address holder signs the ROA with their certificate’s private key. The ROA also contains a maximum prefix length and an expiry date. For instance, if AS 3333 signs a ROA for 193.0.0.0/21 with a maximum prefix length of /22, then AS 3333 is allowed to originate 193.0.0.0/21, 193.0.0.0/22 and 193.0.4.0/22, but not 193.0.2.0/23 or 193.0.7.0/24. However, the holder of 193.0.0.0/21 can generate an additional ROA to allow AS 3333 (or another AS!) to originate the longer prefixes at any time as ROAs may overlap.
Certificates and ROAs are published in publicly accessible repositories, where they can be downloaded and used to generate lists of which prefixes may be originated by which ASes. At this point, the signatures and lifetimes of the certificates and ROAs are checked. If the start date of a ROA (and all the certificates in the chain back to the root certificate) is in the future or its end date is in the past, any the signatures are invalid or have been revoked, the ROA is ignored. All the ones that validate are then used to create a “validated cache”. This is a process that every network executes independently. Then the validated cache is used to generate a filter that is uploaded to the routers.
Routers then check BGP advertisements against this filter, with one of three results: valid, invalid or unknown. The valid state means that there is a ROA matching the prefix and AS number used to originate the prefix. Invalid means there’s a ROA, but the AS number or prefix length doesn’t match. Unknown means there’s no ROA that covers the prefix. A router can then take action based on the RPKI state of a prefix. For instance, this is an example from the Cisco RPKI documentation:
The route-map rtmap-PEX1-3 sets the local preference to 50 when the RPKI state is invalid, 100 when it’s unknown/not found 200 when the RPKI state is valid. So paths that validate are always preferred over paths that aren’t signed, which in turn are always preferred over paths that should validate but don’t. Even if the valid path has a longer AS path than the unknown or invalid paths.
Unfortunately, this doesn’t protect against the case where 193.0.0.0/21 is valid, but a third party tries to get traffic for that prefix using unauthorized advertisements of more specific prefixes, such as 193.0.0.0/24 – 193.0.7.0/24. Those don’t validate and get a local preference of 50, but they still overrule the valid 193.0.0.0/21 advertisement with a local preference of 200, because of the longest match first rule discussed in the previous post.
A more secure approach would be to reject prefixes for which a ROA is present but the advertisement doesn’t validate, i.e., filter out invalids. You would think then if a certificate or ROA expires before a new one is installed, connectivity is lost, and without connectivity, it may prove difficult to generate and upload new certificates and ROAs… But expired (or not-yet-valid) certificates and ROAs are simply ignored, so the prefixes in question revert to unknown rather than invalid and thus remain reachable.
This is a similar example from Juniper’s RPKI documentation:
user@R0# show policy-options
policy-statement send-direct {
}
community origin-validation-state-invalid members 0x43:100:2;
community origin-validation-state-unknown members 0x43:100:1;
community origin-validation-state-valid members 0x43:100:0;
Please see the documentation at your RIR for more information on how to get certificates for your IP addresses:
RIPE has an RPKI tools and resources page, where, amongst other things, you can download an RPKI validator. They also run a Cisco router that you can access over Telnet to try out a few RPKI commands at rpki-rtr.ripe.net (user ripe, empty password) and a Juniper at 193.34.50.25 and 193.34.50.26 (user rpki, password testbed). RIPE also has an RPKI validator where you can view a lot of RPKI information online.
As of March 19th, 2020, 163330 prefixes were marked as valid by a ROA validate. Out of all 7053 invalid ones, 3398 (48.18%) were invalid due to a bad maximum prefix length, 3113 (44.14%) were invalid due to bad origin AS, 469 (6.65%) were invalid due to both bad ML and bad origin AS reasons, and for 73 (1.04%), the origin AS could not be determined. With a total of 863973 IPv4 prefixes advertised in BGP, more than 80% of all prefixes aren’t covered by a ROA yet. See the NIST RPKI monitor, which shows there’s an upward trend for both valid and invalid ROAs.