IPv4 Legacy assignment frustration

Wed Jun 22 16:06:18 UTC 2016

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 at dotat.at> wrote:

> Spurling, Shannon <shannon at 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 at 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.
>

--