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