<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 26, 2020, at 08:27 , James <<a href="mailto:james.chirwa@afrinic.net" class="">james.chirwa@afrinic.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Dear Gregoire, </p><div class=""> <br class="webkit-block-placeholder"></div><p class="MsoNormal">Let me first of all thank you for sharing your
concern as well as<span style="mso-spacerun:yes" class=""> </span>seeking
clarification regarding the matter under hand.</p><p class="MsoNormal">You have sought<span style="mso-spacerun:yes" class="">
</span>from AFRINIC an explanation as regard the term “ delegation
of IP block”.</p><p class="MsoNormal">As far as AFRINIC is concerned , it does not
practice “ delegation of IP Block”. Its handling of IP Blocks
involves only allocation, sub-allocation or assignment .</p></div></div></blockquote>In this context, delegation is used as a superset of the terms allocation, sub-allocation, and assignment.</div><div><br class=""></div><div>From the dictionary:</div><div>delegate (verb)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>to commit (powers, functions, etc.) to another as agent or deputy.<br class=""><br class="">delegation (noun)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>The act of delegating<br class=""></div><div><br class=""></div><div>When number resources are allocated, sub-allocated, or assigned, the RIR, NIR, or LIR is, in fact, committing the administrative functions</div><div>over said addresses to the recipient.</div><div><br class=""></div><div>This is well understood throughout the IP using community and I am surprised by James statement, especially in light of the following:</div><div><br class=""></div><div><a href="https://www.afrinic.net/services/123-afrinic-policy-for-reverse-delegation-on-allocated-ip-addresses" class="">https://www.afrinic.net/services/123-afrinic-policy-for-reverse-delegation-on-allocated-ip-addresses</a></div><div><br class=""></div><div>And of course, CPM 2.6: (<a href="https://afrinic.net/policy/manual" class="">https://afrinic.net/policy/manual</a>)</div><div><br class=""></div><div>2.6 Assignment<br class="">An assignment is an IP address block given by an LIR to its end-users for their own usage. To "assign" means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.</div><div><br class=""></div><div>Owen</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><p class="MsoNormal">You may contact<span style="mso-spacerun:yes" class="">
</span>the operator/member who has utilised<span style="mso-spacerun:yes" class=""> </span>the said term for more
clarification.</p><p class="MsoNormal">Regards,</p><p class="MsoNormal">James<br class="">
</p>
<div class="moz-cite-prefix">On 23/05/2020 18:21, Gregoire EHOUMI
via Community-Discuss wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:E1jcV12-000Gl5-Ez@spamfilter.afrinic.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div dir="auto" class="">
<div dir="auto" class="">Hello,</div>
<div dir="auto" class=""><br class="">
Thanks Mark for exposing the details of the SEACOM AS37353
hijacking.<br class="">
<br class="">
I carefully read your report and also the Cloud Innovation
Limited quick response including their attachments as
justifications.<br class="">
<br class="">
I note that;<br class="">
<br class="">
⁃ the service contract with Cloud Innovation covering the
announcement of their prefixes by SEACOM AS37353 was
terminated by SEACOM.<br class="">
<br class="">
⁃ some stale IRR route objects existed after termination of
the contract.<br class="">
<br class="">
⁃ through some multiple layer distribution an organisation in
Manila Philippines was “delegated“ an IP block from Cloud
Innovation address space.<br class="">
<br class="">
⁃ both upstream ISP and the customer in Manila set up a BGP
session using SEACOM's AS37353 as the ASN of the Manila
customer.<br class="">
<br class="">
⁃ there was a prompt reaction from the involved parties that
included apologies to SEACOM and the wider internet community.<br class="">
<br class="">
⁃ there were promises from said parties to be a better netizen
which would mean, them not hijacking other networks ASN's.<br class="">
<br class="">
⁃ there was clear refusal to disclose the details of the
customer in Manila Philippines who hijacked the affected
SEACOM ASN.<br class="">
<br class="">
All put together, demonstrates that what happened was an
impersonation and not a BGP configuration error, nor an
oversight in checking the right to use of the SEACOM ASN.<br class="">
<br class="">
1. Why is it that the real customer did not bother presenting
its apologies to the community<br class="">
<br class="">
2. Why is there refusal to reveal customer’s details?<br class="">
<br class="">
3. Why is it that the said prefix is no longer seen in the
routing table originated by the genius ASN or any other ASN?<br class="">
<br class="">
4. Which networks were involved and what happened to the end
users?<br class="">
<br class="">
Can someone from AFRINIC explain what “delegation of IP block”
mean?<br class="">
<br class="">
Note: The self organised Internet knows how to deal with bad
net citizens.!<br class="">
<br class="">
Best regards <br class="">
Gregoire Ehoumi </div>
</div>
<div dir="auto" class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div style="font-size: 100%;" dir="auto" class=""><!-- originalMessage -->
<div class="">-------- Original message --------</div>
<div class="">From: Lu Heng <a class="moz-txt-link-rfc2396E" href="mailto:h.lu@anytimechinese.com"><h.lu@anytimechinese.com></a> </div>
<div class="">Date: 2020-05-09 5:41 a.m. (GMT-05:00) </div>
<div class="">To: General Discussions of AFRINIC
<a class="moz-txt-link-rfc2396E" href="mailto:community-discuss@afrinic.net"><community-discuss@afrinic.net></a> </div>
<div class="">Subject: Re: [Community-Discuss] Cloud Innovation Displays
Very Poor, If Not Criminal, Netizenship </div>
<div class=""><br class="">
</div>
</div>
<div dir="ltr" class="">
<div class="">
<div class="">
<div class="">To whom it may concern,
<div class=""><br class="">
</div>
<div class="">On May 8, Mark Think posted a claim to multiple lists
that Cloud Innovation was abusing an ASN (37353) that
didn’t belong to them (Cloud Innovation) but rather
belonged to Seacom through their acquisition of
MacroLAN.</div>
<div class=""><br class="">
</div>
<div class="">While we regret this unfortunate incident, Mark’s
claims that it was criminal or bad netizenship on the
part of Cloud Innovation is without foundation and
utterly incorrect.</div>
<div class=""><br class="">
</div>
<div class="">
<div style="font-family:Lato;font-size:14px" class="">As shown
below in the attached document from Paul
Wollner(Ex-CTO of Macrolan who created IRR routes to
allow Macrolan to announce Cloud Innovation's prefix);
letter from Link Infinity International Ltd. (Link
Infinity), A customer of Cloud Innovation; and
attached LOA from LARUS authorizing IPDC Solutions to
announce the prefix with origin AS134190. And a
Letter from IPDC. This was an innocent mistake
committed by third parties and had nothing to do with
any action by Cloud Innovation or LARUS.</div>
</div>
</div>
</div>
<div class="">
<div class="">
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">Here’s what
happened:<br class="">
</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
</div>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px" class="">
<div class="">
<div style="font-family:Lato;font-size:14px" class="">Cloud
Innovation delegated a /24 to Link Infinity, an ISP in
December 2019.</div>
</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px" class="">
<div class="">Link Infinity further delegated that same /24 to IPDC
and asked Cloud innovation to issue an LOA, which we
did. The LOA specifically required IPDC to use its own
ASN to announce the space (AS134190).</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
</blockquote>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px" class="">
<div class="">
<div style="font-family:Lato;font-size:14px" class="">IPDC
subsequently authorized one of its customers to use
the said prefix.</div>
</div>
</blockquote>
<div class="">
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
</div>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px" class="">
<div class="">
<div style="font-family:Lato;font-size:14px" class="">For reasons
still unknown to Cloud Innovation, IPDC and their
customer set up a BGP session wherein their customer
used AS37353 as the origin to advertise prefix <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a>.</div>
</div>
</blockquote>
<div class="">
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
</div>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px" class="">
<div class="">
<div style="font-family:Lato;font-size:14px" class="">Upon
discovering the announcement, rather than contact
Cloud Innovation, Mark contacted IPDC who provided him
with an incomplete explanation blaming their customer
and Mark, not realizing that Cloud Innovation was not
the customer in question posted far and wide about the
event. It is unclear to us why he chose to do this
rather than contact us to try and resolve the issue.</div>
</div>
</blockquote>
<div class="">
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">A
contributing factor to the erroneous BGP configuration
by IPDC's customer may have been data contained in some
outdated IRR route objects for <a href="http://156.241.0.0/16" target="_blank" moz-do-not-send="true" class="">156.241.0.0/16</a> which have
subsequently been deleted.</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">As soon as we
became aware of the problem (via Mark’s email), we began
to investigate the situation. As soon as it was clear
that this was the result of third-party actions, we
reached out to Mark privately to let him know what we
knew and that we were still investigating. We delayed
making a public statement in order to try and ascertain
all of the facts of the situation. We prefer not to make
public statements based on incomplete information.</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">We apologize
to the community for our small part in this unfortunate
incident and assure you that we work very hard to remain
good netizens and will address any concerns promptly
when they come to our attention.</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">Sincerely,<br class="">
</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">Lu Heng<br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">CEO<br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">Cloud
Innovations<br class="">
</div>
</div>
<div class=""><br class="">
</div>
</div>
</div>
Attached:
<div class=""><span style="white-space:pre-wrap" class=""> </span>1.<span style="white-space:pre-wrap" class=""> </span>Letter
from Paul Wollner</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>2.<span style="white-space:pre-wrap" class=""> </span>Letter
from Link Infinity</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>3.<span style="white-space:pre-wrap" class=""> </span>LOA
Issued to IPDC Solutions for announcing <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a> from AS134190</div>
<div class=""> 4. Letter from IPDC</div>
<div class=""><br class="">
</div>
<div class="">FYI: LARUS is proving IP management service for Cloud
Innovation, while LARUS is also providing IP management
service to other third parties in all regions, for full
disclosure, LARUS and Cloud Innovation are headed by same CEO.</div>
<div class=""><br class="">
</div>
<div class="">Content of those letters have been posted here for your
convince:</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><b class="">IPDC:</b></div>
<div class=""><b class=""><br class="">
</b></div>
<font color="#888888" class="">
<div class=""><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">FOR
IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd]</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">IPDC
Solutions Pte Ltd (IPDC) is a customer of Cloud
Innovation Ltd and over the course of our corporate
relationship we were given the authority to use address
block <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a> since 9th
December 2019. </div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">On
12th December 2019, we have delegated that address block
to our client. Following which our client further
instructed us to announce the prefix with AS37353. In
good will after minimal verification through WHOIS’ IP
Prefix we have proceeded to execute our client’s
request. </div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">On
7th May 2020 IPDC was then contacted by SEACOM, the
legitimate holder of record for that ASN and have since
learned that the customer’s use of that ASN was
erroneous and not permitted by SEACOM and immediate
action has been taken to rectify this situation. </div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">IPDC
would like to apologize for our lack of attention in
conducting thorough verification and wish to highlight
that the involvement of Cloud Innovation Ltd in the
entire process was providing the addresses to us and
that we truly apologize as we understand that this
incident may have indirectly implicated Cloud Innovation
Ltd. </div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">IPDC
however, does not wish to disclose our client
information and our client information shall remain
confidential under present circumstances. Once again, we
apologize for our shortcomings. <br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><b class="">Link
Infinity:</b></div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">To
whom it may concern,<br class="">
<br class="">
We at HK Infinity International Ltd are a customer of
Cloud Innovation and in the course received rights to
use <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a> from them.
Beginning December, 2019, we delegated the right to
announce this prefix to IPDC Solutions Pte Ltd. (IPDC).
We asked Cloud Innovation to provide an LOA authorizing
them to announce the space which was subsequently
received. IPDC subsequently and without our knowledge
delegated this space to one of their customers and
allowed them to originate it from AS37353.<br class="">
<br class="">
This announcement was not authorized by us, nor is it
permitted by the LOA provided by Cloud Innovation.<br class="">
<br class="">
Unfortunately, we were not aware of the situation until
after it had already been resolved.<br class="">
<br class="">
It was never our intent to violate the LOA or to allow
the prefix to be announced from a hijacked ASN. We do
not condone this and apologize sincerely to the
community for what has happened here.<br class="">
<br class="">
Sincere Apologies,<br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><b class="">Paul
Wollner:</b></div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">8
May 2020<br class="">
<br class="">
TO WHOM IT MAY CONCERN
<br class="">
<br class="">
In the light of the recent email on NAPAfrica mailing
list, I would just like to clear the air. </div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
The IP route objects were created by myself for Cloud
Innovation when they signed up as a client of Macrolan (
now SEACOM) as they didn't have their own AS.<br class="">
<br class="">
At the time I was working for Macrolan (now SEACOM). I
left the employment of SEACOM in October 2019.<br class="">
<br class="">
It appears that when Cloud Innovation's contract with
SEACOM came to an end, the route objects were never
cleaned up.<br class="">
<br class="">
This occurred after I left SEACOM's employment. Since
leaving, I have no access to these objects.<br class="">
<br class="">
Regards<br class="">
<br class="">
Paul Wollner<br class="">
082-786-9776</div>
</div>
</font></div>
</div>
<div dir="ltr" class="">
<div class="">
<div class="">
<div class="">To whom it may concern,
<div class=""><br class="">
</div>
<div class="">On May 8, Mark Think posted a claim to multiple lists
that Cloud Innovation was abusing an ASN (37353) that
didn’t belong to them (Cloud Innovation) but rather
belonged to Seacom through their acquisition of
MacroLAN.</div>
<div class=""><br class="">
</div>
<div class="">While we regret this unfortunate incident, Mark’s
claims that it was criminal or bad netizenship on the
part of Cloud Innovation is without foundation and
utterly incorrect.</div>
<div class=""><br class="">
</div>
<div class="">
<div style="font-family:Lato;font-size:14px" class="">As shown
below in the attached document from Paul
Wollner(Ex-CTO of Macrolan who created IRR routes to
allow Macrolan to announce Cloud Innovation's prefix);
letter from Link Infinity International Ltd. (Link
Infinity), A customer of Cloud Innovation; and
attached LOA from LARUS authorizing IPDC Solutions to
announce the prefix with origin AS134190. And a
Letter from IPDC. This was an innocent mistake
committed by third parties and had nothing to do with
any action by Cloud Innovation or LARUS.</div>
</div>
</div>
</div>
<div class="">
<div class="">
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">Here’s what
happened:<br class="">
</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
</div>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px" class="">
<div class="">
<div style="font-family:Lato;font-size:14px" class="">Cloud
Innovation delegated a /24 to Link Infinity, an ISP in
December 2019.</div>
</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px" class="">
<div class="">Link Infinity further delegated that same /24 to IPDC
and asked Cloud innovation to issue an LOA, which we
did. The LOA specifically required IPDC to use its own
ASN to announce the space (AS134190).</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
</blockquote>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px" class="">
<div class="">
<div style="font-family:Lato;font-size:14px" class="">IPDC
subsequently authorized one of its customers to use
the said prefix.</div>
</div>
</blockquote>
<div class="">
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
</div>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px" class="">
<div class="">
<div style="font-family:Lato;font-size:14px" class="">For reasons
still unknown to Cloud Innovation, IPDC and their
customer set up a BGP session wherein their customer
used AS37353 as the origin to advertise prefix <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a>.</div>
</div>
</blockquote>
<div class="">
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
</div>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px" class="">
<div class="">
<div style="font-family:Lato;font-size:14px" class="">Upon
discovering the announcement, rather than contact
Cloud Innovation, Mark contacted IPDC who provided him
with an incomplete explanation blaming their customer
and Mark, not realizing that Cloud Innovation was not
the customer in question posted far and wide about the
event. It is unclear to us why he chose to do this
rather than contact us to try and resolve the issue.</div>
</div>
</blockquote>
<div class="">
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">A
contributing factor to the erroneous BGP configuration
by IPDC's customer may have been data contained in some
outdated IRR route objects for <a href="http://156.241.0.0/16" target="_blank" moz-do-not-send="true" class="">156.241.0.0/16</a> which have
subsequently been deleted.</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">As soon as we
became aware of the problem (via Mark’s email), we began
to investigate the situation. As soon as it was clear
that this was the result of third-party actions, we
reached out to Mark privately to let him know what we
knew and that we were still investigating. We delayed
making a public statement in order to try and ascertain
all of the facts of the situation. We prefer not to make
public statements based on incomplete information.</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">We apologize
to the community for our small part in this unfortunate
incident and assure you that we work very hard to remain
good netizens and will address any concerns promptly
when they come to our attention.</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">Sincerely,<br class="">
</div>
<div style="font-family:Lato;font-size:14px" class=""><br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">Lu Heng<br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">CEO<br class="">
</div>
<div style="font-family:Lato;font-size:14px" class="">Cloud
Innovations<br class="">
</div>
</div>
<div class=""><br class="">
</div>
</div>
</div>
Attached:
<div class=""><span style="white-space:pre-wrap" class=""> </span>1.<span style="white-space:pre-wrap" class=""> </span>Letter
from Paul Wollner</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>2.<span style="white-space:pre-wrap" class=""> </span>Letter
from Link Infinity</div>
<div class=""><span style="white-space:pre-wrap" class=""> </span>3.<span style="white-space:pre-wrap" class=""> </span>LOA
Issued to IPDC Solutions for announcing <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a> from AS134190</div>
<div class=""> 4. Letter from IPDC</div>
<div class=""><br class="">
</div>
<div class="">FYI: LARUS is proving IP management service for Cloud
Innovation, while LARUS is also providing IP management
service to other third parties in all regions, for full
disclosure, LARUS and Cloud Innovation are headed by same CEO.</div>
<div class=""><br class="">
</div>
<div class="">Content of those letters have been posted here for your
convince:</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><b class="">IPDC:</b></div>
<div class=""><b class=""><br class="">
</b></div>
<font color="#888888" class="">
<div class=""><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">FOR
IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd]</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">IPDC
Solutions Pte Ltd (IPDC) is a customer of Cloud
Innovation Ltd and over the course of our corporate
relationship we were given the authority to use address
block <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a> since 9th
December 2019. </div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">On
12th December 2019, we have delegated that address block
to our client. Following which our client further
instructed us to announce the prefix with AS37353. In
good will after minimal verification through WHOIS’ IP
Prefix we have proceeded to execute our client’s
request. </div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">On
7th May 2020 IPDC was then contacted by SEACOM, the
legitimate holder of record for that ASN and have since
learned that the customer’s use of that ASN was
erroneous and not permitted by SEACOM and immediate
action has been taken to rectify this situation. </div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">IPDC
would like to apologize for our lack of attention in
conducting thorough verification and wish to highlight
that the involvement of Cloud Innovation Ltd in the
entire process was providing the addresses to us and
that we truly apologize as we understand that this
incident may have indirectly implicated Cloud Innovation
Ltd. </div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">IPDC
however, does not wish to disclose our client
information and our client information shall remain
confidential under present circumstances. Once again, we
apologize for our shortcomings. <br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><b class="">Link
Infinity:</b></div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">To
whom it may concern,<br class="">
<br class="">
We at HK Infinity International Ltd are a customer of
Cloud Innovation and in the course received rights to
use <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a> from them.
Beginning December, 2019, we delegated the right to
announce this prefix to IPDC Solutions Pte Ltd. (IPDC).
We asked Cloud Innovation to provide an LOA authorizing
them to announce the space which was subsequently
received. IPDC subsequently and without our knowledge
delegated this space to one of their customers and
allowed them to originate it from AS37353.<br class="">
<br class="">
This announcement was not authorized by us, nor is it
permitted by the LOA provided by Cloud Innovation.<br class="">
<br class="">
Unfortunately, we were not aware of the situation until
after it had already been resolved.<br class="">
<br class="">
It was never our intent to violate the LOA or to allow
the prefix to be announced from a hijacked ASN. We do
not condone this and apologize sincerely to the
community for what has happened here.<br class="">
<br class="">
Sincere Apologies,<br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><b class="">Paul
Wollner:</b></div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
</div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class="">8
May 2020<br class="">
<br class="">
TO WHOM IT MAY CONCERN
<br class="">
<br class="">
In the light of the recent email on NAPAfrica mailing
list, I would just like to clear the air. </div><div style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; font-stretch: normal; line-height: normal; font-family: Times;" class=""><br class="">
The IP route objects were created by myself for Cloud
Innovation when they signed up as a client of Macrolan (
now SEACOM) as they didn't have their own AS.<br class="">
<br class="">
At the time I was working for Macrolan (now SEACOM). I
left the employment of SEACOM in October 2019.<br class="">
<br class="">
It appears that when Cloud Innovation's contract with
SEACOM came to an end, the route objects were never
cleaned up.<br class="">
<br class="">
This occurred after I left SEACOM's employment. Since
leaving, I have no access to these objects.<br class="">
<br class="">
Regards<br class="">
<br class="">
Paul Wollner<br class="">
082-786-9776</div>
</div>
</font></div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 8 May 2020 at 22:08,
Mark Tinka <<a href="mailto:mark.tinka@seacom.mu" target="_blank" moz-do-not-send="true" class="">mark.tinka@seacom.mu</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""> <font face="Tahoma" class="">Hi all.<br class="">
<br class="">
I'm not one to b**ch & moan in public, but per
subject, I could not let this one slide.<br class="">
<br class="">
And if you get this from multiple mailing lists, apologies
for that - I'm just trying to make sure that this reaches
as wide an audience as possible, on the continent.<br class="">
<br class="">
SEACOM (AS37100) acquired MacroLan (AS37353) a couple of
years ago. MacroLan is now part of the SEACOM family, and
while we are in the process of integrating that network
into AS37100, some existing services continue to be
delivered on AS37353 until that exercise is completed.<br class="">
<br class="">
One of the customers that AS37353 was providing services
to was Cloud Innovation, in Cape Town. From a routing
perspective, because Cloud Innovation had no AS number for
this service, all of their IP address space was being
originated by AS37353, on their behalf.<br class="">
<br class="">
In December of 2019, AS37353 ceased providing services to
Cloud Innovation. That is 6 months ago.<br class="">
<br class="">
In recent days, it came to SEACOM's attention that some of
Cloud Innovation's IP address space was being originated
by AS37353 - specifically, <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a> - even though
we were sure that they were no longer a customer of
AS37353 since December of 2019. At first, we thought this
was a cached entry in a number of popular looking glasses,
but then every looking glass had the same entry, which
made this an unlikely bug.<br class="">
<br class="">
As of yesterday afternoon, see below what Telia's looking
glass was saying about this prefix:<br class="">
<br class="">
*****<br class="">
<br class="">
Path #1: Received by speaker 0<br class="">
4809 134190 37353<br class="">
2.255.249.42 (metric 2134) from 2.255.253.101
(80.91.242.40)<br class="">
Origin incomplete, localpref 200, valid, internal,
best, group-best, import-candidate<br class="">
Communities:<br class="">
<br class="">
1299:431<br class="">
(RPKI state Unknown)<br class="">
<br class="">
1299:1000 1299:30000 1299:30600 23456:20413 45352:4500
45352:9204<br class="">
<br class="">
*****<br class="">
<br class="">
But when I run a traceroute from my house to that prefix,
it clearly was not ending up in Cape Town, where AS37353's
main operation resides:<br class="">
<br class="">
*****<br class="">
<br class="">
MacBook-Pro-7:~ tinka$ traceroute -I 156.241.3.1<br class="">
traceroute to 156.241.3.1 (156.241.3.1), 64 hops max, 72
byte packets<br class="">
1 172.16.0.254 (172.16.0.254) 14.824 ms 11.522 ms
3.525 ms<br class="">
2 <a href="http://xe-1-3-0-1064.er-01-jnb.za.seacomnet.com/" target="_blank" moz-do-not-send="true" class="">xe-1-3-0-1064.er-01-jnb.za.seacomnet.com</a>
(105.22.37.13) 5.620 ms 9.714 ms 9.887 ms<br class="">
3 <a href="http://ce-0-2-0-0.cr-02-jnb.za.seacomnet.com/" target="_blank" moz-do-not-send="true" class="">ce-0-2-0-0.cr-02-jnb.za.seacomnet.com</a>
(105.16.28.2) 175.232 ms 172.699 ms 175.896 ms<br class="">
4 <a href="http://xe-0-0-0-8.cr-02-cpt.za.seacomnet.com/" target="_blank" moz-do-not-send="true" class="">xe-0-0-0-8.cr-02-cpt.za.seacomnet.com</a>
(105.16.9.182) 164.496 ms 163.578 ms 163.546 ms<br class="">
5 105.16.14.153 (105.16.14.153) 169.812 ms 171.272 ms
177.115 ms<br class="">
6 <a href="http://xe-0-0-0-0.br-02-lhr.uk.seacomnet.com/" target="_blank" moz-do-not-send="true" class="">xe-0-0-0-0.br-02-lhr.uk.seacomnet.com</a>
(105.16.34.253) 168.911 ms 172.958 ms 165.165 ms<br class="">
7 82.112.115.169 (82.112.115.169) 172.700 ms 176.482
ms 174.375 ms<br class="">
8 <a href="http://ae-17.r05.londen12.uk.bb.gin.ntt.net/" target="_blank" moz-do-not-send="true" class="">ae-17.r05.londen12.uk.bb.gin.ntt.net</a>
(129.250.2.147) 672.099 ms 613.617 ms 615.109 ms<br class="">
9 <a href="http://ae-2.r24.londen12.uk.bb.gin.ntt.net/" target="_blank" moz-do-not-send="true" class="">ae-2.r24.londen12.uk.bb.gin.ntt.net</a>
(129.250.4.244) 181.952 ms 183.087 ms 187.302 ms<br class="">
10 <a href="http://ae-16.r20.frnkge13.de.bb.gin.ntt.net/" target="_blank" moz-do-not-send="true" class="">ae-16.r20.frnkge13.de.bb.gin.ntt.net</a>
(129.250.3.13) 190.511 ms 185.579 ms 187.058 ms<br class="">
11 <a href="http://ae-3.r20.sngpsi07.sg.bb.gin.ntt.net/" target="_blank" moz-do-not-send="true" class="">ae-3.r20.sngpsi07.sg.bb.gin.ntt.net</a>
(129.250.4.17) 520.882 ms 613.982 ms 615.275 ms<br class="">
12 <a href="http://ae-9.r24.tkokhk01.hk.bb.gin.ntt.net/" target="_blank" moz-do-not-send="true" class="">ae-9.r24.tkokhk01.hk.bb.gin.ntt.net</a>
(129.250.7.67) 612.301 ms 586.886 ms 436.711 ms<br class="">
13 <a href="http://ae-1.r03.tkokhk01.hk.bb.gin.ntt.net/" target="_blank" moz-do-not-send="true" class="">ae-1.r03.tkokhk01.hk.bb.gin.ntt.net</a>
(129.250.6.98) 614.470 ms 613.416 ms 614.281 ms<br class="">
14 <a href="http://ce-0-3-0-3.r03.tkokhk01.hk.ce.gin.ntt.net/" target="_blank" moz-do-not-send="true" class="">ce-0-3-0-3.r03.tkokhk01.hk.ce.gin.ntt.net</a>
(203.131.241.126) 614.128 ms 613.661 ms 615.416 ms<br class="">
15 * * *<br class="">
16 * * *<br class="">
17 156.241.3.1 (156.241.3.1) 494.400 ms 410.180 ms *<br class="">
MacBook-Pro-7:~ tinka$<br class="">
<br class="">
*****<br class="">
<br class="">
So we, then, realized that this was a fraudulent use of
MacroLan's AS37353, to which we had given no express
permission.<br class="">
<br class="">
As luck would have it, due to my days living and working
in Malaysia, I know the good folk that operate AS134190
(IPDC Solutions), who was the upstream providing transit
for this prefix. So I rang them up yesterday afternoon,
told them what was happening, and within the hour, they
got that eBGP session shutdown. I am most grateful to them
for their quick response and immediate understanding of
what was going on. Even with all the technology we have
today, it, many times, comes down to having good friends
in good places.<br class="">
<br class="">
Anyway, it turns out the ISP that had acquired this prefix
from Cloud Innovation is based in Manila, Philippines.
When IPDC delivered their transit service to them in
Manila, that ISP informed them that they should use
AS37353 for the eBGP session. Yes, one could argue that
IPDC should have done their checks to ensure that the AS
number being provided by their customer belongs to them,
but to be honest, I'm not too bothered about that compared
to Cloud Innovation's thinking that it was okay to use
another network's AS number in order to deliver their
services to their customers.<br class="">
<br class="">
IPDC confirm that this service was activated for the
Manila ISP in December of 2019, right around the time
Cloud Innovation's service with SEACOM, in Cape Town,
ended.<br class="">
<br class="">
As it currently stands, the ISP in Manila is now off the
Internet, with some 12 paying customers currently without
service. Their excuse - they do not have an AS number of
their own.<br class="">
<br class="">
IPDC tried to find out why the ISP in Manila thought that
it was okay to use another network's AS number for their
service, and as it turns out, the network engineer at the
Manila ISP that set this up has since left the company.
All the ones currently there do not have any history about
all of this.<br class="">
<br class="">
Currently, <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a>
is not in the global BGP table:<br class="">
<br class="">
*****<br class="">
<br class="">
<a href="http://lg-01-ams.nl/" target="_blank" moz-do-not-send="true" class="">lg-01-ams.nl</a>>sh ip bgp <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a><br class="">
% Network not in table<br class="">
<a href="http://lg-01-ams.nl/" target="_blank" moz-do-not-send="true" class="">lg-01-ams.nl</a>><br class="">
<br class="">
<a href="http://lg-01-nbo.ke/" target="_blank" moz-do-not-send="true" class="">lg-01-nbo.ke</a>>sh ip bgp <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a><br class="">
% Network not in table<br class="">
<a href="http://lg-01-nbo.ke/" target="_blank" moz-do-not-send="true" class="">lg-01-nbo.ke</a>><br class="">
<br class="">
<a href="http://lg-01-cpt.za/" target="_blank" moz-do-not-send="true" class="">lg-01-cpt.za</a>>sh ip bgp <a href="http://156.241.3.0/24" target="_blank" moz-do-not-send="true" class="">156.241.3.0/24</a><br class="">
% Network not in table<br class="">
<a href="http://lg-01-cpt.za/" target="_blank" moz-do-not-send="true" class="">lg-01-cpt.za</a>><br class="">
<br class="">
*****<br class="">
<br class="">
That Cloud Innovation thought it was okay for them to use
MacroLan's AS number to originate their own prefixes into
the global BGP is as morally reprehensible as it is
technologically distasteful.<br class="">
<br class="">
SEACOM have been working very closely with AFRINIC to
delete previous route objects from their IRR that certify
a relationship between Cloud Innovation's parent /16
aggregates that cover this prefix, and AS37353, but this
is one of those objects that cannot be removed via the
MyAFRINIC portal, and requires manual intervention from
AFRINIC.<br class="">
<br class="">
I have not, personally, spoken to the proprietors of Cloud
Innovation and/or Outside Heaven, as I don't see how
anything could explain this with any degree of
justification.<br class="">
<br class="">
For now, I will find some beer to wipe the foul taste from
my mouth, while we (SEACOM) consider what to do about
this.<br class="">
<br class="">
And yes, for those who are wondering, RPKI's ROV would not
have prevented this, in its current form. This is AS
hijacking, and ROV, today, tries to solve the
prefix-hijacking problem, first.<br class="">
<br class="">
Thank you for your attention.<br class="">
<br class="">
Mark.<br class="">
</font> </div>
_______________________________________________<br class="">
Community-Discuss mailing list<br class="">
<a href="mailto:Community-Discuss@afrinic.net" target="_blank" moz-do-not-send="true" class="">Community-Discuss@afrinic.net</a><br class="">
<a href="https://lists.afrinic.net/mailman/listinfo/community-discuss" rel="noreferrer" target="_blank" moz-do-not-send="true" class="">https://lists.afrinic.net/mailman/listinfo/community-discuss</a><br class="">
</blockquote>
</div>
<br clear="all" class="">
<div class=""><br class="">
</div>
-- <br class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">--<br class="">
Kind regards.<br class="">
Lu<br class="">
<br class="">
</div>
</div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Community-Discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Community-Discuss@afrinic.net">Community-Discuss@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/community-discuss">https://lists.afrinic.net/mailman/listinfo/community-discuss</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
James Chirwa
Acting Manager, Member Services Department
AFRINIC Ltd.
t: +230 403 51 00 | f: +230 466 6758 |
tt: @afrinic | w: <a class="moz-txt-link-abbreviated" href="http://www.afrinic.net/">www.afrinic.net</a>
SM: <a href="http://facebook.com/afrinic" class="">facebook.com/afrinic</a> | <a href="http://flickr.com/afrinic" class="">flickr.com/afrinic</a> | <a href="http://youtube.com/afrinicmedia" class="">youtube.com/afrinicmedia</a>
____________________________</pre>
</div>
_______________________________________________<br class="">Community-Discuss mailing list<br class=""><a href="mailto:Community-Discuss@afrinic.net" class="">Community-Discuss@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo/community-discuss<br class=""></div></blockquote></div><br class=""></body></html>