Data Processing

Fetching

There are two protocols in use to transport RPKI data: rsync and the RPKI Repository Delta Protocol (RRDP), which relies on HTTPS. RRDP was designed to be the successor to rsync in the RPKI. As all RPKI repositories currently advertise support for both protocols, Routinator will prefer RRDP if available.

In the RPKI, the certificate hierarchy follows the same structure as the Internet number resource allocation hierarchy. Routinator starts traversing the tree by connecting to the trust anchors of the Regional Internet Registries (RIRs). Along the way Routinator will find several pointers to child publication points, such as the ones operated by National Internet Registries (NIRs), Local Internet Registries (LIRs) and organisations running delegated RPKI. Each pointer explicitly states if RRDP is offered in addition to rsync.

The RPKI hierarchy

As a precaution, Routinator will not accept rsync and HTTPS URIs from RPKI repositories with dubious hostnames. In particular, it will reject the name localhost, URIs that consist of IP addresses, and hostnames that contain an explicit port. You can change this behaviour with the --allow-dubious-hosts option.

RRDP Fallback

If an RRDP endpoint is unavailable but it has worked in the past, Routinator will assume this is a transient problem. What action is taken is determined by the --rrdp-fallback option. The default policy is stale. This means Routinator will retry using RRDP for up to 60 minutes since the last successful update, during which it will rely on the locally cached data for this repository. After this time, Routinator will try to use rsync to fetch the data instead. To spread out load on the rsync server, the exact moment fallback happens is picked randomly between the refresh time and the --rrdp-fallback-time value. If rsync communication is unsuccessful too, the local cache is used until the objects go stale and ultimately expire.

Another policy for --rrdp-fallback is never. This means that rsync is never tried for a CA that advertises the availability of RRDP. Lastly, the policy new means that rsync is tried if an update via RRDP fails and there is no local copy of the RRDP repository at all. In other words, an update via RRDP has never succeeded for the repository. Choosing this policy allows a repository operator some leeway when first enabling RRDP support.

New in version 0.9.0.

Changed in version 0.12.0: The --rrdp-fallback option

Update Interval

Routinator will fetch new RPKI data ten minutes after the last successful update has finished. The interval can be changed using the --refresh option. It is possible that it takes very long to update a repository due to temporary network problems. To ensure a slow repository doesn’t stop the entire update process from completing, Routinator has a timeout for stalled connections. For RRDP, this timeout is implemented as an HTTP request timeout. For rsync, the timeout is around the spawned rsync process. The default is five minutes for both and can be changed via the --rsync-timeout and --rrdp-timeout options.

Validating

The validation process determines if all certificates, Route Origin Attestations (ROAs) and other signed objects that may appear in the RPKI have the correct signatures. It will also verify if the hashes are correct, no objects have expired and the entire data set is complete. If any of the objects do not pass these checks, the data will be discarded.

Currently, only certificates (.cer), certificate revocation lists (.crl), manifests (.mft), ROAs (.roa), and Ghostbuster Records (.gbr) are allowed to appear the RPKI. If another type of object is encountered Routinator will warn by default, but this can be changed with the --unknown-objects option.

Note that even if unknown objects are accepted, they must appear in the manifest and the hash over their content must match the one given in the manifest. If the hash does not match, the Certificate Authority (CA) and all its objects are still rejected.

Stale Objects

During the validation process, Routinator may encounter objects that are stale. In RPKI, manifests and CRLs can be stale if the time given in their next-update field is in the past, indicating that an update to the object was scheduled but didn’t happen. This can be because of an operational issue at the issuer or an attacker trying to replay old objects.

Ongoing standards efforts and operational experiences suggest that stale objects should be rejected, which is the default policy set by the --stale option since Routinator 0.8.0. As a result, all material published by the CA issuing this manifest and CRL is considered invalid, including all material of any child CA.

ROAs and VRPs

ROAs are cryptographic objects that contain a statement authorising a single Autonomous System Number (ASN) to originate one or more IP prefixes, along with their maximum prefix length. ROAs can only be created by the legitimate holder of the IP prefixes contained within it, but they can authorise any ASN.

If the ROA passes validation, Routinator will produce one or more plain text validated ROA payloads (VRPs) for each ROA, depending on how many IP prefixes are contained within it. Each VRP is a tuple of an ASN, a single prefix and its maximum prefix length. The complete collection of VRPs can be expressed in formats such as CSV or JSON, or exposed via the RPKI-to-Router (RTR) protocol so that they can be compared to all BGP origins seen by your routers. For each route origin it can be determined if they are RPKI “Valid”, “Invalid” or “NotFound”.

Unsafe VRPs

If the address prefix of a VRP overlaps with any resources assigned to a CA that has been rejected because it failed to validate completely, the VRP is said to be unsafe since using it may lead to legitimate routes being flagged as RPKI Invalid.

Routinator has an --unsafe-vrps option that specifies how to deal with these types of VRPs. Currently, the default policy is warn in order to gain operational experience with the frequency and impact of unsafe VRPs. This default may change in future version.

You can learn more about this topic in the Unsafe VRPs section.

Storing

To be resistant against accidental or malicious errors in the data published by repositories, Routinator retains two separate data sets: one that keeps the data of all publication points as it was received from their remote repository, and another – which we call the store – keeps the most recent data of a given RPKI publication point that was found to be correctly published.

Data is only transferred into the store if a manifest was found to be valid and if all files mentioned on the manifest are present and have the correct hash. Otherwise the data for the publication point already present in the store will be used for validation.

If you ever want or need to clear all stored data, you can use the --fresh option. This will be like starting Routinator for the very first time:

routinator --fresh vrps

New in version 0.9.0.