AFRINIC: The Saga Continues

[Ronald F. Guilmette]

My apologies to all.  Certain of the blocks mentioned in my prior
posting here have already been reclaimed, and are currently being
routed by appropriate parties.  In particular, these ones:

152.108.0.0/16
155.237.0.0/16
165.4.0.0/16
165.5.0.0/16

Also, I somehow managed to miss mentioning a few blocks that were also
quite clearly stolen as part of this extensive and elaborate scheme,
specifically these ones:

160.116.0.0/16
163.198.0.0/16
164.88.0.0/16
196.15.96.0/18

A full list of all of the stolen AFRINIC blocks that are still of
ongoing concern at the present moment, taking into account the above
adjustments, is available here:

https://pastebin.com/raw/71zNNriB

Note that many of the blocks listed at the link above have already
been "reclaimed" as far as the AFRINIC WHOIS records are concerned.
But because routing remains almost entirely decoupled from RIR WHOIS
data bases, much of this "reclaimed" space is still being routed as
I write this.  The only difference is that now the space is being
routed as bogons, rather than as "legitimately" allocated space.

A summary of all of the current routing for all of the stolen AFRINIC
IPv4 address space that is still of concern, including routing for
recently reclaimed address space that AFRINIC will eventually be
returning to its free pool is provided below.  This list is sorted
by the number of constituent stolen /24 blocks being routed by each
listed network, thus showing the most major offenders at the top.
A few footnotes concerning specific ASNs in this list follow below
the listing.

I urge everyone on this mailing list to share this data as widely as
possible in and among the global networking connunity.  In all cases
noted below, the networks in question are unambiguously routing IP
blocks that were obtained, in the first instance, via thefts perpetrated
by one or more AFRINIC insiders and then resold on the black market
in secretive deals.  In many and perhaps most cases listed below, the
relevant networks appear to have been more than happy to accept some
cash in exchange for their services, while not looking all that
carefully at the purported (but fradulent) "LOA" documents they were
handed.  (Repeated use of blatantly fradulent documents has been one
of the consistant features of this entire ongoing criminal enterprise.)

All routing data is derived from current data published by RIPEstat.

==
  3719  0   ??  UNROUTED IP SPACE
   629  132165  PK  Connect Communication
   512  18013   HK  Asline Limited
   504  19969   US  Joe's Datacenter, LLC
   500  62355   CO  Network Dedicated SAS
   423  202425  SC  IP Volume inc
   286  58895   PK  Ebone Network (PVT.) Limited
   250  136525  PK  Wancom (Pvt) Ltd.
   192  18530   US  Isomedia, Inc.
   186  9009GB  M247 Ltd
   134  262287  BR  Maxihost LTDA
   132  204655  NL  Novogara LTD
79  132116  IN  Ani Network Pvt Ltd
75  136384  PK  Optix Pakistan (Pvt.) Limited
68  132422  HK  Hong Kong Business Telecom Limited
60  137443  HK  Anchnet Asia Limited
48  63956   AU  Colocation Australia Pty Ltd
26  132335  IN  LeapSwitch Networks Pvt Ltd
21  131284  AF  Etisalat Afghan
20  139043  PK  WellNetworks (Private) Limited
19  43092   JP  OSOA Corporation., LTD
17  36351   US  SoftLayer Technologies Inc.
16  56611   NL  REBA Communications BV
16  199267  IL  Netstyle A. Ltd
16  23679   ID  Media Antar Nusa PT.
14  137085  IN  Nixi
10  63018   US  Dedicated.com
 9  136782  JP  Pingtan Hotline Co., Limited
 8  45671   AU  Servers Australia Pty. Ltd
 8  57717   NL  FiberXpress BV
 7  49335   RU  LLC "Server v arendy"
 7  134451  SG  NewMedia Express Pte Ltd
 6  49367   IT  Seflow S.N.C. Di Marco Brame' & C.
 6  26754   ??  {{unknown organization}}
 5  198504  AE  Star Satellite Communications Company - PJSC
 5  198381  AE  Star Satellite Communications Company - PJSC
 4  38001   SG  NewMedia Express Pte Ltd
 4  263812  AR  TL Group SRL ( IPXON Networks )
 4  30827   GB  Extraordinary Managed Services Ltd
 4  42831   GB  UK Dedicated Servers Limited
 4  37200   NG  SimbaNET Nigeria Limited
 4  133495  PK  Vision telecom Private limited
 4  198394  AE  Star Satellite Communications Company - PJSC
 2  44066   DE  First Colo GmbH
 2  198247  AE  Star Satellite Communications Company - PJSC
 2  133933  PK  NetSat Private Limited
 2  328096  UG  truIT Uganda Limited
 2  38713   PK  Satcomm (Pvt.) Ltd.
 2  31122   IE  Digiweb ltd
 2  46562   US  Total Server Solutions L.L.C.
 2  13737   US  Riverfront Internet Systems LLC
 2  11990   US  Unlimited Net, LLC
 2  20860   GB  Iomart Cloud Services Limited
 2  45382   KR  Ehostict
 2  17216   US  Dc74 Llc
 2  16637   ZA  Mtn Sa
 2  53999   CA  Priority Colo Inc
 1  23470   US  ReliableSite.Net LLC
 1  35074  

Re: Recommended DDoS mitigation appliance?

[Dmitry Sherman]

Check out Wanguard

--
Dmitry Sherman

From: NANOG  on behalf of Colton Conor 

Date: Wednesday, 29 January 2020 at 0:47
To: Mike 
Cc: NANOG 
Subject: Re: Recommended DDoS mitigation appliance?

Mike,

What did you end up going with if not fastnetmon? Were you using their paid or 
free version?

On Thu, Dec 5, 2019 at 4:45 PM Mike 
mailto:mike-na...@tiedyenetworks.com>> wrote:

On 12/5/19 1:43 PM, Hugo Slabbert wrote:
>> FastNetMon is awesome, but its a detection tool with no mitigation
>> capacity whatsoever.
>
> Does is not, though, provide the ability to hook into RTBH or Flowspec
> setups?
>

Yes it does provide RTBH hook.

I evaluated fastnetmon using exactly the 'quick setup' and found it to
have some serious problems with false alarms and statistical anomalies,
at least when using pure netflow data (did not try sampled mode).  Hosts
that were not in fact receiving >100mbps traffic (a traffic level I
predetermined as 'attack' for a given network segment), would
occasionally get flagged as such (and rtbh activated), while 2 real
attacks that came during the testing period (60 days for me) went
completely unnoticed. Support seemed to concede that sampled mode is
really the only accurate method, and which by this time I'd expended all
my interest. Great concept, cool integration, just not ready for prime time.


MIke-

Re: Backup over 4G/LTE

[Colton Conor]

