Re: [routing-wg] [db-wg] [anti-abuse-wg] The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top
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
participants (3)
-
Havard Eidnes -
Nathalie Trenaman -
Ronald F. Guilmette