<div dir="auto"><div><div dir="auto">Hi Paul, </div><div dir="auto"><br></div><div dir="auto">This echos my previous post. It beams light on the grey areas. </div><div dir="auto"> </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 dir="auto">From whatever perspective the onus is on SEACOM and IPDC.</div><div dir="auto"><br></div><div dir="auto">Truely, raising certain topics with giving full details opens widows for personal confrontations and bone picking. We learn from everything, but sometimes it brings the question "who really benefits from the debate?" As opportunists seize their chance to attack individuals, and not issues. </div><br>Kind regards, </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Anthony </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, May 29, 2020, 09:07 <<a href="mailto:community-discuss-request@afrinic.net">community-discuss-request@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Community-Discuss mailing list submissions to<br>
<a href="mailto:community-discuss@afrinic.net" target="_blank" rel="noreferrer">community-discuss@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo/community-discuss" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/community-discuss</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:community-discuss-request@afrinic.net" target="_blank" rel="noreferrer">community-discuss-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:community-discuss-owner@afrinic.net" target="_blank" rel="noreferrer">community-discuss-owner@afrinic.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Community-Discuss digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Cloud Innovation Displays Very Poor, If Not Criminal,<br>
Netizenship (Paul Wollner)<br>
2. Re: Cloud Innovation Displays Very Poor, If Not Criminal,<br>
Netizenship (Arnaud AMELINA)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 29 May 2020 05:17:41 +0200<br>
From: Paul Wollner <<a href="mailto:paulw@wollner.za.net" target="_blank" rel="noreferrer">paulw@wollner.za.net</a>><br>
To: Owen DeLong <<a href="mailto:owen@delong.com" target="_blank" rel="noreferrer">owen@delong.com</a>><br>
Cc: General Discussions of AFRINIC <<a href="mailto:community-discuss@afrinic.net" target="_blank" rel="noreferrer">community-discuss@afrinic.net</a>>,<br>
"rpd >> AfriNIC Resource Policy" <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor,<br>
If Not Criminal, Netizenship<br>
Message-ID:<br>
<CAHovqF202Hd009C6OB5F+1C-pdYJ9NMcA4m2YRTUeM=<a href="mailto:D0WUwLg@mail.gmail.com" target="_blank" rel="noreferrer">D0WUwLg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I have been watching this thread and I feel that I should respond as it was<br>
I that created the route objects in<br>
AFRINIC and RIPE on behalf of Cloud Innovation.<br>
<br>
In light of the accusations that have been made on 8 May, I feel that<br>
SEACOM neglected their duty to remove these objects when the client's<br>
contract came to an end. As the ISP created the records in the first place,<br>
the records should have been updated or deleted by them too. This shows<br>
poor corporate governance by SEACOM and it is ironic that their own<br>
employee in charge of these duties wished to make this public in an attempt<br>
to place blame elsewhere whilst the incompetence lies largely, if not<br>
solely, with SEACOM.<br>
<br>
I was the person who created the objects in the respective databases,<br>
however I was no longer in the employment of SEACOM when Cloud Innovation's<br>
contract came to an end and hence no longer had rights to the route objects.<br>
<br>
It is now almost a month later and the amount of resources wasted on<br>
dealing with this issue when it could have been resolved quickly and safely<br>
by the relevant parties is astounding and personally quite unsettling. This<br>
matter should be put to rest now. As a global community we are dealing with<br>
far bigger issues and we should be putting our efforts towards the greater<br>
good, not petty infighting fueled by drama and misinformation.<br>
<br>
<br>
<br>
On Fri, May 29, 2020 at 3:00 AM Owen DeLong <<a href="mailto:owen@delong.com" target="_blank" rel="noreferrer">owen@delong.com</a>> wrote:<br>
<br>
> Arnaud,<br>
><br>
> You are mistaken on a number of points.<br>
><br>
><br>
> On May 28, 2020, at 13:05 , Arnaud AMELINA <<a href="mailto:amelnaud@gmail.com" target="_blank" rel="noreferrer">amelnaud@gmail.com</a>> wrote:<br>
><br>
> Hi, all communities<br>
><br>
> It was said that the hijacking of AS37353 was a configuration mistake,<br>
> coupled with poor oversight in checking the right to use of the ASN by a<br>
> certain IPDC customer.<br>
><br>
> It was also said that this would have been facilitated by old and stalled<br>
> IRR objects from MacroLAN before the service contract ended in December<br>
> 2019.<br>
><br>
> It was also stated that the BGP announcement was stopped and some actions<br>
> taken to delete the stalled routing registry object from IRR.<br>
><br>
><br>
> Yes? The registry objects created by MacroLAN have been deleted.<br>
><br>
> Below are some data which gives some extra information and confirm<br>
> previous claim that this incident was not accidental.<br>
><br>
><br>
> Below is some very redacted data which gives virtually no information.<br>
><br>
> NB: All data are collected from their source, Today, 28 May 2020, at 10:00<br>
> UTC.<br>
><br>
> IRRs created in March 2020 with AS37353 as Origin for <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a> by<br>
> HGC<br>
><br>
> $ 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>
><br>
> 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<br>
> origin: AS37353 notify: <a href="mailto:matthew.chan@hgc.com.hk" target="_blank" rel="noreferrer">matthew.chan@hgc.com.hk</a> mnt-by:<br>
> MAINT-HGC-INTL changed: <a href="mailto:matthew.chan@hgc.com.hk" target="_blank" rel="noreferrer">matthew.chan@hgc.com.hk</a> 20200304 source:<br>
> RADB<br>
><br>
> =====<br>
> route: <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> descr: Proxy-registered route object origin: AS37353<br>
> remarks: This is a HGC customer route-object<br>
> remarks: which is being exported under this origin AS.<br>
> remarks:<br>
> remarks: This route object was created because no existing<br>
> remarks: route object with the same origin was found.<br>
> remarks:<br>
> remarks: Please contact <a href="mailto:radb@hutchcity.com" target="_blank" rel="noreferrer">radb@hutchcity.com</a> if you have any<br>
> remarks: questions regarding this object.<br>
> notify: <a href="mailto:radb@hutchcity.com" target="_blank" rel="noreferrer">radb@hutchcity.com</a><br>
> mnt-by: MAINT-AS9304<br>
> changed: <a href="mailto:radb@hutchcity.com" target="_blank" rel="noreferrer">radb@hutchcity.com</a> 20200304<br>
> source: NTTCOM<br>
> ====<br>
><br>
><br>
> We haven changed anything, but here?s the full text of that whois command:<br>
> owen (121) ~ % 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>
> 2020/05/28 16:58:50<br>
> route: <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> origin: AS138145<br>
> descr: Customer-AS45250<br>
> admin-c: MAINT-AS138145<br>
> tech-c: MAINT-AS138145<br>
> mnt-by: MAINT-AS138145<br>
> changed: admin@cloudix.online 20200512 #18:26:20Z<br>
> source: RADB<br>
><br>
> route: <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> origin: AS134190<br>
> descr: IPDC Solution PteLtd<br>
> mnt-by: MAINT-LARUS<br>
> changed: <a href="mailto:t.t.xu@laruscloudservice.net" target="_blank" rel="noreferrer">t.t.xu@laruscloudservice.net</a> 20200508 #10:43:19Z<br>
> source: RADB<br>
><br>
> route: <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> descr: Proxy-registered route object<br>
> origin: AS37353<br>
> notify: <a href="mailto:matthew.chan@hgc.com.hk" target="_blank" rel="noreferrer">matthew.chan@hgc.com.hk</a><br>
> mnt-by: MAINT-HGC-INTL<br>
> changed: <a href="mailto:matthew.chan@hgc.com.hk" target="_blank" rel="noreferrer">matthew.chan@hgc.com.hk</a> 20200304<br>
> source: RADB<br>
><br>
> route: <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> descr: Proxy-registered route object<br>
> origin: AS134548<br>
> changed: <a href="mailto:radb@hgcbroadband.com" target="_blank" rel="noreferrer">radb@hgcbroadband.com</a> 20191003<br>
> source: RADB<br>
><br>
> route: <a href="http://156.241.0.0/16" rel="noreferrer noreferrer" target="_blank">156.241.0.0/16</a><br>
> origin: AS37353<br>
> mnt-by: paulwollner<br>
> mnt-by: hk-larus-1-mnt<br>
> created: 2017-08-07T12:27:22Z<br>
> last-modified: 2018-09-04T18:54:09Z<br>
> source: RIPE-NONAUTH<br>
> remarks: ****************************<br>
> remarks: * THIS OBJECT IS MODIFIED<br>
> remarks: * Please note that all data that is generally regarded as<br>
> personal<br>
> remarks: * data has been removed from this object.<br>
> remarks: * To view the original object, please query the RIPE<br>
> Database at:<br>
> remarks: * <a href="http://www.ripe.net/whois" rel="noreferrer noreferrer" target="_blank">http://www.ripe.net/whois</a><br>
> remarks: ****************************<br>
><br>
> route: <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> descr: Proxy-registered route object<br>
> origin: AS37353<br>
> remarks: This is a HGC customer route-object<br>
> remarks: which is being exported under this origin AS.<br>
> remarks:<br>
> remarks: This route object was created because no existing<br>
> remarks: route object with the same origin was found.<br>
> remarks:<br>
> remarks: Please contact <a href="mailto:radb@hutchcity.com" target="_blank" rel="noreferrer">radb@hutchcity.com</a> if you have any<br>
> remarks: questions regarding this object.<br>
> notify: <a href="mailto:radb@hutchcity.com" target="_blank" rel="noreferrer">radb@hutchcity.com</a><br>
> mnt-by: MAINT-AS9304<br>
> changed: <a href="mailto:radb@hutchcity.com" target="_blank" rel="noreferrer">radb@hutchcity.com</a> 20200304<br>
> source: NTTCOM<br>
><br>
> route: <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> descr: Proxy-registered route object<br>
> origin: AS134548<br>
> remarks: This is a HGC customer route-object<br>
> remarks: which is being exported under this origin AS.<br>
> remarks:<br>
> remarks: This route object was created because no existing<br>
> remarks: route object with the same origin was found.<br>
> remarks:<br>
> remarks: Please contact <a href="mailto:radb@hgcbroadband.com" target="_blank" rel="noreferrer">radb@hgcbroadband.com</a> if you have any<br>
> remarks: questions regarding this object.<br>
> notify: <a href="mailto:radb@hgcbroadband.com" target="_blank" rel="noreferrer">radb@hgcbroadband.com</a><br>
> mnt-by: MAINT-AS9304<br>
> changed: <a href="mailto:radb@hgcbroadband.com" target="_blank" rel="noreferrer">radb@hgcbroadband.com</a> 20191003<br>
> source: NTTCOM<br>
><br>
> mntner: MAINT-AS138145<br>
> descr: Advanced Information Co., Ltd.<br>
> admin-c: ADVANCED-APNIC<br>
> tech-c: ADVANCED-APNIC<br>
> upd-to: noc@cloudix.online<br>
> mnt-nfy: noc@cloudix.online<br>
> auth: CRYPT-PW HIDDENCRYPTPW #<br>
> notify: noc@cloudix.online<br>
> mnt-by: MAINT-AS138145<br>
> changed: admin@cloudix.online 20200511 #03:10:36Z<br>
> source: RADB<br>
> 0.000u 0.001s 0:00.19 0.0% 0+0k 0+0io 0pf+0w<br>
> owen (122) ~ %<br>
> 2020/05/28 16:58:53<br>
><br>
> Looks like there?s additional cruft left in some routing registries that<br>
> we still haven?t removed. I?ve asked people to get on that.<br>
><br>
> However, just because it?s in RADB doesn?t mean it?s advertised.<br>
> Nonetheless, we are actively working to get those errant entries cleaned<br>
> up. Thank you for bringing them to our attention.<br>
><br>
><br>
> <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><br>
> <<a href="https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0/24&-T+option=&ip_option=&-i+option=" rel="noreferrer noreferrer" target="_blank">https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0/24&-T+option=&ip_option=&-i+option=</a>><br>
><br>
> These objects havent been deleted.<br>
><br>
> An in-depth check of the routing status of <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a> shows the<br>
> followings:<br>
><br>
> Hurricane Electric BGP tool<br>
><br>
> <a href="https://bgp.he.net/net/156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">https://bgp.he.net/net/156.241.3.0/24</a><br>
><br>
> Origin AS Announcement Description AS37353<br>
> <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a> IRR Valid HONGKONG LINK INFINITY TECHNOLOGY LIMITED<br>
><br>
><br>
> The HE BGP tool doesn?t mean what you think it means.<br>
><br>
> It retains routes which have been withdrawn for a very long time after<br>
> they have been withdrawn, especially if they are not superseded by other<br>
> announcements.<br>
><br>
> OTOH, the HE BGP Looking glass shows:<br>
><br>
><br>
><br>
> RIPESTAT<br>
><br>
> <a href="https://stat.ripe.net/widget/looking-glass#w.resource=156.241.3.0%2F24" rel="noreferrer noreferrer" target="_blank">https://stat.ripe.net/widget/looking-glass#w.resource=156.241.3.0%2F24</a><br>
> <<a href="https://stat.ripe.net/widget/looking-glass#w.resource=156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">https://stat.ripe.net/widget/looking-glass#w.resource=156.241.3.0/24</a>><br>
><br>
> AS37353 is seen as the origin by 1 peer.<br>
><br>
> 103.200.115.1 ?103.200.115.1 is announcing route AS64271 AS9304 AS4809<br>
> AS4809 AS4809 AS134190 AS37353.<br>
><br>
><br>
> Well? That?s historic data. If you view it in BGPLAY, you will see that<br>
> the last transaction for this prefix was on May 7 (Mark?s initial on-list<br>
> complaint came May 8).<br>
><br>
> Even with the limited view, the prefix is still being originated and<br>
> routed and the route objects still exist.<br>
><br>
><br>
> No, you are looking at data from May 7. Current data as above (HE looking<br>
> glass).<br>
><br>
> From Route-views and several other route servers (I have redacted the<br>
> transcript to leave out banner text and other irrelevant data. All routing<br>
> queries are included full prompt to prompt without editing):<br>
> route-views>show ip bgp <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> % Network not in table<br>
> route-views><br>
><br>
><br>
> owen (122) ~ % telnet <a href="http://route-views.oregon-ix.net" rel="noreferrer noreferrer" target="_blank">route-views.oregon-ix.net</a><br>
> 2020/05/28 16:58:53<br>
> Trying 128.223.51.103...<br>
> Connected to <a href="http://route-views.oregon-ix.net" rel="noreferrer noreferrer" target="_blank">route-views.oregon-ix.net</a>.<br>
> Escape character is '^]'.<br>
><br>
> User Access Verification<br>
><br>
> Username: Kerberos: No default realm defined for Kerberos!<br>
> rviews<br>
><br>
> route-views>show ip bgp <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> % Network not in table<br>
> route-views>q<br>
> Connection closed by foreign host.<br>
> 0.007u 0.014s 1:49.98 0.0% 0+0k 0+0io 21pf+0w<br>
> Exit 1<br>
> owen (123) ~ % telnet <a href="http://route-views.optus.net.au" rel="noreferrer noreferrer" target="_blank">route-views.optus.net.au</a><br>
> 2020/05/28 17:26:50<br>
> Trying 203.202.125.6...<br>
> Connected to <a href="http://route-views.optus.net.au" rel="noreferrer noreferrer" target="_blank">route-views.optus.net.au</a>.<br>
> Escape character is '^]'.<br>
><br>
> <a href="http://route-views.optus.net.au" rel="noreferrer noreferrer" target="_blank">route-views.optus.net.au</a>>Kerberos: No default realm defined for Kerberos!<br>
> show ip bgp <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> % Network not in table<br>
> <a href="http://route-views.optus.net.au" rel="noreferrer noreferrer" target="_blank">route-views.optus.net.au</a>>q<br>
> Connection closed by foreign host.<br>
> 0.007u 0.005s 0:21.89 0.0% 0+0k 0+0io 0pf+0w<br>
> Exit 1<br>
><br>
> owen (127) ~ % telnet <a href="http://route-views.ab.bb.telus.com" rel="noreferrer noreferrer" target="_blank">route-views.ab.bb.telus.com</a><br>
> 2020/05/28 17:28:00<br>
> Trying 154.11.98.18...<br>
> Connected to <a href="http://route-views.ab.bb.telus.com" rel="noreferrer noreferrer" target="_blank">route-views.ab.bb.telus.com</a>.<br>
> Escape character is '^]'.<br>
> c<br>
><br>
> route-views.ab>Kerberos: No default realm defined for Kerberos!<br>
> show ip bgp <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> % Network not in table<br>
> route-views.ab>q<br>
> Connection closed by foreign host.<br>
> 0.006u 0.005s 0:05.23 0.0% 0+0k 0+0io 0pf+0w<br>
> Exit 1<br>
> owen (131) ~ % telnet <a href="http://route-server.tinet.net" rel="noreferrer noreferrer" target="_blank">route-server.tinet.net</a><br>
> 2020/05/28 17:28:45<br>
> Trying 213.200.64.94...<br>
> Connected to <a href="http://route-server.tinet.net" rel="noreferrer noreferrer" target="_blank">route-server.tinet.net</a>.<br>
> Escape character is '^]'.<br>
> login: public<br>
> Password:<br>
> Last login: Thu May 28 18:44:36 from <a href="http://vinci.rdsnet.ro" rel="noreferrer noreferrer" target="_blank">vinci.rdsnet.ro</a><br>
><br>
> --- JUNOS 15.1F6-S5.6 Kernel 64-bit JNPR-10.3-20161130.340898_build<br>
><br>
> {master}<br>
> public@route-server.as3257.net-re0> show route <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a> all<br>
> extensive<br>
><br>
> {master}<br>
> public@route-server.as3257.net-re0><br>
> public@route-server.as3257.net-re0> quit<br>
><br>
> Connection closed by foreign host.<br>
> 0.007u 0.009s 0:40.46 0.0% 0+0k 0+0io 0pf+0w<br>
> Exit 1<br>
> owen (132) ~ % telnet <a href="http://route-server.eu.gblx.net" rel="noreferrer noreferrer" target="_blank">route-server.eu.gblx.net</a><br>
> 2020/05/28 17:29:35<br>
> Trying 2001:450:2001:1000::670:1708:1187...<br>
> Connected to <a href="http://loop0.route-server.ams2.gblx.net" rel="noreferrer noreferrer" target="_blank">loop0.route-server.ams2.gblx.net</a>.<br>
> Escape character is '^]'.<br>
><br>
> route-server.ams2>Kerberos: No default realm defined for Kerberos!<br>
> show ip bgp <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> % Network not in table<br>
> route-server.ams2>q<br>
> Connection closed by foreign host.<br>
> 0.006u 0.005s 0:05.51 0.0% 0+0k 0+0io 0pf+0w<br>
> Exit 1<br>
> owen (134) ~ % telnet <a href="http://route-server.opentransit.net" rel="noreferrer noreferrer" target="_blank">route-server.opentransit.net</a><br>
> 2020/05/28 17:30:09<br>
> Trying 204.59.3.38...<br>
> Connected to <a href="http://route-server.opentransit.net" rel="noreferrer noreferrer" target="_blank">route-server.opentransit.net</a>.<br>
> Escape character is '^]'.<br>
> User Access Verification<br>
><br>
> Username: Kerberos: No default realm defined for Kerberos!<br>
> rviews<br>
> Password:<br>
> OAKRS1#show ip bgp <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> % Network not in table<br>
> OAKRS1#exit<br>
> Connection closed by foreign host.<br>
> 0.007u 0.008s 0:29.00 0.0% 0+0k 0+0io 0pf+0w<br>
> Exit 1<br>
> owen (141) ~ % telnet <a href="http://route-server.host.net" rel="noreferrer noreferrer" target="_blank">route-server.host.net</a><br>
> 2020/05/28 17:32:15<br>
> Trying 2001:5b8:fffe::10...<br>
> telnet: connect to address 2001:5b8:fffe::10: Connection refused<br>
> Trying 75.119.191.74...<br>
> Connected to <a href="http://route-server.host.net" rel="noreferrer noreferrer" target="_blank">route-server.host.net</a>.<br>
> Escape character is '^]'.<br>
><br>
> User Access Verification<br>
><br>
> Password:<br>
> route-server> show ip bgp <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> % Network not in table<br>
> route-server> q<br>
> Connection closed by foreign host.<br>
> 0.006u 0.006s 0:06.21 0.0% 0+0k 0+0io 0pf+0w<br>
> Exit 1<br>
><br>
><br>
> As you can see, from many different internet perspectives, the prefix<br>
> simply isn?t in the table.<br>
><br>
> So, Arnaud, your data is flawed and your conclusions are in error. The<br>
> prefix has not been announced since May 7. I don?t know how much you?ve<br>
> tried to remove obsolete or erroneous entries from RADB and its ilk<br>
> generated by others, but I can assure you that it is much like the game of<br>
> whack-a-mole. We appreciate your calling these entries to our attention and<br>
> we will pursue them, but there has been no further incidence of use of<br>
> AS37353 by our customers and the actual problem was, in fact, corrected<br>
> prior to Mark?s initial post.<br>
><br>
> Nothing you have posted indicates otherwise and your claims could be<br>
> considered defamatory.<br>
> Im not sure about the law where you are, but here, defamation requires 4<br>
> elements:<br>
> 1. A false statement purporting to be fact. Your claims above that the<br>
> hijack was an action by Larus (false) and that it was malicious (false) and<br>
> that it continues (false) qualify here.<br>
> 2. Publication or communication of that statement to a third person. By<br>
> posting this on multiple lists, you have more than met this test.<br>
> 3. Fault amounting to at least negligence. This one is a bit more of a<br>
> grey area, but your failure to investigate realtime sources instead of<br>
> relying on sources known to use historical data is, IMHO, negligent.<br>
> 4. Damages or some harm caused to the person or entity. If nothing else,<br>
> the collective time wasted on this continued discussion of a minor mistake<br>
> represents significant harm to the community as a whole.<br>
> Were your statements not so blatantly and easily disproven, or should they<br>
> be believed by anyone, then there is also the question of harm to the good<br>
> name of Larus as a company.<br>
><br>
> Owen<br>
><br>
><br>
> Regards<br>
><br>
> --<br>
> Arnaud<br>
><br>
> Le sam. 9 mai 2020 ? 09:44, Lu Heng <<a href="mailto:h.lu@anytimechinese.com" target="_blank" rel="noreferrer">h.lu@anytimechinese.com</a>> a ?crit :<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 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 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 to<br>
>> investigate the situation. As soon as it was clear that this was the result<br>
>> of third-party actions, we reached out to Mark privately to let him know<br>
>> 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 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>
>> 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 noreferrer" target="_blank">156.241.3.0/24</a> since 9th December 2019.<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>
>> 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>
>> 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>
>> 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>
>> *Link Infinity:*<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 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>
>> *Paul Wollner:*<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>
>> 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>
>> 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 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 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 to<br>
>> investigate the situation. As soon as it was clear that this was the result<br>
>> of third-party actions, we reached out to Mark privately to let him know<br>
>> 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 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>
>> 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 noreferrer" target="_blank">156.241.3.0/24</a> since 9th December 2019.<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>
>> 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>
>> 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>
>> 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>
>> *Link Infinity:*<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 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>
>> *Paul Wollner:*<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>
>> 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>
>> On Fri, 8 May 2020 at 22:08, Mark Tinka <<a href="mailto:mark.tinka@seacom.mu" target="_blank" rel="noreferrer">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 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 was<br>
>>> 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 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 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 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 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 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 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 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 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 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 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 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 to<br>
>>> use another network's AS number for their service, and as it turns out, the<br>
>>> 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 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 noreferrer" target="_blank">lg-01-ams.nl</a>>sh ip bgp <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
>>> % Network not in table<br>
>>> <a href="http://lg-01-ams.nl" rel="noreferrer noreferrer" target="_blank">lg-01-ams.nl</a>><br>
>>><br>
>>> <a href="http://lg-01-nbo.ke" rel="noreferrer noreferrer" target="_blank">lg-01-nbo.ke</a>>sh ip bgp <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
>>> % Network not in table<br>
>>> <a href="http://lg-01-nbo.ke" rel="noreferrer noreferrer" target="_blank">lg-01-nbo.ke</a>><br>
>>><br>
>>> <a href="http://lg-01-cpt.za" rel="noreferrer noreferrer" target="_blank">lg-01-cpt.za</a>>sh ip bgp <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
>>> % Network not in table<br>
>>> <a href="http://lg-01-cpt.za" rel="noreferrer 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>
>>> Community-Discuss mailing list<br>
>>> <a href="mailto:Community-Discuss@afrinic.net" target="_blank" rel="noreferrer">Community-Discuss@afrinic.net</a><br>
>>> <a href="https://lists.afrinic.net/mailman/listinfo/community-discuss" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/community-discuss</a><br>
>>><br>
>><br>
>><br>
>> --<br>
>> --<br>
>> Kind regards.<br>
>> Lu<br>
>><br>
>> _______________________________________________<br>
>> Community-Discuss mailing list<br>
>> <a href="mailto:Community-Discuss@afrinic.net" target="_blank" rel="noreferrer">Community-Discuss@afrinic.net</a><br>
>> <a href="https://lists.afrinic.net/mailman/listinfo/community-discuss" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/community-discuss</a><br>
>><br>
> _______________________________________________<br>
> Community-Discuss mailing list<br>
> <a href="mailto:Community-Discuss@afrinic.net" target="_blank" rel="noreferrer">Community-Discuss@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/community-discuss" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/community-discuss</a><br>
><br>
><br>
> _______________________________________________<br>
> Community-Discuss mailing list<br>
> <a href="mailto:Community-Discuss@afrinic.net" target="_blank" rel="noreferrer">Community-Discuss@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/community-discuss" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/community-discuss</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/604d4eb2/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/604d4eb2/attachment-0001.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: Screen Shot 2020-05-28 at 17.13.51 .png<br>
Type: image/png<br>
Size: 104109 bytes<br>
Desc: not available<br>
URL: <<a href="https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/604d4eb2/attachment-0001.png" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/604d4eb2/attachment-0001.png</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 29 May 2020 08:07:08 +0000<br>
From: Arnaud AMELINA <<a href="mailto:amelnaud@gmail.com" target="_blank" rel="noreferrer">amelnaud@gmail.com</a>><br>
To: Owen DeLong <<a href="mailto:owen@delong.com" target="_blank" rel="noreferrer">owen@delong.com</a>><br>
Cc: General Discussions of AFRINIC <<a href="mailto:community-discuss@afrinic.net" target="_blank" rel="noreferrer">community-discuss@afrinic.net</a>>,<br>
"rpd >> AfriNIC Resource Policy" <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor,<br>
If Not Criminal, Netizenship<br>
Message-ID:<br>
<CAGDMR_dvw8c0eSKwNPKNHm+nOY_5xOsKhZ67C+w_tua=<a href="mailto:9O7-Hg@mail.gmail.com" target="_blank" rel="noreferrer">9O7-Hg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Owen,<br>
I won?t respond to your intimidation but focus on the real technical<br>
issues. See my response below inline<br>
<br>
Le ven. 29 mai 2020 ? 00:59, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank" rel="noreferrer">owen@delong.com</a>> a ?crit :<br>
<br>
> Arnaud,<br>
><br>
> You are mistaken on a number of points.<br>
><br>
><br>
> On May 28, 2020, at 13:05 , Arnaud AMELINA <<a href="mailto:amelnaud@gmail.com" target="_blank" rel="noreferrer">amelnaud@gmail.com</a>> wrote:<br>
><br>
> Hi, all communities<br>
><br>
> It was said that the hijacking of AS37353 was a configuration mistake,<br>
> coupled with poor oversight in checking the right to use of the ASN by a<br>
> certain IPDC customer.<br>
><br>
> It was also said that this would have been facilitated by old and stalled<br>
> IRR objects from MacroLAN before the service contract ended in December<br>
> 2019.<br>
><br>
> It was also stated that the BGP announcement was stopped and some actions<br>
> taken to delete the stalled routing registry object from IRR.<br>
><br>
><br>
> Yes? The registry objects created by MacroLAN have been deleted.<br>
><br>
> Below are some data which gives some extra information and confirm<br>
> previous claim that this incident was not accidental.<br>
><br>
><br>
> Below is some very redacted data which gives virtually no information.<br>
><br>
> NB: All data are collected from their source, Today, 28 May 2020, at 10:00<br>
> UTC.<br>
><br>
> IRRs created in March 2020 with AS37353 as Origin for <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a> by<br>
> HGC<br>
><br>
> $ 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>
><br>
> 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<br>
> origin: AS37353 notify: <a href="mailto:matthew.chan@hgc.com.hk" target="_blank" rel="noreferrer">matthew.chan@hgc.com.hk</a> mnt-by:<br>
> MAINT-HGC-INTL changed: <a href="mailto:matthew.chan@hgc.com.hk" target="_blank" rel="noreferrer">matthew.chan@hgc.com.hk</a> 20200304 source:<br>
> RADB<br>
><br>
> =====<br>
> route: <a href="http://156.241.3.0/24" rel="noreferrer noreferrer" target="_blank">156.241.3.0/24</a><br>
> descr: Proxy-registered route object origin: AS37353<br>
> remarks: This is a HGC customer route-object<br>
> remarks: which is being exported under this origin AS.<br>
> remarks:<br>
> remarks: This route object was created because no existing<br>
> remarks: route object with the same origin was found.<br>
> remarks:<br>
> remarks: Please contact <a href="mailto:radb@hutchcity.com" target="_blank" rel="noreferrer">radb@hutchcity.com</a> if you have any<br>
> remarks: questions regarding this object.<br>
> notify: <a href="mailto:radb@hutchcity.com" target="_blank" rel="noreferrer">radb@hutchcity.com</a><br>
> mnt-by: MAINT-AS9304<br>
> changed: <a href="mailto:radb@hutchcity.com" target="_blank" rel="noreferrer">radb@hutchcity.com</a> 20200304<br>
> source: NTTCOM<br>
> ====<br>
><br>
><br>
> We haven changed anything, but here?s the full text of that whois command:<br>
> ...<br>
> changed: admin@cloudix.online 20200511 #03:10:36Z<br>
> source: RADB<br>
> 0.000u 0.001s 0:00.19 0.0% 0+0k 0+0io 0pf+0w<br>
> owen (122) ~ %<br>
> 2020/05/28 16:58:53<br>
><br>
> Looks like there?s additional cruft left in some routing registries that<br>
> we still haven?t removed. I?ve asked people to get on that.<br>
><br>
><br>
Good.. this is the reason for my mail.<br>
Draw attention on these route objects which should have never existed on<br>
RADB and get them cleaned up by your customer who is the maintainer of the<br>
route object as per the records.<br>
<br>
<br>
> However, just because it?s in RADB doesn?t mean it?s advertised.<br>
><br>
<br>
The routing visibility I referred to was not because route objects are in<br>
RADB or in NTT routing registries..<br>
<br>
Even though the prefix is no longer seen in global routing table, it is<br>
been seen by some route collectors.<br>
<br>
One route collector at RIPE Stat sees as shown in the picture as at now.<br>
<br>
[ picture]<br>
And the ASPATH speaks for itself.<br>
<br>
<br>
> Nonetheless, we are actively working to get those errant entries cleaned<br>
> up. Thank you for bringing them to our attention.<br>
><br>
> Please let the community know when everything is cleaned.<br>
Thank you<br>
<br>
--<br>
Arnaud<br>
<br>
...<br>
<br>
> _______________________________________________<br>
>> Community-Discuss mailing list<br>
>> <a href="mailto:Community-Discuss@afrinic.net" target="_blank" rel="noreferrer">Community-Discuss@afrinic.net</a><br>
>> <a href="https://lists.afrinic.net/mailman/listinfo/community-discuss" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/community-discuss</a><br>
>><br>
> _______________________________________________<br>
> Community-Discuss mailing list<br>
> <a href="mailto:Community-Discuss@afrinic.net" target="_blank" rel="noreferrer">Community-Discuss@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/community-discuss" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/community-discuss</a><br>
><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/288a5518/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/288a5518/attachment.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: IMG_20200529_074734_512.jpg<br>
Type: image/jpeg<br>
Size: 62307 bytes<br>
Desc: not available<br>
URL: <<a href="https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/288a5518/attachment.jpg" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/288a5518/attachment.jpg</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Community-Discuss mailing list<br>
<a href="mailto:Community-Discuss@afrinic.net" target="_blank" rel="noreferrer">Community-Discuss@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/community-discuss" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/community-discuss</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Community-Discuss Digest, Vol 620, Issue 2<br>
*************************************************<br>
</blockquote></div></div></div>