Does Velcloud make an actual LTE box?

On Wed, Jan 29, 2020 at 6:44 AM K. Scott Helms 
wrote:

> There are lots of options to solve that problem.
>
> Peplink, 128T, Viptela (Cisco), Velocloud (VMWare), etc.
>
> Scott Helms
>
>
>
> On Tue, Jan 28, 2020 at 6:31 PM K MEKKAOUI  wrote:
>
>> Dear NANOG Community,
>>
>>
>>
>> Can anyone help with any device information that provides redundancy for
>> business internet access? In other words when the internet provided through
>> the cable modem fails the 4G/LTE takes over automatically to provide
>> internet access to the client.
>>
>>
>>
>> Thank you
>>
>>
>>
>> KARIM M.
>>
>>
>>
>

Re: Recommended DDoS mitigation appliance?

[Colton Conor]

Mike,

The free trial is the paid version right? Just was wondering if you use the
community or advanced paid version.

On Wed, Jan 29, 2020 at 4:38 PM Mike  wrote:

> I had intended to use the paid version once the 'free trial' proved to
> work, but for the previously mentioned reasons it did not and I gave up.
> Would still love to have this style of solution in my network and still
> open to other solutions, just haven't really found anything else.
>
>
> On 1/28/20 2:46 PM, Colton Conor wrote:
>
> Mike,
>
> What did you end up going with if not fastnetmon? Were you using
> their paid or free version?
>
> On Thu, Dec 5, 2019 at 4:45 PM Mike  wrote:
>
>>
>> On 12/5/19 1:43 PM, Hugo Slabbert wrote:
>> >> FastNetMon is awesome, but its a detection tool with no mitigation
>> >> capacity whatsoever.
>> >
>> > Does is not, though, provide the ability to hook into RTBH or Flowspec
>> > setups?
>> >
>>
>> Yes it does provide RTBH hook.
>>
>> I evaluated fastnetmon using exactly the 'quick setup' and found it to
>> have some serious problems with false alarms and statistical anomalies,
>> at least when using pure netflow data (did not try sampled mode).  Hosts
>> that were not in fact receiving >100mbps traffic (a traffic level I
>> predetermined as 'attack' for a given network segment), would
>> occasionally get flagged as such (and rtbh activated), while 2 real
>> attacks that came during the testing period (60 days for me) went
>> completely unnoticed. Support seemed to concede that sampled mode is
>> really the only accurate method, and which by this time I'd expended all
>> my interest. Great concept, cool integration, just not ready for prime
>> time.
>>
>>
>> MIke-
>>
>>

Re: Hawaii exchange and connection to mainland pops

[Martin Hannigan]

Antoni,

Search engine or PeeringDB == Dr Fortress // Fred Rodi. Solid.

They have the primary IX. Charter and Level3/CL are best option for haulage
or IP. #IMHO. Probably cable IRU options, but nit my space.

Let me know if no luck.

Cheers, and good luck!

-M<



On Wed, Jan 29, 2020 at 12:38 Antoni Matamalas 
wrote:

> Hi NANOG,
>
> I'm trying to figure out how is the connectivity in the Hawaiian Islands
> for a project I have. I'm based in Europe and my knowledge of the details
> of the communications in the islands is still limited. The project is based
> in the O'ahu island but I'm trying to understand how things are working in
> the whole Hawaiian islands (pure professional curiosity). I'm focusing on
> two aspects:
>
> * Content delivery and connection to content providers (Google, Apple,
> Netflix,...)
> * Availability of providers that can supply wavelength between Hawaiian
> Islands and the continent (LA, Seattle or other locations)
>
> Doing a quick investigation I found the Aloha-IX in the PeeringDB but it
> looks like it doesn't have many participants and non of them appear to be a
> content provider. I was expecting that Hawaii being one of the major
> landing points of fiber in the Pacific would have some more presence of
> content providers and CDNs. However, I know that the total population of
> the island is not that much (and disperse) and maybe not enough for such
> kind of deployments.
>
> Also, in terms of connectivity to the continent I have not been too lucky
> finding providers with wavelength services. For the moment I have had some
> contact with GTT and NTT but not sure if there are any other
> regional/national providers that can also provide such services.
>
> Thanks you very much in advanced for your help!
>
> Kind regards,
> --
> Antoni
>

Re: Recommended DDoS mitigation appliance?

[Mike]

I had intended to use the paid version once the 'free trial' proved to 
work, but for the previously mentioned reasons it did not and I gave up. 
Would still love to have this style of solution in my network and still 
open to other solutions, just haven't really found anything else.



On 1/28/20 2:46 PM, Colton Conor wrote:

Mike,

What did you end up going with if not fastnetmon? Were you using 
their paid or free version?


On Thu, Dec 5, 2019 at 4:45 PM Mike > wrote:



On 12/5/19 1:43 PM, Hugo Slabbert wrote:
>> FastNetMon is awesome, but its a detection tool with no mitigation
>> capacity whatsoever.
>
> Does is not, though, provide the ability to hook into RTBH or
Flowspec
> setups?
>

Yes it does provide RTBH hook.

I evaluated fastnetmon using exactly the 'quick setup' and found
it to
have some serious problems with false alarms and statistical
anomalies,
at least when using pure netflow data (did not try sampled mode). 
Hosts
that were not in fact receiving >100mbps traffic (a traffic level I
predetermined as 'attack' for a given network segment), would
occasionally get flagged as such (and rtbh activated), while 2 real
attacks that came during the testing period (60 days for me) went
completely unnoticed. Support seemed to concede that sampled mode is
really the only accurate method, and which by this time I'd
expended all
my interest. Great concept, cool integration, just not ready for
prime time.


MIke-

Re: Hawaii exchange and connection to mainland pops

[Scott Weeks]

--- a.matama...@gmail.com wrote:
From: Antoni Matamalas 

I'm trying to figure out how is the connectivity in the Hawaiian Islands
for a project I have. I'm based in Europe and my knowledge of the details
of the communications in the islands is still limited. The project is based
in the O'ahu island but I'm trying to understand how things are working in
the whole Hawaiian islands (pure professional curiosity). I'm focusing on
two aspects:

* Content delivery and connection to content providers (Google, Apple,
Netflix,...)
* Availability of providers that can supply wavelength between Hawaiian
Islands and the continent (LA, Seattle or other locations)
--




I'm assuming you're talking Commercial only?  DoD is a different 
animal as is UH.

I work for the ILEC and can fill you in on that to a certain 
degree. We have the normal Google/Netflix/Akamai/etc caches.

The population in the state of Hawaii is small.
https://census.hawaii.gov/whats-new-releases/2019-state-population-estimates
On July 1, 2019, the resident population for the State of Hawaii 
was 1,415,872.

And of those about 1 million live on one island: Oahu.  There're 
5 other islands.

