Re: [db-wg] [anti-abuse-wg] The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top
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
Ronald F. Guilmette via db-wg wrote on 14/08/2018 21:53:
None of them have even had the courtesy to send me a FOAD message in response.
Their silence on these matters is deafening.
Yes, and there is not a problem with this. The RIPE NCC board of directors are not involved in day-to-day operations in the company and sending them reports about illegitimate registrations in the IRRDB isn't how to deal with this situation. If you need to submit a complaint to the RIPE NCC about problem registrations in the RIPE IRRDB, their contact details can easily be found. A search for "ripe database complaints" provides this as the first result: https://www.ripe.net/support/contact/reporting-procedure Also, could you kindly not cc: your emails to so many working groups? No doubt people appreciate how important your reports are, but spamming your emails across three working groups is, in all fairness, a bit much. Nick
In message <07e92bc3-2856-a40c-4b4e-c248b941dbd3@foobar.org>, Nick Hilliard <nick@foobar.org> wrote:
Ronald F. Guilmette via db-wg wrote on 14/08/2018 21:53:
None of them have even had the courtesy to send me a FOAD message in response.
Their silence on these matters is deafening.
Yes, and there is not a problem with this. The RIPE NCC board of directors are not involved in day-to-day operations...
Wait a minute. Didn't Erik Bais just -advise- me that I -should- be contacting the board? Wouldn't he qualify as an authority, given that he is a chair of a RIPE working group? More to the point, since when has it become a routine part of "day to day operations" to have RIPE members flooding the RIPE data base with blatant bovine excrement? I -do- see, and I -have- reported on an inordinate amount of exactly such deliberate hanky panky being perpetrated within the RIPE region, and within the RIPE data base of late, but I was not aware, until now, that this sort of behavior is nowadays considered, within the RIPE region at least, to be nothing more than "another day at the office". When exactly did the RIPE membership come around to this bland and careless acceptance of the clearly unacceptable? Or has it just always been like this?
If you need to submit a complaint to the RIPE NCC about problem registrations in the RIPE IRRDB...
I see that you have not understood my points at all. Please allow me to try again. The issue I have, and that I have tried to raise, is -not- merely the existance, in the data base, of this one deliberately fradulent entry or that one deliberately fradulent entry. Nor is the real issue even any given *collection* of deliberately fradulent entries that have been placed into the data base by any one specific member. Rather, the real issue I have raised is the question of what, if anything, RIPE is either willing or able to do to disipline any member that has demonstratably engaged in this exact pattern of repeated frauds. Removal of the fradulent data base entries that I have already identified, or that I may in the future identify, is a good thing, but it does not even begin to address the underlying issue: Why does this keep on happening, specifically and, it seems, -exclusively- within the RIPE region? What is RIPE doing, or not doing, that seems to engourage so many RIPE members to try their hand at this exact type of fraud? Could it perhaps be the case that since no one is ever sanctioned in any way for such activities, there is no real downside to giving it a try?
Also, could you kindly not cc: your emails to so many working groups? No doubt people appreciate how important your reports are, but spamming your emails across three working groups is, in all fairness, a bit much.
Let me see if I have understood you. I've sent my recent messages to exactly and only three mailing lists for three clearly relevant working working groups, namely the data base working group, the routing working group and the (arguably mis-named) "anti-abuse" working group. Are you asserting that my points have nothing whatever to do with the RIPE data base? Are you asserting that my points have nothing whatever to do with routing? Does the deliberate pollution of the data base not constitute a type of "abuse" in your opinion? Just to make sure that I understand, you are apparently asserting that it is now just ordinary "day to day" activity for RIPE to permit the creation, in its data base, of numerous deliberately fradulent entries which then serve to legitimize the hijacking of various IP address blocks, right? And because RIPE "is not the Internet Police" it is also true that nobody on any RIPE mailing list cares about the fact that any of this hijacked IP space... space which RIPE has effectively legitimized... has been or is being sub-leased out to various high-end professional snowshoe spanmmers, who have then proceeded to pump out millions or tens of millions of -actual- spams, right? And yet you have the unmitigated audacity to accuse -me- of "spamming" for the unforgivable act of posting the three clearly relevant WG mailing lists? The gentleman doth protest too much, methinks. That having been said, I am at least pleased to learn that there exists one more member of the RIPE community who evinces at least some concern about the global problem of spam. And I look forward to seeing your concern translated into action with respect to the real and primary issue I have raised, which is the sanctioning of clearly misbehaving members, or rather, the apparently abundant current lack thereof. Regards, rfg
Hi, following up on a particular point (only), dropping the anti-abuse WG, but keeping the other two because it relates to database authorization and the IRR:
More to the point, since when has it become a routine part of "day to day operations" to have RIPE members flooding the RIPE data base with blatant bovine excrement?
I guess one important reason is that in some specific cases it's difficult to automate the distinction between what you refer to as "bovine excrement" and legitimate route objects. (This refers to your substantiated claim that fraudulent route objects have been and are being registered in the IRR part of the RIPE database.) Looking at the description of the route object in the RIPE DB: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... and the authorization requirements at https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... my understanding is that it describes that when "route" objects are created which cover in-region address space, authorization is requied from both the maintainer of the AS object as well as from the maintainer of the address space, so registering in-region route objects without the consent of the address space holder is more or less prevented. However, if the address space is out-of-region, the authorization checks for the address space is dropped / ignored, and only the authorization for the AS object is used, allowing the registration of route objects without the consent of the address space holder. I suspect it is this loop-hole which is being abused to register the route objects you are mentioning. I suspect that out-of-region route objects in the RIPE DB are an operational requirement for other reasons. One way to close this loop-hole would be for the RIRs to agree on a uniform authorization model, and share the authorization information (and data) between themselves. I suspect this is no small task. Best regards, - Håvard
Hi Håvard, Please see my comments below.
Op 15 aug. 2018, om 10:21 heeft Havard Eidnes via db-wg <db-wg@ripe.net> het volgende geschreven:
Hi,
following up on a particular point (only), dropping the anti-abuse WG, but keeping the other two because it relates to database authorization and the IRR:
More to the point, since when has it become a routine part of "day to day operations" to have RIPE members flooding the RIPE data base with blatant bovine excrement?
I guess one important reason is that in some specific cases it's difficult to automate the distinction between what you refer to as "bovine excrement" and legitimate route objects.
(This refers to your substantiated claim that fraudulent route objects have been and are being registered in the IRR part of the RIPE database.)
Looking at the description of the route object in the RIPE DB:
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab...
and the authorization requirements at
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab...
my understanding is that it describes that when "route" objects are created which cover in-region address space, authorization is requied from both the maintainer of the AS object as well as from the maintainer of the address space, so registering in-region route objects without the consent of the address space holder is more or less prevented.
Indeed, but this is about to change. The RIPE DB Working Group has decided to remove AS authentication for ROUTE(6) objects. This will come into effect on the 4th of September 2018. From then, only a prefix holder can create a ROUTE(6) object and can reference any AS number.
However, if the address space is out-of-region, the authorization checks for the address space is dropped / ignored, and only the authorization for the AS object is used, allowing the registration of route objects without the consent of the address space holder. I suspect it is this loop-hole which is being abused to register the route objects you are mentioning.
Exactly, and part of the NWI-5 implementation is that from the 4th of September, it will not be possible anymore to create new out-of-region ROUTE(6) objects and AUTNUMs in the RIPE IRR. This loophole will then be closed. All the out-of-region objects will remain in the RIPE IRR, but with a different “source:” attribute: RIPE-NONAUTH. Holders can still update and delete these objects, but not create new ones. We have communicated these changes to all out-of-region object holders and the RIPE DB WG. Also we have communicated this to all other RIRs (most of them wrote articles about these upcoming changes and informed their members. You can read the full implementation plan here: https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implem... <https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation>
I suspect that out-of-region route objects in the RIPE DB are an operational requirement for other reasons.
Well, the WG decided it was time to move on and fixing the loophole was more important.
One way to close this loop-hole would be for the RIRs to agree on a uniform authorization model, and share the authorization information (and data) between themselves. I suspect this is no small task. Best regards,
- Håvard
Best regards, Nathalie Trenaman Product Manager RIPE NCC
In message <20180815.102137.2031302831757015708.he@uninett.no>, Havard Eidnes <he@uninett.no> wrote:
However, if the address space is out-of-region, the authorization checks for the address space is dropped / ignored, and only the authorization for the AS object is used, allowing the registration of route objects without the consent of the address space holder. I suspect it is this loop-hole which is being abused to register the route objects you are mentioning.
I believe that the above analysis is not only correct, but also both self-evident and already well-known. It is my understaing that this "loop-hole" is so well known, in fact, and that it has already been so frquently abused that come September 4th of this year... less than three weeks from now... this loop-hole will be formally, finally, and officially closed for good, at least with respect to -new- route objects. (As I understand it, all of the ones that are already in the data base as of September 4 will be left there, but will be tagged in some manner to indicate their potential unreliability.) It is Good that this step is, at long last, being taken, but that does not do anything at all to address the underlying question that I have asked, and which remains unanswered, and which I quote here again, for the benefit of those who may have missed it the first time: Who exactly does one need to kill, maim, or seriously wound in order to get kicked out of this organization (RIPE)? I sense that the RIPE community attitudes about hijacking -and- even hijacking which has been materially aided and abetted by the introduction of fradulent route objects into the RIPE data base is just one that could best be summed up in that old saying "Oh Well! Boys will be boys!" I am not persuaded that this sort of lackadaisical and laissez-faire attitude towards this kind of situation is even close to an appropriate response, given that fact that litteral billions of people actually rely on this thing we call the Internet every day of the week. This isn't just a private little boy's club anymore, and the days when these types of antics could just be winked at, and smirked at have passed away some time ago already. It's time that RIPE stopped -fostering- this sort of bad behavior by consistantly doing nothing about it, and just allowing the perpetrators to keep their legitimately allocated ASNs, address space, memberships, etc. Regards, rfg
[cc: trimmed to db-wg] Ronald F. Guilmette wrote on 14/08/2018 23:27:
Are you asserting that my points have nothing whatever to do with the RIPE data base? Are you asserting that my points have nothing whatever to do with routing? Does the deliberate pollution of the data base not constitute a type of "abuse" in your opinion?
By that style of argument, you forgot ncc-services-wg, because this is obviously an issue with NCC services. And cooperation-wg because there's a liaison issue going on, and the DNS working group, because the abusers definitely use DNS, and address policy because surely there ought to be policies against this sort of thing? Are you going to argue that there shouldn't be?? And don't forget connect-wg because these routes would never propagate without interconnection. All of which is why there are generally accepted guidelines on the internet about why excessive cross-posting is considered to be anti-social and counter-productive. The rest of your email was too long. I didn't read it. Please, if you are going to post content to a working group, bear in mind that people have neither the time nor the inclination to wade through pages of text, when the entire content of a post could easily be summarised in a couple of lines. Nick
participants (4)
-
Havard Eidnes -
Nathalie Trenaman -
Nick Hilliard -
Ronald F. Guilmette