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/routing-wg@ripe.net/
[routing-wg] Routing Reg. mess [was: Re: [anti-abuse-wg] Fwd: Hijack...]
- Previous message (by thread): [routing-wg] Routing Reg. mess [was: Re: [anti-abuse-wg] Fwd: Hijack...]
- Next message (by thread): [routing-wg] "Proposal for signaling consent from whacked RPKI objects"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald F. Guilmette
rfg at tristatelogic.com
Sun Nov 16 21:50:34 CET 2014
In message <54661D46.8080200 at CC.UniVie.ac.at>, Wilfried Woeber <Woeber at 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.
- Previous message (by thread): [routing-wg] Routing Reg. mess [was: Re: [anti-abuse-wg] Fwd: Hijack...]
- Next message (by thread): [routing-wg] "Proposal for signaling consent from whacked RPKI objects"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]