Re: [db-wg] Further cleanup (was: RIPE NONAUTH route(6) objects
Job Snijders <job@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 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. Regards, rfg
On Wed, Jul 07, 2021 at 01:16:20PM -0700, Ronald F. Guilmette via db-wg wrote:
Job Snijders <job@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
On 07/07/2021 23:16, Ronald F. Guilmette via db-wg wrote:
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.
Can you provide a list of those route objects that reference bogon ASNs as listed here: https://en.wikipedia.org/wiki/Autonomous_system_(Internet)#ASN_Table Thanks, Hank
In message <81050891-b839-e281-993f-c5bfbb86f49e@interall.co.il>, Hank Nussbacher <hank@interall.co.il> wrote:
Can you provide a list of those route objects that reference bogon ASNs as listed here: https://en.wikipedia.org/wiki/Autonomous_system_(Internet)#ASN_Table
My apologies for the slow reply. I had some other things on my plate. In my analysis, I have not attempted to differentiate between those ASNs that are reserved in accordance with some RFC and those that are simply not assigned at the present time, globally, by any RIR to any resource member. I provide here the results of my latest analysis, based on the most recent data files available. Feel free to further break down these results as you may see fit. Within the AUTH RIPE data base there are currently 81 IPv4 route objects that reference AS numbers not assigned to any RIR resource member, globally: https://pastebin.com/raw/mqyiK6hH Within the AUTH RIPE data base there are currently 19 IPv6 route objects that reference AS numbers not assigned to any RIR resource member, globally: https://pastebin.com/raw/cGuB9ZGP Within the NONAUTH RIPE data base there are currently 1,587 IPv4 route objects that reference AS numbers not assigned to any RIR resource member, globally. Note that of these, 562 are, I trust, currently scheduled for removal as part of the already ongoing cleanup of route objects that refer to bogon IPv4 address space. https://pastebin.com/raw/VjamUyjZ Within the NONAUTH RIPE data base there are currently 44 IPv6 route objects that reference AS numbers not assigned to any RIR resource member, globally. Note that of these, 43 are, I trust, currently scheduled for removal as part of the already ongoing cleanup of route6 objects that refer to bogon IPv6 address space. https://pastebin.com/raw/YQsVW0hU Regards, rfg P.S. All dates mentioned in the above files are drawn from the relevant last-modified: fields of each route object, respectively.
On 11/07/2021 10:32, Ronald F. Guilmette via db-wg wrote: Thanks Ronald, but that doesn't answer my question. I was hoping to see route objects which reference *reserved* ASNs - not route objects for unallocated ASNs. In any event, thanks for the effort. Regards, Hank
In message <81050891-b839-e281-993f-c5bfbb86f49e@interall.co.il>, Hank Nussbacher <hank@interall.co.il> wrote:
Can you provide a list of those route objects that reference bogon ASNs as listed here: https://en.wikipedia.org/wiki/Autonomous_system_(Internet)#ASN_Table
My apologies for the slow reply. I had some other things on my plate.
In my analysis, I have not attempted to differentiate between those ASNs that are reserved in accordance with some RFC and those that are simply not assigned at the present time, globally, by any RIR to any resource member. I provide here the results of my latest analysis, based on the most recent data files available. Feel free to further break down these results as you may see fit.
Within the AUTH RIPE data base there are currently 81 IPv4 route objects that reference AS numbers not assigned to any RIR resource member, globally:
https://pastebin.com/raw/mqyiK6hH
Within the AUTH RIPE data base there are currently 19 IPv6 route objects that reference AS numbers not assigned to any RIR resource member, globally:
https://pastebin.com/raw/cGuB9ZGP
Within the NONAUTH RIPE data base there are currently 1,587 IPv4 route objects that reference AS numbers not assigned to any RIR resource member, globally. Note that of these, 562 are, I trust, currently scheduled for removal as part of the already ongoing cleanup of route objects that refer to bogon IPv4 address space.
https://pastebin.com/raw/VjamUyjZ
Within the NONAUTH RIPE data base there are currently 44 IPv6 route objects that reference AS numbers not assigned to any RIR resource member, globally. Note that of these, 43 are, I trust, currently scheduled for removal as part of the already ongoing cleanup of route6 objects that refer to bogon IPv6 address space.
https://pastebin.com/raw/YQsVW0hU
Regards, rfg
P.S. All dates mentioned in the above files are drawn from the relevant last-modified: fields of each route object, respectively.
In message <f77da251-97b8-8527-9ac6-cb06fc281255@interall.co.il>, Hank Nussbacher <hank@interall.co.il> wrote:
Thanks Ronald, but that doesn't answer my question. I was hoping to see route objects which reference *reserved* ASNs - not route objects for unallocated ASNs.
Hank, I'm frankly not sure what the value of such a sub-list would be. A bogon ASN is a bogon ASN, no? Do dues-paying members want to be underwriting the use of bogon ASNs by members whose ASN registrations have lapased due to non-payment of relevant annual fees? Regards, rfg
Hi Ronald,
Do dues-paying members want to be underwriting the use of bogon ASNs by members whose ASN registrations have lapased due to non-payment of relevant annual fees?
I feel like that is not what we are trying to discuss here and is outside our scope, maybe in the scope of AP-WG. (I don't know if this is in their scope though tbh) So could we please look at data for reserved ASNs (not unallocated ASNs) without trying to argue that any bogon is a bogon. If so we could have a much more productive discussion. -Cynthia On Sun, Jul 11, 2021 at 10:13 PM Ronald F. Guilmette via db-wg < db-wg@ripe.net> wrote:
In message <f77da251-97b8-8527-9ac6-cb06fc281255@interall.co.il>, Hank Nussbacher <hank@interall.co.il> wrote:
Thanks Ronald, but that doesn't answer my question. I was hoping to see route objects which reference *reserved* ASNs - not route objects for unallocated ASNs.
Hank, I'm frankly not sure what the value of such a sub-list would be.
A bogon ASN is a bogon ASN, no?
Do dues-paying members want to be underwriting the use of bogon ASNs by members whose ASN registrations have lapased due to non-payment of relevant annual fees?
Regards, rfg
In message <CAKw1M3PNf6wowiYyqEq43MaYbL7b+ZF9Cf+qXiJ-Yy5_fYiN4Q@mail.gmail.com> =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me@cynthia.re> wrote:
Do dues-paying members want to be underwriting the use of bogon ASNs by members whose ASN registrations have lapased due to non-payment of relevant annual fees?
I feel like that is not what we are trying to discuss here and is outside our scope, maybe in the scope of AP-WG. (I don't know if this is in their scope though tbh)
Regretably, I'm forced to take issue with your framing of these matters. In the first place, who are you speaking for when you say "we"? Is that the royal "we"? Hank expressed some interest in seeing a further breakdown of the data I've posted, which encompases -all- route/route6 records in the data base that evidentally refer to ASNs that simply are not assigned by any RIR to any resource member, globally. I've suggested how he could pretty easily glean that information from what I've provided. Until your post however I haven't noticed anyone else who thinks that it is of any value to distinguish mere crap from super extra deluxe double crap. It's all crap. I'm not sure what part of this is either confusing or in the least bit ambiguous. Let me frame this another way... Is it not the purpose of the RIRs to assign numbers to specific parties and then and thereafter to beg, cajole, and encourage everyone to stay in their own assigned lanes? If the number 1 job of the RIRs is not to at least try to bring order out of what would otherwise be chaos then I would ask: What then IS their fundamental purpose? Right now RIPE is effectively endorsing the chaos of people and companies just willy nilly selecting AS numbers at random, and according to whim, and then creating route objects IN THE RIPE DATA BASE for those. All I can say is "Thank God people don't feel equally free to ignore the rules and drive on whichever side of the road they feel like driving on on any particular day!"
So could we please look at data for reserved ASNs (not unallocated ASNs) without trying to argue that any bogon is a bogon.
By all means. I provided the data for all route objects currently present in both the AUTH and NONAUTH data bases which reference some bogon ASN. The format of all of the lines in those data files was and is as simple as it was (and is) obvious: <datestamp> <CIDR> <ASN> If you wish to filter the data I provided so as to generate lists that only mention some subset of all of the globally unassigned ASNs that are mentioned in those lists, then by all means, be my guest. I think it could be done in about 15 lines of Perl, tops. Personally however, as noted above, I don't really see the point, and I do believe that I'd rather spend (waste?) my time arguing over how many angels can dance on the head of a pin. Bogons are bogons. Bogons delenda est. Regards, rfg
participants (4)
-
Cynthia Revström -
Hank Nussbacher -
Job Snijders -
Ronald F. Guilmette