<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Mark,<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 8 May 2020, at 16:06, Mark Tinka <<a href="mailto:mark.tinka@seacom.mu" class="">mark.tinka@seacom.mu</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  

    <meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
  
  <div class="">
    <font face="Tahoma" class="">Hi all.<br class="">
      <br class="">
      I'm not one to b**ch & moan in public, but per subject, I
      could not let this one slide.<br class="">
      <br class="">
      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 class=""></font></div></div></blockquote><div><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Thanks for brining this to the community attention + very detailed explanation where we all can learn from and prevent ourselves/networks we manage.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Specially now days where RPKI it’s an hot topic globally to prevent similar hijacks has the one being reported here.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><font face="Tahoma" class="">
      <br class="">
      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 class="">
      <br class="">
      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 class="">
      <br class="">
      In December of 2019, AS37353 ceased providing services to Cloud
      Innovation. That is 6 months ago.<br class="">
      <br class="">
      In recent days, it came to SEACOM's attention that some of Cloud
      Innovation's IP address space was being originated by AS37353 -
      specifically, 156.241.3.0/24 - 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 class="">
      <br class="">
      As of yesterday afternoon, see below what Telia's looking glass
      was saying about this prefix:<br class="">
      <br class="">
      *****<br class="">
      <br class="">
      Path #1: Received by speaker 0<br class="">
        4809 134190 37353<br class="">
          2.255.249.42 (metric 2134) from 2.255.253.101 (80.91.242.40)<br class="">
            Origin incomplete, localpref 200, valid, internal, best,
      group-best, import-candidate<br class="">
      Communities:<br class="">
      <br class="">
      1299:431<br class="">
          (RPKI state Unknown)<br class="">
      <br class="">
      1299:1000 1299:30000 1299:30600 23456:20413 45352:4500 45352:9204<br class="">
      <br class="">
      *****<br class="">
      <br class="">
      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 class="">
      <br class="">
      *****<br class="">
      <br class="">
      MacBook-Pro-7:~ tinka$ traceroute -I 156.241.3.1<br class="">
      traceroute to 156.241.3.1 (156.241.3.1), 64 hops max, 72 byte
      packets<br class="">
       1  172.16.0.254 (172.16.0.254)  14.824 ms  11.522 ms  3.525 ms<br class="">
       2  <a href="http://xe-1-3-0-1064.er-01-jnb.za.seacomnet.com" class="">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 class="">
       3  <a href="http://ce-0-2-0-0.cr-02-jnb.za.seacomnet.com" class="">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 class="">
       4  <a href="http://xe-0-0-0-8.cr-02-cpt.za.seacomnet.com" class="">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 class="">
       5  105.16.14.153 (105.16.14.153)  169.812 ms  171.272 ms  177.115
      ms<br class="">
       6  <a href="http://xe-0-0-0-0.br-02-lhr.uk.seacomnet.com" class="">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 class="">
       7  82.112.115.169 (82.112.115.169)  172.700 ms  176.482 ms 
      174.375 ms<br class="">
       8  ae-17.r05.londen12.<a href="http://uk.bb.gin.ntt.net" class="">uk.bb.gin.ntt.net</a> (129.250.2.147)  672.099
      ms  613.617 ms  615.109 ms<br class="">
       9  ae-2.r24.londen12.<a href="http://uk.bb.gin.ntt.net" class="">uk.bb.gin.ntt.net</a> (129.250.4.244)  181.952
      ms  183.087 ms  187.302 ms<br class="">
      10  ae-16.r20.frnkge13.<a href="http://de.bb.gin.ntt.net" class="">de.bb.gin.ntt.net</a> (129.250.3.13)  190.511
      ms  185.579 ms  187.058 ms<br class="">
      11  ae-3.r20.sngpsi07.<a href="http://sg.bb.gin.ntt.net" class="">sg.bb.gin.ntt.net</a> (129.250.4.17)  520.882
      ms  613.982 ms  615.275 ms<br class="">
      12  ae-9.r24.tkokhk01.<a href="http://hk.bb.gin.ntt.net" class="">hk.bb.gin.ntt.net</a> (129.250.7.67)  612.301
      ms  586.886 ms  436.711 ms<br class="">
      13  ae-1.r03.tkokhk01.<a href="http://hk.bb.gin.ntt.net" class="">hk.bb.gin.ntt.net</a> (129.250.6.98)  614.470
      ms  613.416 ms  614.281 ms<br class="">
      14  ce-0-3-0-3.r03.tkokhk01.<a href="http://hk.ce.gin.ntt.net" class="">hk.ce.gin.ntt.net</a> (203.131.241.126) 
      614.128 ms  613.661 ms  615.416 ms<br class="">
      15  * *     *<br class="">
      16  * * *<br class="">
      17  156.241.3.1 (156.241.3.1)  494.400 ms  410.180 ms *<br class="">
      MacBook-Pro-7:~ tinka$<br class="">
      <br class="">
      *****<br class="">
      <br class="">
      So we, then, realized that this was a fraudulent use of MacroLan's
      AS37353, to which we had given no express permission.<br class="">
      <br class="">
      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 class=""></font></div></div></blockquote><div><br class=""></div>Shout out to AS134190 who in that case shut the sessions down after your call. <br class=""><blockquote type="cite" class=""><div class=""><div class=""><font face="Tahoma" class="">
      <br class="">
      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 class="">
      <br class="">
      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 class="">
      <br class="">
      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 class="">
      <br class="">
      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 class="">
      <br class="">
      Currently, 156.241.3.0/24 is not in the global BGP table:<br class="">
      <br class="">
      *****<br class="">
      <br class="">
      <a href="http://lg-01-ams.nl" class="">lg-01-ams.nl</a>>sh ip bgp 156.241.3.0/24<br class="">
      % Network not in table<br class="">
      <a href="http://lg-01-ams.nl" class="">lg-01-ams.nl</a>><br class="">
      <br class="">
      lg-01-nbo.ke>sh ip bgp 156.241.3.0/24<br class="">
      % Network not in table<br class="">
      lg-01-nbo.ke><br class="">
      <br class="">
      <a href="http://lg-01-cpt.za" class="">lg-01-cpt.za</a>>sh ip bgp 156.241.3.0/24<br class="">
      % Network not in table<br class="">
      <a href="http://lg-01-cpt.za" class="">lg-01-cpt.za</a>><br class="">
      <br class="">
      *****<br class="">
      <br class="">
      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 class="">
      <br class="">
      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 class=""></font></div></div></blockquote><div><br class=""></div>Curiosity from side: Since MacroLan is now part of the SEACOM family why is it not possible to do that on MyAFRINIC portal? <br class=""><blockquote type="cite" class=""><div class=""><div class=""><font face="Tahoma" class="">
      <br class="">
      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 class="">
      <br class="">
      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 class="">
      <br class="">
      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 class=""></font></div></div></blockquote><div><br class=""></div>I will repeat myself here but, folks/colleagues on the mailing list - if you run a network you should start thinking in adopting those kind of mechanisms to prevent your prefixes to being hijacked - similar to what is being reported here by Mark. Obviously if your equipments support the mentioned mechanisms.</div><div><br class=""></div><div>Thing about it <br class=""><blockquote type="cite" class=""><div class=""><div class=""><font face="Tahoma" class="">
      <br class="">
      Thank you for your attention.<br class="">
      <br class="">
      Mark.<br class="">
    </font>
  </div>

_______________________________________________<br class="">afnog mailing list<br class=""><a href="https://www.afnog.org/mailman/listinfo/afnog" class="">https://www.afnog.org/mailman/listinfo/afnog</a></div></blockquote></div><br class=""></div></body></html>