[db-wg] Further cleanup (was: RIPE NONAUTH route(6) objects

On Wed, Jul 07, 2021 at 01:16:20PM -0700, Ronald F. Guilmette via db-wg wrote:
> Job Snijders <job at sobornost.net> wrote:
> >Should the database server software impose brittle restrictions
> >on that field? No, not worth the headache.
> 
> I never suggested any changes to the data base software.

I think you are, implicitly, because every new deletion rule needs to be
implemented in software.

> I have merely suggested that *existing* route objects that make
> reference to bogon ASNs should be deleted from the data base, just
> as is already and currently being done in the case of those route
> objects that make reference to bogon IP space.
> 
> The overwhelming majority of these "bogon-ASN" route objects are
> quite obviously leftovers that just never got cleaned up... some
> having languished unattended in the data base for as much as 20 years
> or more (and even some of the people who put those there originally
> are no doubt dead by now).
> 
> We are in agreement in our (idealistic?) hops that someday RPKI will
> make all of these issues moot.  By for today, there is no good reason
> not to remove the decades long accumulation of rust.  It isn't doing 
> anybody any good, and I fear it is an active enticement to mischief
> makers, of which the Internet has an over-supply these days.

TL;DR: Please exercise patience. :-)

It is indeed commonly understood and accepted that super old objects
exist in the IRR databases, and that potential downsides exist to have
'digital IRR trash' lingering around. However, ancient objects also
exist that provide value to someone somewhere. Passing judgement on
whether something is junk or treasure is a subjective process.

Exactly for reason, a very elegant garbage collection was devised in
which the community came to consensus that RPKI data (with valid crypto
signatures) are a superior source of information, compared to IRR route
objects (especially when the provenance is clouded in mystery, such as
in RIPE-NONAUTH).

The community agreed that RPKI data can be used to both treat BGP UPDATE
messages as if they are a 'WITHDRAW' (in case there is a conflict
between the BGP message and the RPKI information), but also to justify
the removal of IRR route:/route6: objects that are in conflict with the
RPKI information.

At the time that https://www.ripe.net/publications/docs/ripe-731 was
designed it was understood that this would be a multi-year garbage
collection process, and that whatever remained might have some value to
someone somewhere (which would warrant investigation and careful
consideration).

About your 'challenge', I showed some data here:
https://www.ripe.net/ripe/mail/archives/db-wg/2021-July/007083.html
My apologies if this data does not satisfy your 'challenge'. To me it is
not entirely clear what exactly the terms of your challenge are. To
avoid handwaving and endless emails I would encourage you to share code
and/or terminal typescripts in any standard-ish language (ksh, bash, C,
perl, awk, python) to better understand what exactly you think should
happen. It is fine if it is 'proof of concept' code, the code only
exists to demonstrate the decision tree behind your proposals.

About 'idealism'... in my reality the universal deployment of RPKI
appears to be happening at a steady pace. If you review the graphs at
https://rpki-monitor.antd.nist.gov/ it shows a remarkable curve: a jump
from 21.62% to 29.82% in only a single year. Simiarily, in RIPE-NONAUTH
a decrease (proportional in size to the growth of the RPKI?) can be
observed.

I encourage fellow researchers to start focussing on RPKI security
issues (because the RPKI validation process outcome is the input into
the RIPE-731 process). Are there bad repositories? Are there errata that
need to be filed about protocol specifications? Are there
vulnerabilities in Relaying Party software implementations? Is your
organization able to understand and debug attacks via the RPKI?

I encourage fellow network operators to help identify feature-parity
gaps between IRR and RPKI so that together we can extend the RPKI to the
point where access to 'plain-text IRR service' no longer is a
requirement for day-to-day operations.

Kind regards,

Job