Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24
I just got a spam from 103.11.67.105. The containing /24 appears to be unallocated APNIC space. RIPE tools seem to say that AS18450 has been routing this block since around May 23rd. I see this kind of stuff almost every day now, it seems. And you know, there are days when I really do start to wonder "Has the Internet gone mad?" I'm going to call these turkeys right now and just ask them, point blank, what the bleep they think they're doing, routing unallocated APNIC space. But if history is any guide, this is probably going to turn out to be another one of these "absentee landlord" kinds of ASes, where all they have is an answering machine. I have to either laugh or cry when I see people posting here about the non-functionality of abuse@ email addresses, and then see other people saying "Well, this is why all ASes also have phone numbers." I wish I had a dollar for every AS I had ever tried to contact where -neither- the abuse@ address -nor- the phone number got me to any actual human being. Regards, rfg
On Fri, Oct 28, 2016 at 02:40:23PM -0700, Ronald F. Guilmette said:
I'm going to call these turkeys right now and just ask them, point blank, what the bleep they think they're doing, routing unallocated APNIC space.
Makin' phat stacks. One thing the RIRs could do is put pressure on AS's to not route these objects, and start producing daily public output scores for these orgs, and emailing them -- ultimately threatening them with de-reg of their assets if they dont stop this nonsense. Further more, could get the route db's involved in dereg threats. Is the politcal will there tho? Right now there's no stigma beyond nanog-l in being a bad actor from where I sit. /kc -- Ken Chase - math@sizone.org guelph canada
In message <20161028220510.GF14457@sizone.org>, Ken Chase <math@sizone.org> wrote:
On Fri, Oct 28, 2016 at 02:40:23PM -0700, Ronald F. Guilmette said:
I'm going to call these turkeys right now and just ask them, point blank, what the bleep they think they're doing, routing unallocated APNIC space.
Makin' phat stacks.
One thing the RIRs could do is put pressure on AS's to not route these objects,
Will never happen. The RiRs have been crystal clear, and also utterly consistant... "Not our job man! We am not the Internetz Police." The thing that really baffles me about this kind of thing is how this kind of crud can happen in the first place, and also, even more baffling, how it can persist for months on end without anybody even noticing. I'm looking at this: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=103.11.67.105 which appears to provide a nice list of the rest of the netwits who are also to blame for this one particular singular bit of idiocy: AS2914 -- NTT America, Inc. AS1299 -- Telia Company AB AS12798 -- Ace Data Centers, Inc. AS174 -- Cogent Communications AS6939 -- Hurricane Electric, Inc. AS3491 -- PCCW Global AS7922 -- Comcast Cable Communications, LLC AS6762 -- Telecom Italia Sparkle / Seabone AS10026 -- Pacnet Global Ltd AS11798 -- Ace Data Centers, Inc. So, um, is it really the case that -none- of the above companies have even noticed that anything was amiss here, and that all have failed to do so for months on end? (Or did they notice, but then felt is wasn't their place to say anything about it?) Sorry if those are stupid or naive questions, but... "The more I know, the less I understand." -- Don Henley Is this just another one of these cases where everybody is responsible and thus, nobody is? Is it really the case that none of the above companies ever check that what their peers announce is consistant with any routing registry? I don't pretend to understand this stuff. Somebody please 'splain it to me. I'll be much obliged. Regards, rfg
On Friday, October 28, 2016, Nick Hilliard <nick@foobar.org> wrote:
Ronald F. Guilmette wrote:
Will never happen. The RiRs have been crystal clear, and also utterly consistant... "Not our job man! We am not the Internetz Police."
Ron,
Maybe you could suggest some ideas about how the RIRs can stop someone from illegally squatting space?
Nick
If the space is unassigned, could the rir announce the space to park it to null0. And register it in spamhaus ? This would make the rir the custodian of the space in their possession CB
Ca By wrote:
If the space is unassigned, could the rir announce the space to park it to null0. And register it in spamhaus ?
This would make the rir the custodian of the space in their possession
The space isn't unallocated. It's allocated, but the assignee hasn't announced it in the dfz. There are some statistics about unallocated space here: http://www.potaroo.net/tools/ipv4/index.html summary: this isn't the problem area. Nick
In message <5813DACD.3000309@foobar.org>, Nick Hilliard writes:
Ronald F. Guilmette wrote:
Will never happen. The RiRs have been crystal clear, and also utterly consistant... "Not our job man! We am not the Internetz Police."
Ron,
Maybe you could suggest some ideas about how the RIRs can stop someone from illegally squatting space?
It's not the RIR's job. They already provide the framework for ISP's to do the job of policing route announcements themselves. ISP's just need to use that framework.
Nick -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <5813E03E.6060907@foobar.org>, Mark Andrews <marka@isc.org> wrote:
Mark Andrews wrote:
It's not the RIR's job. They already provide the framework for ISP's to do the job of policing route announcements themselves. ISP's just need to use that framework.
Ron thinks otherwise.
No, I don't. You have made a incorrect inference from the text of my actual comment. In my actual comment I merely noted that RIRs are in fact -not- the Internet Police, and that none of them have ever displayed even the slightest desire to become that (and indeed, when asked, they have, without exception, exhibited a clear desire -not- to be assigned any such role). These observations on my part are all merely recitations of well- established historical facts, all of which are easily verifiable by anyone with a browser. I made no comment at all about who, if anyone, should be tasked to take on the role of The Routing Police. And indeed, if asked, I would express some degree of skepticism about the ability of RIRs to even reliably execute their existing data base maintenance responsibilities to a level which I personally would find entirely satisfactory. (The apparent goofyness relating to 103.11.64.0/22 is just one very small example of this, there being also many other and more serious issues that I could also cite, if pressed, relating strictly to allocation functions and/or to WHOIS data base issues.) Given that I do not have an entirely unequivocal admiration for the quality and consistancy of the work that RIRs are already clearly responsible for, do you really believe that it would be my first choice to assign an entirely seperate but equally critical set of -new- authorities and responsibilities to the RiRs? If so, please allow me to disabuse you of that notion. (I am also and likewise not likely to support any effort any any part of the United States federal government to assign new authorities and responsibilities to the Office of Personnel Management.) Regards, rfg P.S. I may be wrong about this, but it has come to my attention that many, most, or all of the WHOIS records reflecting allocations made by the AFRINIC RIR are utterly devoid of either (a) information specifying the dates on which the relevant allocations were made or (b) email contact addresses for the relevant number resource registrants. I am, of course, utterly appalled by the apparent inability of this RIR to maintain a WHOIS data base which even approximates the modest and minimal level of relevant information commonly available from the WHOIS data bases of other and older RIRs.
Ronald F. Guilmette wrote:
In my actual comment I merely noted that RIRs are in fact -not- the Internet Police, and that none of them have ever displayed even the slightest desire to become that (and indeed, when asked, they have, without exception, exhibited a clear desire -not- to be assigned any such role).
just to be clear: this is a bottom up position, not top-down. The registry roles of the RIRs exist by mandate of the communities they serve to provide a database of integer allocations and assignments. If there's been no inclination to become "Internet Police", it's because their memberships do not want their respective RIRs to take on this role.
Given that I do not have an entirely unequivocal admiration for the quality and consistancy of the work that RIRs are already clearly responsible for, do you really believe that it would be my first choice to assign an entirely seperate but equally critical set of -new- authorities and responsibilities to the RiRs?
This will, of course, vary between RIRs. At least in the RIPE NCC service region, all allocations and assignments by the RIPE NCC are covered by written contractual links and complete records of these contracts are kept by the organisation. Sub-assignments by LIRs may not be as accurate. Other RIR service regions will have different policies.
P.S. I may be wrong about this, but it has come to my attention that many, most, or all of the WHOIS records reflecting allocations made by the AFRINIC RIR are utterly devoid of either (a) information specifying the dates on which the relevant allocations were made or (b) email contact addresses for the relevant number resource registrants.
Works fine for me. Did you use the "-B" flag when querying the Afrinic irrdb? % whois -h whois.afrinic.net " -B x.x.x.x" Nick
In message <58146E84.3030000@foobar.org>, Nick Hilliard <nick@foobar.org> wrote:
P.S. I may be wrong about this, but it has come to my attention that many, most, or all of the WHOIS records reflecting allocations made by the AFRINIC RIR are utterly devoid of either (a) information specifying the dates on which the relevant allocations were made or (b) email contact addresses for the relevant number resource registrants.
Works fine for me. Did you use the "-B" flag when querying the Afrinic irrdb?
I wasn't talking about irrdb. I was just talking about the WHOIS records for IPv4 allocations within the AFRINIC region. Anyway, yes, I do believe that used the -B flag. But nontheless, I really did see some AFRINIC WHOIS records that had -no- email contacts, nor any date information. I will have to try to see if I can dredge those out again. But my overall point remains. If there were ever to be an election where we were all asked who we wanted to see become the once and future Routing Police, the RIRs would not be my own personal first choice. Regards, rfg
Ronald F. Guilmette wrote:
I wasn't talking about irrdb. I was just talking about the WHOIS records for IPv4 allocations within the AFRINIC region.
afrinic, ripe ncc and apnic run a combined (+ partially authenticated) irrdb and whois server.
But my overall point remains. If there were ever to be an election where we were all asked who we wanted to see become the once and future Routing Police, the RIRs would not be my own personal first choice.
Great, we're agreed then. So why do you keep on bringing them up in this context and criticising them whenever someone squats some block of address space? Nick
In message <5815013F.2080502@foobar.org>, Nick Hilliard <nick@foobar.org> wrote:
But my overall point remains. If there were ever to be an election where we were all asked who we wanted to see become the once and future Routing Police, the RIRs would not be my own personal first choice.
Great, we're agreed then. So why do you keep on bringing them up in this context and criticising them whenever someone squats some block of address space?
References please? *I* didn't introduce the topic of RIRs into this thread. It would appear that Ken Chase did that: http://mailman.nanog.org/pipermail/nanog/2016-October/088943.html Later on, I bemoaned what I still feel is a rather lousey WHOIS referrals system, among and between the various RIR WHOIS data bases... with respect to *allocations* (not route registrations)... and it was entirely appropriate for me to mention that, in this thread, as the problem most definitely did impact not only _my_ ability to figure out who the bleep, if anyone, 103.11.67.0/24 is actually registered to, but actually, anyone's ability to do so, including, apparently, bgp.he.net. But this criticism has/had nothing whatever to do, specifically, with either routing or the (hypothetical) Routing Police. If the totality of the RIR WHOIS data bases are needlessly difficult to extract accurate information out of, then this negatively affects *all* uses (and all users) of these data bases, whether one is investigating possible routing squats, or whether one is just trying to figure out who currently owns the block that all of your corporate intellectual property has just been surreptitiously exfiltrated to. Regards, rfg
In message <5813DACD.3000309@foobar.org>, Nick Hilliard <nick@foobar.org> wrote:
Ronald F. Guilmette wrote:
Will never happen. The RiRs have been crystal clear, and also utterly consistant... "Not our job man! We am not the Internetz Police."
Ron,
Maybe you could suggest some ideas about how the RIRs can stop someone from illegally squatting space?
Oh, don't get me wrong. I never said that I either could or would suggest how to convert RiRs into The Internet Police. Nor did I suggest that such a conversion would even be either prudent or advisable. (I am not persuaded that it would be.) We have a longstanding 20 or 30 year tradition/precedent and a division of labor that -does not- allocate to RiRs any responsibility for, or authority over anything to do with what routes people announce, and I am certainly not even nearly so presumptive as to believe that I either can or should try to roll back 30 years of history and ask everyone to start all over again and build governance structures anew, from scratch. (Doing so would be both silly and the very height of arrogance on my part.) I nontheless feel free to note, and to bemoan, the current utter lack of -any- authority which routinely notices apparent routing funny business and/or which works, on a routine basis, to try to put a stop to it all. I do not suggest that RiRs should be "minding the store" with respect to route announcements. I do think it would be helpful if -somebody- were doing so. My own occasional and srictly ad hoc efforts have only succeded in convincing me of how extensive the problem is, and how dire a need there is for a more rigorous solution. Regards, rfg
How does one get ARIN to register resources to come up with this result? https://whois.arin.net/rest/nets;q=103.11.67.105 The /16 is APNIC but there are 2 subnets that appear to be allocated from ARIN. Having just typed 'whois 103.11.67.105' I completely missed the fact that the supernet was APNIC until I checked the web interface. --Doug On Fri, Oct 28, 2016 at 5:40 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
I just got a spam from 103.11.67.105. The containing /24 appears to be unallocated APNIC space.
RIPE tools seem to say that AS18450 has been routing this block since around May 23rd.
I see this kind of stuff almost every day now, it seems. And you know, there are days when I really do start to wonder "Has the Internet gone mad?"
I'm going to call these turkeys right now and just ask them, point blank, what the bleep they think they're doing, routing unallocated APNIC space. But if history is any guide, this is probably going to turn out to be another one of these "absentee landlord" kinds of ASes, where all they have is an answering machine.
I have to either laugh or cry when I see people posting here about the non-functionality of abuse@ email addresses, and then see other people saying "Well, this is why all ASes also have phone numbers."
I wish I had a dollar for every AS I had ever tried to contact where -neither- the abuse@ address -nor- the phone number got me to any actual human being.
Regards, rfg
In message <CADVNyRb-LE2GAgxae149RUwz5fkzQh-9Es6ZcEg_e0N7LVDa9g@mail.gmail.com> Doug Clements <dclements@gmail.com> wrote:
How does one get ARIN to register resources to come up with this result?
https://whois.arin.net/rest/nets;q=103.11.67.105
The /16 is APNIC but there are 2 subnets that appear to be allocated from ARIN. Having just typed 'whois 103.11.67.105' I completely missed the fact that the supernet was APNIC until I checked the web interface.
Oh!! Wow!! I totally missed this also, i.e. that ARIN is showing an allocation for 103.11.64.0/22 to HostUs.Us in Texas. That's really weird, but even that doesn't either explain or excuse what still looks like an illicit squat (by an unrelated Los Angeles company) on the 103.11.67.0/24 block to me... perhaps one that's been re-sold to a spammer (which seems possible, given the spam I got). In my own defense, I didn't see the ARIN allocation because I have a normative process that I use for looking up IP addresses. It's hierarchical, and I always start with whatver whois.iana.org has to say. And it says that that 103.0.0.0/8 belongs to APNIC, so of course, I only looked at what whois.apnic.net had to say about 103.11.67.105. And it says that it's unallocated. (And apparently, data shown for announced prefixes on the bgp.he.net web site is also obtained in this same straightforward way, because it also is showing 103.11.67.0/24 as registered to "Asia Pacific Network Information Centre".) This isn't the first time I've wished that the right hand knew (or cared) what the left hand was doing. I've asked the folks at IANA about this sort of thing in the past, i.e. them giving pointers to the apparently wrong RiR whois server, and they just won't fix it. They just shrug and say "Not our problem man!" And in this case, maybe they're right. If APNIC gave two subparts of 103/8 to ARIN, it might have been helpful if their own whois server was made aware of that fact. Sigh. I have to keep reminding myself of what one friend of mine keeps on telling me... "Ron, there you go again, trying to think about these things logically." Regards, rfg
I would use LACNIC’s whois server for these queries. They have info from all the registries, which is an amazing service that seems beyond the other RIRs. whois -h whois.lacnic.net <http://whois.lacnic.net/> 103.11.67.105 HostUS HOSTUS-IPV4-5 (NET-103-11-64-0-1) 103.11.64.0 - 103.11.67.255 Gaiacom, L.C. SOLVPS-103-11-67-0-24 (NET-103-11-67-0-1) 103.11.67.0 - 103.11.67.255 Mike
On Oct 28, 2016, at 4:36 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In message <CADVNyRb-LE2GAgxae149RUwz5fkzQh-9Es6ZcEg_e0N7LVDa9g@mail.gmail.com> Doug Clements <dclements@gmail.com> wrote:
How does one get ARIN to register resources to come up with this result?
https://whois.arin.net/rest/nets;q=103.11.67.105
The /16 is APNIC but there are 2 subnets that appear to be allocated from ARIN. Having just typed 'whois 103.11.67.105' I completely missed the fact that the supernet was APNIC until I checked the web interface.
Oh!! Wow!! I totally missed this also, i.e. that ARIN is showing an allocation for 103.11.64.0/22 to HostUs.Us in Texas.
That's really weird, but even that doesn't either explain or excuse what still looks like an illicit squat (by an unrelated Los Angeles company) on the 103.11.67.0/24 block to me... perhaps one that's been re-sold to a spammer (which seems possible, given the spam I got).
In my own defense, I didn't see the ARIN allocation because I have a normative process that I use for looking up IP addresses. It's hierarchical, and I always start with whatver whois.iana.org has to say. And it says that that 103.0.0.0/8 belongs to APNIC, so of course, I only looked at what whois.apnic.net had to say about 103.11.67.105. And it says that it's unallocated. (And apparently, data shown for announced prefixes on the bgp.he.net web site is also obtained in this same straightforward way, because it also is showing 103.11.67.0/24 as registered to "Asia Pacific Network Information Centre".)
This isn't the first time I've wished that the right hand knew (or cared) what the left hand was doing. I've asked the folks at IANA about this sort of thing in the past, i.e. them giving pointers to the apparently wrong RiR whois server, and they just won't fix it. They just shrug and say "Not our problem man!" And in this case, maybe they're right. If APNIC gave two subparts of 103/8 to ARIN, it might have been helpful if their own whois server was made aware of that fact.
Sigh. I have to keep reminding myself of what one friend of mine keeps on telling me... "Ron, there you go again, trying to think about these things logically."
Regards, rfg
Ronald F. Guilmette wrote:
I always start with whatver whois.iana.org has to say. And it says that that 103.0.0.0/8 belongs to APNIC, so of course, I only looked at what whois.apnic.net had to say about 103.11.67.105.
yeah, this prefix was transferred from APNIC to ARIN. You can search for the details here: https://www.apnic.net/manage-ip/manage-resources/transfer-resources/transfer... There's a full log on their ftp site: ftp://ftp.apnic.net/public/transfers/apnic/transfer-apnic-latest No doubt other RIRs have their own transfer listings.
This isn't the first time I've wished that the right hand knew (or cared) what the left hand was doing. I've asked the folks at IANA about this sort of thing in the past, i.e. them giving pointers to the apparently wrong RiR whois server, and they just won't fix it.
It's not an IANA problem to fix. IANA handles the initial allocation to the RIR, but does not account for subsequent inter-RIR transfers. There are 5 RIRs, so 20 different ways for data to flow, and IANA is no longer authoritative for the address space once its been RIR-allocated. This excludes ERX space, which is another bundle of fun. I.e. you should no longer depend on whois.iana.org for accurate resource delegation information. The LACNIC whois server (whois.lacnic.net) appears to maintain pointer information, judging by a couple of queries. Nick
On Oct 29, 2016, at 5:18 PM, Nick Hilliard <nick@foobar.org> wrote:
There are 5 RIRs, so 20 different ways for data to flow, and IANA is no longer authoritative for the address space once its been RIR-allocated.
While true, hopefully referrals in RDAP will address the need to identify registration information down to the leaves.
I.e. you should no longer depend on whois.iana.org for accurate resource delegation information.
Well, it should be accurate at the top-level delegation (albeit, the IANA Whois server only deals with /8s). Regards, -drc (speaking only for myself)
In message <5814696F.3060106@foobar.org>, Nick Hilliard <nick@foobar.org> wrote:
Ronald F. Guilmette wrote:
I always start with whatver whois.iana.org has to say. And it says that that 103.0.0.0/8 belongs to APNIC, so of course, I only looked at what whois.apnic.net had to say about 103.11.67.105.
yeah, this prefix was transferred from APNIC to ARIN. You can search for the details here:
https://www.apnic.net/manage-ip/manage-resources/transfer-resources/transfer...
Oh, geeeezzzzz! ... Showing 1 to 10 of 1,823 entries
This isn't the first time I've wished that the right hand knew (or cared) what the left hand was doing. I've asked the folks at IANA about this sort of thing in the past, i.e. them giving pointers to the apparently wrong RiR whois server, and they just won't fix it.
It's not an IANA problem to fix. IANA handles the initial allocation...
You are correct. In this case, it would have been helpful if APNIC's WHOIS server returned something, when queried about 103.11.67.105, that would include an explicit referral to the ARIN WHOIS server. I mean they obviously know all the transfers they've made. But I guess that somebody somwhere decided that that's just too much trouble. Regards, rfg
Ronald F. Guilmette wrote:
Oh, geeeezzzzz! ...
Showing 1 to 10 of 1,823 entries
Yeah, get over it. Number resource transfers are a thing, and this number is only going to increase.
You are correct. In this case, it would have been helpful if APNIC's WHOIS server returned something, when queried about 103.11.67.105, that would include an explicit referral to the ARIN WHOIS server. I mean they obviously know all the transfers they've made.
But I guess that somebody somwhere decided that that's just too much trouble.
David Conrad already pointed out that this problem has been solved using RDAP which supports referrals. Try installing the nicinfo command from: https://github.com/arineng/nicinfo At a guess, I'd say referrals haven't been implemented in whois because the whois "protocol" is unfixably broken and unsuitable for distributed information sharing. Nick
In message <58150673.5090201@foobar.org>, Nick Hilliard <nick@foobar.org> wrote:
David Conrad already pointed out that this problem has been solved using RDAP which supports referrals. Try installing the nicinfo command from:
https://github.com/arineng/nicinfo
At a guess, I'd say referrals haven't been implemented in whois because the whois "protocol" is unfixably broken and unsuitable for distributed information sharing.
So basically, you're saying that the fact that port 43 is still open and still providing answers... known inaccurante answers... at all of the following places is just one big tease? whois.iana.org whois.arin.net whois.ripe.net whois.apnic.net whois.lacnic.net whois.afrinic.net So the overall game plan is to continue to have these things all give out inaccurate and/or misleanding answers until such time as all of the trusting old school hacks like me either die out or get the memo telling us to just stop using this stuff? If so, thanks for telling me. Nobody else has so far had the courtesy to do so. Regards, rfg P.S. Traditional WHOIS supports referrals. For an example, try this: whois -h whois.iana.org 1197 (Providing referrals in traditional WHOIS isn't exactly rocket surgery. The fact that certain RIRs may be too... umm... preoccupied to take the time to properly populate their data bases with such referrals notwithstanding.)
Ronald F. Guilmette wrote:
So the overall game plan is to continue to have these things all give out inaccurate and/or misleanding answers until such time as all of the trusting old school hacks like me either die out or get the memo telling us to just stop using this stuff?
no, it's to move to a protocol which is fit for purpose, which "whois" is not. Nick
Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
You are correct. In this case, it would have been helpful if APNIC's WHOIS server returned something, when queried about 103.11.67.105, that would include an explicit referral to the ARIN WHOIS server. I mean they obviously know all the transfers they've made.
Yes, the state of whois referrals from RIRs is a bit of a mess. I have changed FreeBSD whois to rely more on referrals than built-in knowledge, and this mostly works. There are a couple of hacks to cope with awkward RIRs: AfriNIC's referrals are human-readable though they can be parsed if you assume the rubric is fixed; for RIPE, if the netname is NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK it is treated as a referral to ARIN; there's a similar hack for APNIC's ERX-NETBLOCKs - but evidently this doesn't apply to more recently transferred net blocks :-( It's probably time to make whois use RDAP under the covers for address lookups. Bah. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Southeast Iceland: Westerly veering northwesterly 6 to gale 8, decreasing 4 or 5 for a time. Rough or very rough, occasionally high at first, then becoming moderate in west. Showers. Good, occasionally poor.
On Fri, Oct 28, 2016 at 7:36 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
In my own defense, I didn't see the ARIN allocation because I have a normative process that I use for looking up IP addresses. It's hierarchical, and I always start with whatver whois.iana.org has to say. And it says that that 103.0.0.0/8 belongs to APNIC, so of course, I only looked at what whois.apnic.net had to say about 103.11.67.105. And it says that it's unallocated. (And apparently, data shown for announced prefixes on the bgp.he.net web site is also obtained in this same straightforward way, because it also is showing 103.11.67.0/24 as registered to "Asia Pacific Network Information Centre".)
In this new world of inter-rir transfers your process needs a revision. it's also not uncommon for hosting folks to allocate address space to non-local customers.
Spammers are doing a great job abusing the gaps in the systems. Another common pattern in the last 12-14 months has been a combination of squatting on an AS, forging some business documentation, buying transit to an IX, and proceeding to hijack prefixes over bilateral peering sessions. Pain in the rear to catch, even worse when the IX and transit providers aren't receptive to do anything about it when it's brought to their attention because the business docs used to instantiate those services are 'good enough', and they have a fiduciary interest in _not_ disconnecting the IX port or circuit. This will continue to be the norm until prefix validation is standardized and in widespread use. On Fri, Oct 28, 2016 at 5:40 PM, Ronald F. Guilmette <rfg@tristatelogic.com> wrote:
I just got a spam from 103.11.67.105. The containing /24 appears to be unallocated APNIC space.
RIPE tools seem to say that AS18450 has been routing this block since around May 23rd.
I see this kind of stuff almost every day now, it seems. And you know, there are days when I really do start to wonder "Has the Internet gone mad?"
I'm going to call these turkeys right now and just ask them, point blank, what the bleep they think they're doing, routing unallocated APNIC space. But if history is any guide, this is probably going to turn out to be another one of these "absentee landlord" kinds of ASes, where all they have is an answering machine.
I have to either laugh or cry when I see people posting here about the non-functionality of abuse@ email addresses, and then see other people saying "Well, this is why all ASes also have phone numbers."
I wish I had a dollar for every AS I had ever tried to contact where -neither- the abuse@ address -nor- the phone number got me to any actual human being.
Regards, rfg
participants (12)
-
Ca By -
Christopher Morrow -
David Conrad -
Doug Clements -
Ken Chase -
Mark Andrews -
Michael Smith -
Nick Hilliard -
Ronald F. Guilmette -
Stephen Satchell -
Tom Beecher -
Tony Finch