On Wed, Jul 07, 2021 at 01:16:20PM -0700, Ronald F. Guilmette via db-wg wrote: > Job Snijders <[email protected]> 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
