<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div>Hi Taiwo,</div><div><br></div><div dir="ltr">On Fri, May 29, 2020 at 11:46 AM Taiwo Oyewande <<a href="mailto:taiwo.oyewande88@gmail.com" target="_blank">taiwo.oyewande88@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good day, <br>
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? </blockquote><div><br></div><div>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 <a href="http://156.241.3.0/24" target="_blank">156.241.3.0/24</a> 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 <strike>delegate</strike> (sub-allocate) to the same prefix.<br></div><div><br></div><div>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 "<strike>delegated</strike>" the same prefix by their LIR Cloud Innovation Ltd. <br></div><div><br></div><div>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.<br></div><div><br></div><div>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. </div><div><br></div><div>------------------------</div><div><br></div><div>Hi Ubah,</div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 29, 2020 at 4:37 PM Anthony Ubah <<a href="mailto:ubah.tonyiyke@gmail.com" target="_blank">ubah.tonyiyke@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div dir="auto">Hi Paul, </div><div dir="auto"><br></div><div dir="auto">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.</div></div></div></blockquote><div> </div><div>It's not SEACOM's problem at all and I will explain why.</div><div><br></div><div>So in turns out that on <b>4th March 2020</b> 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 <a href="http://156.241.3.0/24" target="_blank">156.241.3.0/24</a> on the RADB IRR and then associated the prefix with SEACOM AS37353 again. This action was not authorized by SEACOM for the record.</div><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div dir="auto"><br></div><div dir="auto">From whatever perspective the onus is on SEACOM and IPDC.</div></div></div></blockquote><div><br></div><div>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 <a href="http://156.241.3.0/24" target="_blank">156.241.3.0/24</a> that belongs to Cloud Innovation Limited by their customer HongKong Link Infinity Technology Ltd on <b>4th March 2020</b> 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.<br></div><div><br></div><div> $ whois -h <a href="http://whois.radb.net" target="_blank">whois.radb.net</a> '<a href="http://156.241.3.0/24" target="_blank">156.241.3.0/24</a>' <br><pre><code>route: <a href="http://156.241.3.0/24" target="_blank">156.241.3.0/24</a>
descr: Proxy-registered route object
<b>origin: AS37353</b>
notify: <a href="mailto:matthew.chan@hgc.com.hk" target="_blank">matthew.chan@hgc.com.hk</a>
mnt-by: MAINT-HGC-INTL
<b>changed: <a href="mailto:matthew.chan@hgc.com.hk" target="_blank">matthew.chan@hgc.com.hk</a> 20200304</b>
source: RADB</code></pre>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.<br></div><div><br></div><div><a href="https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0%2F24&-T+option=&ip_option=&-i+option" target="_blank">https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0%2F24&-T+option=&ip_option=&-i+option</a></div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>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 <b>open</b> and <b>transparent</b> calling out of parties involved in the abuses related to <b>routing threats</b> that ensure the continued mutual functioning of a <b>healthy global internet</b>. <br></div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>Cheers,<br></div><div>Noah<br></div><div><br> </div><div><br></div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>