[RPKI] Routinator 0.8.0 ‘Strikes and Gutters, Ups and Downs’ Released

[Martin Hoffmann]

Dear mailing list,

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

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.

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.

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, we feel there is currently no consensus for 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 at

   https://github.com/NLnetLabs/routinator/releases/tag/v0.8.0

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

for more information.

Happy Routinating!
 
On behalf of the NLnet Labs RPKI Team,
Martin