We have a lot of trans-pacific fiber landing here, but it mostly 
just transits the island.  Not much gets peeled off to service 
the state due to its size.  The ILEC owns part of SEA-US:
https://www.submarinenetworks.com/systems/trans-pacific/sea-us
and we get service on Hawaiki for South Pacific connectivity.
https://www.submarinenetworks.com/en/systems/australia-usa/hawaiki-cable

Most of the inter-island fiber is owned by the ILEC, which was
bought by Cincinatti Bell, which will be bought by either 
Brookfield Infrastructure or another company whose name isn't 
public yet. (Anyone been bought by BI?  email me, please)

As mentioned in another email HIX is the internet exchange 
managed by UH and DR Fortress connects to that.  We do as 
well:

http://www.hawaii.edu/hix/Hawaii_Internet_Exchange/Home.html

https://www.drfortress.com/about/company-overview/

https://www.drfortress.com/services/internet-exchange/overview/

https://www.drfortress.com/services/internet-exchange/drfxchange/

https://www.drfortress.com/services/internet-exchange/peering-and-connectivity/

scott

Re: Hawaii exchange and connection to mainland pops

[William Herrin]

My information is a little dated (2014) but at the time:

The University of Hawaii runs HIX
DR Fortress by the airport in Honolulu (a former Equinix site)
provides commercial access to HIX

Regards,
Bill Herrin

On Wed, Jan 29, 2020 at 9:37 AM Antoni Matamalas  wrote:
>
> Hi NANOG,
>
> I'm trying to figure out how is the connectivity in the Hawaiian Islands for 
> a project I have. I'm based in Europe and my knowledge of the details of the 
> communications in the islands is still limited. The project is based in the 
> O'ahu island but I'm trying to understand how things are working in the whole 
> Hawaiian islands (pure professional curiosity). I'm focusing on two aspects:
>
> * Content delivery and connection to content providers (Google, Apple, 
> Netflix,...)
> * Availability of providers that can supply wavelength between Hawaiian 
> Islands and the continent (LA, Seattle or other locations)
>
> Doing a quick investigation I found the Aloha-IX in the PeeringDB but it 
> looks like it doesn't have many participants and non of them appear to be a 
> content provider. I was expecting that Hawaii being one of the major landing 
> points of fiber in the Pacific would have some more presence of content 
> providers and CDNs. However, I know that the total population of the island 
> is not that much (and disperse) and maybe not enough for such kind of 
> deployments.
>
> Also, in terms of connectivity to the continent I have not been too lucky 
> finding providers with wavelength services. For the moment I have had some 
> contact with GTT and NTT but not sure if there are any other 
> regional/national providers that can also provide such services.
>
> Thanks you very much in advanced for your help!
>
> Kind regards,
> --
> Antoni



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Hawaii exchange and connection to mainland pops

[Antoni Matamalas]

Hi NANOG,

I'm trying to figure out how is the connectivity in the Hawaiian Islands
for a project I have. I'm based in Europe and my knowledge of the details
of the communications in the islands is still limited. The project is based
in the O'ahu island but I'm trying to understand how things are working in
the whole Hawaiian islands (pure professional curiosity). I'm focusing on
two aspects:

* Content delivery and connection to content providers (Google, Apple,
Netflix,...)
* Availability of providers that can supply wavelength between Hawaiian
Islands and the continent (LA, Seattle or other locations)

Doing a quick investigation I found the Aloha-IX in the PeeringDB but it
looks like it doesn't have many participants and non of them appear to be a
content provider. I was expecting that Hawaii being one of the major
landing points of fiber in the Pacific would have some more presence of
content providers and CDNs. However, I know that the total population of
the island is not that much (and disperse) and maybe not enough for such
kind of deployments.

Also, in terms of connectivity to the continent I have not been too lucky
finding providers with wavelength services. For the moment I have had some
contact with GTT and NTT but not sure if there are any other
regional/national providers that can also provide such services.

Thanks you very much in advanced for your help!

Kind regards,
--
Antoni

RE: Backup over 4G/LTE

[Christopher Trudeau]

I was excited for that UBNT solution when I first saw it on the beta forum… 
then I saw that there is an eSIM with no SIM slot, and you’re locked to AT

Have you seen the price plan?
$15 MRC w/1GB, $10 for each additional GB…..

Maybe this would be great for some users, but not our users… I’ll wait for Gen2 
with a SIM slot.

-Chris

From: NANOG  On Behalf Of Ben 
Cannon
Sent: Tuesday, January 28, 2020 7:18 PM
To: Brandon Svec 
Cc: NANOG Operators' Group 
Subject: Re: Backup over 4G/LTE

New player in this space is Ubiquiti: https://unifi-lte.ui.com - more suited 
for branch office applications IMO, but the setup couldn’t be easier.Expect 
this space to grow dramatically.


-Ben Cannon
CEO 6x7 Networks & 6x7 Telecom, LLC
b...@6by7.net


[cid:245ADEA1-477E-4B5A-989E-9177BDB798AE]

On Jan 28, 2020, at 3:41 PM, Brandon Svec 
mailto:bs...@teamonesolutions.com>> wrote:

All Cisco Meraki MX and Z units.  Some via USB and some with SIM slot.

https://meraki.cisco.com/products/appliances
Security Made Simple with Cisco Meraki: http://bit.ly/MerakiSecure
[http://www.teamonesolutions.com/wp-content/uploads/header_logo.png]
Brandon Svec
CA C-7 Lic. 
#822064
.ılı.ılı. Cisco Meraki CMNA
15106862204 voice | sms
teamonesolutions.com
14729 Catalina St. San Leandro, CA 94577




On Tue, Jan 28, 2020 at 3:31 PM K MEKKAOUI 
mailto:amekka...@mektel.ca>> wrote:
Dear NANOG Community,

Can anyone help with any device information that provides redundancy for 
business internet access? In other words when the internet provided through the 
cable modem fails the 4G/LTE takes over automatically to provide internet 
access to the client.

Thank you

KARIM M.





CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner. Thank 
you.

Re: Reminiscing our first internet connections (WAS)

[Steven G. Huter]

On 1/28/20 4:22 PM, Paul Nash wrote:

Carrying on with the “first Internet connection” thread:

I forget how I found out about Usenet and UUCP email (lost in the mosts of 
time).  I ran a store and forward dial-up link from South Africa to DDSW1 in 
Chicago (Hi Karl!  Thanks!).  I cobbled together a package with a DOS-based 
mail reader and a DOS port of UUCP that several people used to get their email 
(including a local medical research establishment and the local veterinary 
college).  Demand grew, along with a request to relay email to the UNHCR in 
Northen Mozambique, so I scraped some money together to import a horribly 
expensive Telebit modem.  I ended up being the regional non-academic email hub 
for Southern Africa.

Just prior to the 1994 election, I got together with a two friends (Alan Barret 
and Chris Pinkham) and founded the first ISP in sub-Saharan Africa.  We managed 
to get a 64k satellite link at a very good price (the satellite folk were busy 
being retrenched and we were prepared to sign a contract specifically requiring 
satellite service for 5 years, which gave them some job security).  We borrowed 
a Cisco router from DiData (Cisco agents), skirted other telco regulations to 
link regions.

One of our early customers was a group of students who wanted to start a small 
dial ISP nearby.  We gave them service, bootstrapping what became our biggest 
competitor, Internet Solutions (now part of DiData, who never did ask for their 
router back).  Our little ISP grew and grew, and eventually merged with our 
biggest client, was sold, sold again, and so on.  Last time I looked, it had 
become Verizon Africa.


Hello Paul

Good to hear from you. nsrc.org archived some of your notes and 
reflections at the time.


Here is an email message from December 1992 that captures some of the 
early ZA net history.


https://nsrc.org/db/lookup/report.php?id=890202331950:497427756=ZA

And the first ping to the Internet from South Africa via rain.psg.com in 
Oregon on November 12, 1991.


https://nsrc.org/db/lookup/report.php?id=896820262105:488982630=ZA

And where it all began in October 1988. :-)

