[anti-abuse-wg] [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List

You're suggesting that RIR should have reasonable oversight of internet resources?
 
That would make too much sense!
 
In the mean time, here's a brick wall for you to hit your head against:
 
https://www.cdc.gov/nceh/radiation/images/BrickWall.jpg
 
In reality, the RIR (and ICANN) should be arrested for aiding & abetting serious crimes.
 
 
Imagine a bank robber runs in to your back yard, and the police want to enter to arrest them and you stand there saying "WELL DERRR, UNDER POLICY 18/2019, WE HAVE NO CONTROL OVER THIS YARD, SO WE CANNOT AUTHORISE THAT, SO DUUHHHH HER DERRRRRRR YOU NEED TO CONTACT THE JANITOR WHO OWNS THIS RESOURCE AND WHO CARES IF THEY DON'T EVEN CHECK THEIR INBOX FOR THE NEXT 2 YEARS, DUHH DERRRR.."
 
You would be charged with obstruction.
 
Absolutely the RIR employees and ICANN should be arrested and imprisoned.
 
 
 
 
--------- Original Message --------- Subject: Re: [anti-abuse-wg] [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List
From: "Ronald F. Guilmette" <rfg at tristatelogic.com>
Date: 12/24/19 11:57 am
To: "anti-abuse-wg at ripe.net" <anti-abuse-wg at ripe.net>, "RIPE Routing WG" <routing-wg at ripe.net>

In message <CACWOCC--q4g06o62Emtw08Skt+AY9EL4VOTAURRHHJkt+HR1+g at mail.gmail.com>
 Job Snijders <job at ntt.net> wrote:
 
 >On Tue, Dec 24, 2019 at 12:09 AM Ronald F. Guilmette
 ><rfg at tristatelogic.com> wrote:
 >> I feel sure that other IRRs have some or all of the same issues. RADB
 >> stands out however due to its continued widespread use.
 >
 >The above statement is true, and the good news is that there is work
 >under way to reduce the clutter!
 >
 >The largest IRRs (RADB, NTTCOM, ARIN, ALTDB, others) are either
 >actively working on, or have added to their roadmap, a variant of this
 >type of cleanup: https://www.ripe.net/publications/docs/ripe-731
 
 Long overdue, IMHO. I mean it isn't as if the bogus/fradulent routing
 problem just appeared last month or anything. The games and funny business
 have been going on for years now, aided and abetted, in many cases, by an
 apparent utter lack of attention by IRR oprrators.
 
 >For most of these IRR operators there is a project dependency on IRRd
 >4's ability to delete or suppress IRR "route:" objects that are in
 >conflict with RPKI data. This is tracked in
 >https://github.com/irrdnet/irrd4/issues/197 and hopefully the code can
 >be made available in Q1 2020 as part of the "IRRd 4.1" release. This
 >release in turn means for most organisations that they can probably
 >deploy in Q2 or Q3 2020 (after internal software testing & customer
 >outreach).
 >
 >Given that there is active work underway in the community - I would
 >like to suggest that the topic of "stale data in IRRs" is brought up
 >again in about 6 months...
 
 With all due respect to my friend Job, I am, have been, and remain totally
 flummoxed and appalled by the consistant lack of urgency, within the
 Internet community generally, with respect to what could be, quite
 obviously, a swift, effective, and sensible resolution of many of these
 problems, even without the need for any grand policy pronouncements or
 fornalized ratifications thereof. It shouldn't take a genius to note
 that multiple conflicting route objects cannot all be right, or that
 route objects to reserved or unallocated space, or involving reserved
 or unallocated ASNs are, on their faces, utter rubbish which can be and
 which ought to be removed from any IRR that contains them, immediately if
 not sooner.
 
 If any of these RIR operators are unable to develop scripts, within one
 man-week, which would detect and purge route objects for unallocated
 space or involving unallocated ASNs, then they obviously are reserving
 their available cash for Christmas parties or executive bonuses in lieu
 of adequate salaries for competent professional software engineers, and
 even in those cases, I stand ready to volunteer my time to help each one
 to do its homework, as may be needed... and not six months from now, but
 by early January.
 
 Clearly, an awful lot of people are not looking at the things I am looking
 at, and this is apparently the root of the problem when it comes to the
 apparent lack of urgency. It is unfortunate that I must coordinate with
 others in order to arrange for properly timed releases of what I know, but
 that is unavoidable. In the meantime, I can only state for the record
 that if people knew about the various kinds of criminality that are
 currently ongoing with and from a lot of these bogus and, for now at
 least, IRR-sanctioned routes, then people wouldn't be taking the relaxed
 attitude that all of this can and should be revisited in six months.
 Innocent victims are being conned, ripped-off, and hacked every single
 day, and as inconvenient as it may be for the rest of us, the scammers,
 hackers, and criminals of the Internet are quite certainly not taking
 Christmas off, nor are they dedicating any of their time to long term
 scheduling, lengthy policy debates, committee meetings, or the development
 of roadmaps.
 
 I see no compelling reason why all IRRs either cannot or should not be
 able to remove from their respecting published data bases 100% of all
 route objects that refer to unalocated number resources by no later
 than 2020-01-01 00:00:00 UTC, nor do I see any compelling reason why
 they should not do so. This is not rocket surgery. Failure to take
 these obvious remedial actions, and in short order, represents an
 implicit acceptance of the victimization of yet more innocent parties.
 
 
 Regards,
 rfg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20191223/8656a2d3/attachment.html>