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

[Noah]

Hi Abdulkarim

So just to inform you that IPv4 prefixes are associated with Organisation
names and one can not mention a prefix without mentioning the organization
names in this regard.

Similarly ASN are associated with Organisation names and one can not
mention an ASN without mentioning the organization's associated with it in
this regard.

The above is true and you as cochair claiming that the working group should
not mention company names in reference to internet number resources abuses
is wrong and misguided since the information I have presented is factual
with resources policy implications.

Cheers,
Noah


On Sat, 30 May 2020, 09:12 ABDULKARIM AYOPO OLOYEDE, <
oloyede.aa at unilorin.edu.ng> wrote:


> 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/2380d337/attachment.html>