https://nsrc.org/db/lookup/report.php?id=896820010472:489008357=ZA

Steve Huter

Has Anyone managed to get Delegated RPKI working with ARIN

[Christopher Munz-Michielin]

Hi Nanog,

Posting here since my Google-fu is coming up short.  I'm trying to setup delegated RPKI 
in ARIN using rpki.net's rpkid Python daemon and am running into an issue submitting the 
identity file to ARIN's control panel. The same file submitted to RIPE's  test 
environment at https://localcert.ripe.net/#/rpki works without issue, while submitting to 
ARIN results in "Invalid Identity.xml file."

The guide I'm following is this one: 
https://github.com/dragonresearch/rpki.net/blob/master/doc/quickstart/xenial-ca.md
 and I'm able to get as far as generating the identity file.

Wondering if anyone has gone down this road before and has any helpful hints to 
make this work?

Cheers,
Chris

RE: RIP: Bill Manning

[Celeste Anderson]

Definitely sad news.  I worked with Bill at ISI when we were forming the 
MAE-LA-LAAP Internet Exchange and owe a lot of my current contributions to his 
efforts back then. He had some of the most interesting (and funny 
after-the-fact) stories surrounding his many international trips, including the 
time a travel agent forgot to get him a visa to transit from the domestic 
airport in China to the international one.  He definitely touched many people 
and shared his knowledge and expertise for many next generation network 
engineers and computer scientists.

--celeste

-Original Message-
From: NANOG  On Behalf Of Brett Watson
Sent: Monday, January 27, 2020 12:35 PM
To: nanog@nanog.org
Subject: RIP: Bill Manning

I was saddened to see this yesterday, that Bill Manning had passed. I was 
surprised this morning that it hadn’t hit NANOG yet but thought I’d post 
something because I have a ton of respect for Bill as I’m sure many here do.

I met Bill as a very young, thought-I-knew-everything network engineer around 
’92 when I was starting my internet life at a small ISP in Houston. Bill was 
visiting Stan Barber @ Sesquinet, which was my upstream provider at the time 
via T1, if I remember it all correctly.

I was young, fresh out of college with a CS degree, and learning this “internet 
thing.” I met with Bill on campus at Rice University to discuss 
networking/routing, and Bill taught me CIDR, which I had no f-ing idea at that 
time what it was. Bill was always gracious and willing to share/teach. We 
always chatted and stayed in touch at NANOG and IETF conferences and through 
his relationship with Los Nettos over the years. Most notable, to me, was 2007 
when my youngest daughter was diagnosed with cancer, and I believe Bill’s wife 
had (or previously battled) cancer as well. I hadn’t seen Bill for a few years, 
but he immediately reached out, shared his positive thoughts/prayers, and kept 
in touch during the battle we went through. Bill cared about people, and as 
noted below, he was smart as hell, and always had a crazy idea for how to solve 
a problem. Also as noted in Rod’s note below, Bill had a wealth of music 
knowledge and could always recommend something new and interesting to listen to.

I’ll definitely miss Bill, and his passing makes me feel the years, and the 
mileage, but in a good way. 

-b

