[RPKI] Filtering of Unsafe VRPs

[Martin Hoffmann]

Dear mailing list,

we are currently working on improving the filtering of potentially
unsafe VRPs in Routinator. With ‘unsafe’ we mean VRPs whose presence
may accidentally make legitimate announcements RPKI invalid. Before we
decide on the concrete strategy to implement we would very much like to
hear feedback from users.

The reasoning on the strategy we are currently preferring started with
the observation that filtering individual ROAs may lead to legitimate
route announcements being dropped because ROAs only contain a single
originating AS. As a consequence, a prefix possibly being announced by
multiple ASs needs to be authorized via multiple ROAs. If the ROA for
the AS currently announcing the prefix gets dropped for whatever
reason, the prefix becomes invalid and its route gets dropped.

As an immediate measure, it was proposed to drop all objects published
by a CA that has any invalid objects whatsoever. This will make all
ROAs published by this CA disappear but also all child CAs. While this
will solve the above issue for most practical cases, there is still a
possibility that a prefix is delegated to multiple CAs which
independently publish ROAs authorising different ASs. If only the ROAs
published by one of those CAs is dropped, the result may again be a
falsely dropped route. The only way to avoid this is to drop all
authorisations (i.e., VRPs) for all address resources delegated to the
invalid CA.

However, this is still not quite enough. If the VRP for a legitimate
route is dropped because of above filtering and there is a less
specific VRP with a max-length not covering the route, then the route
suddenly becomes invalid too. To avoid that, we need to filter all VRPs
that overlap with any of the resources of invalid CAs.

We have implemented an initial version of exactly that: It creates a
list of all the resources from all the CAs that had to be dropped
because of issues. When creating the final set of VRPs, it filters out
all VRPs whose address prefixes overlap with any of these resources,
making these resources guaranteed to be RPKI unknown.

There is a new metric routinator_vrps_unsafe in Prometheus output or
unsafe-vrps in status output that counts the VRPs filtered that way. At
the time of writing, around 3300 VRPs or 1.9 % were filtered this way.

You can follow this work in a draft PR on Routinator’s Github
repository:

   https://github.com/NLnetLabs/routinator/pull/377

The question here is, whether this aggressive filtering will improve
the overall security of the system. This kind of filtering can -- at
least in theory -- be used by an attacker to actively push their target
space to RPKI unknown as an initial step of a route hijack. I think
this is relatively difficult to achieve and the risk subsequently is
very low, but I’d love to hear opinions -- particularly arguments
against this filtering strategy.

Kind regards,
Martin