In message <545FDE27.7030702@velea.eu>, Elvis Daniel Velea <elvis@velea.eu> wrote:
*Regarding the future process:** * I do not think it will be that easy to come up with a process. RPKI may not be available for legacy (or independent) resources in all the regions. I think this means the RIRs will first need to speed up the deployment of RPKI for all the resources in their registries...
In a first step, a quick fix would be to reject the creation of a rogue route object in (for example) the RIPE Database if the other RIR has a valid registered ROA. But we should not reject the registration if the ROA is not valid; not yet, not before all the resources can be covered by RPKI.
Can anyone speak to this? What resources in what registries cannot currently be covered by RPKI? If the answer is "none", then there is no problem with requiring that right now, correct? I confess that as a relative outsider to all these matters, I am more than a little mystified by the suggestion, here in late 2014, that RPKI might be unavailable for certain resources in certain registries. I say that because I read this: http://www.bgpmon.net/securing-bgp-routing-with-rpki-and-roas/ which suggests that RPKI was rolled out by all five RiRs sometime during 2011 (or even earlier, in the case of APNIC). So if the infrastructure really is all there already, then what's the problem?
Finally, The RIPE NCC will need a clear mandate from us, the community on the process they should follow in order to forcefully delete objects considered to be rogue.
Cart, horse. Firstly, it appears that RIPE NCC may need some guidance about the set of conditions which should cause them to ``consider to be rogue'' a particular AS or other number resource. Deletion could only follow recognition. And if the comment made here yesterday is true, i.e. that RIPE NCC has already had a ticket open on AS201640 for two full months already, then it would seem to that RIPE NCC may not yet consider this thing to be ``rogue'', either according to their formal operating procedures, or perhaps even in any other sense. So that would appear to be the first order problem.
I personally find it difficult to understand how come that a 'company' can hijack 43 prefixes from various RIRs and still operate after more than two and a half months.
Ummm... yea. I was kind-of wondering about that myself. In fact, that's the reason I came here, to this mailing list, i.e. to find out either what has been done about this, or what is being done about this, or what could yet be done about this.
If it would be just for me, I would ask the RIPE NCC to delete _today_ the route objects and the aut-num object. But, it's not just me, what does the rest of the wg say?
I have been working, in my own way, to rid the Internet of spammers since about 1995. Given that, and the fact that there is now abundant proof that the IP space associated with some of these routes has been used, and indeed most probably is being used, as we speak, for, at the very least, spamming, I think that everyone should easily be able to infer which way I would vote on this question, if asked. But in case not, I will be plain: I would fervently like to see these route announcements not just killed but annihilated, with extreme prejudice, and not merely immediately, but yesterday. (I understand that RIPE NCC cannot directly affect either the announcements or their propagation, but they certainly can affect the data which appears to validate the announcements.) Regards, rfg