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

[ABDULKARIM AYOPO OLOYEDE]

Dear Noah,
Your last  email has clearly violated the last warning earlier issued by
the Co-Chair. Therefore we are left with no choice than to moderate any
email you send onto this mailing list. This would be reviewed after a week.

Thanks
CO- PDWG


On Sat, 30 May 2020, 00:44 Noah, <noah at neo.co.tz> wrote:


>

> 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

>

>

>

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd

>


-- 
Website <http://www.unilorin.edu.ng>, Weekly Bulletin 
<http://www.unilorin.edu.ng/index.php/bulletin> UGPortal 
<http://uilugportal.unilorin.edu.ng/> PGPortal 
<https://uilpgportal.unilorin.edu.ng/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200530/c2c5b051/attachment-0001.html>