Routinator 0.8.0 ‘Strikes and Gutters, Ups and Downs’ released

We are happy to announce the latest release of Routinator, version 0.8.0 ‘Strikes and Gutters, Ups and Downs.’

Routinator is an RPKI relying party software that collects and validates statements in the Resource Public Key Infrastructure (RPKI) about allowed route origins and makes them available to the BGP workflow.

This release brings major changes to the way Routinator validates the objects published in the RPKI repository. It mostly follows the rules proposed by draft-ietf-sidrops-6486bis currently discussed in the SIDROPS working group of the IETF.

The most important change is that if any object published by a CA is found to be invalid, the entire CA – including all its objects – is rejected. This means that none of its ROAs are included nor are any of its child CAs even being looked at. This avoids a possible situation where a legitimate route is being marked as RPKI invalid because only a subset of the ROAs covering its prefix were considered valid and used. This change resolves CVE-2020-17366.

Even with this revised strategy such an invalidation of a valid route can, however, still occur if the covering ROAs are spread over multiple CAs via a parent of a rejected CA. In order to avoid these cases, this release contains an experimental feature we dubbed ’filtering of unsafe VRPs.’ It can be enabled via the --unsafe-vrps=reject option and will cause all VRPs overlapping any address prefix delegated to a rejected CA to be filtered out of the final VRP set.

This feature is disabled by default since we aren’t quite sure of the potential impact of such a filter in practice. To gain some practical insights, Routinator will log all the VRPs it would have filtered if the feature were enabled.

The rules proposed by the draft also suggest to consider any stale manifests and CRLs to be invalid. Routinator now follows this proposal by changing the default for the --stale option to reject.

There are, however, two diversions from the current form of the proposal. For one, consensus has not been reached on the proposed strategy to reject any object of an unknown type as this has consequences on introducing new object types to the RPKI. Routinator will instead check that unknown objects are published and have a hash digest corresponding to that stated in the manifest and accept (and subsequently ignore) them if they do.

The proposal also suggests to use previously valid data from a CA that is rejected if such data is available and would still be valid. Unfortunately, the current repository synchronization strategy implemented in Routinator overwrites all previous data when fetching from upstream. This reuse will be addressed in the next release.

In addition to these big changes, there are a number of small changes. You can read about all of them in the release notes.

Finally, users of Debian and Ubuntu might be interested in our unofficial package archive which now also contains packages for Routinator. See packages.nlnetlabs.nl for more information.