>> This morning I talked to Julie Manning, Bill's wife. Bill died early 
>> Saturday morning, at home in Oregon.  Most of you know Bill was 
>> waiting for a new heart. He would perhaps have gotten one next month. 
>> I guess the old one just wouldn't hold out long enough.
>> 
>> I first met Bill in about 1995, when I returned to ISI after my first 
>> stint in Japan.  He had taken a position in the Los Nettos project at 
>> ISI, a regional network project in the days when Internet service and 
>> operations work was still heavily shared between business and 
>> academia.  Bill brought an operator's eye to the project, often 
>> seeing things differently from the researchers in the group.
>> 
>> Bill kept the most erratic hours of any non-student I've ever met.  
>> He might be in the office at 2am or at 2pm, either was equally likely.
>> I'd ask, "Bill, what time did you come in?" He'd reply, "10am."  "I 
>> was here before that, and you were already here, it must have been 
>> earlier."  "Greenwich Mean Time."
>> 
>> And in one phase of life, "Bill, where do you live?" "Seat 4A."  He 
>> would speculate about his average altitude and speed over the 
>> previous month.
>> 
>> And, like any good geek, Bill had a spectacular collection of tie-dye 
>> t-shirts.  He came by the look honestly: growing up in the Bay Area, 
>> he had actually snuck into Grateful Dead rehearsals held in a barn, 
>> and had traveled as a deadhead for a while.
>> 
>> At ISI, we called Bill "the bad idea fairy".  He always brought a 
>> slightly-off-kilter view of technical problems, which triggered 
>> endless discussions of fascinating, if usually implausible, 
>> alternatives.
>> 
>> He had the most broad-ranging musical tastes of anyone I knew, and 
>> would eat almost anything (though, like me, he didn't drink alcohol).
>> I was often envious of his eating and musical experiences.  He 
>> certainly lived life to its fullest.
>> 
>> On one occasion, I recall, we were eating lunch in a Thai restaurant 
>> for the first time.  Bill called for the food "the way you'd make it 
>> in Thailand".  The waiter went back into the kitchen and came out 
>> with a few raw Thai chiles.  Bill ate one whole, without even 
>> breaking a sweat.  The owner of the restaurant immediately came out 
>> to see who was eating them.  Pam became a friend to our group.
>> 
>> On other occasions, when the waiter asked for his order, Bill would 
>> point to another person at the table, and say, "I'll have what she's 
>> having."  "Well, what is she having?" "I don't know, I haven't heard 
>> her say."  Once in a while, he would point to someone 

Re: The curious case of 159.174.0.0/16

[Mel Beckman]

Then why are you sending email to nanog@nanog.org?

LOL!

 -mel 

> On Jan 29, 2020, at 12:41 AM, Ronald F. Guilmette  
> wrote:
> 
> I have a standing policy of never attempting to converse with unaccountable
> anonymized role accounts.  Based on past experience, this is without
> exception an utter waste of my time.

Re: The curious case of 159.174.0.0/16

[Mike Bolitho]

>
> If you always e-mail j...@telco.com instead of n...@telco.com for your
> issues, you may end of in a situation where Jake is gone, on vacation, or
> simply moved on to accounting.


Plus, Jake hates this. He might pretend to be your friend but he's getting
paid to do that. Nothing more annoying than having a customer demand to
work with Jake when Jake has 20 other things going on and literally anyone
else on the team can help you.

Once you're known within the right team, it should be easy to get prompt
> responses.


Exactly. Show the team that you know what you're talking about and that
you're not belligerent and people will be more than happy to work with you.

- Mike Bolitho


On Wed, Jan 29, 2020 at 9:16 AM Sabri Berisha  wrote:

> - On Jan 29, 2020, at 12:40 AM, Ronald F. Guilmette
> r...@tristatelogic.com wrote:
>
> Hi,
>
> > (I have a standing policy of never attempting to converse with
> unaccountable
> > anonymized role accounts.  Based on past experience, this is without
> > exception an utter waste of my time.)
>
> In the real world, this should be the exact opposite. People move teams,
> leave companies. If you always e-mail j...@telco.com instead of
> n...@telco.com for your issues, you may end of in a situation where Jake
> is gone, on vacation, or simply moved on to accounting. Once you're known
> within the right team, it should be easy to get prompt responses.
>
> I'm surprised about the lack of response from FT/DT though.
>
> Thanks,
>
> Sabri
>

Re: The curious case of 159.174.0.0/16

[Sabri Berisha]

- On Jan 29, 2020, at 12:40 AM, Ronald F. Guilmette r...@tristatelogic.com 
wrote:

Hi,

> (I have a standing policy of never attempting to converse with unaccountable
> anonymized role accounts.  Based on past experience, this is without
> exception an utter waste of my time.)

In the real world, this should be the exact opposite. People move teams, leave 
companies. If you always e-mail j...@telco.com instead of n...@telco.com for 
your issues, you may end of in a situation where Jake is gone, on vacation, or 
simply moved on to accounting. Once you're known within the right team, it 
should be easy to get prompt responses.

I'm surprised about the lack of response from FT/DT though.

Thanks,

Sabri

Re: AFRINIC: The Saga Continues

[Chris Knipe]

Hi James,

Just want to make this clear to NANOG as well - there's no beef here.  The
priority was to get delisted.

The beef is with AfriNIC in this case :) It's not CYMRU's fault.  The
datasets are incomplete.

--
C


On Wed, Jan 29, 2020 at 4:03 PM James Shank  wrote:

> Hi all,
>
> I am still looking into the history of this issue, but presently, the
> prefix Chris shared with us is not on our IPv4 BOGON list.
>
> For those wanting to see the list, it is available in plain text here:
>
> https://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt
>
> I welcome input on this as I look into the history a little more.
>
> Cheers!
>
> James
>
> On 1/29/20 7:27 AM, Chris Knipe wrote:
> > Hi All,
> >
> > http://ftp.afrinic.net/stats/afrinic/delegated-afrinic-extended-20200129
> >
> > Another thing that stuck it's head out today now.  No ASN, nor IP
> prefixes
> > allocated since 2019/05/15 is listed in the delegated text files.  Our
> (and
> > I am sure others) prefixes is now null routed at team CYMRU (contacted
> > them, waiting for response).
> >
> > Yesterday's file was incomplete (looks like there were errors with the
> > script perhaps), and today's file is missing an enormous amount of data
> (1
> > ASN, 163 IPv4 allocations, and 272 IPv6 allocations). This is comparing
> the
> > data file from 2020/01/29 (today) to 2020/01/27 (two days ago).
> >
> > We also have a ticket with AfriNIC (no response yet), and when we called
> > them there was no one "available" to assist.
> >
> >
> > On Wed, Jan 29, 2020 at 1:20 AM Ronald F. Guilmette <
> r...@tristatelogic.com>
> > wrote:
> >
> >> In message ,
> >> thomas brenac  wrote:
> >>
> >>> Thank you Ronald, I also heard of governance issue in AFRINIC by some
> >>> people during the last RIPE meeting so the word is spreading. Now is
> >>> there any other /16 impacted to your knowledge ? Would be worth pushing
> >>> to have them in as many Drop list as possible maybe :)
> >>
> >> As reported in Jan Vermeulen's article on the web site
> mybroadband.co.za
> >> published December 4, there has been, and continues to be a large number
> >> of blocks, both "legacy" blocks and other blocks, that were stolen from
> >> the Afrinic free pool.  These blocks are of varying sizes, generally /16
> >> blocks but also some larger ones as well as a few smaller ones.
> >>
> >> The list of affected legacy blocks from Jan's article are as follows:
> >>
> >> 196.10.64.0/19
> >> 196.10.61.0/24
> >> 196.10.62.0/23
> >> 160.121.0.0/16
> >> 155.235.0.0/16
> >> 152.108.0.0/16
> >> 155.237.0.0/16
> >> 169.129.0.0/16
> >> 165.25.0.0/16
> >> 160.122.0.0/16
> >> 168.80.0.0/15
> >> 165.3.0.0/16
> >> 165.4.0.0/16
> >> 165.5.0.0/16
> >> 160.115.0.0/16
> >>
> >> In addition to all of the above, I have some reason to believe that the
> >> following additional legacy block WAS (past tense) stolen, but has now
> >> been reclaimed by, and ressigned to its rightful modern owner:
> >>
> >> 152.108.0.0/16
> >>
> >> It is highly probable that there are other and additional legacy blocks
> >> that have also been stolen.  I have been prevented from fully completing
> >> my research work on this part of the problem by ongoing stonewalling by
> >> Afrinic.  Specifically, despite Afrinic having a defined protocol
> whereby
> >> legitimate researchers may request confidential access to the unredacted
> >> Afrinic WHOIS data base for legitimate research purposes... a protocol
> >> and a process which is fully supported and operational at all of the
> other
> >> four global RIRs... Afrinic has, for reasons unknown, elected to only
> >> provide redacted versions of its WHOIS data base which are identical
> >> to what may be obtained at any time, and without any special protocol,
> >> directly from Afrinic's FTP server (via anonymous FTP).  Because the
> >> accurate identification of stolen Afrinic legacy blocks involves the
> >> careful analysis of the *unredacted* contact person: records, access to
> >> only the redacted data base is of no value whatsoever in the task of
> >> identifying stolen Afrinic legacy blocks.
> >>
> >> Here is the page on the Afrinic web site where they needlessly torment
> >> legitimate researchers into believing that they will be able to get the
>

