<div dir="auto"><div dir="auto">Hello, community</div><div dir="auto"><br></div><div dir="auto">+1 @Gregoire and @Mark Tinka</div><div dir="auto"><br></div><div dir="auto"><b>cloud innovation</b>  were allocated  <b>big bunch of IPv4</b> space as a <b>LIR</b> with <b>no ASN</b>. Interesting, and no <b>v6</b></div><div dir="auto"><br></div><div dir="auto">While the bylaws defines LIR as followed:</div><div dir="auto">++++++</div><div dir="auto">Local Internet Registry (LIR):</div><div dir="auto">any Network Operator that provides Internet services to distinct end-users and end-sites</div><div dir="auto">++++++</div><div dir="auto"><br></div><div dir="auto">I wonder  which network does cloud innovation operate and which internet services it provides to end-users and end-sites in <b>Africa</b>.</div><div dir="auto"><br></div><div dir="auto">How does this network <b>managing 3 x /11 of IPv4</b> <b>operate</b>? </div><div dir="auto"><br></div><div dir="auto">There is something here for the community to learn about.</div><div dir="auto"><br></div><div dir="auto">Regards </div><div dir="auto"><br></div><div dir="auto">--</div><div dir="auto">Arnaud</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 23 mai 2020 à 14:20, Gregoire EHOUMI via RPD <<a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">Hello,</div><div dir="auto"><br>Thanks Mark for exposing the details of the SEACOM AS37353 hijacking.<br><br>I carefully read your report and also the Cloud Innovation Limited quick response including their attachments as justifications.<br><br>I note that;<br><br> ⁃ the service contract with Cloud Innovation covering the announcement of their prefixes by SEACOM AS37353 was terminated  by SEACOM.<br><br> ⁃ some stale IRR route objects existed after termination of the contract.<br><br> ⁃ through some multiple layer distribution an organisation in Manila Philippines was “delegated“ an IP block from Cloud Innovation address space.<br><br> ⁃ both upstream ISP and the customer in Manila set up a BGP session using SEACOM's AS37353 as the ASN of the Manila customer.<br><br> ⁃ there was a prompt reaction from the involved parties that included apologies to SEACOM and the wider internet community.<br><br> ⁃ there were promises from said parties to be a better netizen which would mean, them not hijacking other networks ASN's.<br><br> ⁃ there was clear refusal to disclose the details of the customer in Manila Philippines who hijacked the affected SEACOM ASN.<br><br>All put together, demonstrates that what happened was an impersonation and not a BGP configuration error, nor an oversight in checking the right to use of the SEACOM ASN.<br><br>1. Why is it that the real customer did not bother presenting its apologies to the community<br><br>2. Why is there refusal to reveal customer’s details?<br><br>3. Why is it that the said prefix is no longer seen in the routing table originated by the genius ASN or any other ASN?<br><br>4. Which networks were involved and what happened to the end users?<br><br>Can someone from AFRINIC explain what “delegation of IP block” mean?<br><br>Note: The self organised Internet knows how to deal with bad net citizens.!<br><br>Best regards <br>Gregoire Ehoumi </div><div dir="auto"><br></div><div><br></div><div style="font-size:100%;color:#000000" dir="auto"><div>-------- Original message --------</div><div>From: Lu Heng <<a href="mailto:h.lu@anytimechinese.com" target="_blank" rel="noreferrer">h.lu@anytimechinese.com</a>> </div><div>Date: 2020-05-09  5:43 a.m.  (GMT-05:00) </div><div>To: Mark Tinka <<a href="mailto:mark.tinka@seacom.mu" target="_blank" rel="noreferrer">mark.tinka@seacom.mu</a>> </div><div>Cc: "<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a> >> AfriNIC Resource Policy Discussion List" <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>> </div><div>Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal,       Netizenship </div><div><br></div></div><div dir="ltr"><div><div><div>To whom it may concern,<div><br></div><div>On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was abusing an ASN (37353) that didn’t belong to them (Cloud Innovation) but rather belonged to Seacom through their acquisition of MacroLAN.</div><div><br></div><div>While we regret this unfortunate incident, Mark’s claims that it was criminal or bad netizenship on the part of Cloud Innovation is without foundation and utterly incorrect.</div><div><br></div><div><div style="font-family:Lato;font-size:14px">As shown below in the attached document from Paul Wollner(Ex-CTO of Macrolan who created IRR routes to allow Macrolan to announce Cloud Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A customer of Cloud Innovation; and attached LOA from LARUS authorizing IPDC Solutions to announce the prefix with origin AS134190.  And a Letter from IPDC. This was an innocent mistake committed by third parties and had nothing to do with any action by Cloud Innovation or LARUS.</div></div></div></div><div><div><div style="font-family:Lato;font-size:14px"><br></div><div style="font-family:Lato;font-size:14px">Here’s what happened:<br></div><div style="font-family:Lato;font-size:14px"><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div style="font-family:Lato;font-size:14px">Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019.</div></div></blockquote></div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation to issue an LOA, which we did. The LOA specifically required IPDC to use its own ASN to announce the space (AS134190).</div><div style="font-family:Lato;font-size:14px"><br></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div style="font-family:Lato;font-size:14px">IPDC subsequently authorized one of its customers to use the said prefix.</div></div></blockquote><div><div style="font-family:Lato;font-size:14px"><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div style="font-family:Lato;font-size:14px">For reasons still unknown to Cloud Innovation, IPDC and their customer set up a BGP session wherein their customer used AS37353 as the origin to advertise prefix <a href="http://156.241.3.0/24" target="_blank" rel="noreferrer">156.241.3.0/24</a>.</div></div></blockquote><div><div style="font-family:Lato;font-size:14px"><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div style="font-family:Lato;font-size:14px">Upon discovering the announcement, rather than contact Cloud Innovation, Mark contacted IPDC who provided him with an incomplete explanation blaming their customer and Mark, not realizing that Cloud Innovation was not the customer in question posted far and wide about the event. It is unclear to us why he chose to do this rather than contact us to try and resolve the issue.</div></div></blockquote><div><div style="font-family:Lato;font-size:14px"><br></div><div style="font-family:Lato;font-size:14px">A contributing factor to the erroneous BGP configuration by IPDC's customer may have been data contained in some outdated IRR route objects for <a href="http://156.241.0.0/16" target="_blank" rel="noreferrer">156.241.0.0/16</a> which have subsequently been deleted.</div><div style="font-family:Lato;font-size:14px"><br></div><div style="font-family:Lato;font-size:14px">As soon as we became aware of the problem (via Mark’s email), we began to investigate the situation. As soon as it was clear that this was the result of third-party actions, we reached out to Mark privately to let him know what we knew and that we were still investigating. We delayed making a public statement in order to try and ascertain all of the facts of the situation. We prefer not to make public statements based on incomplete information.</div><div style="font-family:Lato;font-size:14px"><br></div><div style="font-family:Lato;font-size:14px">We apologize to the community for our small part in this unfortunate incident and assure you that we work very hard to remain good netizens and will address any concerns promptly when they come to our attention.</div><div style="font-family:Lato;font-size:14px"><br></div><div style="font-family:Lato;font-size:14px"><br></div><div style="font-family:Lato;font-size:14px">Sincerely,<br></div><div style="font-family:Lato;font-size:14px"><br></div><div style="font-family:Lato;font-size:14px">Lu Heng<br></div><div style="font-family:Lato;font-size:14px">CEO<br></div><div style="font-family:Lato;font-size:14px">Cloud Innovations<br></div></div><div><br></div></div></div>Attached:<div><span style="white-space:pre-wrap">      </span>1.<span style="white-space:pre-wrap">      </span>Letter from Paul Wollner</div><div><span style="white-space:pre-wrap"> </span>2.<span style="white-space:pre-wrap">      </span>Letter from Link Infinity</div><div><span style="white-space:pre-wrap">        </span>3.<span style="white-space:pre-wrap">      </span>LOA Issued to IPDC Solutions for announcing <a href="http://156.241.3.0/24" target="_blank" rel="noreferrer">156.241.3.0/24</a> from AS134190</div><div>        4.     Letter from IPDC</div><div><br></div><div>FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is also providing IP management service to other third parties in all regions, for full disclosure, LARUS and Cloud Innovation are headed by same CEO.</div><div><br></div><div>Content of those letters have been posted here for your convince:</div><div><br></div><div><div><b>IPDC:</b></div><div><b><br></b></div><font color="#888888"><div><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)">FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd]</p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)">IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate relationship we were given the authority to use address block <a href="http://156.241.3.0/24" target="_blank" rel="noreferrer">156.241.3.0/24</a> since 9th December 2019. </p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)">On 12th December 2019, we have delegated that address block to our client. Following which our client further instructed us to announce the prefix with AS37353. In good will after minimal verification through WHOIS’ IP Prefix we have proceeded to execute our client’s request. </p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)">On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and have since learned that the customer’s use of that ASN was erroneous and not permitted by SEACOM and immediate action has been taken to rectify this situation. </p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)">IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud Innovation Ltd. </p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)">IPDC however, does not wish to disclose our client information and our client information shall remain confidential under present circumstances. Once again, we apologize for our shortcomings. <br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><b>Link Infinity:</b></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)">To whom it may concern,<br><br>We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to use <a href="http://156.241.3.0/24" target="_blank" rel="noreferrer">156.241.3.0/24</a> from them. Beginning December, 2019, we delegated the right to announce this prefix to IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to announce the space which was subsequently received. IPDC subsequently and without our knowledge delegated this space to one of their customers and allowed them to originate it from AS37353.<br><br>This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation.<br><br>Unfortunately, we were not aware of the situation until after it had already been resolved.<br><br>It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We do not condone this and apologize sincerely to the community for what has happened here.<br><br>Sincere Apologies,<br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><b>Paul Wollner:</b></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)">8 May 2020<br><br>TO WHOM IT MAY CONCERN                                        <br><br>In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air. </p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br>The IP route objects were created by myself for Cloud Innovation when they signed up as a client of Macrolan ( now SEACOM) as they didn't have their own AS.<br><br>At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October 2019.<br><br>It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were never cleaned up.<br><br>This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects.<br><br>Regards<br><br>Paul Wollner<br>082-786-9776<br></p><p style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,0)"><br></p></div></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 May 2020 at 22:10, Mark Tinka <<a href="mailto:mark.tinka@seacom.mu" target="_blank" rel="noreferrer">mark.tinka@seacom.mu</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>
    <font face="Tahoma">Hi all.<br>
      <br>
      I'm not one to b**ch & moan in public, but per subject, I
      could not let this one slide.<br>
      <br>
      And if you get this from multiple mailing lists, apologies for
      that - I'm just trying to make sure that this reaches as wide an
      audience as possible, on the continent.<br>
      <br>
      SEACOM (AS37100) acquired MacroLan (AS37353) a couple of years
      ago. MacroLan is now part of the SEACOM family, and while we are
      in the process of integrating that network into AS37100, some
      existing services continue to be delivered on AS37353 until that
      exercise is completed.<br>
      <br>
      One of the customers that AS37353 was providing services to was
      Cloud Innovation, in Cape Town. From a routing perspective,
      because Cloud Innovation had no AS number for this service, all of
      their IP address space was being originated by AS37353, on their
      behalf.<br>
      <br>
      In December of 2019, AS37353 ceased providing services to Cloud
      Innovation. That is 6 months ago.<br>
      <br>
      In recent days, it came to SEACOM's attention that some of Cloud
      Innovation's IP address space was being originated by AS37353 -
      specifically, <a href="http://156.241.3.0/24" target="_blank" rel="noreferrer">156.241.3.0/24</a> - even though we were sure that they
      were no longer a customer of AS37353 since December of 2019. At
      first, we thought this was a cached entry in a number of popular
      looking glasses, but then every looking glass had the same entry,
      which made this an unlikely bug.<br>
      <br>
      As of yesterday afternoon, see below what Telia's looking glass
      was saying about this prefix:<br>
      <br>
      *****<br>
      <br>
      Path #1: Received by speaker 0<br>
        4809 134190 37353<br>
          2.255.249.42 (metric 2134) from 2.255.253.101 (80.91.242.40)<br>
            Origin incomplete, localpref 200, valid, internal, best,
      group-best, import-candidate<br>
      Communities:<br>
      <br>
      1299:431<br>
          (RPKI state Unknown)<br>
      <br>
      1299:1000 1299:30000 1299:30600 23456:20413 45352:4500 45352:9204<br>
      <br>
      *****<br>
      <br>
      But when I run a traceroute from my house to that prefix, it
      clearly was not ending up in Cape Town, where AS37353's main
      operation resides:<br>
      <br>
      *****<br>
      <br>
      MacBook-Pro-7:~ tinka$ traceroute -I 156.241.3.1<br>
      traceroute to 156.241.3.1 (156.241.3.1), 64 hops max, 72 byte
      packets<br>
       1  172.16.0.254 (172.16.0.254)  14.824 ms  11.522 ms  3.525 ms<br>
       2  <a href="http://xe-1-3-0-1064.er-01-jnb.za.seacomnet.com" target="_blank" rel="noreferrer">xe-1-3-0-1064.er-01-jnb.za.seacomnet.com</a> (105.22.37.13)  5.620
      ms  9.714 ms  9.887 ms<br>
       3  <a href="http://ce-0-2-0-0.cr-02-jnb.za.seacomnet.com" target="_blank" rel="noreferrer">ce-0-2-0-0.cr-02-jnb.za.seacomnet.com</a> (105.16.28.2)  175.232
      ms  172.699 ms  175.896 ms<br>
       4  <a href="http://xe-0-0-0-8.cr-02-cpt.za.seacomnet.com" target="_blank" rel="noreferrer">xe-0-0-0-8.cr-02-cpt.za.seacomnet.com</a> (105.16.9.182)  164.496
      ms  163.578 ms  163.546 ms<br>
       5  105.16.14.153 (105.16.14.153)  169.812 ms  171.272 ms  177.115
      ms<br>
       6  <a href="http://xe-0-0-0-0.br-02-lhr.uk.seacomnet.com" target="_blank" rel="noreferrer">xe-0-0-0-0.br-02-lhr.uk.seacomnet.com</a> (105.16.34.253)  168.911
      ms  172.958 ms  165.165 ms<br>
       7  82.112.115.169 (82.112.115.169)  172.700 ms  176.482 ms 
      174.375 ms<br>
       8  <a href="http://ae-17.r05.londen12.uk.bb.gin.ntt.net" target="_blank" rel="noreferrer">ae-17.r05.londen12.uk.bb.gin.ntt.net</a> (129.250.2.147)  672.099
      ms  613.617 ms  615.109 ms<br>
       9  <a href="http://ae-2.r24.londen12.uk.bb.gin.ntt.net" target="_blank" rel="noreferrer">ae-2.r24.londen12.uk.bb.gin.ntt.net</a> (129.250.4.244)  181.952
      ms  183.087 ms  187.302 ms<br>
      10  <a href="http://ae-16.r20.frnkge13.de.bb.gin.ntt.net" target="_blank" rel="noreferrer">ae-16.r20.frnkge13.de.bb.gin.ntt.net</a> (129.250.3.13)  190.511
      ms  185.579 ms  187.058 ms<br>
      11  <a href="http://ae-3.r20.sngpsi07.sg.bb.gin.ntt.net" target="_blank" rel="noreferrer">ae-3.r20.sngpsi07.sg.bb.gin.ntt.net</a> (129.250.4.17)  520.882
      ms  613.982 ms  615.275 ms<br>
      12  <a href="http://ae-9.r24.tkokhk01.hk.bb.gin.ntt.net" target="_blank" rel="noreferrer">ae-9.r24.tkokhk01.hk.bb.gin.ntt.net</a> (129.250.7.67)  612.301
      ms  586.886 ms  436.711 ms<br>
      13  <a href="http://ae-1.r03.tkokhk01.hk.bb.gin.ntt.net" target="_blank" rel="noreferrer">ae-1.r03.tkokhk01.hk.bb.gin.ntt.net</a> (129.250.6.98)  614.470
      ms  613.416 ms  614.281 ms<br>
      14  <a href="http://ce-0-3-0-3.r03.tkokhk01.hk.ce.gin.ntt.net" target="_blank" rel="noreferrer">ce-0-3-0-3.r03.tkokhk01.hk.ce.gin.ntt.net</a> (203.131.241.126) 
      614.128 ms  613.661 ms  615.416 ms<br>
      15  * *     *<br>
      16  * * *<br>
      17  156.241.3.1 (156.241.3.1)  494.400 ms  410.180 ms *<br>
      MacBook-Pro-7:~ tinka$<br>
      <br>
      *****<br>
      <br>
      So we, then, realized that this was a fraudulent use of MacroLan's
      AS37353, to which we had given no express permission.<br>
      <br>
      As luck would have it, due to my days living and working in
      Malaysia, I know the good folk that operate AS134190 (IPDC
      Solutions), who was the upstream providing transit for this
      prefix. So I rang them up yesterday afternoon, told them what was
      happening, and within the hour, they got that eBGP session
      shutdown. I am most grateful to them for their quick response and
      immediate understanding of what was going on. Even with all the
      technology we have today, it, many times, comes down to having
      good friends in good places.<br>
      <br>
      Anyway, it turns out the ISP that had acquired this prefix from
      Cloud Innovation is based in Manila, Philippines. When IPDC
      delivered their transit service to them in Manila, that ISP
      informed them that they should use AS37353 for the eBGP session.
      Yes, one could argue that IPDC should have done their checks to
      ensure that the AS number being provided by their customer belongs
      to them, but to be honest, I'm not too bothered about that
      compared to Cloud Innovation's thinking that it was okay to use
      another network's AS number in order to deliver their services to
      their customers.<br>
      <br>
      IPDC confirm that this service was activated for the Manila ISP in
      December of 2019, right around the time Cloud Innovation's service
      with SEACOM, in Cape Town, ended.<br>
      <br>
      As it currently stands, the ISP in Manila is now off the Internet,
      with some 12 paying customers currently without service. Their
      excuse - they do not have an AS number of their own.<br>
      <br>
      IPDC tried to find out why the ISP in Manila thought that it was
      okay to use another network's AS number for their service, and as
      it turns out, the network engineer at the Manila ISP that set this
      up has since left the company. All the ones currently there do not
      have any history about all of this.<br>
      <br>
      Currently, <a href="http://156.241.3.0/24" target="_blank" rel="noreferrer">156.241.3.0/24</a> is not in the global BGP table:<br>
      <br>
      *****<br>
      <br>
      <a href="http://lg-01-ams.nl" target="_blank" rel="noreferrer">lg-01-ams.nl</a>>sh ip bgp <a href="http://156.241.3.0/24" target="_blank" rel="noreferrer">156.241.3.0/24</a><br>
      % Network not in table<br>
      <a href="http://lg-01-ams.nl" target="_blank" rel="noreferrer">lg-01-ams.nl</a>><br>
      <br>
      <a href="http://lg-01-nbo.ke" target="_blank" rel="noreferrer">lg-01-nbo.ke</a>>sh ip bgp <a href="http://156.241.3.0/24" target="_blank" rel="noreferrer">156.241.3.0/24</a><br>
      % Network not in table<br>
      <a href="http://lg-01-nbo.ke" target="_blank" rel="noreferrer">lg-01-nbo.ke</a>><br>
      <br>
      <a href="http://lg-01-cpt.za" target="_blank" rel="noreferrer">lg-01-cpt.za</a>>sh ip bgp <a href="http://156.241.3.0/24" target="_blank" rel="noreferrer">156.241.3.0/24</a><br>
      % Network not in table<br>
      <a href="http://lg-01-cpt.za" target="_blank" rel="noreferrer">lg-01-cpt.za</a>><br>
      <br>
      *****<br>
      <br>
      That Cloud Innovation thought it was okay for them to use
      MacroLan's AS number to originate their own prefixes into the
      global BGP is as morally reprehensible as it is technologically
      distasteful.<br>
      <br>
      SEACOM have been working very closely with AFRINIC to delete
      previous route objects from their IRR that certify a relationship
      between Cloud Innovation's parent /16 aggregates that cover this
      prefix, and AS37353, but this is one of those objects that cannot
      be removed via the MyAFRINIC portal, and requires manual
      intervention from AFRINIC.<br>
      <br>
      I have not, personally, spoken to the proprietors of Cloud
      Innovation and/or Outside Heaven, as I don't see how anything
      could explain this with any degree of justification.<br>
      <br>
      For now, I will find some beer to wipe the foul taste from my
      mouth, while we (SEACOM) consider what to do about this.<br>
      <br>
      And yes, for those who are wondering, RPKI's ROV would not have
      prevented this, in its current form. This is AS hijacking, and
      ROV, today, tries to solve the prefix-hijacking problem, first.<br>
      <br>
      Thank you for your attention.<br>
      <br>
      Mark.<br>
    </font>
  </div>

_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>--<br>Kind regards.<br>Lu<br><br></div></div></div>
</div>_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div>