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