[RPKI] Filtering of Unsafe VRPs

[Martin Hoffmann]

Hi Jay!

Jay Borkenhagen wrote:
> 
> Apologies for not replying sooner.

No worries -- rather thank you for your feedback confirming that
more discussion is needed, certainly before enabling the filter by
default. So for the upcoming 0.8 release, we will keep the filtering
feature behind a config option and disabled it by default.

We will, however, keep logging offending resources and "unsafe VRPs"
even if the option is off, so that we can gain a little more insight
into the actual impact of the filter.

Issue https://github.com/NLnetLabs/routinator/issues/391 is tracking
this revised plan.

I hope that is a good way forward and allows us to release 0.8 fairly
soon.

Kind regards and have a great weekend, everyone,
Martin

> 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