[routing-wg] [anti-abuse-wg] The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top

In message <8A9C974B-FFA9-421C-B5ED-90E95624A8FE at a2b-internet.com>, 
Erik Bais <ebais at 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 at 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