[zanog-discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship

Ronald Bartels ronald at amastelek.com
Sat May 9 12:58:33 SAST 2020


Did you find some beer?



*From:* zanog-discuss <zanog-discuss-bounces at lists.nog.net.za> *On Behalf
Of *Mark Tinka via zanog-discuss
*Sent:* Friday, 08 May 2020 16:09
*To:* ZANog discuss (zanog-discuss at lists.nog.net.za) <
zanog-discuss at lists.nog.net.za>
*Subject:* [zanog-discuss] Cloud Innovation Displays Very Poor, If Not
Criminal, Netizenship



Hi all.

I'm not one to b**ch & moan in public, but per subject, I could not let
this one slide.

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.

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.

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.

In December of 2019, AS37353 ceased providing services to Cloud Innovation.
That is 6 months ago.

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.

As of yesterday afternoon, see below what Telia's looking glass was saying
about this prefix:

*****

Path #1: Received by speaker 0
  4809 134190 37353
    2.255.249.42 (metric 2134) from 2.255.253.101 (80.91.242.40)
      Origin incomplete, localpref 200, valid, internal, best, group-best,
import-candidate
Communities:

1299:431
    (RPKI state Unknown)

1299:1000 1299:30000 1299:30600 23456:20413 45352:4500 45352:9204

*****

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:

*****

MacBook-Pro-7:~ tinka$ traceroute -I 156.241.3.1
traceroute to 156.241.3.1 (156.241.3.1), 64 hops max, 72 byte packets
 1  172.16.0.254 (172.16.0.254)  14.824 ms  11.522 ms  3.525 ms
 2  xe-1-3-0-1064.er-01-jnb.za.seacomnet.com (105.22.37.13)  5.620 ms
9.714 ms  9.887 ms
 3  ce-0-2-0-0.cr-02-jnb.za.seacomnet.com (105.16.28.2)  175.232 ms
172.699 ms  175.896 ms
 4  xe-0-0-0-8.cr-02-cpt.za.seacomnet.com (105.16.9.182)  164.496 ms
163.578 ms  163.546 ms
 5  105.16.14.153 (105.16.14.153)  169.812 ms  171.272 ms  177.115 ms
 6  xe-0-0-0-0.br-02-lhr.uk.seacomnet.com (105.16.34.253)  168.911 ms
172.958 ms  165.165 ms
 7  82.112.115.169 (82.112.115.169)  172.700 ms  176.482 ms  174.375 ms
 8  ae-17.r05.londen12.uk.bb.gin.ntt.net (129.250.2.147)  672.099 ms
613.617 ms  615.109 ms
 9  ae-2.r24.londen12.uk.bb.gin.ntt.net (129.250.4.244)  181.952 ms
183.087 ms  187.302 ms
10  ae-16.r20.frnkge13.de.bb.gin.ntt.net (129.250.3.13)  190.511 ms
185.579 ms  187.058 ms
11  ae-3.r20.sngpsi07.sg.bb.gin.ntt.net (129.250.4.17)  520.882 ms  613.982
ms  615.275 ms
12  ae-9.r24.tkokhk01.hk.bb.gin.ntt.net (129.250.7.67)  612.301 ms  586.886
ms  436.711 ms
13  ae-1.r03.tkokhk01.hk.bb.gin.ntt.net (129.250.6.98)  614.470 ms  613.416
ms  614.281 ms
14  ce-0-3-0-3.r03.tkokhk01.hk.ce.gin.ntt.net (203.131.241.126)  614.128
ms  613.661 ms  615.416 ms
15  * *     *
16  * * *
17  156.241.3.1 (156.241.3.1)  494.400 ms  410.180 ms *
MacBook-Pro-7:~ tinka$

*****

So we, then, realized that this was a fraudulent use of MacroLan's AS37353,
to which we had given no express permission.

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.

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.

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.

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.

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.

Currently, 156.241.3.0/24 is not in the global BGP table:

*****

lg-01-ams.nl>sh ip bgp 156.241.3.0/24
% Network not in table
lg-01-ams.nl>

lg-01-nbo.ke>sh ip bgp 156.241.3.0/24
% Network not in table
lg-01-nbo.ke>

lg-01-cpt.za>sh ip bgp 156.241.3.0/24
% Network not in table
lg-01-cpt.za>

*****

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.

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.

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.

For now, I will find some beer to wipe the foul taste from my mouth, while
we (SEACOM) consider what to do about this.

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.

Thank you for your attention.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nog.net.za/pipermail/zanog-discuss/attachments/20200509/d1be02cd/attachment.html>


More information about the zanog-discuss mailing list