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 -- RPKI mailing list [email protected] https://lists.nlnetlabs.nl/mailman/listinfo/rpki
