IPv4 Legacy assignment frustration
I am not sure how many on the list are Legacy resource holders from before the RIR's were established, but there is an extremely short sighted security practice that is being used across the internet. Apparently, the RIR that has been given "authority" for an IP prefix range that was a legacy assignment is being used as a geographical locator for those prefixes. For instance, we provide access for several /16's that are in the 150/8 prefix that was set as APNIC. I am aware of quite a few organizations in the US that have prefixes in that range. We have registered our legacy resources with ARIN, but there are some people insist that somehow the state of Missouri must be part of China because... "APNIC!". They set firewalls and access rules based on that, and are hard pressed to not fix them. Is there any way to raise awareness to this inconsistency so that security people will stop doing this? Shannon Spurling shannon@more.net
There is absolutely no budgeting for idiots. Beyond a long hard process that is helped by internal escalations from affected people on a corporate network - ideally as senior as you can get - ot their IT staff. “Missouri isn’t in China, you nitwit. Fix it or I, the CFO, will go have a word with the CIO and ..” In other words, have affected people escalate up the chain to the ISP or more likely corporate IT team that’s doing this sort of stupid filteringg.
On 21-Jun-2016, at 8:07 PM, Spurling, Shannon <shannon@more.net> wrote:
I am not sure how many on the list are Legacy resource holders from before the RIR's were established, but there is an extremely short sighted security practice that is being used across the internet.
Apparently, the RIR that has been given "authority" for an IP prefix range that was a legacy assignment is being used as a geographical locator for those prefixes. For instance, we provide access for several /16's that are in the 150/8 prefix that was set as APNIC. I am aware of quite a few organizations in the US that have prefixes in that range. We have registered our legacy resources with ARIN, but there are some people insist that somehow the state of Missouri must be part of China because... "APNIC!". They set firewalls and access rules based on that, and are hard pressed to not fix them.
Is there any way to raise awareness to this inconsistency so that security people will stop doing this?
how is this a problem with the RIR ? On Tue, Jun 21, 2016 at 11:01 PM, Suresh Ramasubramanian < ops.lists@gmail.com> wrote:
There is absolutely no budgeting for idiots. Beyond a long hard process that is helped by internal escalations from affected people on a corporate network - ideally as senior as you can get - ot their IT staff. “Missouri isn’t in China, you nitwit. Fix it or I, the CFO, will go have a word with the CIO and ..”
In other words, have affected people escalate up the chain to the ISP or more likely corporate IT team that’s doing this sort of stupid filteringg.
On 21-Jun-2016, at 8:07 PM, Spurling, Shannon <shannon@more.net> wrote:
I am not sure how many on the list are Legacy resource holders from before the RIR's were established, but there is an extremely short sighted security practice that is being used across the internet.
Apparently, the RIR that has been given "authority" for an IP prefix range that was a legacy assignment is being used as a geographical locator for those prefixes. For instance, we provide access for several /16's that are in the 150/8 prefix that was set as APNIC. I am aware of quite a few organizations in the US that have prefixes in that range. We have registered our legacy resources with ARIN, but there are some people insist that somehow the state of Missouri must be part of China because... "APNIC!". They set firewalls and access rules based on that, and are hard pressed to not fix them.
Is there any way to raise awareness to this inconsistency so that security people will stop doing this?
It’s a problem with the miss-use of the RIR delegation of a legacy block. The assumption that because a block is assigned to a particular RIR, all users in that block have to be in that RIR’s territory, without actually running a query against that RIR’s Whois database. From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, June 21, 2016 10:36 PM To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Spurling, Shannon <shannon@more.net>; nanog@nanog.org Subject: Re: IPv4 Legacy assignment frustration how is this a problem with the RIR ? On Tue, Jun 21, 2016 at 11:01 PM, Suresh Ramasubramanian <ops.lists@gmail.com<mailto:ops.lists@gmail.com>> wrote: There is absolutely no budgeting for idiots. Beyond a long hard process that is helped by internal escalations from affected people on a corporate network - ideally as senior as you can get - ot their IT staff. “Missouri isn’t in China, you nitwit. Fix it or I, the CFO, will go have a word with the CIO and ..” In other words, have affected people escalate up the chain to the ISP or more likely corporate IT team that’s doing this sort of stupid filteringg.
On 21-Jun-2016, at 8:07 PM, Spurling, Shannon <shannon@more.net<mailto:shannon@more.net>> wrote:
I am not sure how many on the list are Legacy resource holders from before the RIR's were established, but there is an extremely short sighted security practice that is being used across the internet.
Apparently, the RIR that has been given "authority" for an IP prefix range that was a legacy assignment is being used as a geographical locator for those prefixes. For instance, we provide access for several /16's that are in the 150/8 prefix that was set as APNIC. I am aware of quite a few organizations in the US that have prefixes in that range. We have registered our legacy resources with ARIN, but there are some people insist that somehow the state of Missouri must be part of China because... "APNIC!". They set firewalls and access rules based on that, and are hard pressed to not fix them.
Is there any way to raise awareness to this inconsistency so that security people will stop doing this?
On 6/22/16 6:36 AM, Spurling, Shannon wrote:
It’s a problem with the miss-use of the RIR delegation of a legacy block.
The assumption that because a block is assigned to a particular RIR, all users in that block have to be in that RIR’s territory, without actually running a query against that RIR’s Whois database.
I don't think it's an RIR / RIR-related problem, just - as you said - a short-sighted security practice. Operators that connect to the Internet and then decide "OMG, Asia is evil" are fairly frustrating. This has caused me a number of problems for decades, as AU/NZ are fairly frequent trading partners of USA and I have frequently run into this attitude.
Spurling, Shannon <shannon@more.net> wrote:
It’s a problem with the miss-use of the RIR delegation of a legacy block.
The assumption that because a block is assigned to a particular RIR, all users in that block have to be in that RIR’s territory, without actually running a query against that RIR’s Whois database.
Actually, a simple whois query often isn't enough to solve this problem. Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses that are registered in other RIRs. ARIN, however, does. (However, if the geoip people are using whois data, I can't believe they aren't handling cases like this properly, because it's blatantly obvious if you scan IPv4 address space for referrals.) If you use FreeBSD-CURRENT's whois client, it tries to work mostly by following referrals, rather than using a built-in database mapping query strings to whois servers. If you query for 150.199.0.0 (for example) you get the following (which I have brutally trimmed for length): % IANA WHOIS server refer: whois.apnic.net inetnum: 150.0.0.0 - 150.255.255.255 organisation: Administered by APNIC status: LEGACY % [whois.apnic.net] inetnum: 150.0.0.0 - 150.255.255.255 netname: ERX-NETBLOCK descr: Early registration addresses remarks: Address ranges from this historical space have now remarks: been transferred to the appropriate RIR database.remarks: remarks: If your search has returned this record, it means the remarks: address range is not administered by APNIC. remarks: remarks: Instead, please search one of the following databases: (It then unhelpfully lists all the other RIRs.) FreeBSD's whois client spots this failure then retries the query at ARIN. There's a similar problem with RIPE, for instance if you query for 141.211.0.0: % IANA WHOIS server refer: whois.ripe.net inetnum: 141.0.0.0 - 141.255.255.255 organisation: Administered by RIPE NCC status: LEGACY % This is the RIPE Database query service. inetnum: 141.209.0.0 - 141.225.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC remarks: You can find the whois server to query, or the remarks: IANA registry to query on this web page: remarks: http://www.iana.org/assignments/ipv4-address-space remarks: remarks: You can access databases of other RIRs at: (It then unhelpfully lists all the other RIRs.) Actually RIPE is even worse than APNIC because it implicitly has a referral loop between IANA and RIPE. BUT NOTE! The APNIC and RIPE databases do in fact contain the referral information - you can get it via RDAP but not whois. Repeating the examples, $ curl -i https://rdap.apnic.net/ip/150.199.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/150.199.0.0 $ curl -i https://rdap.db.ripe.net/ip/141.211.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/141.211.0.0 Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog patches, thundery showers. Moderate, occasionally very poor.
The following might add some clarity, depending upon how you look at it: We, as "core" engineers know better than to use some of the sources listed below, tho, my suspicion is that when an engineer or local IT person, on an edge network starts to see various types of attacks, they play wack-a-mole, based upon outdated or incomplete data, and never think twice about revisiting such, as, from their perspective, everything is working just fine. In a networking psychology test, earlier this morning, I wrote to ten well-known colleagues that I was fairly confident didn't regularly follow the nanog lists. Such individuals comprised of IP and IT engineers for which manage various network sizes and enterprises, ultimately posing the question of "Where in the world is 150.201.15.7, as we were researching some unique traffic patterns". *Seven out of ten came back with overseas*. Two came back with more questions "as the address space appeared to be assigned to APNIC", but was routed domestically. *One came back with the correct response.* (MORENET) Two of the queried parties were representative of major networks, one for an entire state governmental network with hundreds of thousands of actual users and tens of thousands of routers, the other from another major university. (Names left out, in the event they see this message later in the day or week) After probing the origin of their responses, I found the following methods or data-sources were used: -Search Engines - by far, the worst offender. Not necessarily "the engines" at fault, but a result of indexed sites containing inaccurate or outdated CIDR lists. -User generated forums, such as "Block non-North American Traffic for Dummies Like Me <https://www.webmasterworld.com/search_engine_spiders/4663915-2-30.htm>" (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr. Member) -Static (or aged) CIDR web-page based lists, usually placed for advertorial generation purposes and rarely up to date or accurate. (usually via SE's or forum referrals) -APNIC themselves - A basic SE search resulted in an APNIC page <https://www.apnic.net/manage-ip/manage-historical-resources/erx-project/erx-ranges> that, on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the current APNIC range. -GitHub BGP Ranking tools: CIRCL / bgp-ranging example <https://github.com/CIRCL/bgp-ranking/blob/master/lib/db_init/ip_del_list> (last updated on May 16th, 2011, tho an RT lookup <http://bgpranking.circl.lu/ip_lookup?ip=150.201.15.7> via the CIRCL tool does shows the appropriate redirect/org) -Several routing oriented books and Cisco examples <http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/13796-route-leak.pdf> list such range, for example, FR/ISBN 2-212-09238-5. -And even established ISPs, that are publically announcing their "block list <http://www.albury.net.au/netstatus/derouted.html>", such as Albury's Local ISP in Australia The simple answer is to point IT directors, IP engineers or "the receptionists that manages the network" to the appropriate registry data-source, which should convince them that corrective action is necessary, i.e. fix your routing table or firewall. The complexity begins in trying to locate all of these people and directing them to the appropriate data-source, which I think is an unrealistic task, even for the largest of operators. Maybe a nanog-edge group is in order. If the issue was beyond just a nuisance and If I were in your shoes, i'd renumber or use an alternate range for the types of traffic affected by such blocks, i.e. administrative web traffic trying to reach major insurance portals. (Looks like AS2572 is announcing just over 700k IPv4 address, over about 43 ranges with only some potentially affected) Realizing that renumbering is also extremely unrealistic, if you haven't already reached the IPv6 bandwagon, that's an option or, if none of the above seem reasonable, you could always put together a one-page PDF that points these administrators to the appropriate resource to validate that you, are in fact, part of the domestic United States. I agree that a more accurate tool probably needs to be created for the "general population to consume," but then again, even that solution, is "just another tool" for the search-engines to index, and you're back at square one. As much as I think most of us would like to help fix this issue, I don't know that a decent, non-invasive solution exists, at least based upon the few hours we threw at this issue today... On Wed, Jun 22, 2016 at 10:37 AM, Tony Finch <dot@dotat.at> wrote:
Spurling, Shannon <shannon@more.net> wrote:
It’s a problem with the miss-use of the RIR delegation of a legacy block.
The assumption that because a block is assigned to a particular RIR, all users in that block have to be in that RIR’s territory, without actually running a query against that RIR’s Whois database.
Actually, a simple whois query often isn't enough to solve this problem. Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses that are registered in other RIRs. ARIN, however, does.
(However, if the geoip people are using whois data, I can't believe they aren't handling cases like this properly, because it's blatantly obvious if you scan IPv4 address space for referrals.)
If you use FreeBSD-CURRENT's whois client, it tries to work mostly by following referrals, rather than using a built-in database mapping query strings to whois servers. If you query for 150.199.0.0 (for example) you get the following (which I have brutally trimmed for length):
% IANA WHOIS server
refer: whois.apnic.net
inetnum: 150.0.0.0 - 150.255.255.255 organisation: Administered by APNIC status: LEGACY
% [whois.apnic.net]
inetnum: 150.0.0.0 - 150.255.255.255 netname: ERX-NETBLOCK descr: Early registration addresses
remarks: Address ranges from this historical space have now remarks: been transferred to the appropriate RIR database.remarks: remarks: If your search has returned this record, it means the remarks: address range is not administered by APNIC. remarks: remarks: Instead, please search one of the following databases:
(It then unhelpfully lists all the other RIRs.)
FreeBSD's whois client spots this failure then retries the query at ARIN.
There's a similar problem with RIPE, for instance if you query for 141.211.0.0:
% IANA WHOIS server
refer: whois.ripe.net
inetnum: 141.0.0.0 - 141.255.255.255 organisation: Administered by RIPE NCC status: LEGACY
% This is the RIPE Database query service.
inetnum: 141.209.0.0 - 141.225.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC
remarks: You can find the whois server to query, or the remarks: IANA registry to query on this web page: remarks: http://www.iana.org/assignments/ipv4-address-space remarks: remarks: You can access databases of other RIRs at:
(It then unhelpfully lists all the other RIRs.)
Actually RIPE is even worse than APNIC because it implicitly has a referral loop between IANA and RIPE.
BUT NOTE!
The APNIC and RIPE databases do in fact contain the referral information - you can get it via RDAP but not whois. Repeating the examples,
$ curl -i https://rdap.apnic.net/ip/150.199.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/150.199.0.0
$ curl -i https://rdap.db.ripe.net/ip/141.211.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/141.211.0.0
Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog patches, thundery showers. Moderate, occasionally very poor.
--
Regardless of whether or not people "should" do this, I think the horse has already left the barn on this one. I don't see any way of getting people who decided to filter all of APNIC to make changes. Most of them are static configurations that they'll never look to update. On Wed, Jun 22, 2016 at 12:06 PM, Kraig Beahn <kraig@enguity.com> wrote:
The following might add some clarity, depending upon how you look at it:
We, as "core" engineers know better than to use some of the sources listed below, tho, my suspicion is that when an engineer or local IT person, on an edge network starts to see various types of attacks, they play wack-a-mole, based upon outdated or incomplete data, and never think twice about revisiting such, as, from their perspective, everything is working just fine.
In a networking psychology test, earlier this morning, I wrote to ten well-known colleagues that I was fairly confident didn't regularly follow the nanog lists. Such individuals comprised of IP and IT engineers for which manage various network sizes and enterprises, ultimately posing the question of "Where in the world is 150.201.15.7, as we were researching some unique traffic patterns".
*Seven out of ten came back with overseas*. Two came back with more questions "as the address space appeared to be assigned to APNIC", but was routed domestically.
*One came back with the correct response.* (MORENET)
Two of the queried parties were representative of major networks, one for an entire state governmental network with hundreds of thousands of actual users and tens of thousands of routers, the other from another major university. (Names left out, in the event they see this message later in the day or week)
After probing the origin of their responses, I found the following methods or data-sources were used:
-Search Engines - by far, the worst offender. Not necessarily "the engines" at fault, but a result of indexed sites containing inaccurate or outdated CIDR lists. -User generated forums, such as "Block non-North American Traffic for Dummies Like Me <https://www.webmasterworld.com/search_engine_spiders/4663915-2-30.htm>" (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr. Member) -Static (or aged) CIDR web-page based lists, usually placed for advertorial generation purposes and rarely up to date or accurate. (usually via SE's or forum referrals) -APNIC themselves - A basic SE search resulted in an APNIC page < https://www.apnic.net/manage-ip/manage-historical-resources/erx-project/erx-...
that, on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the current APNIC range. -GitHub BGP Ranking tools: CIRCL / bgp-ranging example <https://github.com/CIRCL/bgp-ranking/blob/master/lib/db_init/ip_del_list> (last updated on May 16th, 2011, tho an RT lookup <http://bgpranking.circl.lu/ip_lookup?ip=150.201.15.7> via the CIRCL tool does shows the appropriate redirect/org) -Several routing oriented books and Cisco examples < http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-...
list such range, for example, FR/ISBN 2-212-09238-5. -And even established ISPs, that are publically announcing their "block list <http://www.albury.net.au/netstatus/derouted.html>", such as Albury's Local ISP in Australia
The simple answer is to point IT directors, IP engineers or "the receptionists that manages the network" to the appropriate registry data-source, which should convince them that corrective action is necessary, i.e. fix your routing table or firewall. The complexity begins in trying to locate all of these people and directing them to the appropriate data-source, which I think is an unrealistic task, even for the largest of operators. Maybe a nanog-edge group is in order.
If the issue was beyond just a nuisance and If I were in your shoes, i'd renumber or use an alternate range for the types of traffic affected by such blocks, i.e. administrative web traffic trying to reach major insurance portals. (Looks like AS2572 is announcing just over 700k IPv4 address, over about 43 ranges with only some potentially affected)
Realizing that renumbering is also extremely unrealistic, if you haven't already reached the IPv6 bandwagon, that's an option or, if none of the above seem reasonable, you could always put together a one-page PDF that points these administrators to the appropriate resource to validate that you, are in fact, part of the domestic United States.
I agree that a more accurate tool probably needs to be created for the "general population to consume," but then again, even that solution, is "just another tool" for the search-engines to index, and you're back at square one.
As much as I think most of us would like to help fix this issue, I don't know that a decent, non-invasive solution exists, at least based upon the few hours we threw at this issue today...
On Wed, Jun 22, 2016 at 10:37 AM, Tony Finch <dot@dotat.at> wrote:
Spurling, Shannon <shannon@more.net> wrote:
It’s a problem with the miss-use of the RIR delegation of a legacy block.
The assumption that because a block is assigned to a particular RIR, all users in that block have to be in that RIR’s territory, without actually running a query against that RIR’s Whois database.
Actually, a simple whois query often isn't enough to solve this problem. Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses that are registered in other RIRs. ARIN, however, does.
(However, if the geoip people are using whois data, I can't believe they aren't handling cases like this properly, because it's blatantly obvious if you scan IPv4 address space for referrals.)
If you use FreeBSD-CURRENT's whois client, it tries to work mostly by following referrals, rather than using a built-in database mapping query strings to whois servers. If you query for 150.199.0.0 (for example) you get the following (which I have brutally trimmed for length):
% IANA WHOIS server
refer: whois.apnic.net
inetnum: 150.0.0.0 - 150.255.255.255 organisation: Administered by APNIC status: LEGACY
% [whois.apnic.net]
inetnum: 150.0.0.0 - 150.255.255.255 netname: ERX-NETBLOCK descr: Early registration addresses
remarks: Address ranges from this historical space have now remarks: been transferred to the appropriate RIR database.remarks: remarks: If your search has returned this record, it means the remarks: address range is not administered by APNIC. remarks: remarks: Instead, please search one of the following databases:
(It then unhelpfully lists all the other RIRs.)
FreeBSD's whois client spots this failure then retries the query at ARIN.
There's a similar problem with RIPE, for instance if you query for 141.211.0.0:
% IANA WHOIS server
refer: whois.ripe.net
inetnum: 141.0.0.0 - 141.255.255.255 organisation: Administered by RIPE NCC status: LEGACY
% This is the RIPE Database query service.
inetnum: 141.209.0.0 - 141.225.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC
remarks: You can find the whois server to query, or the remarks: IANA registry to query on this web page: remarks: http://www.iana.org/assignments/ipv4-address-space remarks: remarks: You can access databases of other RIRs at:
(It then unhelpfully lists all the other RIRs.)
Actually RIPE is even worse than APNIC because it implicitly has a referral loop between IANA and RIPE.
BUT NOTE!
The APNIC and RIPE databases do in fact contain the referral information
you can get it via RDAP but not whois. Repeating the examples,
$ curl -i https://rdap.apnic.net/ip/150.199.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/150.199.0.0
$ curl -i https://rdap.db.ripe.net/ip/141.211.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/141.211.0.0
Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog patches, thundery showers. Moderate, occasionally very poor.
--
-- Ray Patrick Soucy Senior Cyber Security Engineer Networkmaine, University of Maine System US:IT 207-561-3526
Hi Ray, Kraig I think people affected just have to try to put pressure on their isps in the path between the afffected ips and hope for the best... public pressure is probably the only way to get around what I think most of us would agree is a terrible practice... I really hope that we can get rid of this practice as the last crumbs of IPv4 are carved up and re-distributed amongst new and growing isps. perhaps a name and shame project to highlight those isps that block ip ranges constantly and indiscriminately, needless to say the impact such practice has on peoples freedom to communicate, Thanks Tom Smyth On Thu, Jun 23, 2016 at 4:09 PM, Ray Soucy <rps@maine.edu> wrote:
Regardless of whether or not people "should" do this, I think the horse has already left the barn on this one. I don't see any way of getting people who decided to filter all of APNIC to make changes. Most of them are static configurations that they'll never look to update.
On Wed, Jun 22, 2016 at 12:06 PM, Kraig Beahn <kraig@enguity.com> wrote:
The following might add some clarity, depending upon how you look at it:
We, as "core" engineers know better than to use some of the sources listed below, tho, my suspicion is that when an engineer or local IT person, on an edge network starts to see various types of attacks, they play wack-a-mole, based upon outdated or incomplete data, and never think twice about revisiting such, as, from their perspective, everything is working just fine.
In a networking psychology test, earlier this morning, I wrote to ten well-known colleagues that I was fairly confident didn't regularly follow the nanog lists. Such individuals comprised of IP and IT engineers for which manage various network sizes and enterprises, ultimately posing the question of "Where in the world is 150.201.15.7, as we were researching some unique traffic patterns".
*Seven out of ten came back with overseas*. Two came back with more questions "as the address space appeared to be assigned to APNIC", but was routed domestically.
*One came back with the correct response.* (MORENET)
Two of the queried parties were representative of major networks, one for an entire state governmental network with hundreds of thousands of actual users and tens of thousands of routers, the other from another major university. (Names left out, in the event they see this message later in the day or week)
After probing the origin of their responses, I found the following methods or data-sources were used:
-Search Engines - by far, the worst offender. Not necessarily "the engines" at fault, but a result of indexed sites containing inaccurate or outdated CIDR lists. -User generated forums, such as "Block non-North American Traffic for Dummies Like Me <https://www.webmasterworld.com/search_engine_spiders/4663915-2-30.htm>" (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr. Member) -Static (or aged) CIDR web-page based lists, usually placed for advertorial generation purposes and rarely up to date or accurate. (usually via SE's or forum referrals) -APNIC themselves - A basic SE search resulted in an APNIC page <
https://www.apnic.net/manage-ip/manage-historical-resources/erx-project/erx-...
that, on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the current APNIC range. -GitHub BGP Ranking tools: CIRCL / bgp-ranging example < https://github.com/CIRCL/bgp-ranking/blob/master/lib/db_init/ip_del_list> (last updated on May 16th, 2011, tho an RT lookup <http://bgpranking.circl.lu/ip_lookup?ip=150.201.15.7> via the CIRCL tool does shows the appropriate redirect/org) -Several routing oriented books and Cisco examples <
list such range, for example, FR/ISBN 2-212-09238-5. -And even established ISPs, that are publically announcing their "block list <http://www.albury.net.au/netstatus/derouted.html>", such as Albury's Local ISP in Australia
The simple answer is to point IT directors, IP engineers or "the receptionists that manages the network" to the appropriate registry data-source, which should convince them that corrective action is necessary, i.e. fix your routing table or firewall. The complexity begins in trying to locate all of these people and directing them to the appropriate data-source, which I think is an unrealistic task, even for
largest of operators. Maybe a nanog-edge group is in order.
If the issue was beyond just a nuisance and If I were in your shoes, i'd renumber or use an alternate range for the types of traffic affected by such blocks, i.e. administrative web traffic trying to reach major insurance portals. (Looks like AS2572 is announcing just over 700k IPv4 address, over about 43 ranges with only some potentially affected)
Realizing that renumbering is also extremely unrealistic, if you haven't already reached the IPv6 bandwagon, that's an option or, if none of the above seem reasonable, you could always put together a one-page PDF that points these administrators to the appropriate resource to validate that you, are in fact, part of the domestic United States.
I agree that a more accurate tool probably needs to be created for the "general population to consume," but then again, even that solution, is "just another tool" for the search-engines to index, and you're back at square one.
As much as I think most of us would like to help fix this issue, I don't know that a decent, non-invasive solution exists, at least based upon the few hours we threw at this issue today...
On Wed, Jun 22, 2016 at 10:37 AM, Tony Finch <dot@dotat.at> wrote:
Spurling, Shannon <shannon@more.net> wrote:
It’s a problem with the miss-use of the RIR delegation of a legacy block.
The assumption that because a block is assigned to a particular RIR, all users in that block have to be in that RIR’s territory, without actually running a query against that RIR’s Whois database.
Actually, a simple whois query often isn't enough to solve this
Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses
are registered in other RIRs. ARIN, however, does.
(However, if the geoip people are using whois data, I can't believe
http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-... the problem. that they
aren't handling cases like this properly, because it's blatantly obvious if you scan IPv4 address space for referrals.)
If you use FreeBSD-CURRENT's whois client, it tries to work mostly by following referrals, rather than using a built-in database mapping query strings to whois servers. If you query for 150.199.0.0 (for example) you get the following (which I have brutally trimmed for length):
% IANA WHOIS server
refer: whois.apnic.net
inetnum: 150.0.0.0 - 150.255.255.255 organisation: Administered by APNIC status: LEGACY
% [whois.apnic.net]
inetnum: 150.0.0.0 - 150.255.255.255 netname: ERX-NETBLOCK descr: Early registration addresses
remarks: Address ranges from this historical space have now remarks: been transferred to the appropriate RIR database.remarks: remarks: If your search has returned this record, it means the remarks: address range is not administered by APNIC. remarks: remarks: Instead, please search one of the following databases:
(It then unhelpfully lists all the other RIRs.)
FreeBSD's whois client spots this failure then retries the query at ARIN.
There's a similar problem with RIPE, for instance if you query for 141.211.0.0:
% IANA WHOIS server
refer: whois.ripe.net
inetnum: 141.0.0.0 - 141.255.255.255 organisation: Administered by RIPE NCC status: LEGACY
% This is the RIPE Database query service.
inetnum: 141.209.0.0 - 141.225.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC
remarks: You can find the whois server to query, or the remarks: IANA registry to query on this web page: remarks: http://www.iana.org/assignments/ipv4-address-space remarks: remarks: You can access databases of other RIRs at:
(It then unhelpfully lists all the other RIRs.)
Actually RIPE is even worse than APNIC because it implicitly has a referral loop between IANA and RIPE.
BUT NOTE!
The APNIC and RIPE databases do in fact contain the referral information
you can get it via RDAP but not whois. Repeating the examples,
$ curl -i https://rdap.apnic.net/ip/150.199.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/150.199.0.0
$ curl -i https://rdap.db.ripe.net/ip/141.211.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/141.211.0.0
Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog patches, thundery showers. Moderate, occasionally very poor.
--
-- Ray Patrick Soucy Senior Cyber Security Engineer Networkmaine, University of Maine System US:IT
207-561-3526
-- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments.
<3 name and shame. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Tom Smyth" <tom.smyth@wirelessconnect.eu> To: "Ray Soucy" <rps@maine.edu> Cc: nanog@nanog.org Sent: Thursday, June 23, 2016 10:23:39 AM Subject: Re: IPv4 Legacy assignment frustration Hi Ray, Kraig I think people affected just have to try to put pressure on their isps in the path between the afffected ips and hope for the best... public pressure is probably the only way to get around what I think most of us would agree is a terrible practice... I really hope that we can get rid of this practice as the last crumbs of IPv4 are carved up and re-distributed amongst new and growing isps. perhaps a name and shame project to highlight those isps that block ip ranges constantly and indiscriminately, needless to say the impact such practice has on peoples freedom to communicate, Thanks Tom Smyth On Thu, Jun 23, 2016 at 4:09 PM, Ray Soucy <rps@maine.edu> wrote:
Regardless of whether or not people "should" do this, I think the horse has already left the barn on this one. I don't see any way of getting people who decided to filter all of APNIC to make changes. Most of them are static configurations that they'll never look to update.
On Wed, Jun 22, 2016 at 12:06 PM, Kraig Beahn <kraig@enguity.com> wrote:
The following might add some clarity, depending upon how you look at it:
We, as "core" engineers know better than to use some of the sources listed below, tho, my suspicion is that when an engineer or local IT person, on an edge network starts to see various types of attacks, they play wack-a-mole, based upon outdated or incomplete data, and never think twice about revisiting such, as, from their perspective, everything is working just fine.
In a networking psychology test, earlier this morning, I wrote to ten well-known colleagues that I was fairly confident didn't regularly follow the nanog lists. Such individuals comprised of IP and IT engineers for which manage various network sizes and enterprises, ultimately posing the question of "Where in the world is 150.201.15.7, as we were researching some unique traffic patterns".
*Seven out of ten came back with overseas*. Two came back with more questions "as the address space appeared to be assigned to APNIC", but was routed domestically.
*One came back with the correct response.* (MORENET)
Two of the queried parties were representative of major networks, one for an entire state governmental network with hundreds of thousands of actual users and tens of thousands of routers, the other from another major university. (Names left out, in the event they see this message later in the day or week)
After probing the origin of their responses, I found the following methods or data-sources were used:
-Search Engines - by far, the worst offender. Not necessarily "the engines" at fault, but a result of indexed sites containing inaccurate or outdated CIDR lists. -User generated forums, such as "Block non-North American Traffic for Dummies Like Me <https://www.webmasterworld.com/search_engine_spiders/4663915-2-30.htm>" (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr. Member) -Static (or aged) CIDR web-page based lists, usually placed for advertorial generation purposes and rarely up to date or accurate. (usually via SE's or forum referrals) -APNIC themselves - A basic SE search resulted in an APNIC page <
https://www.apnic.net/manage-ip/manage-historical-resources/erx-project/erx-...
that, on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the current APNIC range. -GitHub BGP Ranking tools: CIRCL / bgp-ranging example < https://github.com/CIRCL/bgp-ranking/blob/master/lib/db_init/ip_del_list> (last updated on May 16th, 2011, tho an RT lookup <http://bgpranking.circl.lu/ip_lookup?ip=150.201.15.7> via the CIRCL tool does shows the appropriate redirect/org) -Several routing oriented books and Cisco examples <
list such range, for example, FR/ISBN 2-212-09238-5. -And even established ISPs, that are publically announcing their "block list <http://www.albury.net.au/netstatus/derouted.html>", such as Albury's Local ISP in Australia
The simple answer is to point IT directors, IP engineers or "the receptionists that manages the network" to the appropriate registry data-source, which should convince them that corrective action is necessary, i.e. fix your routing table or firewall. The complexity begins in trying to locate all of these people and directing them to the appropriate data-source, which I think is an unrealistic task, even for
largest of operators. Maybe a nanog-edge group is in order.
If the issue was beyond just a nuisance and If I were in your shoes, i'd renumber or use an alternate range for the types of traffic affected by such blocks, i.e. administrative web traffic trying to reach major insurance portals. (Looks like AS2572 is announcing just over 700k IPv4 address, over about 43 ranges with only some potentially affected)
Realizing that renumbering is also extremely unrealistic, if you haven't already reached the IPv6 bandwagon, that's an option or, if none of the above seem reasonable, you could always put together a one-page PDF that points these administrators to the appropriate resource to validate that you, are in fact, part of the domestic United States.
I agree that a more accurate tool probably needs to be created for the "general population to consume," but then again, even that solution, is "just another tool" for the search-engines to index, and you're back at square one.
As much as I think most of us would like to help fix this issue, I don't know that a decent, non-invasive solution exists, at least based upon the few hours we threw at this issue today...
On Wed, Jun 22, 2016 at 10:37 AM, Tony Finch <dot@dotat.at> wrote:
Spurling, Shannon <shannon@more.net> wrote:
It’s a problem with the miss-use of the RIR delegation of a legacy block.
The assumption that because a block is assigned to a particular RIR, all users in that block have to be in that RIR’s territory, without actually running a query against that RIR’s Whois database.
Actually, a simple whois query often isn't enough to solve this
Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses
are registered in other RIRs. ARIN, however, does.
(However, if the geoip people are using whois data, I can't believe
http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-... the problem. that they
aren't handling cases like this properly, because it's blatantly obvious if you scan IPv4 address space for referrals.)
If you use FreeBSD-CURRENT's whois client, it tries to work mostly by following referrals, rather than using a built-in database mapping query strings to whois servers. If you query for 150.199.0.0 (for example) you get the following (which I have brutally trimmed for length):
% IANA WHOIS server
refer: whois.apnic.net
inetnum: 150.0.0.0 - 150.255.255.255 organisation: Administered by APNIC status: LEGACY
% [whois.apnic.net]
inetnum: 150.0.0.0 - 150.255.255.255 netname: ERX-NETBLOCK descr: Early registration addresses
remarks: Address ranges from this historical space have now remarks: been transferred to the appropriate RIR database.remarks: remarks: If your search has returned this record, it means the remarks: address range is not administered by APNIC. remarks: remarks: Instead, please search one of the following databases:
(It then unhelpfully lists all the other RIRs.)
FreeBSD's whois client spots this failure then retries the query at ARIN.
There's a similar problem with RIPE, for instance if you query for 141.211.0.0:
% IANA WHOIS server
refer: whois.ripe.net
inetnum: 141.0.0.0 - 141.255.255.255 organisation: Administered by RIPE NCC status: LEGACY
% This is the RIPE Database query service.
inetnum: 141.209.0.0 - 141.225.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC
remarks: You can find the whois server to query, or the remarks: IANA registry to query on this web page: remarks: http://www.iana.org/assignments/ipv4-address-space remarks: remarks: You can access databases of other RIRs at:
(It then unhelpfully lists all the other RIRs.)
Actually RIPE is even worse than APNIC because it implicitly has a referral loop between IANA and RIPE.
BUT NOTE!
The APNIC and RIPE databases do in fact contain the referral information
you can get it via RDAP but not whois. Repeating the examples,
$ curl -i https://rdap.apnic.net/ip/150.199.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/150.199.0.0
$ curl -i https://rdap.db.ripe.net/ip/141.211.0.0 HTTP/1.1 301 Moved Permanently Location: https://rdap.arin.net/registry/ip/141.211.0.0
Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog patches, thundery showers. Moderate, occasionally very poor.
--
-- Ray Patrick Soucy Senior Cyber Security Engineer Networkmaine, University of Maine System US:IT
207-561-3526
-- Kindest regards, Tom Smyth Mobile: +353 87 6193172 --------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL This email contains information which may be confidential or privileged. The information is intended solely for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify me by telephone or by electronic mail immediately. Any opinions expressed are those of the author, not the company's .This email does not constitute either offer or acceptance of any contractually binding agreement. Such offer or acceptance must be communicated in writing. You are requested to carry out your own virus check before opening any attachment. Thomas Smyth accepts no liability for any loss or damage which may be caused by malicious software or attachments.
participants (9)
-
Alastair Johnson -
Christopher Morrow -
Kraig Beahn -
Mike Hammett -
Ray Soucy -
Spurling, Shannon -
Suresh Ramasubramanian -
Tom Smyth -
Tony Finch