The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top
The entire set of objects in the RIPE WHOIS data base that are currently registered with mnt-by: MNT-SERVERSGET is listed here: https://pastebin.com/raw/GiYWxHMh Among this set of objects there are 235 separate route objects. Evidence indicates persuasively that some sizable fraction of these RIPE- registered route objects are fradulent and are simply there to provide cover for multiple IPv4 address block hijacks. The presence of these objects in the data base permits the following set of ASNs to claim that they are acting "legitimately" even as they route these hijacked blocks: AS9009 M247 Ltd (UK) AS43350 NFOrce Internet Sevices (Netherlands) AS57129 Optibit, LLC (Russia) AS197328 Istanbuldc Veri Merkezi Ltd. Sti (Turkey) AS202287 Men Danil Valentinovich (Russia) AS204895 Santa Plus, LLC (Russia) The total amount of IPv4 space encompassed within the set of route objects registered with mnt-by: MNT-SERVERSGET at the present time amounts to eight hundred and fifty nine (859) /24 blocks. Of these, only three hundred and five (305) actually have correctly functioning and properly delegated reverse DNS at the present time, and even among those, only two hundred and two (202) have functioning reverse DNS delegations to the prefered name servers of MNT-SERVERSGET, which is to say the name servers ns5.dnsget.top and ns6.dnsget.top. The bottom line is that it appears that, at the present time, something less than 1/4 of all of the IPv4 address space currently registered in the RIPE data base (via route objects) by and to MNT-SERVERSGET is space for which a plausible case could be made that the blocks in question are actually legitimately assigned to and/or under the legitimate control of whoever or whatever is MNT-SERVERSGET. The other 3/4ths of the IPv4 space in question has provenance which is, at best, dubious. Due to its use of little country-of-registration flags for each IP address block, the web site bgp.he.net provides the most visually obvious indications of at least two of the specific block hijacks in this case, specifically the hijacks of 27.103.192.0/19 and 36.0.192.0/19 by AS57129: https://bgp.he.net/AS57129#_prefixes Based upon the foregoing, I hereby respectfully request RIPE NCC to undertake an immediate and conmprehensive review of all objects in the data base that are currently registered with mnt-by: MNT-SERVERSGET. Additionally, I also respectfully request RIPE NCC to publish the results of this review to the mailing lists of the Database Working Group and the Anti-Abuse Working Group. The charters of both of these Working Groups are directly relevant to this issue, and there exists neither need nor reason to simply sweep this issue quietly under the carpet, as has been done in previous and similar cases. Cases such as this, and the two others of similar magnitude that I have publicly disclosed just this summer, affect the operation of, the stability of, and the continued enjoyment of the entire planetary Internet and its billions of users. Despite its status as a strictly private corporation, RIPE has a public responsibility, not only to handle such incidents responsibly and competently, but to show the world that it is ready, willing, and able to do so. The responses of RIPE to prior instances of this exact type of bad behavior have been largely or entirely cloaked in secrecy, presumably to protect the guilty. This longstanding and antiquated tradition of omerta within the RIPE community is unambiguously counterproductive to the goal of a well-managed and properly fuctioning Internet. Just as importantly, it naturally gives rise to unavoidable questions about the actual competence of, and capabilities of RIPE NCC staff as they attempt to deal with such incidents. I personally feel that RIPE NCC staff are doing the best they can when responding to incidents such as this, but the tradition of playing "hide the ball" with respect to their actions in such cases reflects badly on them, and badly on RIPE generally. It certainly raises doubts about RIPE's claim to authority over even its own data base. Lastly, I respectfully request both the RIPE Executive Board and the RIPE membership to make plain and explicit their respective intentions with regards to the various bad actors that have been caught, and that may in future be caught red handed engaging in the deliberate and premeditated corruption of the RIPE data base. To date, the policies an actions that RIPE applies, or which RIPE may apply to such bad actors have been shrouded in apparently deliberate secrecy and mystery. To put this request in more concrete terms, I would like to know if RIPE and the Executive Board actually and deliberately intend to take no action whatsoever with respect to the ongoing RIPE memberships of clearly identified bad actors, specifically, in this case, whatever persons or entities are currently hiding behind the RIPE WHOIS handle MNT-SERVERSGET (aka AS202287 and AS202275), which would appear to be this specific entity / RIPE member: https://www.ripe.net/membership/indices/data/ru.danil.html Is it the express intention of both the Board and the RIPE membership to simply deprive this bad actor of just those fradulent data base entries that have effectively legitimized his/her/its fradulent routing announcements? Is it the express intention of both the Board and the RIPE membership to simply make this bad actor give back what he has stolen, and to otherwise take no action, just as the response has been in the two other and similar cases that have also arisen in the RIPE region and that I have also publicly reported on this summer? https://mailman.nanog.org/pipermail/nanog/2018-June/096034.html https://mailman.nanog.org/pipermail/nanog/2018-July/096437.html My question is prompted by the following simple facts. In the two prior cases cited above, and also in the one I am presenting here today, the bad actors involved were seen to have not only hijacked large swaths of IP address space that clearly didn't belong to them, but also, as in the case I am presenting today, these same bad actors additionally acted to corrupt the RIPE data base with premeditated and deliberately fradulent entries. Nonetheless, and regardless of these attacks on the reliability and trustworthyness of the RIPE data base, to date it appears that no action whatsoever has been taken which might affect the ongoing RIPE memberships of the relevant parties and bad actors involved, and they are all still members in good standing of RIPE at the present time: https://www.ripe.net/membership/indices/data/pt.bitcanal-pt.html https://www.ripe.net/membership/indices/data/ua.d2investukraine.html https://www.ripe.net/membership/indices/data/bz.universal.html This is, to say the least, puzzling. I would like to know when, where, and how the Executive Board and/or the RIPE membership reached the altogether dubious conclusion that the best possible way to deal with bad actors such as these is to make them give back -just- the stuff the stole, and then to otherwise impose no penality of any kind, thus allowing them to live on, so that they may hijack another day. Whether this policy is a result of either deliberation or default, it *does* appear to be the policy, based on the evidence. Without intending to be rude, I feel that I must ask the obvious question: In what Universe does this otherwise admirable and generous Christian policy of "turning the other cheek" with respect to such verified bad actors have any effect other than encouraging the next hijacker, and then next one, and the one after that? Has either the Board or the membership even ever seriously debated what penalties should be imposed upon those members who are caught red handed deliberately corrupting the RIPE data base? Is the present RIPE policy of "forgive and forget" with respect to such travesties a product of anyone's intentional design, or is it instead merely the result of utter apathy and indifference on the part of the entire RIPE community? In either case, I believe it to be self evident that the time is... ummm... blooming, blossoming, burgeoning, flourishing, and flowering for this policy to be reexamined and revised. From where I am sitting it is self evident that the current policy of turning a blind eye to these events, and to the bad actors behind them is quite clearly encouraging others to follow suit and to themselves undertake the exact same sorts of travesties. Why shouldn't they? There is no downside. At the very worst, one is simply made to give back all of the stuff that one has stolen, and one is then allowed to go on one's merry way. Regards, rfg P.S. As incensed as I am at the fact that the above named bad actors have been allowed not only to retain their RIPE memberships, but also, apparently, 100% of their legitimately-allocated number resources, this is not even nearly as utterly appalling and inexplicable as the fact that two of the bad actors with direct and provable connections to the prior instances of hijacking that I have reported on publicly this summer have been allowed to remain as officially recognized RIPE IP brokers: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/brok... I am referring here specifically to Ebonyhorizon Telecomunicacoes Lda (aka Bitcanal) and also to NetAssist LLC (AS29632), which conveniently continues to maintain its association with, and peering arrangements with both AS57166 aka D2 International Investment Ukraine, Ltd. and, indirectly via D2, AS205869 aka Universal IP Solution Corp., both of which apparently continue to this day to try their best to hijack, either directly or indirectly, via AS Path fraud, a number of IPv4 blocks that clearly do not belong to any of these three Ukranian entities: https://bgp.he.net/AS57166#_peers https://bgp.he.net/AS205869#_peers https://bgp.he.net/AS29632#_peers What IP blocks are these two officially recognized RIPE IP brokers, Ebony Horizon and NetAssist brokering, exactly? Are they blocks that have been successfully hijacked? Does either RIPE or RIPE NCC even know? Does either RIPE or RIPE NCC even care? (One cannot help but wonder what might occur if RIPE were put in charge of distributing meat supplies within Europe. Would RIPE officially designate the McDonald's "Hamburglar" as RIPE's officially recognized agent for said distributions?) I guess that, in the end, all of the questions I have raised above can be boiled down to just one simple question: Who exactly does one need to either kill or maim or seriously wound in order to get kicked out of this organization (RIPE)? Regards, rfg P.P.S. Among the set of six companies / ASNs listed toward the top of this message as possible facilitators of the current hijacks of MNT-SERVERSGET, three are already fairly well known... at least in anti-spam circles... as being among "the usual suspects" when it comes to facilitating spamming and spammers. And no, I do not care to publicly specify which three. It may be true, as the saying goes that "On the Internet, nobody knows that you're a dog", but memories are long, and people don't forget if your company has been repeatedly caught acting like one.
Hi Ronald, I'll respond here ( AA-WG ML) to ask you a couple clarifying questions about this HUGE post that you made and the amount of cross links. I've put the other WG's in BCC, and will only reply to the anti-abuse WG ML to have it correctly documented in a single WG. So if someone would like to comment, please do it only in AA-WG. I've seen the bitcanal story and from what I can see in your email, your are stating that there are a lot of prefixes where mnt-serversget is listed as either the maintainer or the mnt-route or mnt-domain contact. From my experience, it wouldn't be possible, without the owners permission of the actual resource, to put the maintainer of mnt-serversget in any of those objects. Stating that some or most of the listed prefixes don't have their reverse DNS in place isn't a reason, last time I checked, to take some kind of action ... So the question that I have with all the information that you stated here. - Are they doing something (Other than 'probably' leasing IP space) wrong ?? - Are the leased or used prefixes used to send out spam or host malware or do something else that is frowned upon ? or even illegal.. ( And is there proof of spam source or hijacking etc.. ? ) - Are the prefixes they used / leased perhaps not cleaned by the current legit holder ... for some reason .. Because from all the information that you stated, that is not something I could get out of your email. If you want to get the exec-board to take action to a listed broker, that should be take up with the exec-board and the NCC. It is my experience that they are very responsive if you have the situation presented that a child could understand it. Because if it is based on speculations, it is very hard to take action on members. If you want someone to take action on something, it is probably best to make the case a bit more clear, as it is for me (and I actually like to read stuff like this and see if I can find the same or something else.. ) very unclear what the goal is.. Regards, Erik Bais On 10/08/2018, 02:08, "anti-abuse-wg on behalf of Ronald F. Guilmette" <anti-abuse-wg-bounces@ripe.net on behalf of rfg@tristatelogic.com> wrote: The entire set of objects in the RIPE WHOIS data base that are currently registered with mnt-by: MNT-SERVERSGET is listed here: https://pastebin.com/raw/GiYWxHMh Among this set of objects there are 235 separate route objects. Evidence indicates persuasively that some sizable fraction of these RIPE- registered route objects are fradulent and are simply there to provide cover for multiple IPv4 address block hijacks. The presence of these objects in the data base permits the following set of ASNs to claim that they are acting "legitimately" even as they route these hijacked blocks: AS9009 M247 Ltd (UK) AS43350 NFOrce Internet Sevices (Netherlands) AS57129 Optibit, LLC (Russia) AS197328 Istanbuldc Veri Merkezi Ltd. Sti (Turkey) AS202287 Men Danil Valentinovich (Russia) AS204895 Santa Plus, LLC (Russia) The total amount of IPv4 space encompassed within the set of route objects registered with mnt-by: MNT-SERVERSGET at the present time amounts to eight hundred and fifty nine (859) /24 blocks. Of these, only three hundred and five (305) actually have correctly functioning and properly delegated reverse DNS at the present time, and even among those, only two hundred and two (202) have functioning reverse DNS delegations to the prefered name servers of MNT-SERVERSGET, which is to say the name servers ns5.dnsget.top and ns6.dnsget.top. The bottom line is that it appears that, at the present time, something less than 1/4 of all of the IPv4 address space currently registered in the RIPE data base (via route objects) by and to MNT-SERVERSGET is space for which a plausible case could be made that the blocks in question are actually legitimately assigned to and/or under the legitimate control of whoever or whatever is MNT-SERVERSGET. The other 3/4ths of the IPv4 space in question has provenance which is, at best, dubious. Due to its use of little country-of-registration flags for each IP address block, the web site bgp.he.net provides the most visually obvious indications of at least two of the specific block hijacks in this case, specifically the hijacks of 27.103.192.0/19 and 36.0.192.0/19 by AS57129: https://bgp.he.net/AS57129#_prefixes Based upon the foregoing, I hereby respectfully request RIPE NCC to undertake an immediate and conmprehensive review of all objects in the data base that are currently registered with mnt-by: MNT-SERVERSGET. Additionally, I also respectfully request RIPE NCC to publish the results of this review to the mailing lists of the Database Working Group and the Anti-Abuse Working Group. The charters of both of these Working Groups are directly relevant to this issue, and there exists neither need nor reason to simply sweep this issue quietly under the carpet, as has been done in previous and similar cases. Cases such as this, and the two others of similar magnitude that I have publicly disclosed just this summer, affect the operation of, the stability of, and the continued enjoyment of the entire planetary Internet and its billions of users. Despite its status as a strictly private corporation, RIPE has a public responsibility, not only to handle such incidents responsibly and competently, but to show the world that it is ready, willing, and able to do so. The responses of RIPE to prior instances of this exact type of bad behavior have been largely or entirely cloaked in secrecy, presumably to protect the guilty. This longstanding and antiquated tradition of omerta within the RIPE community is unambiguously counterproductive to the goal of a well-managed and properly fuctioning Internet. Just as importantly, it naturally gives rise to unavoidable questions about the actual competence of, and capabilities of RIPE NCC staff as they attempt to deal with such incidents. I personally feel that RIPE NCC staff are doing the best they can when responding to incidents such as this, but the tradition of playing "hide the ball" with respect to their actions in such cases reflects badly on them, and badly on RIPE generally. It certainly raises doubts about RIPE's claim to authority over even its own data base. Lastly, I respectfully request both the RIPE Executive Board and the RIPE membership to make plain and explicit their respective intentions with regards to the various bad actors that have been caught, and that may in future be caught red handed engaging in the deliberate and premeditated corruption of the RIPE data base. To date, the policies an actions that RIPE applies, or which RIPE may apply to such bad actors have been shrouded in apparently deliberate secrecy and mystery. To put this request in more concrete terms, I would like to know if RIPE and the Executive Board actually and deliberately intend to take no action whatsoever with respect to the ongoing RIPE memberships of clearly identified bad actors, specifically, in this case, whatever persons or entities are currently hiding behind the RIPE WHOIS handle MNT-SERVERSGET (aka AS202287 and AS202275), which would appear to be this specific entity / RIPE member: https://www.ripe.net/membership/indices/data/ru.danil.html Is it the express intention of both the Board and the RIPE membership to simply deprive this bad actor of just those fradulent data base entries that have effectively legitimized his/her/its fradulent routing announcements? Is it the express intention of both the Board and the RIPE membership to simply make this bad actor give back what he has stolen, and to otherwise take no action, just as the response has been in the two other and similar cases that have also arisen in the RIPE region and that I have also publicly reported on this summer? https://mailman.nanog.org/pipermail/nanog/2018-June/096034.html https://mailman.nanog.org/pipermail/nanog/2018-July/096437.html My question is prompted by the following simple facts. In the two prior cases cited above, and also in the one I am presenting here today, the bad actors involved were seen to have not only hijacked large swaths of IP address space that clearly didn't belong to them, but also, as in the case I am presenting today, these same bad actors additionally acted to corrupt the RIPE data base with premeditated and deliberately fradulent entries. Nonetheless, and regardless of these attacks on the reliability and trustworthyness of the RIPE data base, to date it appears that no action whatsoever has been taken which might affect the ongoing RIPE memberships of the relevant parties and bad actors involved, and they are all still members in good standing of RIPE at the present time: https://www.ripe.net/membership/indices/data/pt.bitcanal-pt.html https://www.ripe.net/membership/indices/data/ua.d2investukraine.html https://www.ripe.net/membership/indices/data/bz.universal.html This is, to say the least, puzzling. I would like to know when, where, and how the Executive Board and/or the RIPE membership reached the altogether dubious conclusion that the best possible way to deal with bad actors such as these is to make them give back -just- the stuff the stole, and then to otherwise impose no penality of any kind, thus allowing them to live on, so that they may hijack another day. Whether this policy is a result of either deliberation or default, it *does* appear to be the policy, based on the evidence. Without intending to be rude, I feel that I must ask the obvious question: In what Universe does this otherwise admirable and generous Christian policy of "turning the other cheek" with respect to such verified bad actors have any effect other than encouraging the next hijacker, and then next one, and the one after that? Has either the Board or the membership even ever seriously debated what penalties should be imposed upon those members who are caught red handed deliberately corrupting the RIPE data base? Is the present RIPE policy of "forgive and forget" with respect to such travesties a product of anyone's intentional design, or is it instead merely the result of utter apathy and indifference on the part of the entire RIPE community? In either case, I believe it to be self evident that the time is... ummm... blooming, blossoming, burgeoning, flourishing, and flowering for this policy to be reexamined and revised. From where I am sitting it is self evident that the current policy of turning a blind eye to these events, and to the bad actors behind them is quite clearly encouraging others to follow suit and to themselves undertake the exact same sorts of travesties. Why shouldn't they? There is no downside. At the very worst, one is simply made to give back all of the stuff that one has stolen, and one is then allowed to go on one's merry way. Regards, rfg P.S. As incensed as I am at the fact that the above named bad actors have been allowed not only to retain their RIPE memberships, but also, apparently, 100% of their legitimately-allocated number resources, this is not even nearly as utterly appalling and inexplicable as the fact that two of the bad actors with direct and provable connections to the prior instances of hijacking that I have reported on publicly this summer have been allowed to remain as officially recognized RIPE IP brokers: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/brok... I am referring here specifically to Ebonyhorizon Telecomunicacoes Lda (aka Bitcanal) and also to NetAssist LLC (AS29632), which conveniently continues to maintain its association with, and peering arrangements with both AS57166 aka D2 International Investment Ukraine, Ltd. and, indirectly via D2, AS205869 aka Universal IP Solution Corp., both of which apparently continue to this day to try their best to hijack, either directly or indirectly, via AS Path fraud, a number of IPv4 blocks that clearly do not belong to any of these three Ukranian entities: https://bgp.he.net/AS57166#_peers https://bgp.he.net/AS205869#_peers https://bgp.he.net/AS29632#_peers What IP blocks are these two officially recognized RIPE IP brokers, Ebony Horizon and NetAssist brokering, exactly? Are they blocks that have been successfully hijacked? Does either RIPE or RIPE NCC even know? Does either RIPE or RIPE NCC even care? (One cannot help but wonder what might occur if RIPE were put in charge of distributing meat supplies within Europe. Would RIPE officially designate the McDonald's "Hamburglar" as RIPE's officially recognized agent for said distributions?) I guess that, in the end, all of the questions I have raised above can be boiled down to just one simple question: Who exactly does one need to either kill or maim or seriously wound in order to get kicked out of this organization (RIPE)? Regards, rfg P.P.S. Among the set of six companies / ASNs listed toward the top of this message as possible facilitators of the current hijacks of MNT-SERVERSGET, three are already fairly well known... at least in anti-spam circles... as being among "the usual suspects" when it comes to facilitating spamming and spammers. And no, I do not care to publicly specify which three. It may be true, as the saying goes that "On the Internet, nobody knows that you're a dog", but memories are long, and people don't forget if your company has been repeatedly caught acting like one.
In message <8A9C974B-FFA9-421C-B5ED-90E95624A8FE@a2b-internet.com>, Erik Bais <ebais@a2b-internet.com> wrote:
So the question that I have with all the information that you stated here. - Are they doing something (Other than 'probably' leasing IP space) wrong??
The answer to that question is a clear "yes" and indeed, the events that have followed in the wake of my posting of only a few days ago have actually proven that to be the case, beyond a reasonable doubt. There are two key facts that support this view. First, China is not in the habit of allowing mysterious Russians to route their IP space for them. Call it a matter of national pride, or a matter of national security, or something else. It doesn't matter. The Chinese simply don't allow this sort of thing. I challenge you to find an example, i.e. _any_ example, that will prove this assertion wrong. Second, and even more convincingly, someone somewhere (perhaps someone within RIPE NCC) clearly understood that some or all of the route objects that were in the data base as recently as last week, and that were associated with MNT-SERVERSGET were in fact fradulent, and as a result, _many_ of these route objects have now been quietly removed from the data base. In my prior posting, I specifically called out the following two route objects for special attention: ======================================================================== route: 27.103.192.0/19 origin: AS204895 mnt-by: MNT-SERVERSGET created: 2018-07-02T07:30:29Z last-modified: 2018-07-02T07:30:29Z source: RIPE ======================================================================== route: 36.0.192.0/19 origin: AS204895 mnt-by: MNT-SERVERSGET created: 2018-07-02T07:30:55Z last-modified: 2018-07-02T07:30:55Z source: RIPE ======================================================================== Since my posting, these routes objects, *and numerous others* (full list available upon request) have been withdrawn from the data base *by someone*. By your question Erik, are you attempting to deny that these objects existed in the data base, as recently as last week? By your question, are you attempting to deny that these routes have since been removed from the data base? By your question, are you attempting to assert that these routes... and the several others that have now also been quietly and mysteriously disappeared from the data base... were anything other than blatantly and obviously fradulent?
- Are the leased or used prefixes used to send out spam or host malware or do something else that is frowned upon ? or even illegal.. ( And is there proof of spam source or hijacking etc.. ? )
I believe that to be the case, and I could even marshall some compelling evidence of that, but as I am sure you know that is entirely irrelevant here. Do I really need to say what has already been said innumerable times in the past, i.e. that RIPE is not the Internet Police? The issue I have raised has nothing to do with spamming, which RIPE and all of its members have elected not to concern themselves with. The issue I have raised also has nothing to do with the hijacking of IP address space via the BGP announcement of fradulent routes. This is also a topic which, I am told, RIPE and all of its members have elected not to concern themselves with, because once again, RIPE is not the Internet Police. So, please Erik, do not attempt to confuse the issue by injecting these irrelevancies into the conversation. Let's try to stay focused. The one issue that RIPE and its membership _have_ generally asserted a serious interest in is the quality and accuracy of the data base. The clear evidence, from both last week and today, and particularly the comparison between the two, show quite clearly that *somebody* knows that one hell of a lot of fradulent route objects were inserted into the data base by the party or parties associated with the MNT-SERVERSGET handle. And as a direct result of my posting of last week, *someone* has now mysteriously "disappeared" most or all of the fradulent route objects that had been put into the data base by MNT-SERVERSGET aka Alexander Samuilov. (I say that these route objects have been "mysteriously disappeared" because whoever did that did not see fit to mention who was doing the disappearing or why it was being done, exactly, on any of the RIPE mailing lists to which I posted my message of last week. Nor have I received any private messages explaining why these route objects were being removed.) Try as you might Erik, you cannot make these inconvenient facts go away, e.g. just by introducing a bunch of irrelevancies into the conversation. People... even people here in the relevant RIPE mailing lists... are not all stupid. They can see for themselves that there were in fact *numerous* fradulent route objects in the RIPE data base last week that have mysterious disappeared since my posting of last week. (If anyone needs to have me generate a side-by-side comparison showing the set of fradulent MNT-SERVERSGET route objects that have been disappeared from the data base over just the past few days then I will try to create that sort of side-by-side listing so that any doubters may have a clear view and a clear understanding of what has happened, over just the past few days.) How do you explain this Erik? How does RIPE NCC explain all of these sudden disappearances of route objects from the data base? Does it not seem, even to you, that the rather sudden and unexplained disapperances, just since my posting last week, of so many of the MNT-SERVERSGET route objects may be somewhat more than just purely coincidental? Somebody somewhere knows that those route objects were unambiguously fradulent. Perhaps it was only the perpetrator, Mr. Alexander Samuilov. Perhaps it was some member of the technical staff inside RIPE NCC. Whoever it was, it cannot now be denied that the route objects in question were fradulent, or that this pollution was deliberately inserted into the data base by *some* RIPE member. So the only remaining question is: Is RIPE even willing or able to "police" its own data base? What sanctions, if any, are going to be imposed, by RIPE, on the crook who engineered all of this crap? RIPE has a bad habit of just looking the other way when its members spam massively, engage in massive hacking attacks, and even when they use BGP to hijack IP space that doesn't belong to them. Will RIPE also now look the other way and do nothing when the one and only thing that all RIPE members actually hold dear, i.e. the data base, is used like a toilet by certain specific and easily identifiable members?
If you want to get the exec-board to take action to a listed broker, that should be take up with the exec-board and the NCC. It is my experience that they are very responsive
Your experience is apparently unique. Since my posting of last week, which was CC'd to exec-board@ripe.net, and which clearly and unambiguously called for the investigation of, and the expulsion of several very specific RIPE members (and also the deletion of certain entities from RIPE's list of officially recognized IP brokers), I have had not a single response of any kind from *any* board member. None of them have even had the courtesy to send me a FOAD message in response. Their silence on these matters is deafening. Regards, rfg
Dear Ronald, Thank you for your email. It's probably good to revisit this topic publicly every now and then, so we can have something on the record for future reference. The RIPE community has repeatedly reminded the RIPE NCC that it has no role to play in policing routing and no mandate to make judgments on whether the route objects people create correspond to legitimate BGP announcements. Given this lack of a mandate, it's hard to imagine that the community would support the RIPE NCC unilaterally sanctioning members for incorrect/malicious route announcements. Despite your request, the RIPE NCC doesn't comment on its members or the investigations it undertakes. Similarly, it has always declined to "Name and shame" its members by discussing them on a public mailing list. If you find inaccurate information in the RIPE Database, please use the report form to let the RIPE NCC know. I fully trust that the RIPE NCC staff will follow up on all cases that are properly reported and take appropriate action. If you feel that the RIPE NCC is failing to uphold its responsibilities as described in RIPE policies and RIPE NCC procedural documents, please let the Board know and we will look into it. On the other hand if you think that the RIPE NCC should get involved in policing route object creation, that's a different discussion. In this case it's not the Board but rather the RIPE community that you'll need to convince. Here you'll find that the RIPE Policy Development Process (PDP) is at your disposal - the RIPE NCC can explain how the process works and help you to get started. You could also work with the Database Working Group to see if there isn't a technical solution that might solve some of these issues. Finally, regarding your second email - RIPE NCC staff have confirmed that they did not delete the route objects in question. Regards Nigel Titley Chairman of the RIPE NCC Executive Board
I think it will be a good idea if we can have a better understanding of what's going on with these route objects registered under MNT-SERVERSGET. That can perhaps allows us to clarify what's the condition of the "dubious" 3/4 of IP addresses. This is perhaps a way to deal with hijacking. Vivien
Mr. Titley, Thanks for responding. My comments are included inline below. In message <cf0758bb-88e7-faa6-8b29-11af41c75f8f@titley.com>, Nigel Titley <nigel@titley.com> wrote:
The RIPE community has repeatedly reminded the RIPE NCC that it has no role to play in policing routing and no mandate to make judgments on whether the route objects people create correspond to legitimate BGP announcements.
But that's not really or entirely an accurate statement is it? It is my understanding that RIPE disallows the creation of route objects in the data base that make reference to RIPE issued IP space in the absence of proper permission/endorsement from the actual registrant of the relevant IP space. Is that not so? If it is so, then isn't this quite obviously one way that RIPE is actually and materially -regulating- the creation of route objects in the data base? If this isn't a regulation (or limitation) that RIPE is applying to the creation of route objects then what is it? Likewise and simuilarly it is also my understanding that as of September 4th, less than three weeks from now, RIPE will -additionally- begin enforcing a new regulation preventing the creation, in the data base, of -any- new route objects for out-of-region IP space. Is that not so? So, it seems that RIPE -is- already regulating the creation of such objects in the data base, and it seems that it already been doing so for some time. It is just highly unfortunate that it has been doing it very very badly indeed, as clearly evidenced by the several reports that I've made public this summer alone.
Given this lack of a mandate, it's hard to imagine that the community would support the RIPE NCC unilaterally sanctioning members for incorrect/malicious route announcements.
I did not ask about route announcements. I asked what the RIPE policy is with respect to members who are caught repeatedly, deliberately, and maliciously creating clearly fradulent route objects in the data base. This is a very different matter, as I am sure you must appreciate. With all due respect, you appear to be deftly trying to dodge my actual question, which has nothing to do with route announcements and everything to do with route objects in the data base. I have every reason to believe that you -do- fully appreciate and understand the distinction between these two things, so I ask my question again. What is the RIPE policy with respect to members that are caught red handed, repeatedly, deliberately, and maliciously entering fradulent route objects into the RIPE data base? If you prefer, I would be just as happy if you instead answered my more colloquial formulation of this question: Who exactly does one need to kill, maim, or seriously wound in order to get kicked out of this organization (RIPE)? It seems that there are very nearly no limits on the scope or breadth of the travesties that your members are permitted to engage in, even when it comes to polluting your own data base with easily recognized rubbish. But there -are- apparently at least -some- acts that are so over-the-top egregious that even RIPE can no longer turn a blind eye. This was verified previously by a member of your legal staff who previously reported that there have been at least four separate non-person entities that have actually been kicked out of RIPE, just in the last few years, for reasons other than the non-payment of fees due. So what did these four specific and extra special crooks do, exactly, that was so horrifically bad that even RIPE couldn't turn a blind eye anymore? What could have been so magnificently malevolent that it causes even RIPE, which apparently tolerates very nearly every kind of mischief that can be perpetrated on the Internet, to kick these four entities out? I am reminded of a famous line from the movie Casablanca: "I've often speculated on why you don't return to America. Did you abscond with the church funds? Did you run off with a Senator's wife? I like to think that you killed a man. It's the romantic in me." I ask yet again, what does it take to get kicked out of this organization?
Despite your request, the RIPE NCC doesn't comment on its members or the investigations it undertakes.
I am not asking you to. I am asking you to identify for me *any* form or kind of malfeasance, any kind of travesty, any kind of crime, even one perpetrated against your own data base, that would result in RIPE actually opening its legendary blind eye and taking action for once. Does RIPE even happily tolerate the utter pollution and prostitution of its own data base? As of now, the answer seems to be yes.
If you find inaccurate information in the RIPE Database, please use the report form to let the RIPE NCC know. I fully trust that the RIPE NCC staff will follow up on all cases that are properly reported and take appropriate action.
Well, that makes one of us, at least. I myself have no such faith. Mind you, it is *not* that they aren't perfectly capable of doing their jobs, however those jobs are defined for them. The problem is that -your- definition of "appropriate action" in the cases that I have publically reported on this summer seems to come down to just winking and nodding and otherwise doing nothing whatsoever.
On the other hand if you think that the RIPE NCC should get involved in policing route object creation, that's a different discussion.
See above. RIPE NCC already -is- quite clearly involved in regulating the creation of route objects in the data base, and has been for quite some time already. It is just being done very very badly in cases relating to out-of-region objects. That's not the fault of the engineers. It's clearly the fault of the politicians, including yourself. If you had even a small amount of either foresight or leadership, then you would have put a stop to all of this nonsense years ago. Instead this problem was allowed to grow and fester without limits, and even as we speak is still permitted within the RIPE region. (September 3rd, will be a busy day indeed for the various crooks in the RIPE region.) Lastly, I see that even as you deftly attempted to avoid answering my real question, by trying to change the subject from route objects to route announcements, you didn't even make any pretense at answering my other question, which was abouit what it might take for someone to get kicked out of the club of RIPE "Recognized IP Brokers". Perhaps, instead of asking you what, if anything, it might take for RIPE to kick someone -out- of this totally separate exclusive club, I should instead be asking you what sorts of scoundrels, murders, and rapists RIPE, in its infinite wisdom, is allowing -in- to its club of "Recognized IP brokers" in the first place. Is there -any- party who RIPE would -not- allow to join this club, as long as they can produce the required cash payment to RIPE? Would Bernie Madoff be allowed to be a RIPE-recognized IP broker? How about Charles Ponzi? Are there -any- qualifications needed to become a RIPE-recognized IP broker, other than have a pulse and a bag full of cash (to give to RIPE)? I look forward to your clarifications. Regards, rfg
Dear Ronald, I've grouped some of your questions together for the sake of brevity. 1. Isn't RIPE already regulating route objects through restrictions in the RIPE Database? What about the upcoming changes to out-of-region objects? Sorry if I was unclear on this point. It's important to note the distinction between RIPE (community/policy-setting) and the RIPE NCC (legal organisation/implementation). The RIPE community is absolutely able to set policy or issue directions to the RIPE NCC that would regulate the creation of route objects (such as the existing features in the RIPE Database or the upcoming changes with out-of-region objects). However, while RIPE has this ability - the RIPE NCC requires an explicit mandate or instructions from the community. So, my original point stands - it's not the RIPE NCC or the Board you should be addressing your comments to. If the RIPE community instructs the RIPE NCC to monitor or validate route objects in the RIPE Database, then that is what the organisation will do. If the community could reach consensus on what a fraudulent route object looked like, that would be a start. Again, the RIPE Policy Development Process is there for you to suggest an approach that satisfies all stakeholders. 2. What does the RIPE NCC do when members are repeatedly caught making fraudulent route objects? For what reasons can the RIPE NCC close a member? The RIPE NCC does not have a mandate to determine whether route objects in the RIPE Database are valid. Therefore, "caught" doesn't mean much in this context - especially if the community hasn't provided a definition of "fraudulent". Because the organisation doesn't have a mandate, it can't take any action against its members for this behaviour. Similarly, the community has never given the RIPE NCC a mandate to examine murder cases - so to reference your other question - a member would not be closed down for murdering or maiming someone. And to be frank, I think we have the community's support on this. It's not the role of the RIPE NCC to investigate murders, or any other crime for that matter. In your email, you asked what behaviour would be so extreme that the RIPE NCC would be finally obliged to close down a member. In all cases where members have been closed, it was because they violated the terms of their Standard Service Agreement (SSA) with the RIPE NCC. It's therefore important to approach this in terms of whether they broke their agreement, rather than the severity of their behaviour. The reasons for which the RIPE NCC can terminate a membership are listed here: https://www.ripe.net/publications/docs/ripe-697 A few more members have been closed since the four you referenced. This has come from an increase in members attempting to gain control of other people's IPv4 addresses or opening LIR accounts with fraudulent or untruthful information. In 2018 so far, 58 LIRs have been closed for these reasons (up from five in 2016 and four in 2017). A further five have been closed in 2018 for unresponsiveness. A member could be closed for failing to maintain accurate data in the RIPE Database - but the document linked above explains what types of data must be maintained, and this does not include route objects. Also, because the RIPE NCC is concerned primarily with correct registration, it will work with the resource holder to update their information in the first instance. A member has never been closed for this reason, and it would only happen after they had been given ample opportunity to correct their data. This is consistent with guidance from the RIPE community. 3. On brokers Regarding brokers, there are certain legal considerations when deciding whether to break the agreement with them - especially if this would be on the basis of allegations the organisation is unable to take a position on. The RIPE NCC has canceled two broker agreements in cases where a broker was found to have violated the terms of their agreement (spamming RIPE Database contacts). As an aside, it's worth noting that brokers don't pay anything to the RIPE NCC as part of this agreement. Ronald, I trust that this has adequately clarified the RIPE NCC's position. If you have any further comments, I suggest you share them with your colleagues in the relevant working group, or perhaps consider attending a RIPE Meeting where we could discuss this in person. Best Regards Nigel Titley Chairman of the RIPE NCC Executive Board
participants (4)
-
Anne-vivien Paris -
Erik Bais -
Nigel Titley -
Ronald F. Guilmette