Hi Ronald, On Sun, Jan 26, 2020 at 09:40:13PM -0800, Ronald F. Guilmette wrote:
In message <20200127052621.GJ36653@vurt.meerval.net>, Job Snijders <job@ntt.net> wrote:
The dates, the website at https://www.thriftdrug.org/, the non-US origin of the announcement all seem to suggest that someone discovered the block was dangling, the domain unregistered, and some quick registration & forgery could lead to treasure.
Yes. My apologies to all. I made a bit of a mistake here.
Upon further review, this block (206.195.224.0/19) now appears to have been stolen, i.e. with the (assumed unwitting) participation of ARIN.
As Job has noted, multiple aspects of the WHOIS record are most certainly non-conformant with common sense. I highlight these below. (I have attempted to call the new contact phone number and it is dead/disconnected.)
Good call to try to phone them.
It is my hope, of course, that the apparent illicit take-over of this block was a product of garden variety incompetence @ ARIN, rather than, you know, the alternative.
I think it is very counter-productive to frame things as 'incompetence @ ARIN', we rather should assume positive intent. If this indeed is a case of theft, the attacker was sophisiticated enough to understand the rules of the game and how to cheat them. The various registries may be tricked at times, that's part of life, the real failure would be if they don't act after the registration problem is reported to them. I have no reason to believe this will be the case. Please be nice ronald! :-)
It appears from ARIN WhoWas data that this takeover began on 2019-08-12 with additional fradulent changes to the WHOIS also on 2019-08-14, 2019-08-15, and lastly 2019-09-24, when the OriginAS was fiddled to its present state.
This probably makes for a clear case of misuse of ARIN's services, and simply should be submitted to ARIN's Fraud Reporting process at https://www.arin.net/reference/tools/fraud_report/ If this is a case of theft, ARIN will revert the OriginAS change, which will impact NTT's "OriginAS to IRR"-bridge, which in turn will result in the "route:" object disappearing from the IRR eco-system. This in turn will result in the automatic removal from various EBGP allowlists in places that generate their filters using IRR data, further hampering propagation of the BGP route. Kind regards, Job