[db-wg] 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/brokers

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.