We take security very seriously. If you have found a security issue in one of our RPKI products, please submit a security report.

Invalid RPKI data could disable Route Origin Validation on RTR clients

Credit:Job Snijders
Affects:Routinator up to and including version 0.9.0
Not affected:Other versions
Impact:Route Origin Validation could be disabled for RTR clients
Solution:Install Routinator 0.10.0 or newer

Routinator prior to 0.10.0 produces invalid RTR payload if an RPKI CA uses too large values in the max-length parameter in a ROA. This will lead to RTR clients such as routers to reject the RPKI data set, effectively disabling Route Origin Validation.

Due to lack of checking of ROA object content, Routinator will simply pass through any max-length value provided in the ROA. However, a max-length value must never be larger than the maximum prefix length of the address family. Data with larger values will be considered invalid by any RTR client leading to a rejection of the entire data set.

Routinator 0.10.0 ensures that any ROA objects containing max-length values larger than the maximum prefix length of a prefix’ address family are rejected.

Missing files should result in entire CA being considered invalid

Credit:Job Snijders
Affects:Routinator up to and including version 0.7.1
Not affected:Other versions
Impact:A legitimate route is marked as RPKI invalid
Solution:Install Routinator 0.8.0 or newer

An issue was discovered in NLnet Labs Routinator 0.1.0 through 0.7.1. It allows remote attackers to bypass intended access restrictions or to cause a denial of service on dependent routing systems by strategically withholding RPKI Route Origin Authorisation ".roa" files or X.509 Certificate Revocation List files from the RPKI relying party's view.

Routinator 0.8.0 follows the rules proposed by draft-ietf-sidrops-6486bis. It ensures 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.