Re: Backup over 4G/LTE

[Shawn Ritchie]

I do this with Accelerated devices tied to Juniper SRXes as well as Velocloud 
VCEs depending on the customer's other needs. Increasingly common application.

--
Shawn




On Wed, Jan 29, 2020, at 8:08 AM, Alain Hebert wrote:
>  Juniper SRX and any reliable consumer LTE router =D.
> 
> -
Alain Hebertaheb...@pubnix.net   
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
> 
> On 2020-01-28 18:30, K MEKKAOUI wrote:
>> Dear NANOG Community,

>> 

>> Can anyone help with any device information that provides redundancy for 
>> business internet access? In other words when the internet provided through 
>> the cable modem fails the 4G/LTE takes over automatically to provide 
>> internet access to the client.

>> 

>> Thank you

>> 

>> KARIM M.

>> 

Re: Backup over 4G/LTE

[Alain Hebert]

    Juniper SRX and any reliable consumer LTE router =D.

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 2020-01-28 18:30, K MEKKAOUI wrote:


Dear NANOG Community,

Can anyone help with any device information that provides redundancy 
for business internet access? In other words when the internet 
provided through the cable modem fails the 4G/LTE takes over 
automatically to provide internet access to the client.


Thank you

KARIM M.

Re: AFRINIC: The Saga Continues

[James Shank]

Hi all,

I am still looking into the history of this issue, but presently, the
prefix Chris shared with us is not on our IPv4 BOGON list.

For those wanting to see the list, it is available in plain text here:

https://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt

I welcome input on this as I look into the history a little more.

Cheers!

James

On 1/29/20 7:27 AM, Chris Knipe wrote:
> Hi All,
> 
> http://ftp.afrinic.net/stats/afrinic/delegated-afrinic-extended-20200129
> 
> Another thing that stuck it's head out today now.  No ASN, nor IP prefixes
> allocated since 2019/05/15 is listed in the delegated text files.  Our (and
> I am sure others) prefixes is now null routed at team CYMRU (contacted
> them, waiting for response).
> 
> Yesterday's file was incomplete (looks like there were errors with the
> script perhaps), and today's file is missing an enormous amount of data (1
> ASN, 163 IPv4 allocations, and 272 IPv6 allocations). This is comparing the
> data file from 2020/01/29 (today) to 2020/01/27 (two days ago).
> 
> We also have a ticket with AfriNIC (no response yet), and when we called
> them there was no one "available" to assist.
> 
> 
> On Wed, Jan 29, 2020 at 1:20 AM Ronald F. Guilmette 
> wrote:
> 
>> In message ,
>> thomas brenac  wrote:
>>
>>> Thank you Ronald, I also heard of governance issue in AFRINIC by some
>>> people during the last RIPE meeting so the word is spreading. Now is
>>> there any other /16 impacted to your knowledge ? Would be worth pushing
>>> to have them in as many Drop list as possible maybe :)
>>
>> As reported in Jan Vermeulen's article on the web site mybroadband.co.za
>> published December 4, there has been, and continues to be a large number
>> of blocks, both "legacy" blocks and other blocks, that were stolen from
>> the Afrinic free pool.  These blocks are of varying sizes, generally /16
>> blocks but also some larger ones as well as a few smaller ones.
>>
>> The list of affected legacy blocks from Jan's article are as follows:
>>
>> 196.10.64.0/19
>> 196.10.61.0/24
>> 196.10.62.0/23
>> 160.121.0.0/16
>> 155.235.0.0/16
>> 152.108.0.0/16
>> 155.237.0.0/16
>> 169.129.0.0/16
>> 165.25.0.0/16
>> 160.122.0.0/16
>> 168.80.0.0/15
>> 165.3.0.0/16
>> 165.4.0.0/16
>> 165.5.0.0/16
>> 160.115.0.0/16
>>
>> In addition to all of the above, I have some reason to believe that the
>> following additional legacy block WAS (past tense) stolen, but has now
>> been reclaimed by, and ressigned to its rightful modern owner:
>>
>> 152.108.0.0/16
>>
>> It is highly probable that there are other and additional legacy blocks
>> that have also been stolen.  I have been prevented from fully completing
>> my research work on this part of the problem by ongoing stonewalling by
>> Afrinic.  Specifically, despite Afrinic having a defined protocol whereby
>> legitimate researchers may request confidential access to the unredacted
>> Afrinic WHOIS data base for legitimate research purposes... a protocol
>> and a process which is fully supported and operational at all of the other
>> four global RIRs... Afrinic has, for reasons unknown, elected to only
>> provide redacted versions of its WHOIS data base which are identical
>> to what may be obtained at any time, and without any special protocol,
>> directly from Afrinic's FTP server (via anonymous FTP).  Because the
>> accurate identification of stolen Afrinic legacy blocks involves the
>> careful analysis of the *unredacted* contact person: records, access to
>> only the redacted data base is of no value whatsoever in the task of
>> identifying stolen Afrinic legacy blocks.
>>
>> Here is the page on the Afrinic web site where they needlessly torment
>> legitimate researchers into believing that they will be able to get the
>> same kind of unredacted WHOIS data base access as is provided, upon
>> vetting and approval, by all of the other RIRs:
>>
>> https://www.afrinic.net/services/207-bulk-whois-access
>>
>> The list of blocks that appear to have been stolen from the Afrinic free
>> pool, as published in Jan's Dec 4 article are as follows:
>>
>> "Infoplan"/"Network and Information Technology Limited":
>> 196.16.0.0/14
>> 196.4.36.0/22
>> 196.4.40.0/22
>> 196.4.44.0/23
>>
>> "Cape of Good Hope Bank"/"CGHB":
>> 165.52.0.0/14
>> 137.171.0.0/16
>> 160.184.0.0/16
>> 168.211.0.0/16
>> 192.96.146.0/24  -- NOTE!!  -- 100% legitimate legacy allocation!
>&g

Re: Backup over 4G/LTE

[K. Scott Helms]

There are lots of options to solve that problem.

Peplink, 128T, Viptela (Cisco), Velocloud (VMWare), etc.

Scott Helms



On Tue, Jan 28, 2020 at 6:31 PM K MEKKAOUI  wrote:

