<div dir="auto">Hi Abdulkarim<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Noah</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 30 May 2020, 09:12 ABDULKARIM AYOPO OLOYEDE, <<a href="mailto:oloyede.aa@unilorin.edu.ng">oloyede.aa@unilorin.edu.ng</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Dear Noah,<div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Thanks</div><div dir="auto">CO- PDWG</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 30 May 2020, 00:44 Noah, <<a href="mailto:noah@neo.co.tz" target="_blank" rel="noreferrer">noah@neo.co.tz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" target="_blank">whois.radb.net</a> '<a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a>' <br><pre><code>route: <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" target="_blank">matthew.chan@hgc.com.hk</a>
mnt-by: MAINT-HGC-INTL
<b>changed: <a href="mailto:matthew.chan@hgc.com.hk" rel="noreferrer noreferrer" 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" rel="noreferrer noreferrer" 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>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" rel="noreferrer noreferrer" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div>
<br>
<div><a href="http://www.unilorin.edu.ng" style="font-size:1.3em" target="_blank" rel="noreferrer">Website</a><span style="font-size:1.3em">,</span><span style="font-size:1.3em"> </span><span style="font-size:1.3em"><a href="http://www.unilorin.edu.ng/index.php/bulletin" target="_blank" rel="noreferrer">Weekly Bulletin</a> <a href="http://uilugportal.unilorin.edu.ng/" target="_blank" rel="noreferrer">UGPortal</a> <a href="https://uilpgportal.unilorin.edu.ng/" target="_blank" rel="noreferrer">PGPortal</a></span></div><div><br></div></blockquote></div>