This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg] [anti-abuse-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
- Previous message (by thread): [routing-wg] [anti-abuse-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
- Next message (by thread): [routing-wg] [anti-abuse-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
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald F. Guilmette
rfg at tristatelogic.com
Tue Dec 24 00:08:35 CET 2019
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
- Previous message (by thread): [routing-wg] [anti-abuse-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
- Next message (by thread): [routing-wg] [anti-abuse-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
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]