> Dear NANOG Community,
>
>
>
> Can anyone help with any device information that provides redundancy for
> business internet access? In other words when the internet provided through
> the cable modem fails the 4G/LTE takes over automatically to provide
> internet access to the client.
>
>
>
> Thank you
>
>
>
> KARIM M.
>
>
>

Re: AFRINIC: The Saga Continues

[Chris Knipe]

Hi All,

http://ftp.afrinic.net/stats/afrinic/delegated-afrinic-extended-20200129

Another thing that stuck it's head out today now.  No ASN, nor IP prefixes
allocated since 2019/05/15 is listed in the delegated text files.  Our (and
I am sure others) prefixes is now null routed at team CYMRU (contacted
them, waiting for response).

Yesterday's file was incomplete (looks like there were errors with the
script perhaps), and today's file is missing an enormous amount of data (1
ASN, 163 IPv4 allocations, and 272 IPv6 allocations). This is comparing the
data file from 2020/01/29 (today) to 2020/01/27 (two days ago).

We also have a ticket with AfriNIC (no response yet), and when we called
them there was no one "available" to assist.


On Wed, Jan 29, 2020 at 1:20 AM Ronald F. Guilmette 
wrote:

> In message ,
> thomas brenac  wrote:
>
> >Thank you Ronald, I also heard of governance issue in AFRINIC by some
> >people during the last RIPE meeting so the word is spreading. Now is
> >there any other /16 impacted to your knowledge ? Would be worth pushing
> >to have them in as many Drop list as possible maybe :)
>
> As reported in Jan Vermeulen's article on the web site mybroadband.co.za
> published December 4, there has been, and continues to be a large number
> of blocks, both "legacy" blocks and other blocks, that were stolen from
> the Afrinic free pool.  These blocks are of varying sizes, generally /16
> blocks but also some larger ones as well as a few smaller ones.
>
> The list of affected legacy blocks from Jan's article are as follows:
>
> 196.10.64.0/19
> 196.10.61.0/24
> 196.10.62.0/23
> 160.121.0.0/16
> 155.235.0.0/16
> 152.108.0.0/16
> 155.237.0.0/16
> 169.129.0.0/16
> 165.25.0.0/16
> 160.122.0.0/16
> 168.80.0.0/15
> 165.3.0.0/16
> 165.4.0.0/16
> 165.5.0.0/16
> 160.115.0.0/16
>
> In addition to all of the above, I have some reason to believe that the
> following additional legacy block WAS (past tense) stolen, but has now
> been reclaimed by, and ressigned to its rightful modern owner:
>
> 152.108.0.0/16
>
> It is highly probable that there are other and additional legacy blocks
> that have also been stolen.  I have been prevented from fully completing
> my research work on this part of the problem by ongoing stonewalling by
> Afrinic.  Specifically, despite Afrinic having a defined protocol whereby
> legitimate researchers may request confidential access to the unredacted
> Afrinic WHOIS data base for legitimate research purposes... a protocol
> and a process which is fully supported and operational at all of the other
> four global RIRs... Afrinic has, for reasons unknown, elected to only
> provide redacted versions of its WHOIS data base which are identical
> to what may be obtained at any time, and without any special protocol,
> directly from Afrinic's FTP server (via anonymous FTP).  Because the
> accurate identification of stolen Afrinic legacy blocks involves the
> careful analysis of the *unredacted* contact person: records, access to
> only the redacted data base is of no value whatsoever in the task of
> identifying stolen Afrinic legacy blocks.
>
> Here is the page on the Afrinic web site where they needlessly torment
> legitimate researchers into believing that they will be able to get the
> same kind of unredacted WHOIS data base access as is provided, upon
> vetting and approval, by all of the other RIRs:
>
> https://www.afrinic.net/services/207-bulk-whois-access
>
> The list of blocks that appear to have been stolen from the Afrinic free
> pool, as published in Jan's Dec 4 article are as follows:
>
> "Infoplan"/"Network and Information Technology Limited":
> 196.16.0.0/14
> 196.4.36.0/22
> 196.4.40.0/22
> 196.4.44.0/23
>
> "Cape of Good Hope Bank"/"CGHB":
> 165.52.0.0/14
> 137.171.0.0/16
> 160.184.0.0/16
> 168.211.0.0/16
> 192.96.146.0/24  -- NOTE!!  -- 100% legitimate legacy allocation!
>
> The following additional blocks had also been stolen from the Afrinic free
> pool.  I had informed Jan about these blocks also, but for some reason
> these were not mentioned in Jan's Dec 4th article.  (I assume that this
> was simply a clerical oversight on Jan's part.  I had given him quite
> a lot of material to sort through.)
>
> "ITC":
> 196.194.0.0/15
> 196.246.0.0/16
> 196.45.112.0/20
> 196.42.128.0/17
> 196.193.0.0/16
>
> "Link Data Group":
> 160.255.0.0/16
> 196.62.0.0/16
> 198.54.232.0/24
> 196.207.64.0/18
> 196.192.192.0/18
> 160.181.0.0/16
> 213.247.0.0/19
>
> As of this moment, Afrinic has properly reclaimed all of the "ITC" and
> "Link Data Group" and "Cape of Good

Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC

[xanonyws]

Not blocking them will drain my outgoing bandwidth.




 On Wed, 29 Jan 2020 01:18:32 +0100 dam...@google.com wrote 


I recommend you *not* block the outgoing RST packets, as blocking them will 
only make matters worse:
  - it leaves the webservers being abused for reflection in the half-open 
SYN_RECV state, which may attract more attention (and blacklisting)
  - retries from those servers will increase the load to your network


Damian


On Tue, Jan 28, 2020 at 1:42 PM Octolus Development  wrote:

Yes, my server would then respond with RST.


Screenshot: https://i.imgur.com/ZVti2yY.png


We've blocked outgoing RST, 136.244.67.19 was our test server.


But even if the ip is not even exposed to the internet, services will blacklist 
us. Even if we don't respond, and block every request from the internet 
incoming & outgoing.

On 28.01.2020 22:36:18, "Jean | ddostest.me via NANOG"  wrote:

But you do receive the SYN/ACK?

The way to open a TCP socket is the 3 way handshake. Sorry to write that 
here... I feel it's useless.

1. SYN

2. SYN/ACK

3. ACK


Step 1: So hackers spoof the original SYN with your source IP of your network.


Step 2: You should then receive those SYN/ACK packets with your network as the 
dst ip and SONY as the src ip. Can you catch a few and post the TCP flags that 
you see please? (This is step 2)

You don't need sony or imperva for that. Just a sniffer at the right place in 
your network. You won't block anything, but we should see something  very 
interesting that will help you fix this.


If it is happening like you  are describing, you should see those packets and 
you should be able to capture them.


No worries if you can't.


Jean


On 2020-01-28 11:31, Octolus Development wrote:

I have tried numerous of times to reach out to Imperva.


