<div dir="ltr"><div dir="ltr"><p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">I feel this
is gradually brewing up and steering up an unnecessary tension within the
community.</span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">I took time
to go through the trail, the post shared by the CEO of Cloud Innovation contained a
email by IPDC in which they have already openly apologized for their mistake(s).</span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">On the
other hand, heaping all blame on Cloud Innovation isn’t totally logical. </span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">From my
understanding, IPDC hijacked SEACOM’s ASN, IPDC being Cloud Innovation’s
customer. However, I don’t clearly see what role it plays in the whole process.
Predict ing it’s customer’s behaviour is scarcely possible, hardly any company can. Also is the company in the position/business to care of it per se, and without
violation of privacy?</span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">A typical example
is a Kitchenware store; If the store sells a knife to an individual, and the individual uses the same knife to commit a crime, would the hardware store also be held partly
accountable for the crime? </span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Thus, whatever
the problem is IPDC should settle its differences directly with SEACOM</span></p><p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"><br></span></p><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><p style="line-height:150%"><b style="line-height:150%;font-size:12.8px"><span style="line-height:150%"><font face="garamond, serif">Best Regards,</font></span></b></p><p style="line-height:150%"><font face="garamond, serif"><b style="line-height:150%;font-size:12.8px"><span style="line-height:150%">Anthony</span></b></font></p><p style="text-align:left"><font size="2" color="#999999" face="garamond, serif"><span style="line-height:150%;background-color:white">E-mail: <a href="mailto:anthony.ubah@gloworld.com" target="_blank">anthony.ubah@goldspine.com</a>.ng<br></span></font></p></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 26, 2020 at 12:01 AM <<a href="mailto:rpd-request@afrinic.net">rpd-request@afrinic.net</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">Send RPD mailing list submissions to<br>
<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:rpd-request@afrinic.net" target="_blank">rpd-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:rpd-owner@afrinic.net" target="_blank">rpd-owner@afrinic.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of RPD digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Cloud Innovation Displays Very Poor, If Not Criminal,<br>
Netizenship (Arnaud AMELINA)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 25 May 2020 23:00:43 +0000<br>
From: Arnaud AMELINA <<a href="mailto:amelnaud@gmail.com" target="_blank">amelnaud@gmail.com</a>><br>
To: Paschal Ochang <<a href="mailto:pascosoft@gmail.com" target="_blank">pascosoft@gmail.com</a>><br>
Cc: General Discussions of AFRINIC <<a href="mailto:community-discuss@afrinic.net" target="_blank">community-discuss@afrinic.net</a>>,<br>
"rpd >> AfriNIC Resource Policy" <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><br>
Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not<br>
Criminal, Netizenship<br>
Message-ID:<br>
<CAGDMR_dmscN4ndR9_xPhpk=<a href="mailto:qjSL5yDjDZFZ1y-PXVE6z1y41RA@mail.gmail.com" target="_blank">qjSL5yDjDZFZ1y-PXVE6z1y41RA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Paschal,<br>
<br>
Please explain why it?s a personal attack when no person was mentioned?<br>
<br>
Please be enlightened that the topic under discussion is allowed because<br>
its application of policy with implications.<br>
<br>
FWIW, Cloud Innovation Ltd, rendering an apology does not make the problem<br>
go away and the working group has to solve the real problem at hand<br>
<br>
Let us be aware that, the way internet deals with bad netizens may cause<br>
damage to parents and even to the whole region if nothing is done to stop<br>
it<br>
<br>
--<br>
Arnaud<br>
<br>
Le lun. 25 mai 2020 ? 11:30, Paschal Ochang <<a href="mailto:pascosoft@gmail.com" target="_blank">pascosoft@gmail.com</a>> a ?crit :<br>
<br>
> This sounds like a personal attack in my opinion instead of a justified<br>
> accusation. Why is this topic allowed to be discussed here when it?s rather<br>
> irrelevant?. The parties involved have tendered formal apologies as<br>
> reflected in their letters which is a sign of admittance and promotes the<br>
> intent of good netizenship. It?s just irrelevant.<br>
><br>
> On Monday, May 25, 2020, Arnaud AMELINA <<a href="mailto:amelnaud@gmail.com" target="_blank">amelnaud@gmail.com</a>> wrote:<br>
><br>
>> Hello, community<br>
>><br>
>> +1 @Gregoire and @Mark Tinka<br>
>><br>
>> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR*<br>
>> with *no ASN*. Interesting, and no *v6*<br>
>><br>
>> While the bylaws defines LIR as followed:<br>
>> ++++++<br>
>> Local Internet Registry (LIR):<br>
>> any Network Operator that provides Internet services to distinct<br>
>> end-users and end-sites<br>
>> ++++++<br>
>><br>
>> I wonder which network does cloud innovation operate and which internet<br>
>> services it provides to end-users and end-sites in *Africa*.<br>
>><br>
>> How does this network *managing 3 x /11 of IPv4* *operate*?<br>
>><br>
>> There is something here for the community to learn about.<br>
>><br>
>> Regards<br>
>><br>
>> --<br>
>> Arnaud<br>
>><br>
>> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD <<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>> a<br>
>> ?crit :<br>
>><br>
>>> Hello,<br>
>>><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<br>
>>> response including their attachments as justifications.<br>
>>><br>
>>> I note that;<br>
>>><br>
>>> ? the service contract with Cloud Innovation covering the announcement<br>
>>> 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<br>
>>> 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<br>
>>> using SEACOM's AS37353 as the ASN of the Manila customer.<br>
>>><br>
>>> ? there was a prompt reaction from the involved parties that included<br>
>>> apologies to SEACOM and the wider internet community.<br>
>>><br>
>>> ? there were promises from said parties to be a better netizen which<br>
>>> would mean, them not hijacking other networks ASN's.<br>
>>><br>
>>> ? there was clear refusal to disclose the details of the customer in<br>
>>> Manila Philippines who hijacked the affected SEACOM ASN.<br>
>>><br>
>>> All put together, demonstrates that what happened was an impersonation<br>
>>> and not a BGP configuration error, nor an oversight in checking the right<br>
>>> to use of the SEACOM ASN.<br>
>>><br>
>>> 1. Why is it that the real customer did not bother presenting its<br>
>>> 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<br>
>>> 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<br>
>>> citizens.!<br>
>>><br>
>>> Best regards<br>
>>> Gregoire Ehoumi<br>
>>><br>
>>><br>
>>> -------- Original message --------<br>
>>> From: Lu Heng <<a href="mailto:h.lu@anytimechinese.com" target="_blank">h.lu@anytimechinese.com</a>><br>
>>> Date: 2020-05-09 5:43 a.m. (GMT-05:00)<br>
>>> To: Mark Tinka <<a href="mailto:mark.tinka@seacom.mu" target="_blank">mark.tinka@seacom.mu</a>><br>
>>> Cc: "<a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a> >> AfriNIC Resource Policy Discussion List" <<br>
>>> <a href="mailto:rpd@afrinic.net" target="_blank">rpd@afrinic.net</a>><br>
>>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal,<br>
>>> Netizenship<br>
>>><br>
>>> To whom it may concern,<br>
>>><br>
>>> On May 8, Mark Think posted a claim to multiple lists that Cloud<br>
>>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud<br>
>>> Innovation) but rather belonged to Seacom through their acquisition of<br>
>>> MacroLAN.<br>
>>><br>
>>> While we regret this unfortunate incident, Mark?s claims that it was<br>
>>> criminal or bad netizenship on the part of Cloud Innovation is without<br>
>>> foundation and utterly incorrect.<br>
>>><br>
>>> As shown below in the attached document from Paul Wollner(Ex-CTO of<br>
>>> Macrolan who created IRR routes to allow Macrolan to announce Cloud<br>
>>> Innovation's prefix); letter from Link Infinity International Ltd. (Link<br>
>>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS<br>
>>> authorizing IPDC Solutions to announce the prefix with origin AS134190.<br>
>>> And a Letter from IPDC. This was an innocent mistake committed by third<br>
>>> parties and had nothing to do with any action by Cloud Innovation or LARUS.<br>
>>><br>
>>> Here?s what happened:<br>
>>><br>
>>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December<br>
>>> 2019.<br>
>>><br>
>>><br>
>>> Link Infinity further delegated that same /24 to IPDC and asked Cloud<br>
>>> innovation to issue an LOA, which we did. The LOA specifically required<br>
>>> IPDC to use its own ASN to announce the space (AS134190).<br>
>>><br>
>>> IPDC subsequently authorized one of its customers to use the said prefix.<br>
>>><br>
>>><br>
>>> For reasons still unknown to Cloud Innovation, IPDC and their customer<br>
>>> set up a BGP session wherein their customer used AS37353 as the origin to<br>
>>> advertise prefix <a href="http://156.241.3.0/24" rel="noreferrer" target="_blank">156.241.3.0/24</a>.<br>
>>><br>
>>><br>
>>> Upon discovering the announcement, rather than contact Cloud Innovation,<br>
>>> Mark contacted IPDC who provided him with an incomplete explanation blaming<br>
>>> their customer and Mark, not realizing that Cloud Innovation was not the<br>
>>> customer in question posted far and wide about the event. It is unclear to<br>
>>> us why he chose to do this rather than contact us to try and resolve the<br>
>>> issue.<br>
>>><br>
>>><br>
>>> A contributing factor to the erroneous BGP configuration by IPDC's<br>
>>> customer may have been data contained in some outdated IRR route objects<br>
>>> for <a href="http://156.241.0.0/16" rel="noreferrer" target="_blank">156.241.0.0/16</a> which have subsequently been deleted.<br>
>>><br>
>>> As soon as we became aware of the problem (via Mark?s email), we began<br>
>>> to investigate the situation. As soon as it was clear that this was the<br>
>>> result of third-party actions, we reached out to Mark privately to let him<br>
>>> know what we knew and that we were still investigating. We delayed making a<br>
>>> public statement in order to try and ascertain all of the facts of the<br>
>>> situation. We prefer not to make public statements based on incomplete<br>
>>> information.<br>
>>><br>
>>> We apologize to the community for our small part in this unfortunate<br>
>>> incident and assure you that we work very hard to remain good netizens and<br>
>>> will address any concerns promptly when they come to our attention.<br>
>>><br>
>>><br>
>>> Sincerely,<br>
>>><br>
>>> Lu Heng<br>
>>> CEO<br>
>>> Cloud Innovations<br>
>>><br>
>>> Attached:<br>
>>> 1. Letter from Paul Wollner<br>
>>> 2. Letter from Link Infinity<br>
>>> 3. LOA Issued to IPDC Solutions for announcing <a href="http://156.241.3.0/24" rel="noreferrer" target="_blank">156.241.3.0/24</a> from<br>
>>> AS134190<br>
>>> 4. Letter from IPDC<br>
>>><br>
>>> FYI: LARUS is proving IP management service for Cloud Innovation, while<br>
>>> LARUS is also providing IP management service to other third parties in all<br>
>>> regions, for full disclosure, LARUS and Cloud Innovation are headed by same<br>
>>> CEO.<br>
>>><br>
>>> Content of those letters have been posted here for your convince:<br>
>>><br>
>>> *IPDC:*<br>
>>><br>
>>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd]<br>
>>><br>
>>><br>
>>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and<br>
>>> over the course of our corporate relationship we were given the authority<br>
>>> to use address block <a href="http://156.241.3.0/24" rel="noreferrer" target="_blank">156.241.3.0/24</a> since 9th December 2019.<br>
>>><br>
>>><br>
>>> On 12th December 2019, we have delegated that address block to our<br>
>>> client. Following which our client further instructed us to announce the<br>
>>> prefix with AS37353. In good will after minimal verification through WHOIS?<br>
>>> IP Prefix we have proceeded to execute our client?s request.<br>
>>><br>
>>><br>
>>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder<br>
>>> of record for that ASN and have since learned that the customer?s use of<br>
>>> that ASN was erroneous and not permitted by SEACOM and immediate action has<br>
>>> been taken to rectify this situation.<br>
>>><br>
>>><br>
>>> IPDC would like to apologize for our lack of attention in conducting<br>
>>> thorough verification and wish to highlight that the involvement of Cloud<br>
>>> Innovation Ltd in the entire process was providing the addresses to us and<br>
>>> that we truly apologize as we understand that this incident may have<br>
>>> indirectly implicated Cloud Innovation Ltd.<br>
>>><br>
>>><br>
>>> IPDC however, does not wish to disclose our client information and our<br>
>>> client information shall remain confidential under present circumstances.<br>
>>> Once again, we apologize for our shortcomings.<br>
>>><br>
>>><br>
>>> *Link Infinity:*<br>
>>><br>
>>><br>
>>> To whom it may concern,<br>
>>><br>
>>> We at HK Infinity International Ltd are a customer of Cloud Innovation<br>
>>> and in the course received rights to use <a href="http://156.241.3.0/24" rel="noreferrer" target="_blank">156.241.3.0/24</a> from them.<br>
>>> Beginning December, 2019, we delegated the right to announce this prefix to<br>
>>> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA<br>
>>> authorizing them to announce the space which was subsequently received.<br>
>>> IPDC subsequently and without our knowledge delegated this space to one of<br>
>>> 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<br>
>>> LOA provided by Cloud Innovation.<br>
>>><br>
>>> Unfortunately, we were not aware of the situation until after it had<br>
>>> already been resolved.<br>
>>><br>
>>> It was never our intent to violate the LOA or to allow the prefix to be<br>
>>> announced from a hijacked ASN. We do not condone this and apologize<br>
>>> sincerely to the community for what has happened here.<br>
>>><br>
>>> Sincere Apologies,<br>
>>><br>
>>><br>
>>> *Paul Wollner:*<br>
>>><br>
>>><br>
>>> 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<br>
>>> like to clear the air.<br>
>>><br>
>>><br>
>>> The IP route objects were created by myself for Cloud Innovation when<br>
>>> they signed up as a client of Macrolan ( now SEACOM) as they didn't have<br>
>>> their own AS.<br>
>>><br>
>>> At the time I was working for Macrolan (now SEACOM). I left the<br>
>>> employment of SEACOM in October 2019.<br>
>>><br>
>>> It appears that when Cloud Innovation's contract with SEACOM came to an<br>
>>> end, the route objects were never cleaned up.<br>
>>><br>
>>> This occurred after I left SEACOM's employment. Since leaving, I have no<br>
>>> access to these objects.<br>
>>><br>
>>> Regards<br>
>>><br>
>>> Paul Wollner<br>
>>> 082-786-9776<br>
>>><br>
>>><br>
>>><br>
>>> On Fri, 8 May 2020 at 22:10, Mark Tinka <<a href="mailto:mark.tinka@seacom.mu" target="_blank">mark.tinka@seacom.mu</a>> wrote:<br>
>>><br>
>>>> Hi all.<br>
>>>><br>
>>>> I'm not one to b**ch & moan in public, but per subject, I could not let<br>
>>>> this one slide.<br>
>>>><br>
>>>> And if you get this from multiple mailing lists, apologies for that -<br>
>>>> I'm just trying to make sure that this reaches as wide an audience as<br>
>>>> possible, on the continent.<br>
>>>><br>
>>>> SEACOM (AS37100) acquired MacroLan (AS37353) a couple of years ago.<br>
>>>> MacroLan is now part of the SEACOM family, and while we are in the process<br>
>>>> of integrating that network into AS37100, some existing services continue<br>
>>>> to be delivered on AS37353 until that exercise is completed.<br>
>>>><br>
>>>> One of the customers that AS37353 was providing services to was Cloud<br>
>>>> Innovation, in Cape Town. From a routing perspective, because Cloud<br>
>>>> Innovation had no AS number for this service, all of their IP address space<br>
>>>> was being originated by AS37353, on their behalf.<br>
>>>><br>
>>>> In December of 2019, AS37353 ceased providing services to Cloud<br>
>>>> Innovation. That is 6 months ago.<br>
>>>><br>
>>>> In recent days, it came to SEACOM's attention that some of Cloud<br>
>>>> Innovation's IP address space was being originated by AS37353 -<br>
>>>> specifically, <a href="http://156.241.3.0/24" rel="noreferrer" target="_blank">156.241.3.0/24</a> - even though we were sure that they were<br>
>>>> no longer a customer of AS37353 since December of 2019. At first, we<br>
>>>> thought this was a cached entry in a number of popular looking glasses, but<br>
>>>> then every looking glass had the same entry, which made this an unlikely<br>
>>>> bug.<br>
>>>><br>
>>>> As of yesterday afternoon, see below what Telia's looking glass was<br>
>>>> 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,<br>
>>>> 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<br>
>>>> 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" rel="noreferrer" target="_blank">xe-1-3-0-1064.er-01-jnb.za.seacomnet.com</a> (105.22.37.13) 5.620 ms<br>
>>>> 9.714 ms 9.887 ms<br>
>>>> 3 <a href="http://ce-0-2-0-0.cr-02-jnb.za.seacomnet.com" rel="noreferrer" target="_blank">ce-0-2-0-0.cr-02-jnb.za.seacomnet.com</a> (105.16.28.2) 175.232 ms<br>
>>>> 172.699 ms 175.896 ms<br>
>>>> 4 <a href="http://xe-0-0-0-8.cr-02-cpt.za.seacomnet.com" rel="noreferrer" target="_blank">xe-0-0-0-8.cr-02-cpt.za.seacomnet.com</a> (105.16.9.182) 164.496 ms<br>
>>>> 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" rel="noreferrer" target="_blank">xe-0-0-0-0.br-02-lhr.uk.seacomnet.com</a> (105.16.34.253) 168.911 ms<br>
>>>> 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" rel="noreferrer" target="_blank">ae-17.r05.londen12.uk.bb.gin.ntt.net</a> (129.250.2.147) 672.099 ms<br>
>>>> 613.617 ms 615.109 ms<br>
>>>> 9 <a href="http://ae-2.r24.londen12.uk.bb.gin.ntt.net" rel="noreferrer" target="_blank">ae-2.r24.londen12.uk.bb.gin.ntt.net</a> (129.250.4.244) 181.952 ms<br>
>>>> 183.087 ms 187.302 ms<br>
>>>> 10 <a href="http://ae-16.r20.frnkge13.de.bb.gin.ntt.net" rel="noreferrer" target="_blank">ae-16.r20.frnkge13.de.bb.gin.ntt.net</a> (129.250.3.13) 190.511 ms<br>
>>>> 185.579 ms 187.058 ms<br>
>>>> 11 <a href="http://ae-3.r20.sngpsi07.sg.bb.gin.ntt.net" rel="noreferrer" target="_blank">ae-3.r20.sngpsi07.sg.bb.gin.ntt.net</a> (129.250.4.17) 520.882 ms<br>
>>>> 613.982 ms 615.275 ms<br>
>>>> 12 <a href="http://ae-9.r24.tkokhk01.hk.bb.gin.ntt.net" rel="noreferrer" target="_blank">ae-9.r24.tkokhk01.hk.bb.gin.ntt.net</a> (129.250.7.67) 612.301 ms<br>
>>>> 586.886 ms 436.711 ms<br>
>>>> 13 <a href="http://ae-1.r03.tkokhk01.hk.bb.gin.ntt.net" rel="noreferrer" target="_blank">ae-1.r03.tkokhk01.hk.bb.gin.ntt.net</a> (129.250.6.98) 614.470 ms<br>
>>>> 613.416 ms 614.281 ms<br>
>>>> 14 <a href="http://ce-0-3-0-3.r03.tkokhk01.hk.ce.gin.ntt.net" rel="noreferrer" target="_blank">ce-0-3-0-3.r03.tkokhk01.hk.ce.gin.ntt.net</a> (203.131.241.126)<br>
>>>> 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<br>
>>>> 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<br>
>>>> know the good folk that operate AS134190 (IPDC Solutions), who was the<br>
>>>> upstream providing transit for this prefix. So I rang them up yesterday<br>
>>>> afternoon, told them what was happening, and within the hour, they got that<br>
>>>> eBGP session shutdown. I am most grateful to them for their quick response<br>
>>>> and immediate understanding of what was going on. Even with all the<br>
>>>> technology we have today, it, many times, comes down to having good friends<br>
>>>> in good places.<br>
>>>><br>
>>>> Anyway, it turns out the ISP that had acquired this prefix from Cloud<br>
>>>> Innovation is based in Manila, Philippines. When IPDC delivered their<br>
>>>> transit service to them in Manila, that ISP informed them that they should<br>
>>>> use AS37353 for the eBGP session. Yes, one could argue that IPDC should<br>
>>>> have done their checks to ensure that the AS number being provided by their<br>
>>>> customer belongs to them, but to be honest, I'm not too bothered about that<br>
>>>> compared to Cloud Innovation's thinking that it was okay to use another<br>
>>>> 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<br>
>>>> December of 2019, right around the time Cloud Innovation's service with<br>
>>>> SEACOM, in Cape Town, ended.<br>
>>>><br>
>>>> As it currently stands, the ISP in Manila is now off the Internet, with<br>
>>>> some 12 paying customers currently without service. Their excuse - they do<br>
>>>> 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<br>
>>>> to use another network's AS number for their service, and as it turns out,<br>
>>>> the network engineer at the Manila ISP that set this up has since left the<br>
>>>> company. All the ones currently there do not have any history about all of<br>
>>>> this.<br>
>>>><br>
>>>> Currently, <a href="http://156.241.3.0/24" rel="noreferrer" target="_blank">156.241.3.0/24</a> is not in the global BGP table:<br>
>>>><br>
>>>> *****<br>
>>>><br>
>>>> <a href="http://lg-01-ams.nl" rel="noreferrer" target="_blank">lg-01-ams.nl</a>>sh ip bgp <a href="http://156.241.3.0/24" rel="noreferrer" target="_blank">156.241.3.0/24</a><br>
>>>> % Network not in table<br>
>>>> <a href="http://lg-01-ams.nl" rel="noreferrer" target="_blank">lg-01-ams.nl</a>><br>
>>>><br>
>>>> <a href="http://lg-01-nbo.ke" rel="noreferrer" target="_blank">lg-01-nbo.ke</a>>sh ip bgp <a href="http://156.241.3.0/24" rel="noreferrer" target="_blank">156.241.3.0/24</a><br>
>>>> % Network not in table<br>
>>>> <a href="http://lg-01-nbo.ke" rel="noreferrer" target="_blank">lg-01-nbo.ke</a>><br>
>>>><br>
>>>> <a href="http://lg-01-cpt.za" rel="noreferrer" target="_blank">lg-01-cpt.za</a>>sh ip bgp <a href="http://156.241.3.0/24" rel="noreferrer" target="_blank">156.241.3.0/24</a><br>
>>>> % Network not in table<br>
>>>> <a href="http://lg-01-cpt.za" rel="noreferrer" target="_blank">lg-01-cpt.za</a>><br>
>>>><br>
>>>> *****<br>
>>>><br>
>>>> That Cloud Innovation thought it was okay for them to use MacroLan's AS<br>
>>>> number to originate their own prefixes into the global BGP is as morally<br>
>>>> reprehensible as it is technologically distasteful.<br>
>>>><br>
>>>> SEACOM have been working very closely with AFRINIC to delete previous<br>
>>>> route objects from their IRR that certify a relationship between Cloud<br>
>>>> Innovation's parent /16 aggregates that cover this prefix, and AS37353, but<br>
>>>> this is one of those objects that cannot be removed via the MyAFRINIC<br>
>>>> portal, and requires manual intervention from AFRINIC.<br>
>>>><br>
>>>> I have not, personally, spoken to the proprietors of Cloud Innovation<br>
>>>> and/or Outside Heaven, as I don't see how anything could explain this with<br>
>>>> any degree of justification.<br>
>>>><br>
>>>> For now, I will find some beer to wipe the foul taste from my mouth,<br>
>>>> while we (SEACOM) consider what to do about this.<br>
>>>><br>
>>>> And yes, for those who are wondering, RPKI's ROV would not have<br>
>>>> prevented this, in its current form. This is AS hijacking, and ROV, today,<br>
>>>> tries to solve the prefix-hijacking problem, first.<br>
>>>><br>
>>>> Thank you for your attention.<br>
>>>><br>
>>>> Mark.<br>
>>>> _______________________________________________<br>
>>>> RPD mailing list<br>
>>>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
>>>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>>>><br>
>>><br>
>>><br>
>>> --<br>
>>> --<br>
>>> Kind regards.<br>
>>> Lu<br>
>>><br>
>>> _______________________________________________<br>
>>> RPD mailing list<br>
>>> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
>>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>>><br>
>> _______________________________________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20200525/1ba40a18/attachment.html" rel="noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20200525/1ba40a18/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
------------------------------<br>
<br>
End of RPD Digest, Vol 164, Issue 26<br>
************************************<br>
</blockquote></div></div>