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
as Alexander Azimov pointed out: people can just announce a *less* specific, which will be "Not Found" even if an AS0 ROA exists for more specific. And because there is no competing (valid/not found) announcement they will attract the traffic.
this was brought up in the sidr wg when as0 was first proposed. but it is very hard to stop the bright idea train in sidr[ops] or the ietf in general. randy
Regarding this general idea of having some authority make route announcements for unallocated/unassigned blocks, Mr. Azimov is quite clerly correct that Bad Actors could still promulgate more specific announcements. The solution is obvious. All such preemptive announcements could be deaggregated down to the /24 level. This would not be dramatically different from what innumerable foolish providers are already doing on a fairly routine basis, and the net effects would surely make the equipment vendors almost as happy as IPV6. An alternative that seems to have gotten rather less attention would be to simply work to try to get all of the toxic sludge that is currently present in various IRRs (not including RIPE anymore, thank goodness) cleaned up. Until such time as more than 50% of the net is actively using and relying on RPKI, this is the low hanging fruit with regards to routing security. The most glaring offender is RADB. Today, even nearly a month after the ``explosive'' article in the South African publication mybroadband.co.za regarding the activities of a corrupt insider in Afrinic, and even after reports relative to that have allegedly been filed with relevant law enforcement bodies, I daresay that there are still route objects in RADB for a fair amount of the illictly purloined IPv4 space. But that is not even nearly the end of the rot that is present there. Additionally, I have seen instances of route objects in RADB involving IPv4 blocks that were formally and fully reclaimed by the relevant RIRs years ago, and in a similar vein, RADB also contains route objects for ASNs that were likewise reclaimed by their respective RIRs years ago. I have written to the RADB maintainers about some of these issues in the past. My emails were ignored and I was not even given the courtest of a reply to inform me that my messages were being ignored. In short, it appears from where I sit that RADB is being run on autopilot. It is certainly not being "maintained" in any sense of the word that I am familiar with. If RADB were a toxic waste dump, it would be among those that we here in the U.S. refer to as a "Superfund site". I feel sure that other IRRs have some or all of the same issues. RADB stands out however due to its continued widespread use. I say again that the glaring issues relating to the serious lack of competent maintenance of IRRs generally is the low hanging fruit of routing security. As such, my hope is that others will join me in at least trying to get the attention of RADB management focused on a long-overdue and badly-needed competent cleanup effort. Regards, rfg
Dear all, On Tue, Dec 24, 2019 at 12:09 AM Ronald F. Guilmette <rfg@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 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. After the deployment of IRRd 4.1 we'll have a better view on what is still needs to be cleaned up and what mechanism can be used. Kind regards, Job
In message <CACWOCC--q4g06o62Emtw08Skt+AY9EL4VOTAURRHHJkt+HR1+g@mail.gmail.com> Job Snijders <job@ntt.net> wrote:
On Tue, Dec 24, 2019 at 12:09 AM Ronald F. Guilmette <rfg@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
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@tristatelogic.com> Date: 12/24/19 11:57 am To: "anti-abuse-wg@ripe.net" <anti-abuse-wg@ripe.net>, "RIPE Routing WG" <routing-wg@ripe.net> In message <CACWOCC--q4g06o62Emtw08Skt+AY9EL4VOTAURRHHJkt+HR1+g@mail.gmail.com> Job Snijders <job@ntt.net> wrote:
On Tue, Dec 24, 2019 at 12:09 AM Ronald F. Guilmette <rfg@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
In message <20191223180753.af7f9f79718891d8e76b551cf73e1563.1c863887b3.mailapi@ email19.godaddy.com>, "Fi Shing" <phishing@storey.xxx> wrote:
You're suggesting that RIR should have reasonable oversight of internet resources?
Not really. My comments weer directed rather explicitly at IRRs, which is a somewhat different set of entities, albeit with a considerable overlap.
In reality, the RIR (and ICANN) should be arrested for aiding & abetting serious crimes. ... Absolutely the RIR employees and ICANN should be arrested and imprisoned.
Thank you for sharing Mr. Fi Shing. I myself would not go quite that far, even retorically, and indeed, I am conflicted about even lesser remedies. On the one hand, part of me would like nothing better than to see certain poorly maintained IRRs end up on the business end of at least one civil legal action charging vicarious liability and/or professional negligence. This would quite certainly get everyone's attention. On the other hand, I am mindful of the fact that even the vague possibility of some such civil legal action has been asserted as the basis for ARIN's demand for indemnification from all those wishing to avail themselves of ARIN's RPKI-related services, and that this in turn has purportedly been responsible for retarding the adoption of RPKI materially and globally. Given this contextual backdrop, I continue to hope that we in the technical community will continue, as we have, to try find ways to solve what are fundamentally technical problems of our own making, without resort to fisticuffs, war, attorneys, or law enforcement. Wherever possible, we should clean up our own messes, and serious public/peer pressure on the wayward IRRs has not yet been adequately explored as a means to the desired result. Regards, rfg
participants (4)
-
Fi Shing -
Job Snijders -
Randy Bush -
Ronald F. Guilmette