Imperva said Sony have to contact them & said they cannot help me because I am 
not a customer of theirs.
Something Sony will not do. Sony simply stopped responding my emails after some 
time.


But yes you are right.


My IP's are being spoofed, spoofing SYN requests to hundreds of thousands of 
web servers. Which then results in a blacklist, that Imperva uses.. which 
prevents me and my clients from accessing Sony's services.. because they use 
Imperva.

On 28.01.2020 17:29:12, Tom Beecher  wrote:

Trying to summarize here, this convo has been a bit disjointed. 


Is this an accurate summary?


- The malicious traffic with spoofed sources is targeting multiple different 
destinations.
- The aggregate of all those flows is causing Impervia to flag your IP range as 
a bad actor. 
- Sony uses Impervia blacklists, and since Impervia has flagged your space as 
bad, Sony is blocking you. 


If that is true, my advice would be to go right to Impervia. Explain the 
situation, and ask for their assistance in identifying and or/reaching out to 
the networks that they are detecting this spoofed traffic coming from. The 
backscatter, as Jared said earlier, could probably help you a bit too, but 
Impervia should be willing to assist. It's in their best interests to not have 
false positives, but who knows. 


On Tue, Jan 28, 2020 at 6:17 AM Octolus Development  wrote:

The problem is that they are spoofing our IP, to millions of IP's running port 
80.
Making upstream providers filter it is quite difficult, i don't know all the 
upstream providers are used. 


The main problem is honestly services that reports SYN_RECV as Port Flood, but 
there isn't much one can do about misconfigured firewalls.I am sure there is a 
decent amount of honeypots on the internet acting the same way, resulting us 
(the victims of the attack) getting blacklisted for 'sending' attacks.

On 28.01.2020 05:50:14, "Dobbins, Roland"  wrote:





On Jan 28, 2020, at 11:40, Dobbins, Roland  wrote:


And even if his network weren't on the receiving end of a 
reflection/amplification attack, OP could still see backscatter, as Jared 
indicated. 


In point of fact, if the traffic was low-volume, this might in fact be what he 
was seeing. 





Roland Dobbins 

The curious case of 159.174.0.0/16

[Ronald F. Guilmette]

[[ Fair warning to newcomers:  I write and post longish pieces here
   regarding my various investigations of funny business I find going
   on within the IPv4 address space and the allocations and uses thereof.
   If you're looking for a quick 2 minute read then you are advised to
   skip this message now. ]]

I confess that I have been meaning to write about the 159.174.0.0/16
legacy IPv4 block for quite some time now.  What can I say?  I was busy.


The Present State of 159.174.0.0/16
---

I discovered quite some long time ago that this block was getting routing
from a rather unusual place, and that the ASN in question was also
announcing a few other nice juicy /16 legacy blocks, which by itself
was more than a little suspicious.  But that's not imporant now.  Please
allow me to just talk about who is routing this block at present, and
who the alleged legitimate registrants are, going by ARIN's relevant
current WHOIS record for this block:

https://pastebin.com/raw/FBWMN9p3

As you can see, this block is registered to an entity located in Wilton,
Connecticut.  The block appears to have been originally assigned on
1992-05-11, well before the formation of ARIN.  It is thus an unusually
valuable "legacy" block.

The first indication that something might be a bit off about this block
is the contact phone number, +1-407-476-9854.  In this modern era of
number portability the area code portion of that may or may not have
any real-world geographical implications at all, but it turns out to
be notable, in this case, that area code 407 corresponds, historically,
to the greater Orlando, Florida area and surrounding Florida counties.

A quick bit of research reveals that there is in fact an entity calling
itself Dunsnet, LLC and that it is located in Winter Park, Florida,
a northern suburb of Orlando:


http://search.sunbiz.org/Inquiry/CorporationSearch/SearchResultDetail?inquirytype=EntityName=Initial=DUNSNET%20L120001007590=flal-l12000100759-15618501-6ea8-4b18-898e-6470337507d1=dunsnet=DUNSNET%20L120001007590

Further research on the Florida Secretary of State's web site confirms that
this entity does exist, that it is "active", and that it has one and only
one manager, that being another corporate entity called Ahosting, Inc.:


http://search.sunbiz.org/Inquiry/CorporationSearch/SearchResultDetail?inquirytype=EntityName=Initial=AHOSTING%20P070001262120=domp-p07000126212-a6386b50-075c-4b07-b36e-ff5a3ba1b33c=ahosting=AHOSTING%20P070001262120

As you can see via the above link, Ahosting, Inc. has only two corporate
directors, i.e.  a Mr. Erkan Ozdogan and a Mr. Adnan Canturk, both
apparently residents of Istanbul, Turkey.

At the present time, 100% of the 159.174.0.0/16 legacy block is being routed
by AS54163, aka Ahosting, Inc.:

https://bgp.he.net/AS54163#_prefixes

The question is: Is this proper?


A Brief History of 159.174.0.0/16
-

When the 159.174.0.0/16 block was first allocated and registered, way back
on 1992-05-11 it was assigned at that time to a unit of the famous Dun &
Bradstreet financial information company for use in connection with one
of the company's early forays into the world of the Internet:

Fortune Magazine, August 19, 1985:

https://archive.fortune.com/magazines/fortune/fortune_archive/1985/08/19/66327/index.htm

"Dun & Bradstreet also operates DunsNet, a $20- million private
telecommunications network completed in March, which connects
customers in 155 cities directly to the company's mainframes."

On June 8th, 1994, Dun & Bradstreet's "Dunsnet" operation announced that
it had elected to partner with a European company named Eunetcom SA, which
was itself a partnership between Deutsche Bundespost Telekom and France
Telecom:

https://www.cbronline.com/news/eunetcom_wins_dunsnet_pact/

In August, 1994, Eunetcom apparently elected to buy out its customer,
Dunsnet:

"The Information Superhighway" (Randall L. Carlson - 1996)
https://bit.ly/2O7kV48

"Eunetcom is actively pursuing customers and entry into the North
American market.  Its first customer was worth $200 million over
five years and was {subequently} acquired by purchasing the
networking services of Dun & Bradstreet's DunsNet.  DunsNet
provides data communications services for the Dun & Bradstreet
companies, a role that Eunetcom now assumes."


https://www.postjobfree.com/resume/pumacu/unix-administrator-technical-analyst-reg-shelton

"In August 1994, DunsNet was acquired by eunetcom, a joint venture
between Deutsche Telekom and France Telecom."

As we all know, unlike the situation today, IPv4 blocks in the 1990s had
essentially no monetary value.  And thus the 159.174.0.0/16 block became
forgotten and abandoned by its rightful owners, which is to say Deutsche
Telekom and France Telecom.

Fast forward some 16 years to June 29, 2011, on which