[RPKI] Filtering of Unsafe VRPs

Martin Hoffmann martin at nlnetlabs.nl
Tue Sep 15 14:45:39 UTC 2020


Hi!

Martin Hoffmann via RPKI wrote:
> 
> 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.

A quick update on the results of this filtering. I previously stated:

> 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.

I’m not entirely sure how I ended up at this number. I suspect it is
actually from before I introduced that metric as it is actually the
difference between total number of verified VRPs and final number of
VRPs in the data set and thus is the number of duplicate VRPs. The
number of unsafe filtered VRPs was zero until this morning and is now
one. So I guess it is working.

Here’s the current summary (with apologies for the overly long lines,
I’ll be working on that):

Summary at 2020-09-15 14:30:43.567283870 UTC
ripe: 18320 verified ROAs, 96848 verified VRPs, 0 unsafe VRPs, 96848 final VRPs.
apnic: 10162 verified ROAs, 52626 verified VRPs, 0 unsafe VRPs, 52582 final VRPs.
afrinic: 850 verified ROAs, 1439 verified VRPs, 0 unsafe VRPs, 1424 final VRPs.
arin: 15951 verified ROAs, 20408 verified VRPs, 1 unsafe VRPs, 17049 final VRPs.
lacnic: 4993 verified ROAs, 11588 verified VRPs, 0 unsafe VRPs, 10573 final VRPs.
total: 50276 verified ROAs, 182909 verified VRPs, 1 unsafe VRPs, 178476 final VRPs.

One more note: We have also added an exception to not add /0 prefixes
and ASN ranges covering the full set to the unsafe filter list. This
is because these tend to be used in the trust anchor. One trust anchor
being broken would then result in _all_ VRPs going away which is
unnecessary given that there shouldn’t actually be an overlap between
RIRs.

Kind regards,
Martin


More information about the RPKI mailing list