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" 
<[email protected] on behalf of [email protected]> 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/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.
    
    

Reply via email to