In message <[email protected]>,
Elvis Daniel Velea <[email protected]> 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
