[Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship

[Noah]

Hi Taiwo,

On Fri, May 29, 2020 at 11:46 AM Taiwo Oyewande <taiwo.oyewande88 at gmail.com>
wrote:


> Good day,

> I agree with Paul here. In this entire matter, the authors have blamed the

> wrong party - i think it should be a SEACOM issue in the first place. This

> makes me wonder -why did the authors put the blame on Cloud Innovation?



So if you cared to really read the original email, you would have realized
that the issue that was reported involved an incident where SEACOM's
AS37353  was being used by a network in Manila to announce an IPv4 prefix
156.241.3.0/24 that forms part of the IPv4 address blocks assigned to Cloud
Innovation Ltd by AfriNIC. Therefore it's safe to say that as per the RIR
database entries, Cloud Innovation Ltd is responsible for the prefix as
guided by AfriNIC's CPM and their multiple customers whom they delegate
(sub-allocate) to the same prefix.

As such, its widely well know that the best standard practice within the
Internet community dictates that any internet number resources abuse issues
and/or common routing threats concerned with a prefix would attract the
attention of the LIR the prefix was assigned too by AfriNIC and in this
case, Cloud Innovation Ltd, which is bestowed with that responsibility,
which is why among the documents folks from Cloud Innovation Ltd shared
with the Internet community in their apology as pertains to this incident,
were attachments of some LOA (Letters of Authorization) in reference to
their customers IPDC and HongKong Link Infinity Technology Ltd who were "
delegated" the same prefix by their LIR Cloud Innovation Ltd.

Word is that one of them mistakenly announced the prefix using SEACOM's
AS37353 instead of the ASN they had been advised to use in the LOA provided
to them by Cloud Innovation Ltd. The Issue then becomes that; "if the LOA
clearly informs you to use AS134190 and in your bgp configuration you take
it upon yourself to use AS37353 instead", then that becomes very doggy for
some customer in Manila who has nothing to do with AS37353. BGP
configurations are done by conscious humans manually and sometimes through
careful automation.

Cloud Innovation Ltd was put to task and the issue was resolved immediately
and I hope by now you get the idea why they became a party of interest as
far as fixing this issue was concerned for the best interest of a secure
Internet and routing norms.

------------------------

Hi Ubah,

On Fri, May 29, 2020 at 4:37 PM Anthony Ubah <ubah.tonyiyke at gmail.com>
wrote:


> Hi Paul,

>

> Apparently, it’s SEACOM’s problem. Debating without a clear picture is

> bound to lead to more misunderstanding. Thus the reason some parties blames

> Cloud Innovation.

>


It's not SEACOM's problem at all and I will explain why.

So in turns out that on *4th March 2020* just over two months ago, the same
customer of Cloud Innovation Ltd, that is HongKong Link Infinity Technology
Ltd created a route object for the same prefix 156.241.3.0/24 on the RADB
IRR and then associated the prefix with SEACOM AS37353 again. This action
was not authorized by SEACOM for the record.

A good member of the Internet community shared some data to the above
effect on a previous thread earlier. A renowned patron of Cloud Innovation
Ltd responded acknowledging the fact which also shared more data which
contained exactly the issue that was being pointed out and he thanked the
good member for pointing this out to Cloud Innovation Ltd. He asked his
people to get on the issue and immediately fix the issue and when you look
at the current RADB entry, of the said prefix, you will realise that the
issue has been fixed as the route object was deleted with immediate effect.



>

> From whatever perspective the onus is on SEACOM and IPDC.

>


I beg to correct you that for this particular case the issue was a
conscious and deliberate creation of a route object for the prefix
156.241.3.0/24 that belongs to Cloud Innovation Limited by their customer
HongKong Link Infinity Technology Ltd on *4th March 2020* and associated it
with SEACOM ASN again. Neither of them was a SEACOM customer at the time of
creation of this route object and the real change like I said was done on
2020-03-04 by one Matthew Chan under MNT-BY: MAINT-HGC-INTL.

 $ whois -h whois.radb.net '156.241.3.0/24'

route:      156.241.3.0/24
descr:      Proxy-registered route object*origin:     AS37353*
notify:     matthew.chan at hgc.com.hk
mnt-by:     MAINT-HGC-INTL*changed:    matthew.chan at hgc.com.hk
<matthew.chan at hgc.com.hk> 20200304*
source:     RADB

NOTE: The good news is that, after the issue was raised by the good members
of the internet community,  the object above has since been deleted and
removed by those who had created it as per link below.

https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0%2F24&-T+option=&ip_option=&-i+option

PS: ASN hijacks happen often across the Internet and even though projects
like MANRS offers some mechanism for a fix (and in this case as relates to
apparent bgp miss configurations by some IPDC customer or unauthorized IRR
database entries by HongKong Link Infinity Ltd), more than anything is
often the *open* and *transparent* calling out of parties involved in the
abuses related to *routing threats* that ensure the continued mutual
functioning of a *healthy global internet*.

SEACOM ensures to play its part for the best interest of the Internet and
like Mark said, today it is SEACOM tomorrow it can be some other network.

I hope I have endeavoured to clarify to you both and that you realize that
the responsibility is with all of us to collectively ensure a safe and
secure Internet and those involved in abuses are held accountable.

Cheers,
Noah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/community-discuss/attachments/20200530/cef3e236/attachment.html>