[RPKI] Filtering of Unsafe VRPs

[Jay Borkenhagen]

Hi Martin,

Apologies for not replying sooner.

I appreciate the goal behind this: to reduce the chances that
something broken within the RPKI system will cause ISP networks to
mis-categorize legit BGP announcements as 'rpki-invalid', instead
falling back to 'rpki-not-found'.

But in thinking this through, I keep coming back to a feeling that
overall it would be best to keep things simple.  For RPs like
Routinator that would mean looking at the entire RPKI (I admit there
are devilish details buried in "entire"), applying the standardized
set of rules to vet the retrieved objects, then publishing VRPs for
everything that checks out OK.

I am a big believer in the Principle of Least Astonishment (POLA).  In
this context POLA would seem to say that a problem in generating one
VRP somewhere should not cause a wide swath of perfectly acceptable
VRPs to disappear.

In addition, if "Filtering of Unsafe VRPs" were to go forward, I think
that should happen only as a new standard that all RP implementations
should be expected to adopt.  Many networks do run different flavors
of RPs, and there's no value in one RP filtering away the dangers if
the others do not do so as well.


I would certainly like to hear more discussion of this topic.

Thanks!!

					Jay B.


On 11-September-2020, Martin Hoffmann via RPKI writes:
 > 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
 > RPKI at lists.nlnetlabs.nl
 > https://lists.nlnetlabs.nl/mailman/listinfo/rpki