Michael Horn wrote: (to anti-abuse-wg@ripe.net)

[...]

...

will result in significant workload. Holy dingus, is this database a mess... And not just "this" one. The whole "Routing Registry" stuff is an incredible mess, and since years, actually. Not really a Numbers Registry failure or a negligence, but rather a multi-faceted mesh of FUD, History and Trade Secrets claimed.

Let me try to collect some facts, at least according to my memory. Please correct me where I'm wrong...

- not all 5 RIRs actually do support an IRR functionality.

- the RPSL doc.set, back in the good old days, had some ideas and provisions for integrating the 5 (or then, rather 3, iirc) pieces of Numbers Registries into a single, global, consistent structure. As Gert put it: it didn't fly. Since then, we were putting band-aid over patch over whatever to deal with that. The result is what we have before us, right now.

- the whole system of creating objects, at least in the RIPE Region, has become totally inconsistent. For an address block, where the RIPE DB is authoritative, and an AS number, you need the credentials from both parties to register a route: or route6: object.

for out-of-region authoritative entries, the dreaded maintainer was created, in order to provide the (useless) 2nd auth: token.

For the RPKI stuff, again, there isn't a requirment for a second authentication token, iirc not even a *notification* to the AS ref.d, when an RoA is created. Anyone of you still thinks RPKI is going to be helpful here? Bah, it's just going to give another false impression of credibility + new vectors for errors and attacks.

...

-mh The only way(s) forward I can see are:

- require manual approval of route: objects for the case of out-of-region registrations sounds like an other patch, one that I would welcome as a temporary solution.

- get the RPSL flaws fixed, the RFCs updated and then implemented

Hi Wilfried, finally someone responding to the problem presented. I was about to think that nobody cares anymore. On 14/11/14 16:18, Wilfried Woeber wrote: this will probably take years..

- integrate the 5 Number Registries into a homogenous, distributed DB with consistent authentication mechanisms

- come up with a viable proposal for 1 (one!!) global routing registry that is authoritative, up-todate and complete, used by all operators (yes, I know, it is the wrong type of year /w a XMAS)

I've been asking myself for years why the RIRs can not, under the NRO, ASO, IANA, (?) umbrellas to come up with a unique registry (resource + routing).. It's not like the communities do not want/need it... Do we need to pass a global policy to ask the RIRs to work together? :-) A single source of information is, at this moment, a dream.

- try to do any or all of the above and do so without RPKI requirements. Please!

Wilfried.

regards, elvis

In message <54661D46.8080200@CC.UniVie.ac.at>, Wilfried Woeber <Woeber@CC.UniVie.ac.at> wrote:

The only way(s) forward I can see are:

- require manual approval of route: objects for the case of out-of-region registrations ...

This would seem to be a simple thing to implement... no? Every allocated IP block in every region has... or should have... an existing WHOIS record which is stored in the relevant RiR's WHOIS data base. Each of those records contains a contact e-mail address for the registrant of that IP block. So if some party `X' requests the creation of a route object within the RIPE DB which refers to some IP address block `Y' which is out-of-region, then that request could be held in a ``pending'' queue and an e-mail message requesting confirmation of the request could be sent... with a magic crypto token... to the actual registrant of the IP block, asking for his/her approval of the request. And the route object would not be created unless and until the actual registrant of the block responds, with an affirmative response, to the request for confirmation. None of what I have just described requires either RPKI or any other particularly fancy technology. all that is required is that kind of confirmation process that is already implmented and used for millions of mailing lists already, today, worldwide, INCLUDING THIS ONE. So why not just do that? Regards, rfg P.S. If there are IP address blocks in other regions which _do_ have associated WHOIS records but which _do not_ have working contact e-mail addresses within the WHOIS records for those blocks then... a) Whose fault is that? b) It would be, I think, a profoundly Good Thing if some new RIPE procedures or processes were to actually encourage all registrants of IP blocks worldwide to at least keep their &$%@&#$ contact e-mail addresses up to date. P.P.S. Regarding point (b) above, I would like to note, for everyone's benefit, that when I first noticed the scope of what was going on with AS201640 it was, at that time, hijacking eleven (11) separate IP blocks. I personally took it upon myself to send warning e-mails about this to _every_ e-mail contact I could find, anywhere, for each one of those eleven different companies. The results of this effort were as follows: a) Many undeliverable bounces. b) Zero actual replies to any of my warnings. c) Nothing at all changed in terms of who was routing what. In short, I think that it is safe to say that: a) There exist many IP block registrations, wouldwide, where the associated contact e-mail addresses have become completely stale. b) There exist many IP block registrations, wouldwide, where the associated contact e-mail addresses have been either functionally or actually aliased to /dev/null. c) Nobody except those few people who fight against fraud, crime, and spam on the Internet seems to even give a damn about either (a) or (b). d) The fix for (a) and (b) is simple and obvious... require (re-)verification of all contact e-mail addresses at least annually, or better yet, quarterly. In contrast, I have no idea how to fix (c), which is a political problem.