Why do ROV-ASes announce some invalid route?

Fri Nov 11 13:00:45 UTC 2022

<note I didn't look at the RV data for this>

There are 2 sides to the bgp conversation for any ASN, and then really 4 sides.
  customer -> RAS -> peer (settlement-free)
  peer(sfp) -> RAS -> customer
  customer -> ras -> transit
  transit -> ras -> customer

Depending on the RAS's capabilities or status in their journey to
'fully RAS', it's
possible that they may have:
  o "We OV all customer sessions" (notably not SFP peers)
  o "We OV all sessions(*)" (noting not all, and maybe depending on
platform specifics)

There are a bunch of ways this goes wrong :( This also doesn't really
tell what sort of peering
the RAS has set up with RouteViews (customer? peer? partial peer?)

Also, also, possibly the output path on the session(s) here is not
filtering in an OV fashion.

On Thu, Nov 10, 2022 at 9:13 AM 孙乐童 <slt20 at mails.tsinghua.edu.cn> wrote:
>
> Hello Job,
>   Thank you very much for your reply! I got that no AS can actually filter all the invalids. Yet I was trying to figure out why we couldn't see reasonable amount of withdrawals from AS6939 about invalid prefixes, as they explained how they implement ROV (https://mailman.nanog.org/pipermail/nanog/2020-June/108309.html). Perhaps we need to learn their detailed implementations.
>   Thank you very much!
>
> Best wishes,
> Sun Letong
>
> 在2022-11-08 00:11:24,Job Snijders<job at fastly.com>写道：
> > Dear 孙乐童,
> >
> > On Mon, Nov 07, 2022 at 08:40:57PM +0800, 孙乐童 wrote:
> > > We learned from Cloudflare's https://isbgpsafeyet.com/ that some ASes
> > > have deployed RPKI Origin Validation (ROV). However, we downloaded BGP
> > > collection data from RouteViews and RipeRis platforms and found that
> > > some ROV-ASes can announce some invalid routes. For example, from RIB
> > > data at 2022-10-31 00:00:00, 13 out of 17 ASes which declared to
> > > deploy ROV announced invalid routes, and we list the number of related
> > > prefixes for each AS below.
> > >
> > > [snip]
> > >
> > > As a comparison, we count the invalid routes the non-ROV ASes (also
> > > declared in https://isbgpsafeyet.com/) announces, as below:
> > >
> > > We can see that ROV ASes announced apparently fewer invalid routes
> > > compared to the non-ROV ASes, though they did not filter all the
> > > invalids.
> > >
> > > [snip]
> > >
> > > Can anyone help us to correctly interpret this case? Thank you very much.
> >
> > You ask great questions! I hope an answer to your questions can be found
> > in a message I sent a year ago:
> >
> >       https://mailman.nanog.org/pipermail/nanog/2021-April/213346.html
> >
> > The summary: in any sufficiently large network, chances are not 100% of
> > all equipment supports RPKI-based BGP Route Origin Validation; in such
> > cases a handful of invalid routes may still percolate through the
> > system. Another contributing factor might be certain types of software
> > upgrades; where ROV temporarily is disabled on one or more devices. Or
> > perhaps an ISP made a handful of exceptions for test/beacon invalid
> > routes to propagate.
> >
> > Kind regards,
> >
> > Job
>