Speaking of routing funny business... what's up with AS65021?
Apparently, not all routing funny business involves hijacked IP address space. I was just doing some preliminary testing of a tool which I hope will allow me to automate more of my spam reporting process. I don't like to report spam to the registered owner of the smallest containing IP address block of the spam source because a substantial fraction of the time, those are the very people actually doing the spamming. So I prefer instead to send spam reports to the designated abuse contacts for the entire relevant ASN. Fortunately, these days, for most RIPE and ARIN ASNs at least, the relevant abuse reporting address for any given ASN is easy to obtain, and obtaining those email addresses may be done in a fully automated fashion from the relevant ASN WHOIS records. But as I have only just now learned, while I was doing preliminary testing on my simple software tool, there are some exceptional cases where mapping an ASN to a corresponding abuse reporting address becomes problematic. Specifically, I have noticed some spammers cammped out on a block of IPv4 addresses that are currently routed by AS65021. The whois.iana.org WHOIS server tells me that this is a reserved ASN, and that it doesn't actually belong to anybody at all. Thus, my rather simple Perl script which attempts to find a proper reporting email address for this one specific spammer infestation fails rather horribly. The CIDRs currently being routed by AS65021 are: 31.13.210.0/24 31.13.241.0/24 87.120.104.0/24 87.120.253.0/24 87.120.255.0/24 87.121.116.0/24 93.123.64.0/24 216.99.221.0/24 (seen by bgp.he.net) Some of these have been routed by (bogus) AS65021 since 2018-12-03. All of those CIDRs are properly registered to cloudware.bg except for the last one which is registered to International Payout Systems Inc. (Florida). Apparently, cloudware.bg is part of Neterra, Ltd. of Bulgaria (AS34224): https://www.cloudware.bg/en/about "As part of Neterra..." I would say that this is just a very temporary mishap, and a temporary "fat fingered" anomaly if it were not for the fact that some of these routes have, according to RIPE Rotuing History, been countinuously announced for over four full months now. Can anyone explain this to me? Please? I have more than a little trouble understanding why a company like Neterra, Ltd., which -does- already have its very own ASN (AS34224), feels the need to effectively steal a reserved ASN for their own private use. Are new AS numbers really all that expensive in the RIPE region, so that some businesses might be motivated to save some money by just grabbing onto one of the reserved ones? None of this makes particularly much sense, but I do plan to send email to Neterra, Ltd. in order to ask them what the devil goes on here. Mostly, I am just reporting theis here as a sort of indirect way of asking other people on the list for their opinions about Neterra, Ltd. of Bulgaria. Is that compaony in the habit of doing routing funny business? For my own part, all I can say is that this is certainly not the first time that I have encountered that company name... and not in a good way. Regards, rfg
Hi, On 4/5/19 20:53, Ronald F. Guilmette wrote:
Are new AS numbers really all that expensive in the RIPE region, so that some businesses might be motivated to save some money by just grabbing onto one of the reserved ones?
the ASNs in the RIPE Region are *free* for both the LIR and the end-user. cheers, elvis
Hi Ronald, All, On Fri, 5 Apr 2019, Ronald F. Guilmette wrote:
Apparently, not all routing funny business involves hijacked IP address space.
Yes. This one may seem a bit odd, but probably has nothing to do with an hijack. (...)
Specifically, I have noticed some spammers cammped out on a block of IPv4 addresses that are currently routed by AS65021. The whois.iana.org WHOIS server tells me that this is a reserved ASN, and that it doesn't actually belong to anybody at all.
Yes, AS65021 is for private use. Same as 10.0.0.0/8 (and all RFC1918 space) is for private use. Sometimes people mess up with filters :-) It's usually fat fingers, and AS-PATH information may well confirm that.
Thus, my rather simple Perl script which attempts to find a proper reporting email address for this one specific spammer infestation fails rather horribly.
Extra line of code needed perhaps... if <private_ASN> then <nothing_is_sent> :-) or maybe look for the upstream's contact.
The CIDRs currently being routed by AS65021 are:
31.13.210.0/24 31.13.241.0/24 87.120.104.0/24 87.120.253.0/24 87.120.255.0/24 87.121.116.0/24 93.123.64.0/24 216.99.221.0/24 (seen by bgp.he.net)
Some of these have been routed by (bogus) AS65021 since 2018-12-03.
216.99.220/23 seems to have a RPKI ROA (associated with AS6939 - Hurricane Electric), resulting in any /24 from it becoming an INVALID. RIPE stat shows me two INVALIDs: - 216.99.220.0/23 from AS14587 - 216.99.221.0/24 from AS33132 It looks to me that someone should fix their RPKI stuff :-)
All of those CIDRs are properly registered to cloudware.bg except for the last one which is registered to International Payout Systems Inc. (Florida).
Apparently, cloudware.bg is part of Neterra, Ltd. of Bulgaria (AS34224):
https://www.cloudware.bg/en/about "As part of Neterra..."
I would say that this is just a very temporary mishap, and a temporary "fat fingered" anomaly if it were not for the fact that some of these routes have, according to RIPE Rotuing History, been countinuously announced for over four full months now.
That's a bit long so that noone notices it... (and fixes it).
Can anyone explain this to me? Please? I have more than a little trouble understanding why a company like Neterra, Ltd., which -does- already have its very own ASN (AS34224), feels the need to effectively steal a reserved ASN for their own private use.
It's not "stealing" as i see it. Private use ASNs are available so anyone can use them, but on a _private_ capacity. Meaning... you can agree with your neighbor to origin a route from that private ASN, but the neibhbor is expected not to let that go into any other network... Or if it does, it removes the private-AS from the route's AS-PATH. Thus, some filters are not in place or they have a serious hole... :-(
Are new AS numbers really all that expensive in the RIPE region, so that some businesses might be motivated to save some money by just grabbing onto one of the reserved ones?
If you are a LIR it costs _ZERO_. Of course there is an admnistrative process to get a new ASN, but that isn't something complext or time-consuming. If you are not a LIR, then you just have to find a LIR that can sponsor the ASN for you. If the LIR will charge anything to the customer, that's their decision, but the LIR will not be charged by the RIPE NCC for the new ASN. (...)
Regards, rfg
Best Regards, Carlos
In message <alpine.LRH.2.21.1904060910530.21127@gauntlet.corp.fccn.pt>, =?ISO-8859-15?Q?Carlos_Fria=E7as?= <cfriacas@fccn.pt> wrote:
I would say that this is just a very temporary mishap, and a temporary "fat fingered" anomaly if it were not for the fact that some of these routes have, according to RIPE Rotuing History, been countinuously announced for over four full months now.
That's a bit long so that noone notices it... (and fixes it).
Yes.
Thus, some filters are not in place or they have a serious hole... :-(
Can I request someone within the RIPE region to contact these people and try to see if they will respnd about this issue in a meaningful fashion? I already tried myself, but I just got back a response saying, in effect, "Yea. So? Why are you bothering us?" I guess that I have not been able to explain the problem to them very well. Regards, rfg
participants (3)
-
Carlos Friaças -
Elvis Daniel Velea -
Ronald F. Guilmette