From mark.tinka at seacom.mu Fri May 8 14:07:26 2020 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 8 May 2020 16:07:26 +0200 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship Message-ID: 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: From h.lu at anytimechinese.com Sat May 9 09:39:29 2020 From: h.lu at anytimechinese.com (Lu Heng) Date: Sat, 9 May 2020 17:39:29 +0800 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: To whom it may concern, On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather belonged to Seacom through their acquisition of MacroLAN. While we regret this unfortunate incident, Mark?s claims that it was criminal or bad netizenship on the part of Cloud Innovation is without foundation and utterly incorrect. As shown below in the attached document from Paul Wollner(Ex-CTO of Macrolan who created IRR routes to allow Macrolan to announce Cloud Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A customer of Cloud Innovation; and attached LOA from LARUS authorizing IPDC Solutions to announce the prefix with origin AS134190. And a Letter from IPDC. This was an innocent mistake committed by third parties and had nothing to do with any action by Cloud Innovation or LARUS. Here?s what happened: Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation to issue an LOA, which we did. The LOA specifically required IPDC to use its own ASN to announce the space (AS134190). IPDC subsequently authorized one of its customers to use the said prefix. For reasons still unknown to Cloud Innovation, IPDC and their customer set up a BGP session wherein their customer used AS37353 as the origin to advertise prefix 156.241.3.0/24. Upon discovering the announcement, rather than contact Cloud Innovation, Mark contacted IPDC who provided him with an incomplete explanation blaming their customer and Mark, not realizing that Cloud Innovation was not the customer in question posted far and wide about the event. It is unclear to us why he chose to do this rather than contact us to try and resolve the issue. A contributing factor to the erroneous BGP configuration by IPDC's customer may have been data contained in some outdated IRR route objects for 156.241.0.0/16 which have subsequently been deleted. As soon as we became aware of the problem (via Mark?s email), we began to investigate the situation. As soon as it was clear that this was the result of third-party actions, we reached out to Mark privately to let him know what we knew and that we were still investigating. We delayed making a public statement in order to try and ascertain all of the facts of the situation. We prefer not to make public statements based on incomplete information. We apologize to the community for our small part in this unfortunate incident and assure you that we work very hard to remain good netizens and will address any concerns promptly when they come to our attention. Sincerely, Lu Heng CEO Cloud Innovations Attached: 1. Letter from Paul Wollner 2. Letter from Link Infinity 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from AS134190 4. Letter from IPDC FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is also providing IP management service to other third parties in all regions, for full disclosure, LARUS and Cloud Innovation are headed by same CEO. Content of those letters have been posted here for your convince: *IPDC:* FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate relationship we were given the authority to use address block 156.241.3.0/24 since 9th December 2019. On 12th December 2019, we have delegated that address block to our client. Following which our client further instructed us to announce the prefix with AS37353. In good will after minimal verification through WHOIS? IP Prefix we have proceeded to execute our client?s request. On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and immediate action has been taken to rectify this situation. IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud Innovation Ltd. IPDC however, does not wish to disclose our client information and our client information shall remain confidential under present circumstances. Once again, we apologize for our shortcomings. *Link Infinity:* To whom it may concern, We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to use 156.241.3.0/24 from them. Beginning December, 2019, we delegated the right to announce this prefix to IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to announce the space which was subsequently received. IPDC subsequently and without our knowledge delegated this space to one of their customers and allowed them to originate it from AS37353. This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation. Unfortunately, we were not aware of the situation until after it had already been resolved. It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We do not condone this and apologize sincerely to the community for what has happened here. Sincere Apologies, *Paul Wollner:* 8 May 2020 TO WHOM IT MAY CONCERN In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air. The IP route objects were created by myself for Cloud Innovation when they signed up as a client of Macrolan ( now SEACOM) as they didn't have their own AS. At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October 2019. It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were never cleaned up. This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects. Regards Paul Wollner 082-786-9776 To whom it may concern, On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather belonged to Seacom through their acquisition of MacroLAN. While we regret this unfortunate incident, Mark?s claims that it was criminal or bad netizenship on the part of Cloud Innovation is without foundation and utterly incorrect. As shown below in the attached document from Paul Wollner(Ex-CTO of Macrolan who created IRR routes to allow Macrolan to announce Cloud Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A customer of Cloud Innovation; and attached LOA from LARUS authorizing IPDC Solutions to announce the prefix with origin AS134190. And a Letter from IPDC. This was an innocent mistake committed by third parties and had nothing to do with any action by Cloud Innovation or LARUS. Here?s what happened: Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation to issue an LOA, which we did. The LOA specifically required IPDC to use its own ASN to announce the space (AS134190). IPDC subsequently authorized one of its customers to use the said prefix. For reasons still unknown to Cloud Innovation, IPDC and their customer set up a BGP session wherein their customer used AS37353 as the origin to advertise prefix 156.241.3.0/24. Upon discovering the announcement, rather than contact Cloud Innovation, Mark contacted IPDC who provided him with an incomplete explanation blaming their customer and Mark, not realizing that Cloud Innovation was not the customer in question posted far and wide about the event. It is unclear to us why he chose to do this rather than contact us to try and resolve the issue. A contributing factor to the erroneous BGP configuration by IPDC's customer may have been data contained in some outdated IRR route objects for 156.241.0.0/16 which have subsequently been deleted. As soon as we became aware of the problem (via Mark?s email), we began to investigate the situation. As soon as it was clear that this was the result of third-party actions, we reached out to Mark privately to let him know what we knew and that we were still investigating. We delayed making a public statement in order to try and ascertain all of the facts of the situation. We prefer not to make public statements based on incomplete information. We apologize to the community for our small part in this unfortunate incident and assure you that we work very hard to remain good netizens and will address any concerns promptly when they come to our attention. Sincerely, Lu Heng CEO Cloud Innovations Attached: 1. Letter from Paul Wollner 2. Letter from Link Infinity 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from AS134190 4. Letter from IPDC FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is also providing IP management service to other third parties in all regions, for full disclosure, LARUS and Cloud Innovation are headed by same CEO. Content of those letters have been posted here for your convince: *IPDC:* FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate relationship we were given the authority to use address block 156.241.3.0/24 since 9th December 2019. On 12th December 2019, we have delegated that address block to our client. Following which our client further instructed us to announce the prefix with AS37353. In good will after minimal verification through WHOIS? IP Prefix we have proceeded to execute our client?s request. On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and immediate action has been taken to rectify this situation. IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud Innovation Ltd. IPDC however, does not wish to disclose our client information and our client information shall remain confidential under present circumstances. Once again, we apologize for our shortcomings. *Link Infinity:* To whom it may concern, We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to use 156.241.3.0/24 from them. Beginning December, 2019, we delegated the right to announce this prefix to IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to announce the space which was subsequently received. IPDC subsequently and without our knowledge delegated this space to one of their customers and allowed them to originate it from AS37353. This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation. Unfortunately, we were not aware of the situation until after it had already been resolved. It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We do not condone this and apologize sincerely to the community for what has happened here. Sincere Apologies, *Paul Wollner:* 8 May 2020 TO WHOM IT MAY CONCERN In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air. The IP route objects were created by myself for Cloud Innovation when they signed up as a client of Macrolan ( now SEACOM) as they didn't have their own AS. At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October 2019. It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were never cleaned up. This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects. Regards Paul Wollner 082-786-9776 On Fri, 8 May 2020 at 22:08, Mark Tinka wrote: > 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. > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LOA.pdf Type: application/pdf Size: 335184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 200509 IPDC-CI Official Letter for IR.pdf Type: application/pdf Size: 67129 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 200508_Wollner_Paul_NAPAfrica.pdf Type: application/pdf Size: 942672 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: HK LINK INFINITY LETTER.pdf Type: application/pdf Size: 569698 bytes Desc: not available URL: From comms at afrinic.net Mon May 11 10:37:31 2020 From: comms at afrinic.net (AFRINIC Communication) Date: Mon, 11 May 2020 14:37:31 +0400 Subject: [Community-Discuss] Extension of deadline for Nomination Period Message-ID: [French, Arabic and Portuguese versions below] Dear AFRINIC Community, NomCom2020 would like to extend the Nomination Period to Monday 25th May, 2020 at 23:59 GMT. We still do not have enough nominations for all available positions. We thus request members of the AFRINIC community to kindly use this period to nominate qualified candidates for the open seats. Please note that this is the final extension for nominations. We still welcome nominations for the following positions: 1. Co-Chair of the Policy Development Working Group (PDWG): Whilst we believe we have enough nominations for this particular seat, in order to keep the situation fair, this position has not been closed. Information on the process of filling the vacancies is available here https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open __________________ 2. The Board of Director: Seat 3 (Indian Ocean), Seat 4 (Central Africa), Seat 8 (Non-Regional), and Seat 6 (Eastern Africa): Information on the process of filling the vacancies is available here https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. NRO NC/ASO AC position: Information on the role responsibilities, criteria, and the process of filling the vacancies is available here https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc ________________________ 4. The AFRINIC Governance Committee (GovCom): Read more on the criteria and qualifications for eligibility here https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members Once again, the deadline for submission of applications is Monday 25th May, 2020 at 23:59 GMT. NomCom 2020 ?????????????????????????????? Ch?re Communaut? d'AFRINIC, NomCom2020 souhaite prolonger la p?riode de nomination jusqu'au lundi 25 mai 2020 ? 23:59 GMT. Nous n'avons pas encore assez de nominations pour tous les postes disponibles. Nous demandons donc aux membres de la communaut? AFRINIC de bien vouloir profiter de cette p?riode pour proposer des candidats qualifi?s pour les si?ges ouverts. Veuillez noter qu'il s'agit de la derni?re prolongation pour les nominations. Nous acceptons toujours les candidatures pour les postes suivants : 1. Co-pr?sident du groupe de travail sur l'?laboration des politiques (PDWG) : Bien que nous pensions avoir suffisamment de candidatures pour ce si?ge particulier, afin de maintenir une situation ?quitable, ce poste n'a pas ?t? ferm?. Des informations sur le processus de pourvoi des postes vacants sont disponibles ici https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open 2. Le conseil d'administration : Si?ge 3 (oc?an Indien), si?ge 4 (Afrique centrale), si?ge 8 (non r?gional) et si?ge 6 (Afrique de l'Est) : Des informations sur le processus de pourvoi des postes vacants sont disponibles ici https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. Position du NRO NC/ASO AC : Des informations sur les responsabilit?s, les crit?res et le processus de pourvoi des postes vacants sont disponibles ici https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc 4. Le comit? de gouvernance AFRINIC (GovCom) : Pour en savoir plus sur les crit?res et les qualifications d'?ligibilit?, cliquez ici https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members Une fois de plus, la date limite de d?p?t des candidatures est fix?e au lundi 25 mai 2020 ? 23h59 GMT. NomCom 2020 ????????????????? ????? ????? ?????? ? ??? NomCom2020 ????? ???? ??????? ??? ??? ??????? 25 ???? 2020 ?????? 23:59 ?????? ??????. ??? ????? ??? ???? ?? ???? ?? ????????? ????? ??????? ???????. ???????? ???? ?? ????? ????? AFRINIC ??????? ??? ?????? ?????? ?????? ?????? ??????? ????????. ???? ?????? ?? ??? ?? ??????? ??????? ?????????. ?? ???? ???? ?????????? ??????? ???????: 1. ?????? ??????? ??????? ??? ????? ???????? (PDWG): ?? ??? ???? ????? ?? ????? ?? ???? ?? ????????? ???? ?????? ?????? ? ?? ??? ?????? ??? ????? ?????? ? ?? ??? ????? ??? ??????. ??????? ?? ????? ??? ??????? ??????? ????? ??? https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open __________________ 2 - ???? ???????: ?????? 3 (?????? ??????) ? ?????? 4 (??? ???????) ? ?????? 8 (??? ????????) ? ?????? 6 (??? ???????): ??????? ?? ????? ??? ??????? ??????? ????? ??? https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. ???? NRO NC / ASO AC: ????? ??????? ??? ???????? ????? ????????? ?????? ??? ??????? ??? https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc ________________________ 4. ???? ??????? ????????? (GovCom): ???? ?????? ?? ?????? ??????? ??????? ??? https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members ??? ???? ? ?????? ??????? ?????? ??????? ?? ??? ??????? 25 ???? 2020 ?????? 23:59 ?????? ??????. NomCom 2020 ??????????????. Cara Comunidade AFRINIC, O NomCom2020 gostaria de prolongar o per?odo de nomea??o at? segunda-feira, 25 de Maio de 2020, ?s 23:59 GMT. Ainda n?o temos nomea??es suficientes para todos os cargos dispon?veis. Assim, solicitamos aos membros da comunidade AFRINIC que utilizem gentilmente este per?odo para nomear candidatos qualificados para os lugares abertos. Note-se que esta ? a ?ltima prorroga??o para as nomea??es. Continuamos a acolher favoravelmente as nomea??es para os seguintes cargos: 1. Co-presidente do Grupo de Trabalho para o Desenvolvimento de Pol?ticas (PDWG): Embora consideremos que temos nomea??es suficientes para este lugar em particular, a fim de manter a situa??o justa, esta posi??o n?o foi encerrada. Informa??es sobre o processo de preenchimento das vagas est?o dispon?veis aqui https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open __________________ 2. O Conselho de Administra??o: Lugar 3 (Oceano ?ndico), lugar 4 (?frica Central), lugar 8 (N?o-Regional) e lugar 6 (?frica Oriental): Informa??es sobre o processo de preenchimento das vagas est?o dispon?veis aqui https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. Posi??o NRO NC/ASO AC: Informa??es sobre as responsabilidades, os crit?rios e o processo de preenchimento das vagas est?o dispon?veis aqui https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc ________________________ 4. A Comiss?o de Governa??o AFRINIC (GovCom): Leia mais sobre os crit?rios e qualifica??es de elegibilidade aqui https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members Mais uma vez, o prazo para a apresenta??o de candidaturas ? segunda-feira, 25 de Maio de 2020, ?s 23:59 GMT. NomCom 2020 Dear AFRINIC Community, NomCom2020 would like to extend the Nomination Period to Monday 25th May, 2020 at 23:59 GMT. We still do not have enough nominations for all available positions. We thus request members of the AFRINIC community to kindly use this period to nominate qualified candidates for the open seats. Please note that this is the final extension for nominations. We still welcome nominations for the following positions: 1. Co-Chair of the Policy Development Working Group (PDWG): Whilst we believe we have enough nominations for this particular seat, in order to keep the situation fair, this position has not been closed. Information on the process of filling the vacancies is available here https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open __________________ 2. The Board of Director: Seat 3 (Indian Ocean), Seat 4 (Central Africa), Seat 8 (Non-Regional), and Seat 6 (Eastern Africa): Information on the process of filling the vacancies is available here https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. NRO NC/ASO AC position: Information on the role responsibilities, criteria, and the process of filling the vacancies is available here https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc ________________________ 4. The AFRINIC Governance Committee (GovCom): Read more on the criteria and qualifications for eligibility here https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members Once again, the deadline for submission of applications is Monday 25th May, 2020 at 23:59 GMT. NomCom 2020 ?????????????????????????????? Ch?re Communaut? d'AFRINIC, NomCom2020 souhaite prolonger la p?riode de nomination jusqu'au lundi 25 mai 2020 ? 23:59 GMT. Nous n'avons pas encore assez de nominations pour tous les postes disponibles. Nous demandons donc aux membres de la communaut? AFRINIC de bien vouloir profiter de cette p?riode pour proposer des candidats qualifi?s pour les si?ges ouverts. Veuillez noter qu'il s'agit de la derni?re prolongation pour les nominations. Nous acceptons toujours les candidatures pour les postes suivants : 1. Co-pr?sident du groupe de travail sur l'?laboration des politiques (PDWG) : Bien que nous pensions avoir suffisamment de candidatures pour ce si?ge particulier, afin de maintenir une situation ?quitable, ce poste n'a pas ?t? ferm?. Des informations sur le processus de pourvoi des postes vacants sont disponibles ici https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open 2. Le conseil d'administration : Si?ge 3 (oc?an Indien), si?ge 4 (Afrique centrale), si?ge 8 (non r?gional) et si?ge 6 (Afrique de l'Est) : Des informations sur le processus de pourvoi des postes vacants sont disponibles ici https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. Position du NRO NC/ASO AC : Des informations sur les responsabilit?s, les crit?res et le processus de pourvoi des postes vacants sont disponibles ici https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc 4. Le comit? de gouvernance AFRINIC (GovCom) : Pour en savoir plus sur les crit?res et les qualifications d'?ligibilit?, cliquez ici https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members Une fois de plus, la date limite de d?p?t des candidatures est fix?e au lundi 25 mai 2020 ? 23h59 GMT. NomCom 2020 ????????????????? ????? ????? ?????? ? ??? NomCom2020 ????? ???? ??????? ??? ??? ??????? 25 ???? 2020 ?????? 23:59 ?????? ??????. ??? ????? ??? ???? ?? ???? ?? ????????? ????? ??????? ???????. ???????? ???? ?? ????? ????? AFRINIC ??????? ??? ?????? ?????? ?????? ?????? ??????? ????????. ???? ?????? ?? ??? ?? ??????? ??????? ?????????. ?? ???? ???? ?????????? ??????? ???????: 1. ?????? ??????? ??????? ??? ????? ???????? (PDWG): ?? ??? ???? ????? ?? ????? ?? ???? ?? ????????? ???? ?????? ?????? ? ?? ??? ?????? ??? ????? ?????? ? ?? ??? ????? ??? ??????. ??????? ?? ????? ??? ??????? ??????? ????? ??? https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open __________________ 2 - ???? ???????: ?????? 3 (?????? ??????) ? ?????? 4 (??? ???????) ? ?????? 8 (??? ????????) ? ?????? 6 (??? ???????): ??????? ?? ????? ??? ??????? ??????? ????? ??? https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. ???? NRO NC / ASO AC: ????? ??????? ??? ???????? ????? ????????? ?????? ??? ??????? ??? https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc ________________________ 4. ???? ??????? ????????? (GovCom): ???? ?????? ?? ?????? ??????? ??????? ??? https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members ??? ???? ? ?????? ??????? ?????? ??????? ?? ??? ??????? 25 ???? 2020 ?????? 23:59 ?????? ??????. NomCom 2020 ??????????????. Cara Comunidade AFRINIC, O NomCom2020 gostaria de prolongar o per?odo de nomea??o at? segunda-feira, 25 de Maio de 2020, ?s 23:59 GMT. Ainda n?o temos nomea??es suficientes para todos os cargos dispon?veis. Assim, solicitamos aos membros da comunidade AFRINIC que utilizem gentilmente este per?odo para nomear candidatos qualificados para os lugares abertos. Note-se que esta ? a ?ltima prorroga??o para as nomea??es. Continuamos a acolher favoravelmente as nomea??es para os seguintes cargos: 1. Co-presidente do Grupo de Trabalho para o Desenvolvimento de Pol?ticas (PDWG): Embora consideremos que temos nomea??es suficientes para este lugar em particular, a fim de manter a situa??o justa, esta posi??o n?o foi encerrada. Informa??es sobre o processo de preenchimento das vagas est?o dispon?veis aqui https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open __________________ 2. O Conselho de Administra??o: Lugar 3 (Oceano ?ndico), lugar 4 (?frica Central), lugar 8 (N?o-Regional) e lugar 6 (?frica Oriental): Informa??es sobre o processo de preenchimento das vagas est?o dispon?veis aqui https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. Posi??o NRO NC/ASO AC: Informa??es sobre as responsabilidades, os crit?rios e o processo de preenchimento das vagas est?o dispon?veis aqui https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc ________________________ 4. A Comiss?o de Governa??o AFRINIC (GovCom): Leia mais sobre os crit?rios e qualifica??es de elegibilidade aqui https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members Mais uma vez, o prazo para a apresenta??o de candidaturas ? segunda-feira, 25 de Maio de 2020, ?s 23:59 GMT. NomCom 2020 From comms at afrinic.net Wed May 20 10:15:44 2020 From: comms at afrinic.net (AFRINIC Communication) Date: Wed, 20 May 2020 14:15:44 +0400 Subject: [Community-Discuss] Reminder: Extension of deadline for Nomination Period Message-ID: <702A9789-B089-4DD8-8765-9C79B3F7581E@afrinic.net> Dear AFRINIC Community, NomCom2020 would like to extend the Nomination Period to Monday 25th May, 2020 at 23:59 GMT. We still do not have enough nominations for all available positions. We thus request members of the AFRINIC community to kindly use this period to nominate qualified candidates for the open seats. Please note that this is the final extension for nominations. We still welcome nominations for the following positions: 1. Co-Chair of the Policy Development Working Group (PDWG): Whilst we believe we have enough nominations for this particular seat, in order to keep the situation fair, this position has not been closed. Information on the process of filling the vacancies is available here https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open __________________ 2. The Board of Director: Seat 3 (Indian Ocean), Seat 4 (Central Africa), Seat 8 (Non-Regional), and Seat 6 (Eastern Africa): Information on the process of filling the vacancies is available here https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. NRO NC/ASO AC position: Information on the role responsibilities, criteria, and the process of filling the vacancies is available here https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc ________________________ 4. The AFRINIC Governance Committee (GovCom): Read more on the criteria and qualifications for eligibility here https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members Once again, the deadline for submission of applications is Monday 25th May, 2020 at 23:59 GMT. NomCom 2020 ?????????????????????????????? Ch?re Communaut? d'AFRINIC, NomCom2020 souhaite prolonger la p?riode de nomination jusqu'au lundi 25 mai 2020 ? 23:59 GMT. Nous n'avons pas encore assez de nominations pour tous les postes disponibles. Nous demandons donc aux membres de la communaut? AFRINIC de bien vouloir profiter de cette p?riode pour proposer des candidats qualifi?s pour les si?ges ouverts. Veuillez noter qu'il s'agit de la derni?re prolongation pour les nominations. Nous acceptons toujours les candidatures pour les postes suivants : 1. Co-pr?sident du groupe de travail sur l'?laboration des politiques (PDWG) : Bien que nous pensions avoir suffisamment de candidatures pour ce si?ge particulier, afin de maintenir une situation ?quitable, ce poste n'a pas ?t? ferm?. Des informations sur le processus de pourvoi des postes vacants sont disponibles ici https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open 2. Le conseil d'administration : Si?ge 3 (oc?an Indien), si?ge 4 (Afrique centrale), si?ge 8 (non r?gional) et si?ge 6 (Afrique de l'Est) : Des informations sur le processus de pourvoi des postes vacants sont disponibles ici https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. Position du NRO NC/ASO AC : Des informations sur les responsabilit?s, les crit?res et le processus de pourvoi des postes vacants sont disponibles ici https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc 4. Le comit? de gouvernance AFRINIC (GovCom) : Pour en savoir plus sur les crit?res et les qualifications d'?ligibilit?, cliquez ici https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members Une fois de plus, la date limite de d?p?t des candidatures est fix?e au lundi 25 mai 2020 ? 23h59 GMT. NomCom 2020 ????????????????? ????? ????? ?????? ? ??? NomCom2020 ????? ???? ??????? ??? ??? ??????? 25 ???? 2020 ?????? 23:59 ?????? ??????. ??? ????? ??? ???? ?? ???? ?? ????????? ????? ??????? ???????. ???????? ???? ?? ????? ????? AFRINIC ??????? ??? ?????? ?????? ?????? ?????? ??????? ????????. ???? ?????? ?? ??? ?? ??????? ??????? ?????????. ?? ???? ???? ?????????? ??????? ???????: 1. ?????? ??????? ??????? ??? ????? ???????? (PDWG): ?? ??? ???? ????? ?? ????? ?? ???? ?? ????????? ???? ?????? ?????? ? ?? ??? ?????? ??? ????? ?????? ? ?? ??? ????? ??? ??????. ??????? ?? ????? ??? ??????? ??????? ????? ??? https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open __________________ 2 - ???? ???????: ?????? 3 (?????? ??????) ? ?????? 4 (??? ???????) ? ?????? 8 (??? ????????) ? ?????? 6 (??? ???????): ??????? ?? ????? ??? ??????? ??????? ????? ??? https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. ???? NRO NC / ASO AC: ????? ??????? ??? ???????? ????? ????????? ?????? ??? ??????? ??? https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc ________________________ 4. ???? ??????? ????????? (GovCom): ???? ?????? ?? ?????? ??????? ??????? ??? https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members ??? ???? ? ?????? ??????? ?????? ??????? ?? ??? ??????? 25 ???? 2020 ?????? 23:59 ?????? ??????. NomCom 2020 ??????????????. Cara Comunidade AFRINIC, O NomCom2020 gostaria de prolongar o per?odo de nomea??o at? segunda-feira, 25 de Maio de 2020, ?s 23:59 GMT. Ainda n?o temos nomea??es suficientes para todos os cargos dispon?veis. Assim, solicitamos aos membros da comunidade AFRINIC que utilizem gentilmente este per?odo para nomear candidatos qualificados para os lugares abertos. Note-se que esta ? a ?ltima prorroga??o para as nomea??es. Continuamos a acolher favoravelmente as nomea??es para os seguintes cargos: 1. Co-presidente do Grupo de Trabalho para o Desenvolvimento de Pol?ticas (PDWG): Embora consideremos que temos nomea??es suficientes para este lugar em particular, a fim de manter a situa??o justa, esta posi??o n?o foi encerrada. Informa??es sobre o processo de preenchimento das vagas est?o dispon?veis aqui https://www.afrinic.net/20200304-call-for-nominations-for-co-chair-of-the-policy-development-working-group-pdwg-is-open __________________ 2. O Conselho de Administra??o: Lugar 3 (Oceano ?ndico), lugar 4 (?frica Central), lugar 8 (N?o-Regional) e lugar 6 (?frica Oriental): Informa??es sobre o processo de preenchimento das vagas est?o dispon?veis aqui https://www.afrinic.net/20200304-call-for-nominations-for-open-board-of-directors-seats _____________________ 3. Posi??o NRO NC/ASO AC: Informa??es sobre as responsabilidades, os crit?rios e o processo de preenchimento das vagas est?o dispon?veis aqui https://www.afrinic.net/20200304-call-for-nominations-for-an-open-seat-on-the-nro-nc ________________________ 4. A Comiss?o de Governa??o AFRINIC (GovCom): Leia mais sobre os crit?rios e qualifica??es de elegibilidade aqui https://www.afrinic.net/20200304-call-for-nominations-afrinic-governance-committee-gc-members Mais uma vez, o prazo para a apresenta??o de candidaturas ? segunda-feira, 25 de Maio de 2020, ?s 23:59 GMT. NomCom 2020 From Nkeramugaba at isoc.org Thu May 21 08:26:59 2020 From: Nkeramugaba at isoc.org (Ghislain Nkeramugaba) Date: Thu, 21 May 2020 08:26:59 +0000 Subject: [Community-Discuss] Inscrivez-vous pour le Forum en ligne sur le Peering d?Afrique Centrale/ Register for the Central Africa online Peering Forum Message-ID: <5A4D5B07-1E17-4CB7-9B1F-796527F8DF31@isoc.org> *Apology for cross-posting/Veuillez excuser les envois multiples* -English version below- Bonjour- Face ? la pand?mie de COVID-19, il est important plus que jamais de maintenir des discussions et des ?changes sur la fa?on de d?velopper l'interconnexion, le peering et la croissance d'Internet en Afrique Centrale. Nous avons r?uni un groupe d'experts de conf?renciers locaux, r?gionaux et mondiaux pour partager leur expertise et leurs id?es sur l'impact de COVID-19 et comment planifier une nouvelle normalit?. Rejoignez-nous en ligne au Forum sur le Peering d?Afrique Central le mercredi 27 mai ? 15:00-17:00 (WAT ou UTC+1). [27 Mai 2020 14:00-16:00 UTC] Inscrivez-vous pour votre place gratuite maintenant: https://www.internetsociety.org/events/central-africa-peering-forum/registration/ Cordialement, Ghislain, ISOC -------------------------------------------------------- Hi everyone- In the face of the COVID-19 pandemic, it is more important than ever to keep conversations alive about how to develop interconnection, peering and Internet growth across Central Africa. We?ve gathered an expert panel of local, regional and global speakers to share their expertise and insights on the impact of COVID-19 and how to plan for a new normal. Join us online at the Central Africa Peering Forum on Wednesday 27 May at 15:00-17:00 (WAT or UTC+1), [May 27, 2020 14:00-16:00 UTC] Register for your free place now: https://www.internetsociety.org/fr/events/central-africa-peering-forum/registration/ Regards, Ghislain, ISOC -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregoire.ehoumi at yahoo.fr Sat May 23 14:21:26 2020 From: gregoire.ehoumi at yahoo.fr (Gregoire EHOUMI) Date: Sat, 23 May 2020 10:21:26 -0400 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: Message-ID: Hello,Thanks Mark for exposing the details of the SEACOM AS37353 hijacking.I carefully read your report and also the Cloud Innovation Limited quick response including their attachments as justifications.I note that; ? the service contract with Cloud Innovation covering the announcement of their prefixes by SEACOM AS37353 was terminated? by SEACOM. ? some stale IRR route objects existed after termination of the contract. ? through some multiple layer distribution an organisation in Manila Philippines was ?delegated? an IP block from Cloud Innovation address space. ? both upstream ISP and the customer in Manila set up a BGP session using SEACOM's AS37353 as the ASN of the Manila customer. ? there was a prompt reaction from the involved parties that included apologies to SEACOM and the wider internet community. ? there were promises from said parties to be a better netizen which would mean, them not hijacking other networks ASN's. ? there was clear refusal to disclose the details of the customer in Manila Philippines who hijacked the affected SEACOM ASN.All put together, demonstrates that what happened was an impersonation and not a BGP configuration error, nor an oversight in checking the right to use of the SEACOM ASN.1. Why is it that the real customer did not bother presenting its apologies to the community2. Why is there refusal to reveal customer?s details?3. Why is it that the said prefix is no longer seen in the routing table originated by the genius ASN or any other ASN?4. Which networks were involved and what happened to the end users?Can someone from AFRINIC explain what ?delegation of IP block? mean?Note: The self organised Internet knows how to deal with bad net citizens.!Best regards?Gregoire Ehoumi? -------- Original message --------From: Lu Heng Date: 2020-05-09 5:41 a.m. (GMT-05:00) To: General Discussions of AFRINIC Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship To whom it may concern,On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather belonged to Seacom through their acquisition of MacroLAN.While we regret this unfortunate incident, Mark?s claims that it was criminal or bad netizenship on the part of Cloud Innovation is without foundation and utterly incorrect.As shown below in the attached document from Paul Wollner(Ex-CTO of Macrolan who created IRR routes to allow Macrolan to announce Cloud Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A customer of Cloud Innovation; and attached LOA from LARUS authorizing IPDC Solutions to announce the prefix with origin AS134190.? And a Letter from IPDC. This was an innocent mistake committed by third parties and had nothing to do with any action by Cloud Innovation or LARUS.Here?s what happened:Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019.Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation to issue an LOA, which we did. The LOA specifically required IPDC to use its own ASN to announce the space (AS134190).IPDC subsequently authorized one of its customers to use the said prefix.For reasons still unknown to Cloud Innovation, IPDC and their customer set up a BGP session wherein their customer used AS37353 as the origin to advertise prefix?156.241.3.0/24.Upon discovering the announcement, rather than contact Cloud Innovation, Mark contacted IPDC who provided him with an incomplete explanation blaming their customer and Mark, not realizing that Cloud Innovation was not the customer in question posted far and wide about the event. It is unclear to us why he chose to do this rather than contact us to try and resolve the issue.A contributing factor to the erroneous BGP configuration by IPDC's customer may have been data contained in some outdated IRR route objects for?156.241.0.0/16?which have subsequently been deleted.As soon as we became aware of the problem (via Mark?s email), we began to investigate the situation. As soon as it was clear that this was the result of third-party actions, we reached out to Mark privately to let him know what we knew and that we were still investigating. We delayed making a public statement in order to try and ascertain all of the facts of the situation. We prefer not to make public statements based on incomplete information.We apologize to the community for our small part in this unfortunate incident and assure you that we work very hard to remain good netizens and will address any concerns promptly when they come to our attention.Sincerely,Lu HengCEOCloud InnovationsAttached: 1. Letter from Paul Wollner 2. Letter from Link Infinity 3. LOA Issued to IPDC Solutions for announcing?156.241.3.0/24?from AS134190? ? ? ? 4.? ? ?Letter from IPDCFYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is also providing IP management service to other third parties in all regions, for full disclosure, LARUS and Cloud Innovation are headed by same CEO.Content of those letters have been posted here for your convince:IPDC:FOR IMMEDIATE RELEASE?[Perusal of Cloud Innovation Ltd]IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate relationship we were given the authority to use address block?156.241.3.0/24?since 9th December 2019.?On 12th December 2019, we have delegated that address block to our client. Following which our client further instructed us to announce the prefix with AS37353.?In good will after minimal verification through WHOIS? IP Prefix we have proceeded to execute our client?s request.?On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and immediate action has been taken to rectify this situation.?IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud Innovation Ltd.?IPDC however, does not wish to disclose our client information and our client information shall remain confidential under present circumstances. Once again, we apologize for our shortcomings.?Link Infinity:To whom it may concern,We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to use?156.241.3.0/24?from them. Beginning December, 2019, we delegated the right to announce this prefix to IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to announce the space which was subsequently received. IPDC subsequently and without our knowledge delegated this space to one of their customers and allowed them to originate it from AS37353.This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation.Unfortunately, we were not aware of the situation until after it had already been resolved.It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We do not condone this and apologize sincerely to the community for what has happened here.Sincere Apologies,Paul Wollner:8 May 2020TO WHOM IT MAY CONCERN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air.?The IP route objects were created by myself for Cloud Innovation when they signed up as a client of Macrolan ( now SEACOM) as they didn't have their own AS.At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October 2019.It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were never cleaned up.This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects.RegardsPaul Wollner082-786-9776To whom it may concern,On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather belonged to Seacom through their acquisition of MacroLAN.While we regret this unfortunate incident, Mark?s claims that it was criminal or bad netizenship on the part of Cloud Innovation is without foundation and utterly incorrect.As shown below in the attached document from Paul Wollner(Ex-CTO of Macrolan who created IRR routes to allow Macrolan to announce Cloud Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A customer of Cloud Innovation; and attached LOA from LARUS authorizing IPDC Solutions to announce the prefix with origin AS134190.? And a Letter from IPDC. This was an innocent mistake committed by third parties and had nothing to do with any action by Cloud Innovation or LARUS.Here?s what happened:Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019.Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation to issue an LOA, which we did. The LOA specifically required IPDC to use its own ASN to announce the space (AS134190).IPDC subsequently authorized one of its customers to use the said prefix.For reasons still unknown to Cloud Innovation, IPDC and their customer set up a BGP session wherein their customer used AS37353 as the origin to advertise prefix?156.241.3.0/24.Upon discovering the announcement, rather than contact Cloud Innovation, Mark contacted IPDC who provided him with an incomplete explanation blaming their customer and Mark, not realizing that Cloud Innovation was not the customer in question posted far and wide about the event. It is unclear to us why he chose to do this rather than contact us to try and resolve the issue.A contributing factor to the erroneous BGP configuration by IPDC's customer may have been data contained in some outdated IRR route objects for?156.241.0.0/16?which have subsequently been deleted.As soon as we became aware of the problem (via Mark?s email), we began to investigate the situation. As soon as it was clear that this was the result of third-party actions, we reached out to Mark privately to let him know what we knew and that we were still investigating. We delayed making a public statement in order to try and ascertain all of the facts of the situation. We prefer not to make public statements based on incomplete information.We apologize to the community for our small part in this unfortunate incident and assure you that we work very hard to remain good netizens and will address any concerns promptly when they come to our attention.Sincerely,Lu HengCEOCloud InnovationsAttached: 1. Letter from Paul Wollner 2. Letter from Link Infinity 3. LOA Issued to IPDC Solutions for announcing?156.241.3.0/24?from AS134190? ? ? ? 4.? ? ?Letter from IPDCFYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is also providing IP management service to other third parties in all regions, for full disclosure, LARUS and Cloud Innovation are headed by same CEO.Content of those letters have been posted here for your convince:IPDC:FOR IMMEDIATE RELEASE?[Perusal of Cloud Innovation Ltd]IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate relationship we were given the authority to use address block?156.241.3.0/24?since 9th December 2019.?On 12th December 2019, we have delegated that address block to our client. Following which our client further instructed us to announce the prefix with AS37353.?In good will after minimal verification through WHOIS? IP Prefix we have proceeded to execute our client?s request.?On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and immediate action has been taken to rectify this situation.?IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud Innovation Ltd.?IPDC however, does not wish to disclose our client information and our client information shall remain confidential under present circumstances. Once again, we apologize for our shortcomings.?Link Infinity:To whom it may concern,We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to use?156.241.3.0/24?from them. Beginning December, 2019, we delegated the right to announce this prefix to IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to announce the space which was subsequently received. IPDC subsequently and without our knowledge delegated this space to one of their customers and allowed them to originate it from AS37353.This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation.Unfortunately, we were not aware of the situation until after it had already been resolved.It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We do not condone this and apologize sincerely to the community for what has happened here.Sincere Apologies,Paul Wollner:8 May 2020TO WHOM IT MAY CONCERN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air.?The IP route objects were created by myself for Cloud Innovation when they signed up as a client of Macrolan ( now SEACOM) as they didn't have their own AS.At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October 2019.It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were never cleaned up.This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects.RegardsPaul Wollner082-786-9776On Fri, 8 May 2020 at 22:08, Mark Tinka wrote: 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. _______________________________________________ Community-Discuss mailing list Community-Discuss at afrinic.net https://lists.afrinic.net/mailman/listinfo/community-discuss -- --Kind regards.Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From amessinoukossi at gmail.com Sat May 23 22:54:55 2020 From: amessinoukossi at gmail.com (Kossi Amessinou) Date: Sat, 23 May 2020 23:54:55 +0100 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Thanks Mr. Ehoumi for your d?tail. We are waiting for afrinic staff answer. Thank you. Le sam. 23 mai 2020 ? 15:21, Gregoire EHOUMI via Community-Discuss < community-discuss at afrinic.net> a ?crit : > Hello, > > Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. > > I carefully read your report and also the Cloud Innovation Limited quick > response including their attachments as justifications. > > I note that; > > ? the service contract with Cloud Innovation covering the announcement of > their prefixes by SEACOM AS37353 was terminated by SEACOM. > > ? some stale IRR route objects existed after termination of the contract. > > ? through some multiple layer distribution an organisation in Manila > Philippines was ?delegated? an IP block from Cloud Innovation address space. > > ? both upstream ISP and the customer in Manila set up a BGP session using > SEACOM's AS37353 as the ASN of the Manila customer. > > ? there was a prompt reaction from the involved parties that included > apologies to SEACOM and the wider internet community. > > ? there were promises from said parties to be a better netizen which would > mean, them not hijacking other networks ASN's. > > ? there was clear refusal to disclose the details of the customer in > Manila Philippines who hijacked the affected SEACOM ASN. > > All put together, demonstrates that what happened was an impersonation and > not a BGP configuration error, nor an oversight in checking the right to > use of the SEACOM ASN. > > 1. Why is it that the real customer did not bother presenting its > apologies to the community > > 2. Why is there refusal to reveal customer?s details? > > 3. Why is it that the said prefix is no longer seen in the routing table > originated by the genius ASN or any other ASN? > > 4. Which networks were involved and what happened to the end users? > > Can someone from AFRINIC explain what ?delegation of IP block? mean? > > Note: The self organised Internet knows how to deal with bad net citizens.! > > Best regards > Gregoire Ehoumi > > > -------- Original message -------- > From: Lu Heng > Date: 2020-05-09 5:41 a.m. (GMT-05:00) > To: General Discussions of AFRINIC > Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor, If > Not Criminal, Netizenship > > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud > Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > Innovation) but rather belonged to Seacom through their acquisition of > MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was > criminal or bad netizenship on the part of Cloud Innovation is without > foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of > Macrolan who created IRR routes to allow Macrolan to announce Cloud > Innovation's prefix); letter from Link Infinity International Ltd. (Link > Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > authorizing IPDC Solutions to announce the prefix with origin AS134190. > And a Letter from IPDC. This was an innocent mistake committed by third > parties and had nothing to do with any action by Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. > > > Link Infinity further delegated that same /24 to IPDC and asked Cloud > innovation to issue an LOA, which we did. The LOA specifically required > IPDC to use its own ASN to announce the space (AS134190). > > IPDC subsequently authorized one of its customers to use the said prefix. > > > For reasons still unknown to Cloud Innovation, IPDC and their customer set > up a BGP session wherein their customer used AS37353 as the origin to > advertise prefix 156.241.3.0/24. > > > Upon discovering the announcement, rather than contact Cloud Innovation, > Mark contacted IPDC who provided him with an incomplete explanation blaming > their customer and Mark, not realizing that Cloud Innovation was not the > customer in question posted far and wide about the event. It is unclear to > us why he chose to do this rather than contact us to try and resolve the > issue. > > > A contributing factor to the erroneous BGP configuration by IPDC's > customer may have been data contained in some outdated IRR route objects > for 156.241.0.0/16 which have subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began to > investigate the situation. As soon as it was clear that this was the result > of third-party actions, we reached out to Mark privately to let him know > what we knew and that we were still investigating. We delayed making a > public statement in order to try and ascertain all of the facts of the > situation. We prefer not to make public statements based on incomplete > information. > > We apologize to the community for our small part in this unfortunate > incident and assure you that we work very hard to remain good netizens and > will address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1. Letter from Paul Wollner > 2. Letter from Link Infinity > 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > AS134190 > 4. Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, while > LARUS is also providing IP management service to other third parties in all > regions, for full disclosure, LARUS and Cloud Innovation are headed by same > CEO. > > Content of those letters have been posted here for your convince: > > *IPDC:* > > FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > over the course of our corporate relationship we were given the authority > to use address block 156.241.3.0/24 since 9th December 2019. > > > On 12th December 2019, we have delegated that address block to our client. > Following which our client further instructed us to announce the prefix > with AS37353. In good will after minimal verification through WHOIS? IP > Prefix we have proceeded to execute our client?s request. > > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > of record for that ASN and have since learned that the customer?s use of > that ASN was erroneous and not permitted by SEACOM and immediate action has > been taken to rectify this situation. > > > IPDC would like to apologize for our lack of attention in conducting > thorough verification and wish to highlight that the involvement of Cloud > Innovation Ltd in the entire process was providing the addresses to us and > that we truly apologize as we understand that this incident may have > indirectly implicated Cloud Innovation Ltd. > > > IPDC however, does not wish to disclose our client information and our > client information shall remain confidential under present circumstances. > Once again, we apologize for our shortcomings. > > > *Link Infinity:* > > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and > in the course received rights to use 156.241.3.0/24 from them. Beginning > December, 2019, we delegated the right to announce this prefix to IPDC > Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > authorizing them to announce the space which was subsequently received. > IPDC subsequently and without our knowledge delegated this space to one of > their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA > provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had > already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be > announced from a hijacked ASN. We do not condone this and apologize > sincerely to the community for what has happened here. > > Sincere Apologies, > > > *Paul Wollner:* > > > 8 May 2020 > > TO WHOM IT MAY CONCERN > > In the light of the recent email on NAPAfrica mailing list, I would just > like to clear the air. > > > The IP route objects were created by myself for Cloud Innovation when they > signed up as a client of Macrolan ( now SEACOM) as they didn't have their > own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment > of SEACOM in October 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an > end, the route objects were never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no > access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud > Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > Innovation) but rather belonged to Seacom through their acquisition of > MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was > criminal or bad netizenship on the part of Cloud Innovation is without > foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of > Macrolan who created IRR routes to allow Macrolan to announce Cloud > Innovation's prefix); letter from Link Infinity International Ltd. (Link > Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > authorizing IPDC Solutions to announce the prefix with origin AS134190. > And a Letter from IPDC. This was an innocent mistake committed by third > parties and had nothing to do with any action by Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. > > > Link Infinity further delegated that same /24 to IPDC and asked Cloud > innovation to issue an LOA, which we did. The LOA specifically required > IPDC to use its own ASN to announce the space (AS134190). > > IPDC subsequently authorized one of its customers to use the said prefix. > > > For reasons still unknown to Cloud Innovation, IPDC and their customer set > up a BGP session wherein their customer used AS37353 as the origin to > advertise prefix 156.241.3.0/24. > > > Upon discovering the announcement, rather than contact Cloud Innovation, > Mark contacted IPDC who provided him with an incomplete explanation blaming > their customer and Mark, not realizing that Cloud Innovation was not the > customer in question posted far and wide about the event. It is unclear to > us why he chose to do this rather than contact us to try and resolve the > issue. > > > A contributing factor to the erroneous BGP configuration by IPDC's > customer may have been data contained in some outdated IRR route objects > for 156.241.0.0/16 which have subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began to > investigate the situation. As soon as it was clear that this was the result > of third-party actions, we reached out to Mark privately to let him know > what we knew and that we were still investigating. We delayed making a > public statement in order to try and ascertain all of the facts of the > situation. We prefer not to make public statements based on incomplete > information. > > We apologize to the community for our small part in this unfortunate > incident and assure you that we work very hard to remain good netizens and > will address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1. Letter from Paul Wollner > 2. Letter from Link Infinity > 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > AS134190 > 4. Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, while > LARUS is also providing IP management service to other third parties in all > regions, for full disclosure, LARUS and Cloud Innovation are headed by same > CEO. > > Content of those letters have been posted here for your convince: > > *IPDC:* > > FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > over the course of our corporate relationship we were given the authority > to use address block 156.241.3.0/24 since 9th December 2019. > > > On 12th December 2019, we have delegated that address block to our client. > Following which our client further instructed us to announce the prefix > with AS37353. In good will after minimal verification through WHOIS? IP > Prefix we have proceeded to execute our client?s request. > > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > of record for that ASN and have since learned that the customer?s use of > that ASN was erroneous and not permitted by SEACOM and immediate action has > been taken to rectify this situation. > > > IPDC would like to apologize for our lack of attention in conducting > thorough verification and wish to highlight that the involvement of Cloud > Innovation Ltd in the entire process was providing the addresses to us and > that we truly apologize as we understand that this incident may have > indirectly implicated Cloud Innovation Ltd. > > > IPDC however, does not wish to disclose our client information and our > client information shall remain confidential under present circumstances. > Once again, we apologize for our shortcomings. > > > *Link Infinity:* > > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and > in the course received rights to use 156.241.3.0/24 from them. Beginning > December, 2019, we delegated the right to announce this prefix to IPDC > Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > authorizing them to announce the space which was subsequently received. > IPDC subsequently and without our knowledge delegated this space to one of > their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA > provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had > already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be > announced from a hijacked ASN. We do not condone this and apologize > sincerely to the community for what has happened here. > > Sincere Apologies, > > > *Paul Wollner:* > > > 8 May 2020 > > TO WHOM IT MAY CONCERN > > In the light of the recent email on NAPAfrica mailing list, I would just > like to clear the air. > > > The IP route objects were created by myself for Cloud Innovation when they > signed up as a client of Macrolan ( now SEACOM) as they didn't have their > own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment > of SEACOM in October 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an > end, the route objects were never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no > access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > > On Fri, 8 May 2020 at 22:08, Mark Tinka wrote: > >> 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. >> _______________________________________________ >> Community-Discuss mailing list >> Community-Discuss at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/community-discuss >> > > > -- > -- > Kind regards. > Lu > > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amelnaud at gmail.com Mon May 25 01:28:10 2020 From: amelnaud at gmail.com (Arnaud AMELINA) Date: Mon, 25 May 2020 01:28:10 +0000 Subject: [Community-Discuss] [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Hello, community +1 @Gregoire and @Mark Tinka *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* with *no ASN*. Interesting, and no *v6* While the bylaws defines LIR as followed: ++++++ Local Internet Registry (LIR): any Network Operator that provides Internet services to distinct end-users and end-sites ++++++ I wonder which network does cloud innovation operate and which internet services it provides to end-users and end-sites in *Africa*. How does this network *managing 3 x /11 of IPv4* *operate*? There is something here for the community to learn about. Regards -- Arnaud Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a ?crit : > Hello, > > Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. > > I carefully read your report and also the Cloud Innovation Limited quick > response including their attachments as justifications. > > I note that; > > ? the service contract with Cloud Innovation covering the announcement of > their prefixes by SEACOM AS37353 was terminated by SEACOM. > > ? some stale IRR route objects existed after termination of the contract. > > ? through some multiple layer distribution an organisation in Manila > Philippines was ?delegated? an IP block from Cloud Innovation address space. > > ? both upstream ISP and the customer in Manila set up a BGP session using > SEACOM's AS37353 as the ASN of the Manila customer. > > ? there was a prompt reaction from the involved parties that included > apologies to SEACOM and the wider internet community. > > ? there were promises from said parties to be a better netizen which would > mean, them not hijacking other networks ASN's. > > ? there was clear refusal to disclose the details of the customer in > Manila Philippines who hijacked the affected SEACOM ASN. > > All put together, demonstrates that what happened was an impersonation and > not a BGP configuration error, nor an oversight in checking the right to > use of the SEACOM ASN. > > 1. Why is it that the real customer did not bother presenting its > apologies to the community > > 2. Why is there refusal to reveal customer?s details? > > 3. Why is it that the said prefix is no longer seen in the routing table > originated by the genius ASN or any other ASN? > > 4. Which networks were involved and what happened to the end users? > > Can someone from AFRINIC explain what ?delegation of IP block? mean? > > Note: The self organised Internet knows how to deal with bad net citizens.! > > Best regards > Gregoire Ehoumi > > > -------- Original message -------- > From: Lu Heng > Date: 2020-05-09 5:43 a.m. (GMT-05:00) > To: Mark Tinka > Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < > rpd at afrinic.net> > Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, > Netizenship > > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud > Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > Innovation) but rather belonged to Seacom through their acquisition of > MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was > criminal or bad netizenship on the part of Cloud Innovation is without > foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of > Macrolan who created IRR routes to allow Macrolan to announce Cloud > Innovation's prefix); letter from Link Infinity International Ltd. (Link > Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > authorizing IPDC Solutions to announce the prefix with origin AS134190. > And a Letter from IPDC. This was an innocent mistake committed by third > parties and had nothing to do with any action by Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. > > > Link Infinity further delegated that same /24 to IPDC and asked Cloud > innovation to issue an LOA, which we did. The LOA specifically required > IPDC to use its own ASN to announce the space (AS134190). > > IPDC subsequently authorized one of its customers to use the said prefix. > > > For reasons still unknown to Cloud Innovation, IPDC and their customer set > up a BGP session wherein their customer used AS37353 as the origin to > advertise prefix 156.241.3.0/24. > > > Upon discovering the announcement, rather than contact Cloud Innovation, > Mark contacted IPDC who provided him with an incomplete explanation blaming > their customer and Mark, not realizing that Cloud Innovation was not the > customer in question posted far and wide about the event. It is unclear to > us why he chose to do this rather than contact us to try and resolve the > issue. > > > A contributing factor to the erroneous BGP configuration by IPDC's > customer may have been data contained in some outdated IRR route objects > for 156.241.0.0/16 which have subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began to > investigate the situation. As soon as it was clear that this was the result > of third-party actions, we reached out to Mark privately to let him know > what we knew and that we were still investigating. We delayed making a > public statement in order to try and ascertain all of the facts of the > situation. We prefer not to make public statements based on incomplete > information. > > We apologize to the community for our small part in this unfortunate > incident and assure you that we work very hard to remain good netizens and > will address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1. Letter from Paul Wollner > 2. Letter from Link Infinity > 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > AS134190 > 4. Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, while > LARUS is also providing IP management service to other third parties in all > regions, for full disclosure, LARUS and Cloud Innovation are headed by same > CEO. > > Content of those letters have been posted here for your convince: > > *IPDC:* > > FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > over the course of our corporate relationship we were given the authority > to use address block 156.241.3.0/24 since 9th December 2019. > > > On 12th December 2019, we have delegated that address block to our client. > Following which our client further instructed us to announce the prefix > with AS37353. In good will after minimal verification through WHOIS? IP > Prefix we have proceeded to execute our client?s request. > > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > of record for that ASN and have since learned that the customer?s use of > that ASN was erroneous and not permitted by SEACOM and immediate action has > been taken to rectify this situation. > > > IPDC would like to apologize for our lack of attention in conducting > thorough verification and wish to highlight that the involvement of Cloud > Innovation Ltd in the entire process was providing the addresses to us and > that we truly apologize as we understand that this incident may have > indirectly implicated Cloud Innovation Ltd. > > > IPDC however, does not wish to disclose our client information and our > client information shall remain confidential under present circumstances. > Once again, we apologize for our shortcomings. > > > *Link Infinity:* > > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and > in the course received rights to use 156.241.3.0/24 from them. Beginning > December, 2019, we delegated the right to announce this prefix to IPDC > Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > authorizing them to announce the space which was subsequently received. > IPDC subsequently and without our knowledge delegated this space to one of > their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA > provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had > already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be > announced from a hijacked ASN. We do not condone this and apologize > sincerely to the community for what has happened here. > > Sincere Apologies, > > > *Paul Wollner:* > > > 8 May 2020 > > TO WHOM IT MAY CONCERN > > In the light of the recent email on NAPAfrica mailing list, I would just > like to clear the air. > > > The IP route objects were created by myself for Cloud Innovation when they > signed up as a client of Macrolan ( now SEACOM) as they didn't have their > own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment > of SEACOM in October 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an > end, the route objects were never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no > access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > > > > On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: > >> 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. >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > > > -- > -- > Kind regards. > Lu > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oloyede.aa at unilorin.edu.ng Mon May 25 12:00:22 2020 From: oloyede.aa at unilorin.edu.ng (ABDULKARIM AYOPO OLOYEDE) Date: Mon, 25 May 2020 13:00:22 +0100 Subject: [Community-Discuss] [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Dear All, Please let us all be reminded that this mailing list is to discuss policies and directly related issues. There are other mailing lists where issues like this can be discussed but definitely not here because the issue is *out of scope* for this mailing list Please, Co-Chairs would like us to put an end to this discussion. CO-Chairs PDWG On Mon, May 25, 2020 at 12:31 PM Paschal Ochang wrote: > This sounds like a personal attack in my opinion instead of a justified > accusation. Why is this topic allowed to be discussed here when it?s rather > irrelevant?. The parties involved have tendered formal apologies as > reflected in their letters which is a sign of admittance and promotes the > intent of good netizenship. It?s just irrelevant. > > On Monday, May 25, 2020, Arnaud AMELINA wrote: > >> Hello, community >> >> +1 @Gregoire and @Mark Tinka >> >> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* >> with *no ASN*. Interesting, and no *v6* >> >> While the bylaws defines LIR as followed: >> ++++++ >> Local Internet Registry (LIR): >> any Network Operator that provides Internet services to distinct >> end-users and end-sites >> ++++++ >> >> I wonder which network does cloud innovation operate and which internet >> services it provides to end-users and end-sites in *Africa*. >> >> How does this network *managing 3 x /11 of IPv4* *operate*? >> >> There is something here for the community to learn about. >> >> Regards >> >> -- >> Arnaud >> >> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a >> ?crit : >> >>> Hello, >>> >>> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. >>> >>> I carefully read your report and also the Cloud Innovation Limited quick >>> response including their attachments as justifications. >>> >>> I note that; >>> >>> ? the service contract with Cloud Innovation covering the announcement >>> of their prefixes by SEACOM AS37353 was terminated by SEACOM. >>> >>> ? some stale IRR route objects existed after termination of the contract. >>> >>> ? through some multiple layer distribution an organisation in Manila >>> Philippines was ?delegated? an IP block from Cloud Innovation address space. >>> >>> ? both upstream ISP and the customer in Manila set up a BGP session >>> using SEACOM's AS37353 as the ASN of the Manila customer. >>> >>> ? there was a prompt reaction from the involved parties that included >>> apologies to SEACOM and the wider internet community. >>> >>> ? there were promises from said parties to be a better netizen which >>> would mean, them not hijacking other networks ASN's. >>> >>> ? there was clear refusal to disclose the details of the customer in >>> Manila Philippines who hijacked the affected SEACOM ASN. >>> >>> All put together, demonstrates that what happened was an impersonation >>> and not a BGP configuration error, nor an oversight in checking the right >>> to use of the SEACOM ASN. >>> >>> 1. Why is it that the real customer did not bother presenting its >>> apologies to the community >>> >>> 2. Why is there refusal to reveal customer?s details? >>> >>> 3. Why is it that the said prefix is no longer seen in the routing table >>> originated by the genius ASN or any other ASN? >>> >>> 4. Which networks were involved and what happened to the end users? >>> >>> Can someone from AFRINIC explain what ?delegation of IP block? mean? >>> >>> Note: The self organised Internet knows how to deal with bad net >>> citizens.! >>> >>> Best regards >>> Gregoire Ehoumi >>> >>> >>> -------- Original message -------- >>> From: Lu Heng >>> Date: 2020-05-09 5:43 a.m. (GMT-05:00) >>> To: Mark Tinka >>> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < >>> rpd at afrinic.net> >>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, >>> Netizenship >>> >>> To whom it may concern, >>> >>> On May 8, Mark Think posted a claim to multiple lists that Cloud >>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud >>> Innovation) but rather belonged to Seacom through their acquisition of >>> MacroLAN. >>> >>> While we regret this unfortunate incident, Mark?s claims that it was >>> criminal or bad netizenship on the part of Cloud Innovation is without >>> foundation and utterly incorrect. >>> >>> As shown below in the attached document from Paul Wollner(Ex-CTO of >>> Macrolan who created IRR routes to allow Macrolan to announce Cloud >>> Innovation's prefix); letter from Link Infinity International Ltd. (Link >>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS >>> authorizing IPDC Solutions to announce the prefix with origin AS134190. >>> And a Letter from IPDC. This was an innocent mistake committed by third >>> parties and had nothing to do with any action by Cloud Innovation or LARUS. >>> >>> Here?s what happened: >>> >>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December >>> 2019. >>> >>> >>> Link Infinity further delegated that same /24 to IPDC and asked Cloud >>> innovation to issue an LOA, which we did. The LOA specifically required >>> IPDC to use its own ASN to announce the space (AS134190). >>> >>> IPDC subsequently authorized one of its customers to use the said prefix. >>> >>> >>> For reasons still unknown to Cloud Innovation, IPDC and their customer >>> set up a BGP session wherein their customer used AS37353 as the origin to >>> advertise prefix 156.241.3.0/24. >>> >>> >>> Upon discovering the announcement, rather than contact Cloud Innovation, >>> Mark contacted IPDC who provided him with an incomplete explanation blaming >>> their customer and Mark, not realizing that Cloud Innovation was not the >>> customer in question posted far and wide about the event. It is unclear to >>> us why he chose to do this rather than contact us to try and resolve the >>> issue. >>> >>> >>> A contributing factor to the erroneous BGP configuration by IPDC's >>> customer may have been data contained in some outdated IRR route objects >>> for 156.241.0.0/16 which have subsequently been deleted. >>> >>> As soon as we became aware of the problem (via Mark?s email), we began >>> to investigate the situation. As soon as it was clear that this was the >>> result of third-party actions, we reached out to Mark privately to let him >>> know what we knew and that we were still investigating. We delayed making a >>> public statement in order to try and ascertain all of the facts of the >>> situation. We prefer not to make public statements based on incomplete >>> information. >>> >>> We apologize to the community for our small part in this unfortunate >>> incident and assure you that we work very hard to remain good netizens and >>> will address any concerns promptly when they come to our attention. >>> >>> >>> Sincerely, >>> >>> Lu Heng >>> CEO >>> Cloud Innovations >>> >>> Attached: >>> 1. Letter from Paul Wollner >>> 2. Letter from Link Infinity >>> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from >>> AS134190 >>> 4. Letter from IPDC >>> >>> FYI: LARUS is proving IP management service for Cloud Innovation, while >>> LARUS is also providing IP management service to other third parties in all >>> regions, for full disclosure, LARUS and Cloud Innovation are headed by same >>> CEO. >>> >>> Content of those letters have been posted here for your convince: >>> >>> *IPDC:* >>> >>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] >>> >>> >>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and >>> over the course of our corporate relationship we were given the authority >>> to use address block 156.241.3.0/24 since 9th December 2019. >>> >>> >>> On 12th December 2019, we have delegated that address block to our >>> client. Following which our client further instructed us to announce the >>> prefix with AS37353. In good will after minimal verification through WHOIS? >>> IP Prefix we have proceeded to execute our client?s request. >>> >>> >>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder >>> of record for that ASN and have since learned that the customer?s use of >>> that ASN was erroneous and not permitted by SEACOM and immediate action has >>> been taken to rectify this situation. >>> >>> >>> IPDC would like to apologize for our lack of attention in conducting >>> thorough verification and wish to highlight that the involvement of Cloud >>> Innovation Ltd in the entire process was providing the addresses to us and >>> that we truly apologize as we understand that this incident may have >>> indirectly implicated Cloud Innovation Ltd. >>> >>> >>> IPDC however, does not wish to disclose our client information and our >>> client information shall remain confidential under present circumstances. >>> Once again, we apologize for our shortcomings. >>> >>> >>> *Link Infinity:* >>> >>> >>> To whom it may concern, >>> >>> We at HK Infinity International Ltd are a customer of Cloud Innovation >>> and in the course received rights to use 156.241.3.0/24 from them. >>> Beginning December, 2019, we delegated the right to announce this prefix to >>> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA >>> authorizing them to announce the space which was subsequently received. >>> IPDC subsequently and without our knowledge delegated this space to one of >>> their customers and allowed them to originate it from AS37353. >>> >>> This announcement was not authorized by us, nor is it permitted by the >>> LOA provided by Cloud Innovation. >>> >>> Unfortunately, we were not aware of the situation until after it had >>> already been resolved. >>> >>> It was never our intent to violate the LOA or to allow the prefix to be >>> announced from a hijacked ASN. We do not condone this and apologize >>> sincerely to the community for what has happened here. >>> >>> Sincere Apologies, >>> >>> >>> *Paul Wollner:* >>> >>> >>> 8 May 2020 >>> >>> TO WHOM IT MAY CONCERN >>> >>> In the light of the recent email on NAPAfrica mailing list, I would just >>> like to clear the air. >>> >>> >>> The IP route objects were created by myself for Cloud Innovation when >>> they signed up as a client of Macrolan ( now SEACOM) as they didn't have >>> their own AS. >>> >>> At the time I was working for Macrolan (now SEACOM). I left the >>> employment of SEACOM in October 2019. >>> >>> It appears that when Cloud Innovation's contract with SEACOM came to an >>> end, the route objects were never cleaned up. >>> >>> This occurred after I left SEACOM's employment. Since leaving, I have no >>> access to these objects. >>> >>> Regards >>> >>> Paul Wollner >>> 082-786-9776 >>> >>> >>> >>> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: >>> >>>> 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. >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>> >>> >>> -- >>> -- >>> Kind regards. >>> Lu >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -- Website ,?Weekly Bulletin ?UGPortal PGPortal -------------- next part -------------- An HTML attachment was scrubbed... URL: From libren at tuta.io Mon May 25 13:47:06 2020 From: libren at tuta.io (libren at tuta.io) Date: Mon, 25 May 2020 15:47:06 +0200 (CEST) Subject: [Community-Discuss] [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Hello, Very interesting question of 3 x /11 allocated to Cloud Innovations. Regards, Libren -- Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com May 25, 2020, 15:00 by community-discuss-request at afrinic.net: > Send Community-Discuss mailing list submissions to > community-discuss at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/community-discuss > or, via email, send a message with subject or body 'help' to > community-discuss-request at afrinic.net > > You can reach the person managing the list at > community-discuss-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Community-Discuss digest..." > > > Today's Topics: > > 1. Re: [rpd] Cloud Innovation Displays Very Poor, If Not > Criminal, Netizenship (Arnaud AMELINA) > 2. Re: [rpd] Cloud Innovation Displays Very Poor, If Not > Criminal, Netizenship (ABDULKARIM AYOPO OLOYEDE) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 May 2020 01:28:10 +0000 > From: Arnaud AMELINA > To: Gregoire EHOUMI > Cc: General Discussions of AFRINIC , > "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" > > Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very > Poor, If Not Criminal, Netizenship > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hello, community > > +1 @Gregoire and @Mark Tinka > > *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* > with *no ASN*. Interesting, and no *v6* > > While the bylaws defines LIR as followed: > ++++++ > Local Internet Registry (LIR): > any Network Operator that provides Internet services to distinct end-users > and end-sites > ++++++ > > I wonder which network does cloud innovation operate and which internet > services it provides to end-users and end-sites in *Africa*. > > How does this network *managing 3 x /11 of IPv4* *operate*? > > There is something here for the community to learn about. > > Regards > > -- > Arnaud > > Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a > ?crit : > >> Hello, >> >> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. >> >> I carefully read your report and also the Cloud Innovation Limited quick >> response including their attachments as justifications. >> >> I note that; >> >> ? the service contract with Cloud Innovation covering the announcement of >> their prefixes by SEACOM AS37353 was terminated by SEACOM. >> >> ? some stale IRR route objects existed after termination of the contract. >> >> ? through some multiple layer distribution an organisation in Manila >> Philippines was ?delegated? an IP block from Cloud Innovation address space. >> >> ? both upstream ISP and the customer in Manila set up a BGP session using >> SEACOM's AS37353 as the ASN of the Manila customer. >> >> ? there was a prompt reaction from the involved parties that included >> apologies to SEACOM and the wider internet community. >> >> ? there were promises from said parties to be a better netizen which would >> mean, them not hijacking other networks ASN's. >> >> ? there was clear refusal to disclose the details of the customer in >> Manila Philippines who hijacked the affected SEACOM ASN. >> >> All put together, demonstrates that what happened was an impersonation and >> not a BGP configuration error, nor an oversight in checking the right to >> use of the SEACOM ASN. >> >> 1. Why is it that the real customer did not bother presenting its >> apologies to the community >> >> 2. Why is there refusal to reveal customer?s details? >> >> 3. Why is it that the said prefix is no longer seen in the routing table >> originated by the genius ASN or any other ASN? >> >> 4. Which networks were involved and what happened to the end users? >> >> Can someone from AFRINIC explain what ?delegation of IP block? mean? >> >> Note: The self organised Internet knows how to deal with bad net citizens.! >> >> Best regards >> Gregoire Ehoumi >> >> >> -------- Original message -------- >> From: Lu Heng >> Date: 2020-05-09 5:43 a.m. (GMT-05:00) >> To: Mark Tinka >> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < >> rpd at afrinic.net> >> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, >> Netizenship >> >> To whom it may concern, >> >> On May 8, Mark Think posted a claim to multiple lists that Cloud >> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud >> Innovation) but rather belonged to Seacom through their acquisition of >> MacroLAN. >> >> While we regret this unfortunate incident, Mark?s claims that it was >> criminal or bad netizenship on the part of Cloud Innovation is without >> foundation and utterly incorrect. >> >> As shown below in the attached document from Paul Wollner(Ex-CTO of >> Macrolan who created IRR routes to allow Macrolan to announce Cloud >> Innovation's prefix); letter from Link Infinity International Ltd. (Link >> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS >> authorizing IPDC Solutions to announce the prefix with origin AS134190. >> And a Letter from IPDC. This was an innocent mistake committed by third >> parties and had nothing to do with any action by Cloud Innovation or LARUS. >> >> Here?s what happened: >> >> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. >> >> >> Link Infinity further delegated that same /24 to IPDC and asked Cloud >> innovation to issue an LOA, which we did. The LOA specifically required >> IPDC to use its own ASN to announce the space (AS134190). >> >> IPDC subsequently authorized one of its customers to use the said prefix. >> >> >> For reasons still unknown to Cloud Innovation, IPDC and their customer set >> up a BGP session wherein their customer used AS37353 as the origin to >> advertise prefix 156.241.3.0/24. >> >> >> Upon discovering the announcement, rather than contact Cloud Innovation, >> Mark contacted IPDC who provided him with an incomplete explanation blaming >> their customer and Mark, not realizing that Cloud Innovation was not the >> customer in question posted far and wide about the event. It is unclear to >> us why he chose to do this rather than contact us to try and resolve the >> issue. >> >> >> A contributing factor to the erroneous BGP configuration by IPDC's >> customer may have been data contained in some outdated IRR route objects >> for 156.241.0.0/16 which have subsequently been deleted. >> >> As soon as we became aware of the problem (via Mark?s email), we began to >> investigate the situation. As soon as it was clear that this was the result >> of third-party actions, we reached out to Mark privately to let him know >> what we knew and that we were still investigating. We delayed making a >> public statement in order to try and ascertain all of the facts of the >> situation. We prefer not to make public statements based on incomplete >> information. >> >> We apologize to the community for our small part in this unfortunate >> incident and assure you that we work very hard to remain good netizens and >> will address any concerns promptly when they come to our attention. >> >> >> Sincerely, >> >> Lu Heng >> CEO >> Cloud Innovations >> >> Attached: >> 1. Letter from Paul Wollner >> 2. Letter from Link Infinity >> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from >> AS134190 >> 4. Letter from IPDC >> >> FYI: LARUS is proving IP management service for Cloud Innovation, while >> LARUS is also providing IP management service to other third parties in all >> regions, for full disclosure, LARUS and Cloud Innovation are headed by same >> CEO. >> >> Content of those letters have been posted here for your convince: >> >> *IPDC:* >> >> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] >> >> >> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and >> over the course of our corporate relationship we were given the authority >> to use address block 156.241.3.0/24 since 9th December 2019. >> >> >> On 12th December 2019, we have delegated that address block to our client. >> Following which our client further instructed us to announce the prefix >> with AS37353. In good will after minimal verification through WHOIS? IP >> Prefix we have proceeded to execute our client?s request. >> >> >> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder >> of record for that ASN and have since learned that the customer?s use of >> that ASN was erroneous and not permitted by SEACOM and immediate action has >> been taken to rectify this situation. >> >> >> IPDC would like to apologize for our lack of attention in conducting >> thorough verification and wish to highlight that the involvement of Cloud >> Innovation Ltd in the entire process was providing the addresses to us and >> that we truly apologize as we understand that this incident may have >> indirectly implicated Cloud Innovation Ltd. >> >> >> IPDC however, does not wish to disclose our client information and our >> client information shall remain confidential under present circumstances. >> Once again, we apologize for our shortcomings. >> >> >> *Link Infinity:* >> >> >> To whom it may concern, >> >> We at HK Infinity International Ltd are a customer of Cloud Innovation and >> in the course received rights to use 156.241.3.0/24 from them. Beginning >> December, 2019, we delegated the right to announce this prefix to IPDC >> Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA >> authorizing them to announce the space which was subsequently received. >> IPDC subsequently and without our knowledge delegated this space to one of >> their customers and allowed them to originate it from AS37353. >> >> This announcement was not authorized by us, nor is it permitted by the LOA >> provided by Cloud Innovation. >> >> Unfortunately, we were not aware of the situation until after it had >> already been resolved. >> >> It was never our intent to violate the LOA or to allow the prefix to be >> announced from a hijacked ASN. We do not condone this and apologize >> sincerely to the community for what has happened here. >> >> Sincere Apologies, >> >> >> *Paul Wollner:* >> >> >> 8 May 2020 >> >> TO WHOM IT MAY CONCERN >> >> In the light of the recent email on NAPAfrica mailing list, I would just >> like to clear the air. >> >> >> The IP route objects were created by myself for Cloud Innovation when they >> signed up as a client of Macrolan ( now SEACOM) as they didn't have their >> own AS. >> >> At the time I was working for Macrolan (now SEACOM). I left the employment >> of SEACOM in October 2019. >> >> It appears that when Cloud Innovation's contract with SEACOM came to an >> end, the route objects were never cleaned up. >> >> This occurred after I left SEACOM's employment. Since leaving, I have no >> access to these objects. >> >> Regards >> >> Paul Wollner >> 082-786-9776 >> >> >> >> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: >> >>> 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. >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> >> >> -- >> -- >> Kind regards. >> Lu >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Mon, 25 May 2020 13:00:22 +0100 > From: ABDULKARIM AYOPO OLOYEDE > To: Paschal Ochang > Cc: General Discussions of AFRINIC , > "rpd >> AfriNIC Resource Policy" > Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very > Poor, If Not Criminal, Netizenship > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Dear All, > Please let us all be reminded that this mailing list is to discuss > policies and directly related issues. > There are other mailing lists where issues like this can be discussed but > definitely not here because the issue is *out of scope* for this mailing > list > Please, Co-Chairs would like us to put an end to this discussion. > > CO-Chairs > PDWG > > > On Mon, May 25, 2020 at 12:31 PM Paschal Ochang wrote: > >> This sounds like a personal attack in my opinion instead of a justified >> accusation. Why is this topic allowed to be discussed here when it?s rather >> irrelevant?. The parties involved have tendered formal apologies as >> reflected in their letters which is a sign of admittance and promotes the >> intent of good netizenship. It?s just irrelevant. >> >> On Monday, May 25, 2020, Arnaud AMELINA wrote: >> >>> Hello, community >>> >>> +1 @Gregoire and @Mark Tinka >>> >>> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* >>> with *no ASN*. Interesting, and no *v6* >>> >>> While the bylaws defines LIR as followed: >>> ++++++ >>> Local Internet Registry (LIR): >>> any Network Operator that provides Internet services to distinct >>> end-users and end-sites >>> ++++++ >>> >>> I wonder which network does cloud innovation operate and which internet >>> services it provides to end-users and end-sites in *Africa*. >>> >>> How does this network *managing 3 x /11 of IPv4* *operate*? >>> >>> There is something here for the community to learn about. >>> >>> Regards >>> >>> -- >>> Arnaud >>> >>> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a >>> ?crit : >>> >>>> Hello, >>>> >>>> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. >>>> >>>> I carefully read your report and also the Cloud Innovation Limited quick >>>> response including their attachments as justifications. >>>> >>>> I note that; >>>> >>>> ? the service contract with Cloud Innovation covering the announcement >>>> of their prefixes by SEACOM AS37353 was terminated by SEACOM. >>>> >>>> ? some stale IRR route objects existed after termination of the contract. >>>> >>>> ? through some multiple layer distribution an organisation in Manila >>>> Philippines was ?delegated? an IP block from Cloud Innovation address space. >>>> >>>> ? both upstream ISP and the customer in Manila set up a BGP session >>>> using SEACOM's AS37353 as the ASN of the Manila customer. >>>> >>>> ? there was a prompt reaction from the involved parties that included >>>> apologies to SEACOM and the wider internet community. >>>> >>>> ? there were promises from said parties to be a better netizen which >>>> would mean, them not hijacking other networks ASN's. >>>> >>>> ? there was clear refusal to disclose the details of the customer in >>>> Manila Philippines who hijacked the affected SEACOM ASN. >>>> >>>> All put together, demonstrates that what happened was an impersonation >>>> and not a BGP configuration error, nor an oversight in checking the right >>>> to use of the SEACOM ASN. >>>> >>>> 1. Why is it that the real customer did not bother presenting its >>>> apologies to the community >>>> >>>> 2. Why is there refusal to reveal customer?s details? >>>> >>>> 3. Why is it that the said prefix is no longer seen in the routing table >>>> originated by the genius ASN or any other ASN? >>>> >>>> 4. Which networks were involved and what happened to the end users? >>>> >>>> Can someone from AFRINIC explain what ?delegation of IP block? mean? >>>> >>>> Note: The self organised Internet knows how to deal with bad net >>>> citizens.! >>>> >>>> Best regards >>>> Gregoire Ehoumi >>>> >>>> >>>> -------- Original message -------- >>>> From: Lu Heng >>>> Date: 2020-05-09 5:43 a.m. (GMT-05:00) >>>> To: Mark Tinka >>>> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < >>>> rpd at afrinic.net> >>>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, >>>> Netizenship >>>> >>>> To whom it may concern, >>>> >>>> On May 8, Mark Think posted a claim to multiple lists that Cloud >>>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud >>>> Innovation) but rather belonged to Seacom through their acquisition of >>>> MacroLAN. >>>> >>>> While we regret this unfortunate incident, Mark?s claims that it was >>>> criminal or bad netizenship on the part of Cloud Innovation is without >>>> foundation and utterly incorrect. >>>> >>>> As shown below in the attached document from Paul Wollner(Ex-CTO of >>>> Macrolan who created IRR routes to allow Macrolan to announce Cloud >>>> Innovation's prefix); letter from Link Infinity International Ltd. (Link >>>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS >>>> authorizing IPDC Solutions to announce the prefix with origin AS134190. >>>> And a Letter from IPDC. This was an innocent mistake committed by third >>>> parties and had nothing to do with any action by Cloud Innovation or LARUS. >>>> >>>> Here?s what happened: >>>> >>>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December >>>> 2019. >>>> >>>> >>>> Link Infinity further delegated that same /24 to IPDC and asked Cloud >>>> innovation to issue an LOA, which we did. The LOA specifically required >>>> IPDC to use its own ASN to announce the space (AS134190). >>>> >>>> IPDC subsequently authorized one of its customers to use the said prefix. >>>> >>>> >>>> For reasons still unknown to Cloud Innovation, IPDC and their customer >>>> set up a BGP session wherein their customer used AS37353 as the origin to >>>> advertise prefix 156.241.3.0/24. >>>> >>>> >>>> Upon discovering the announcement, rather than contact Cloud Innovation, >>>> Mark contacted IPDC who provided him with an incomplete explanation blaming >>>> their customer and Mark, not realizing that Cloud Innovation was not the >>>> customer in question posted far and wide about the event. It is unclear to >>>> us why he chose to do this rather than contact us to try and resolve the >>>> issue. >>>> >>>> >>>> A contributing factor to the erroneous BGP configuration by IPDC's >>>> customer may have been data contained in some outdated IRR route objects >>>> for 156.241.0.0/16 which have subsequently been deleted. >>>> >>>> As soon as we became aware of the problem (via Mark?s email), we began >>>> to investigate the situation. As soon as it was clear that this was the >>>> result of third-party actions, we reached out to Mark privately to let him >>>> know what we knew and that we were still investigating. We delayed making a >>>> public statement in order to try and ascertain all of the facts of the >>>> situation. We prefer not to make public statements based on incomplete >>>> information. >>>> >>>> We apologize to the community for our small part in this unfortunate >>>> incident and assure you that we work very hard to remain good netizens and >>>> will address any concerns promptly when they come to our attention. >>>> >>>> >>>> Sincerely, >>>> >>>> Lu Heng >>>> CEO >>>> Cloud Innovations >>>> >>>> Attached: >>>> 1. Letter from Paul Wollner >>>> 2. Letter from Link Infinity >>>> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from >>>> AS134190 >>>> 4. Letter from IPDC >>>> >>>> FYI: LARUS is proving IP management service for Cloud Innovation, while >>>> LARUS is also providing IP management service to other third parties in all >>>> regions, for full disclosure, LARUS and Cloud Innovation are headed by same >>>> CEO. >>>> >>>> Content of those letters have been posted here for your convince: >>>> >>>> *IPDC:* >>>> >>>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] >>>> >>>> >>>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and >>>> over the course of our corporate relationship we were given the authority >>>> to use address block 156.241.3.0/24 since 9th December 2019. >>>> >>>> >>>> On 12th December 2019, we have delegated that address block to our >>>> client. Following which our client further instructed us to announce the >>>> prefix with AS37353. In good will after minimal verification through WHOIS? >>>> IP Prefix we have proceeded to execute our client?s request. >>>> >>>> >>>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder >>>> of record for that ASN and have since learned that the customer?s use of >>>> that ASN was erroneous and not permitted by SEACOM and immediate action has >>>> been taken to rectify this situation. >>>> >>>> >>>> IPDC would like to apologize for our lack of attention in conducting >>>> thorough verification and wish to highlight that the involvement of Cloud >>>> Innovation Ltd in the entire process was providing the addresses to us and >>>> that we truly apologize as we understand that this incident may have >>>> indirectly implicated Cloud Innovation Ltd. >>>> >>>> >>>> IPDC however, does not wish to disclose our client information and our >>>> client information shall remain confidential under present circumstances. >>>> Once again, we apologize for our shortcomings. >>>> >>>> >>>> *Link Infinity:* >>>> >>>> >>>> To whom it may concern, >>>> >>>> We at HK Infinity International Ltd are a customer of Cloud Innovation >>>> and in the course received rights to use 156.241.3.0/24 from them. >>>> Beginning December, 2019, we delegated the right to announce this prefix to >>>> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA >>>> authorizing them to announce the space which was subsequently received. >>>> IPDC subsequently and without our knowledge delegated this space to one of >>>> their customers and allowed them to originate it from AS37353. >>>> >>>> This announcement was not authorized by us, nor is it permitted by the >>>> LOA provided by Cloud Innovation. >>>> >>>> Unfortunately, we were not aware of the situation until after it had >>>> already been resolved. >>>> >>>> It was never our intent to violate the LOA or to allow the prefix to be >>>> announced from a hijacked ASN. We do not condone this and apologize >>>> sincerely to the community for what has happened here. >>>> >>>> Sincere Apologies, >>>> >>>> >>>> *Paul Wollner:* >>>> >>>> >>>> 8 May 2020 >>>> >>>> TO WHOM IT MAY CONCERN >>>> >>>> In the light of the recent email on NAPAfrica mailing list, I would just >>>> like to clear the air. >>>> >>>> >>>> The IP route objects were created by myself for Cloud Innovation when >>>> they signed up as a client of Macrolan ( now SEACOM) as they didn't have >>>> their own AS. >>>> >>>> At the time I was working for Macrolan (now SEACOM). I left the >>>> employment of SEACOM in October 2019. >>>> >>>> It appears that when Cloud Innovation's contract with SEACOM came to an >>>> end, the route objects were never cleaned up. >>>> >>>> This occurred after I left SEACOM's employment. Since leaving, I have no >>>> access to these objects. >>>> >>>> Regards >>>> >>>> Paul Wollner >>>> 082-786-9776 >>>> >>>> >>>> >>>> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: >>>> >>>>> 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. >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>> >>>> >>>> -- >>>> -- >>>> Kind regards. >>>> Lu >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>> _______________________________________________ >>> >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > > -- > Website ,?Weekly Bulletin > ?UGPortal > PGPortal > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > ------------------------------ > > End of Community-Discuss Digest, Vol 616, Issue 1 > ************************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From libren at tuta.io Mon May 25 13:57:23 2020 From: libren at tuta.io (libren at tuta.io) Date: Mon, 25 May 2020 15:57:23 +0200 (CEST) Subject: [Community-Discuss] [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Hello, Seems cloud Innovation is using USA Data Center Multacom and using their ASN. Maybe these are legacy blocks and Afrinic has no control over it? If they are not legacy blocks then what was the ip justification for acquiring these IP and what Afrinic was policy? https://bgp.he.net/AS35916#_prefixes 45.199.0.0/16 Cloud Innovation Ltd 45.201.0.0/16 Cloud Innovation Ltd 45.205.0.0/16 Cloud Innovation Ltd 154.81.0.0/16 Cloud Innovation Ltd 154.82.0.0/16 Cloud Innovation Ltd 154.83.0.0/16 Cloud Innovation Ltd 154.84.0.0/16 Cloud Innovation Ltd 154.85.0.0/16 Cloud Innovation Ltd 154.86.0.0/16 Cloud Innovation Ltd 154.87.0.0/16 Cloud Innovation Ltd 154.88.0.0/16 Cloud Innovation Ltd 154.90.0.0/16 Cloud Innovation Ltd 154.92.0.0/14 Cloud Innovation Ltd 154.193.0.0/16 Cloud Innovation Ltd 154.195.0.0/16 Cloud Innovation Ltd 154.198.0.0/16 Cloud Innovation Ltd 154.201.0.0/16 Cloud Innovation Ltd 154.202.0.0/16 Cloud Innovation Ltd 154.205.0.0/16 Cloud Innovation Ltd 154.208.0.0/16 Cloud Innovation Ltd 154.209.0.0/16 Cloud Innovation Ltd 154.212.0.0/16 Cloud Innovation Ltd 154.213.0.0/16 CloudInnovation infrastructure 154.214.0.0/16 Cloud Innovation Ltd 154.215.0.0/16 Cloud Innovation Ltd 154.216.0.0/16 CloudInnovation infrastructure 154.217.0.0/16 CloudInnovation infrastructure 154.218.0.0/16 Cloud Innovation Ltd 154.218.0.0/17 Cloud Innovation Ltd 154.219.0.0/16 Cloud Innovation Ltd 154.220.0.0/16 CloudInnovation infrastructure 154.221.0.0/16 Cloud Innovation Ltd 156.229.0.0/16 Cloud Innovation Ltd 156.231.0.0/16 Cloud Innovation Ltd 156.232.0.0/16 Cloud Innovation Ltd 156.235.0.0/16 Cloud Innovation Ltd 156.236.0.0/16 Cloud Innovation Ltd 156.237.0.0/16 Cloud Innovation Ltd 156.238.0.0/16 Cloud Innovation Ltd 156.239.0.0/16 Cloud Innovation Ltd 156.242.0.0/16 Cloud Innovation Ltd 156.243.0.0/16 Cloud Innovation Ltd 156.247.0.0/16 Cloud Innovation Ltd 156.249.0.0/16 Cloud Innovation Ltd 156.251.0.0/16 Cloud Innovation Ltd 156.252.0.0/24 Cloud Innovation_infrastructure Regards, Libren -- Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com May 25, 2020, 16:47 by libren at tuta.io: > Hello, > Very interesting question of 3 x /11 allocated to Cloud Innovations. > > Regards, > Libren > > -- > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: > https://tutanota.com > > > May 25, 2020, 15:00 by community-discuss-request at afrinic.net: > >> Send Community-Discuss mailing list submissions to >> community-discuss at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/community-discuss >> or, via email, send a message with subject or body 'help' to >> community-discuss-request at afrinic.net >> >> You can reach the person managing the list at >> community-discuss-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Community-Discuss digest..." >> >> >> Today's Topics: >> >> 1. Re: [rpd] Cloud Innovation Displays Very Poor, If Not >> Criminal, Netizenship (Arnaud AMELINA) >> 2. Re: [rpd] Cloud Innovation Displays Very Poor, If Not >> Criminal, Netizenship (ABDULKARIM AYOPO OLOYEDE) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 25 May 2020 01:28:10 +0000 >> From: Arnaud AMELINA >> To: Gregoire EHOUMI >> Cc: General Discussions of AFRINIC , >> "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" >> >> Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very >> Poor, If Not Criminal, Netizenship >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> Hello, community >> >> +1 @Gregoire and @Mark Tinka >> >> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* >> with *no ASN*. Interesting, and no *v6* >> >> While the bylaws defines LIR as followed: >> ++++++ >> Local Internet Registry (LIR): >> any Network Operator that provides Internet services to distinct end-users >> and end-sites >> ++++++ >> >> I wonder which network does cloud innovation operate and which internet >> services it provides to end-users and end-sites in *Africa*. >> >> How does this network *managing 3 x /11 of IPv4* *operate*? >> >> There is something here for the community to learn about. >> >> Regards >> >> -- >> Arnaud >> >> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a >> ?crit : >> >>> Hello, >>> >>> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. >>> >>> I carefully read your report and also the Cloud Innovation Limited quick >>> response including their attachments as justifications. >>> >>> I note that; >>> >>> ? the service contract with Cloud Innovation covering the announcement of >>> their prefixes by SEACOM AS37353 was terminated by SEACOM. >>> >>> ? some stale IRR route objects existed after termination of the contract. >>> >>> ? through some multiple layer distribution an organisation in Manila >>> Philippines was ?delegated? an IP block from Cloud Innovation address space. >>> >>> ? both upstream ISP and the customer in Manila set up a BGP session using >>> SEACOM's AS37353 as the ASN of the Manila customer. >>> >>> ? there was a prompt reaction from the involved parties that included >>> apologies to SEACOM and the wider internet community. >>> >>> ? there were promises from said parties to be a better netizen which would >>> mean, them not hijacking other networks ASN's. >>> >>> ? there was clear refusal to disclose the details of the customer in >>> Manila Philippines who hijacked the affected SEACOM ASN. >>> >>> All put together, demonstrates that what happened was an impersonation and >>> not a BGP configuration error, nor an oversight in checking the right to >>> use of the SEACOM ASN. >>> >>> 1. Why is it that the real customer did not bother presenting its >>> apologies to the community >>> >>> 2. Why is there refusal to reveal customer?s details? >>> >>> 3. Why is it that the said prefix is no longer seen in the routing table >>> originated by the genius ASN or any other ASN? >>> >>> 4. Which networks were involved and what happened to the end users? >>> >>> Can someone from AFRINIC explain what ?delegation of IP block? mean? >>> >>> Note: The self organised Internet knows how to deal with bad net citizens.! >>> >>> Best regards >>> Gregoire Ehoumi >>> >>> >>> -------- Original message -------- >>> From: Lu Heng >>> Date: 2020-05-09 5:43 a.m. (GMT-05:00) >>> To: Mark Tinka >>> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < >>> rpd at afrinic.net> >>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, >>> Netizenship >>> >>> To whom it may concern, >>> >>> On May 8, Mark Think posted a claim to multiple lists that Cloud >>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud >>> Innovation) but rather belonged to Seacom through their acquisition of >>> MacroLAN. >>> >>> While we regret this unfortunate incident, Mark?s claims that it was >>> criminal or bad netizenship on the part of Cloud Innovation is without >>> foundation and utterly incorrect. >>> >>> As shown below in the attached document from Paul Wollner(Ex-CTO of >>> Macrolan who created IRR routes to allow Macrolan to announce Cloud >>> Innovation's prefix); letter from Link Infinity International Ltd. (Link >>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS >>> authorizing IPDC Solutions to announce the prefix with origin AS134190. >>> And a Letter from IPDC. This was an innocent mistake committed by third >>> parties and had nothing to do with any action by Cloud Innovation or LARUS. >>> >>> Here?s what happened: >>> >>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. >>> >>> >>> Link Infinity further delegated that same /24 to IPDC and asked Cloud >>> innovation to issue an LOA, which we did. The LOA specifically required >>> IPDC to use its own ASN to announce the space (AS134190). >>> >>> IPDC subsequently authorized one of its customers to use the said prefix. >>> >>> >>> For reasons still unknown to Cloud Innovation, IPDC and their customer set >>> up a BGP session wherein their customer used AS37353 as the origin to >>> advertise prefix 156.241.3.0/24. >>> >>> >>> Upon discovering the announcement, rather than contact Cloud Innovation, >>> Mark contacted IPDC who provided him with an incomplete explanation blaming >>> their customer and Mark, not realizing that Cloud Innovation was not the >>> customer in question posted far and wide about the event. It is unclear to >>> us why he chose to do this rather than contact us to try and resolve the >>> issue. >>> >>> >>> A contributing factor to the erroneous BGP configuration by IPDC's >>> customer may have been data contained in some outdated IRR route objects >>> for 156.241.0.0/16 which have subsequently been deleted. >>> >>> As soon as we became aware of the problem (via Mark?s email), we began to >>> investigate the situation. As soon as it was clear that this was the result >>> of third-party actions, we reached out to Mark privately to let him know >>> what we knew and that we were still investigating. We delayed making a >>> public statement in order to try and ascertain all of the facts of the >>> situation. We prefer not to make public statements based on incomplete >>> information. >>> >>> We apologize to the community for our small part in this unfortunate >>> incident and assure you that we work very hard to remain good netizens and >>> will address any concerns promptly when they come to our attention. >>> >>> >>> Sincerely, >>> >>> Lu Heng >>> CEO >>> Cloud Innovations >>> >>> Attached: >>> 1. Letter from Paul Wollner >>> 2. Letter from Link Infinity >>> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from >>> AS134190 >>> 4. Letter from IPDC >>> >>> FYI: LARUS is proving IP management service for Cloud Innovation, while >>> LARUS is also providing IP management service to other third parties in all >>> regions, for full disclosure, LARUS and Cloud Innovation are headed by same >>> CEO. >>> >>> Content of those letters have been posted here for your convince: >>> >>> *IPDC:* >>> >>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] >>> >>> >>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and >>> over the course of our corporate relationship we were given the authority >>> to use address block 156.241.3.0/24 since 9th December 2019. >>> >>> >>> On 12th December 2019, we have delegated that address block to our client. >>> Following which our client further instructed us to announce the prefix >>> with AS37353. In good will after minimal verification through WHOIS? IP >>> Prefix we have proceeded to execute our client?s request. >>> >>> >>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder >>> of record for that ASN and have since learned that the customer?s use of >>> that ASN was erroneous and not permitted by SEACOM and immediate action has >>> been taken to rectify this situation. >>> >>> >>> IPDC would like to apologize for our lack of attention in conducting >>> thorough verification and wish to highlight that the involvement of Cloud >>> Innovation Ltd in the entire process was providing the addresses to us and >>> that we truly apologize as we understand that this incident may have >>> indirectly implicated Cloud Innovation Ltd. >>> >>> >>> IPDC however, does not wish to disclose our client information and our >>> client information shall remain confidential under present circumstances. >>> Once again, we apologize for our shortcomings. >>> >>> >>> *Link Infinity:* >>> >>> >>> To whom it may concern, >>> >>> We at HK Infinity International Ltd are a customer of Cloud Innovation and >>> in the course received rights to use 156.241.3.0/24 from them. Beginning >>> December, 2019, we delegated the right to announce this prefix to IPDC >>> Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA >>> authorizing them to announce the space which was subsequently received. >>> IPDC subsequently and without our knowledge delegated this space to one of >>> their customers and allowed them to originate it from AS37353. >>> >>> This announcement was not authorized by us, nor is it permitted by the LOA >>> provided by Cloud Innovation. >>> >>> Unfortunately, we were not aware of the situation until after it had >>> already been resolved. >>> >>> It was never our intent to violate the LOA or to allow the prefix to be >>> announced from a hijacked ASN. We do not condone this and apologize >>> sincerely to the community for what has happened here. >>> >>> Sincere Apologies, >>> >>> >>> *Paul Wollner:* >>> >>> >>> 8 May 2020 >>> >>> TO WHOM IT MAY CONCERN >>> >>> In the light of the recent email on NAPAfrica mailing list, I would just >>> like to clear the air. >>> >>> >>> The IP route objects were created by myself for Cloud Innovation when they >>> signed up as a client of Macrolan ( now SEACOM) as they didn't have their >>> own AS. >>> >>> At the time I was working for Macrolan (now SEACOM). I left the employment >>> of SEACOM in October 2019. >>> >>> It appears that when Cloud Innovation's contract with SEACOM came to an >>> end, the route objects were never cleaned up. >>> >>> This occurred after I left SEACOM's employment. Since leaving, I have no >>> access to these objects. >>> >>> Regards >>> >>> Paul Wollner >>> 082-786-9776 >>> >>> >>> >>> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: >>> >>>> 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. >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>> >>> >>> -- >>> -- >>> Kind regards. >>> Lu >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 25 May 2020 13:00:22 +0100 >> From: ABDULKARIM AYOPO OLOYEDE >> To: Paschal Ochang >> Cc: General Discussions of AFRINIC , >> "rpd >> AfriNIC Resource Policy" >> Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very >> Poor, If Not Criminal, Netizenship >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> Dear All, >> Please let us all be reminded that this mailing list is to discuss >> policies and directly related issues. >> There are other mailing lists where issues like this can be discussed but >> definitely not here because the issue is *out of scope* for this mailing >> list >> Please, Co-Chairs would like us to put an end to this discussion. >> >> CO-Chairs >> PDWG >> >> >> On Mon, May 25, 2020 at 12:31 PM Paschal Ochang wrote: >> >>> This sounds like a personal attack in my opinion instead of a justified >>> accusation. Why is this topic allowed to be discussed here when it?s rather >>> irrelevant?. The parties involved have tendered formal apologies as >>> reflected in their letters which is a sign of admittance and promotes the >>> intent of good netizenship. It?s just irrelevant. >>> >>> On Monday, May 25, 2020, Arnaud AMELINA wrote: >>> >>>> Hello, community >>>> >>>> +1 @Gregoire and @Mark Tinka >>>> >>>> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* >>>> with *no ASN*. Interesting, and no *v6* >>>> >>>> While the bylaws defines LIR as followed: >>>> ++++++ >>>> Local Internet Registry (LIR): >>>> any Network Operator that provides Internet services to distinct >>>> end-users and end-sites >>>> ++++++ >>>> >>>> I wonder which network does cloud innovation operate and which internet >>>> services it provides to end-users and end-sites in *Africa*. >>>> >>>> How does this network *managing 3 x /11 of IPv4* *operate*? >>>> >>>> There is something here for the community to learn about. >>>> >>>> Regards >>>> >>>> -- >>>> Arnaud >>>> >>>> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a >>>> ?crit : >>>> >>>>> Hello, >>>>> >>>>> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. >>>>> >>>>> I carefully read your report and also the Cloud Innovation Limited quick >>>>> response including their attachments as justifications. >>>>> >>>>> I note that; >>>>> >>>>> ? the service contract with Cloud Innovation covering the announcement >>>>> of their prefixes by SEACOM AS37353 was terminated by SEACOM. >>>>> >>>>> ? some stale IRR route objects existed after termination of the contract. >>>>> >>>>> ? through some multiple layer distribution an organisation in Manila >>>>> Philippines was ?delegated? an IP block from Cloud Innovation address space. >>>>> >>>>> ? both upstream ISP and the customer in Manila set up a BGP session >>>>> using SEACOM's AS37353 as the ASN of the Manila customer. >>>>> >>>>> ? there was a prompt reaction from the involved parties that included >>>>> apologies to SEACOM and the wider internet community. >>>>> >>>>> ? there were promises from said parties to be a better netizen which >>>>> would mean, them not hijacking other networks ASN's. >>>>> >>>>> ? there was clear refusal to disclose the details of the customer in >>>>> Manila Philippines who hijacked the affected SEACOM ASN. >>>>> >>>>> All put together, demonstrates that what happened was an impersonation >>>>> and not a BGP configuration error, nor an oversight in checking the right >>>>> to use of the SEACOM ASN. >>>>> >>>>> 1. Why is it that the real customer did not bother presenting its >>>>> apologies to the community >>>>> >>>>> 2. Why is there refusal to reveal customer?s details? >>>>> >>>>> 3. Why is it that the said prefix is no longer seen in the routing table >>>>> originated by the genius ASN or any other ASN? >>>>> >>>>> 4. Which networks were involved and what happened to the end users? >>>>> >>>>> Can someone from AFRINIC explain what ?delegation of IP block? mean? >>>>> >>>>> Note: The self organised Internet knows how to deal with bad net >>>>> citizens.! >>>>> >>>>> Best regards >>>>> Gregoire Ehoumi >>>>> >>>>> >>>>> -------- Original message -------- >>>>> From: Lu Heng >>>>> Date: 2020-05-09 5:43 a.m. (GMT-05:00) >>>>> To: Mark Tinka >>>>> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < >>>>> rpd at afrinic.net> >>>>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, >>>>> Netizenship >>>>> >>>>> To whom it may concern, >>>>> >>>>> On May 8, Mark Think posted a claim to multiple lists that Cloud >>>>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud >>>>> Innovation) but rather belonged to Seacom through their acquisition of >>>>> MacroLAN. >>>>> >>>>> While we regret this unfortunate incident, Mark?s claims that it was >>>>> criminal or bad netizenship on the part of Cloud Innovation is without >>>>> foundation and utterly incorrect. >>>>> >>>>> As shown below in the attached document from Paul Wollner(Ex-CTO of >>>>> Macrolan who created IRR routes to allow Macrolan to announce Cloud >>>>> Innovation's prefix); letter from Link Infinity International Ltd. (Link >>>>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS >>>>> authorizing IPDC Solutions to announce the prefix with origin AS134190. >>>>> And a Letter from IPDC. This was an innocent mistake committed by third >>>>> parties and had nothing to do with any action by Cloud Innovation or LARUS. >>>>> >>>>> Here?s what happened: >>>>> >>>>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December >>>>> 2019. >>>>> >>>>> >>>>> Link Infinity further delegated that same /24 to IPDC and asked Cloud >>>>> innovation to issue an LOA, which we did. The LOA specifically required >>>>> IPDC to use its own ASN to announce the space (AS134190). >>>>> >>>>> IPDC subsequently authorized one of its customers to use the said prefix. >>>>> >>>>> >>>>> For reasons still unknown to Cloud Innovation, IPDC and their customer >>>>> set up a BGP session wherein their customer used AS37353 as the origin to >>>>> advertise prefix 156.241.3.0/24. >>>>> >>>>> >>>>> Upon discovering the announcement, rather than contact Cloud Innovation, >>>>> Mark contacted IPDC who provided him with an incomplete explanation blaming >>>>> their customer and Mark, not realizing that Cloud Innovation was not the >>>>> customer in question posted far and wide about the event. It is unclear to >>>>> us why he chose to do this rather than contact us to try and resolve the >>>>> issue. >>>>> >>>>> >>>>> A contributing factor to the erroneous BGP configuration by IPDC's >>>>> customer may have been data contained in some outdated IRR route objects >>>>> for 156.241.0.0/16 which have subsequently been deleted. >>>>> >>>>> As soon as we became aware of the problem (via Mark?s email), we began >>>>> to investigate the situation. As soon as it was clear that this was the >>>>> result of third-party actions, we reached out to Mark privately to let him >>>>> know what we knew and that we were still investigating. We delayed making a >>>>> public statement in order to try and ascertain all of the facts of the >>>>> situation. We prefer not to make public statements based on incomplete >>>>> information. >>>>> >>>>> We apologize to the community for our small part in this unfortunate >>>>> incident and assure you that we work very hard to remain good netizens and >>>>> will address any concerns promptly when they come to our attention. >>>>> >>>>> >>>>> Sincerely, >>>>> >>>>> Lu Heng >>>>> CEO >>>>> Cloud Innovations >>>>> >>>>> Attached: >>>>> 1. Letter from Paul Wollner >>>>> 2. Letter from Link Infinity >>>>> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from >>>>> AS134190 >>>>> 4. Letter from IPDC >>>>> >>>>> FYI: LARUS is proving IP management service for Cloud Innovation, while >>>>> LARUS is also providing IP management service to other third parties in all >>>>> regions, for full disclosure, LARUS and Cloud Innovation are headed by same >>>>> CEO. >>>>> >>>>> Content of those letters have been posted here for your convince: >>>>> >>>>> *IPDC:* >>>>> >>>>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] >>>>> >>>>> >>>>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and >>>>> over the course of our corporate relationship we were given the authority >>>>> to use address block 156.241.3.0/24 since 9th December 2019. >>>>> >>>>> >>>>> On 12th December 2019, we have delegated that address block to our >>>>> client. Following which our client further instructed us to announce the >>>>> prefix with AS37353. In good will after minimal verification through WHOIS? >>>>> IP Prefix we have proceeded to execute our client?s request. >>>>> >>>>> >>>>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder >>>>> of record for that ASN and have since learned that the customer?s use of >>>>> that ASN was erroneous and not permitted by SEACOM and immediate action has >>>>> been taken to rectify this situation. >>>>> >>>>> >>>>> IPDC would like to apologize for our lack of attention in conducting >>>>> thorough verification and wish to highlight that the involvement of Cloud >>>>> Innovation Ltd in the entire process was providing the addresses to us and >>>>> that we truly apologize as we understand that this incident may have >>>>> indirectly implicated Cloud Innovation Ltd. >>>>> >>>>> >>>>> IPDC however, does not wish to disclose our client information and our >>>>> client information shall remain confidential under present circumstances. >>>>> Once again, we apologize for our shortcomings. >>>>> >>>>> >>>>> *Link Infinity:* >>>>> >>>>> >>>>> To whom it may concern, >>>>> >>>>> We at HK Infinity International Ltd are a customer of Cloud Innovation >>>>> and in the course received rights to use 156.241.3.0/24 from them. >>>>> Beginning December, 2019, we delegated the right to announce this prefix to >>>>> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA >>>>> authorizing them to announce the space which was subsequently received. >>>>> IPDC subsequently and without our knowledge delegated this space to one of >>>>> their customers and allowed them to originate it from AS37353. >>>>> >>>>> This announcement was not authorized by us, nor is it permitted by the >>>>> LOA provided by Cloud Innovation. >>>>> >>>>> Unfortunately, we were not aware of the situation until after it had >>>>> already been resolved. >>>>> >>>>> It was never our intent to violate the LOA or to allow the prefix to be >>>>> announced from a hijacked ASN. We do not condone this and apologize >>>>> sincerely to the community for what has happened here. >>>>> >>>>> Sincere Apologies, >>>>> >>>>> >>>>> *Paul Wollner:* >>>>> >>>>> >>>>> 8 May 2020 >>>>> >>>>> TO WHOM IT MAY CONCERN >>>>> >>>>> In the light of the recent email on NAPAfrica mailing list, I would just >>>>> like to clear the air. >>>>> >>>>> >>>>> The IP route objects were created by myself for Cloud Innovation when >>>>> they signed up as a client of Macrolan ( now SEACOM) as they didn't have >>>>> their own AS. >>>>> >>>>> At the time I was working for Macrolan (now SEACOM). I left the >>>>> employment of SEACOM in October 2019. >>>>> >>>>> It appears that when Cloud Innovation's contract with SEACOM came to an >>>>> end, the route objects were never cleaned up. >>>>> >>>>> This occurred after I left SEACOM's employment. Since leaving, I have no >>>>> access to these objects. >>>>> >>>>> Regards >>>>> >>>>> Paul Wollner >>>>> 082-786-9776 >>>>> >>>>> >>>>> >>>>> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: >>>>> >>>>>> 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. >>>>>> _______________________________________________ >>>>>> RPD mailing list >>>>>> RPD at afrinic.net >>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Kind regards. >>>>> Lu >>>>> >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>> _______________________________________________ >>>> >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> >> -- >> Website ,?Weekly Bulletin >> ?UGPortal >> PGPortal >> >> >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> Community-Discuss mailing list >> Community-Discuss at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/community-discuss >> >> >> ------------------------------ >> >> End of Community-Discuss Digest, Vol 616, Issue 1 >> ************************************************* >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amelnaud at gmail.com Mon May 25 23:00:43 2020 From: amelnaud at gmail.com (Arnaud AMELINA) Date: Mon, 25 May 2020 23:00:43 +0000 Subject: [Community-Discuss] [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Paschal, Please explain why it?s a personal attack when no person was mentioned? Please be enlightened that the topic under discussion is allowed because its application of policy with implications. FWIW, Cloud Innovation Ltd, rendering an apology does not make the problem go away and the working group has to solve the real problem at hand Let us be aware that, the way internet deals with bad netizens may cause damage to parents and even to the whole region if nothing is done to stop it -- Arnaud Le lun. 25 mai 2020 ? 11:30, Paschal Ochang a ?crit : > This sounds like a personal attack in my opinion instead of a justified > accusation. Why is this topic allowed to be discussed here when it?s rather > irrelevant?. The parties involved have tendered formal apologies as > reflected in their letters which is a sign of admittance and promotes the > intent of good netizenship. It?s just irrelevant. > > On Monday, May 25, 2020, Arnaud AMELINA wrote: > >> Hello, community >> >> +1 @Gregoire and @Mark Tinka >> >> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* >> with *no ASN*. Interesting, and no *v6* >> >> While the bylaws defines LIR as followed: >> ++++++ >> Local Internet Registry (LIR): >> any Network Operator that provides Internet services to distinct >> end-users and end-sites >> ++++++ >> >> I wonder which network does cloud innovation operate and which internet >> services it provides to end-users and end-sites in *Africa*. >> >> How does this network *managing 3 x /11 of IPv4* *operate*? >> >> There is something here for the community to learn about. >> >> Regards >> >> -- >> Arnaud >> >> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a >> ?crit : >> >>> Hello, >>> >>> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. >>> >>> I carefully read your report and also the Cloud Innovation Limited quick >>> response including their attachments as justifications. >>> >>> I note that; >>> >>> ? the service contract with Cloud Innovation covering the announcement >>> of their prefixes by SEACOM AS37353 was terminated by SEACOM. >>> >>> ? some stale IRR route objects existed after termination of the contract. >>> >>> ? through some multiple layer distribution an organisation in Manila >>> Philippines was ?delegated? an IP block from Cloud Innovation address space. >>> >>> ? both upstream ISP and the customer in Manila set up a BGP session >>> using SEACOM's AS37353 as the ASN of the Manila customer. >>> >>> ? there was a prompt reaction from the involved parties that included >>> apologies to SEACOM and the wider internet community. >>> >>> ? there were promises from said parties to be a better netizen which >>> would mean, them not hijacking other networks ASN's. >>> >>> ? there was clear refusal to disclose the details of the customer in >>> Manila Philippines who hijacked the affected SEACOM ASN. >>> >>> All put together, demonstrates that what happened was an impersonation >>> and not a BGP configuration error, nor an oversight in checking the right >>> to use of the SEACOM ASN. >>> >>> 1. Why is it that the real customer did not bother presenting its >>> apologies to the community >>> >>> 2. Why is there refusal to reveal customer?s details? >>> >>> 3. Why is it that the said prefix is no longer seen in the routing table >>> originated by the genius ASN or any other ASN? >>> >>> 4. Which networks were involved and what happened to the end users? >>> >>> Can someone from AFRINIC explain what ?delegation of IP block? mean? >>> >>> Note: The self organised Internet knows how to deal with bad net >>> citizens.! >>> >>> Best regards >>> Gregoire Ehoumi >>> >>> >>> -------- Original message -------- >>> From: Lu Heng >>> Date: 2020-05-09 5:43 a.m. (GMT-05:00) >>> To: Mark Tinka >>> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < >>> rpd at afrinic.net> >>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, >>> Netizenship >>> >>> To whom it may concern, >>> >>> On May 8, Mark Think posted a claim to multiple lists that Cloud >>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud >>> Innovation) but rather belonged to Seacom through their acquisition of >>> MacroLAN. >>> >>> While we regret this unfortunate incident, Mark?s claims that it was >>> criminal or bad netizenship on the part of Cloud Innovation is without >>> foundation and utterly incorrect. >>> >>> As shown below in the attached document from Paul Wollner(Ex-CTO of >>> Macrolan who created IRR routes to allow Macrolan to announce Cloud >>> Innovation's prefix); letter from Link Infinity International Ltd. (Link >>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS >>> authorizing IPDC Solutions to announce the prefix with origin AS134190. >>> And a Letter from IPDC. This was an innocent mistake committed by third >>> parties and had nothing to do with any action by Cloud Innovation or LARUS. >>> >>> Here?s what happened: >>> >>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December >>> 2019. >>> >>> >>> Link Infinity further delegated that same /24 to IPDC and asked Cloud >>> innovation to issue an LOA, which we did. The LOA specifically required >>> IPDC to use its own ASN to announce the space (AS134190). >>> >>> IPDC subsequently authorized one of its customers to use the said prefix. >>> >>> >>> For reasons still unknown to Cloud Innovation, IPDC and their customer >>> set up a BGP session wherein their customer used AS37353 as the origin to >>> advertise prefix 156.241.3.0/24. >>> >>> >>> Upon discovering the announcement, rather than contact Cloud Innovation, >>> Mark contacted IPDC who provided him with an incomplete explanation blaming >>> their customer and Mark, not realizing that Cloud Innovation was not the >>> customer in question posted far and wide about the event. It is unclear to >>> us why he chose to do this rather than contact us to try and resolve the >>> issue. >>> >>> >>> A contributing factor to the erroneous BGP configuration by IPDC's >>> customer may have been data contained in some outdated IRR route objects >>> for 156.241.0.0/16 which have subsequently been deleted. >>> >>> As soon as we became aware of the problem (via Mark?s email), we began >>> to investigate the situation. As soon as it was clear that this was the >>> result of third-party actions, we reached out to Mark privately to let him >>> know what we knew and that we were still investigating. We delayed making a >>> public statement in order to try and ascertain all of the facts of the >>> situation. We prefer not to make public statements based on incomplete >>> information. >>> >>> We apologize to the community for our small part in this unfortunate >>> incident and assure you that we work very hard to remain good netizens and >>> will address any concerns promptly when they come to our attention. >>> >>> >>> Sincerely, >>> >>> Lu Heng >>> CEO >>> Cloud Innovations >>> >>> Attached: >>> 1. Letter from Paul Wollner >>> 2. Letter from Link Infinity >>> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from >>> AS134190 >>> 4. Letter from IPDC >>> >>> FYI: LARUS is proving IP management service for Cloud Innovation, while >>> LARUS is also providing IP management service to other third parties in all >>> regions, for full disclosure, LARUS and Cloud Innovation are headed by same >>> CEO. >>> >>> Content of those letters have been posted here for your convince: >>> >>> *IPDC:* >>> >>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] >>> >>> >>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and >>> over the course of our corporate relationship we were given the authority >>> to use address block 156.241.3.0/24 since 9th December 2019. >>> >>> >>> On 12th December 2019, we have delegated that address block to our >>> client. Following which our client further instructed us to announce the >>> prefix with AS37353. In good will after minimal verification through WHOIS? >>> IP Prefix we have proceeded to execute our client?s request. >>> >>> >>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder >>> of record for that ASN and have since learned that the customer?s use of >>> that ASN was erroneous and not permitted by SEACOM and immediate action has >>> been taken to rectify this situation. >>> >>> >>> IPDC would like to apologize for our lack of attention in conducting >>> thorough verification and wish to highlight that the involvement of Cloud >>> Innovation Ltd in the entire process was providing the addresses to us and >>> that we truly apologize as we understand that this incident may have >>> indirectly implicated Cloud Innovation Ltd. >>> >>> >>> IPDC however, does not wish to disclose our client information and our >>> client information shall remain confidential under present circumstances. >>> Once again, we apologize for our shortcomings. >>> >>> >>> *Link Infinity:* >>> >>> >>> To whom it may concern, >>> >>> We at HK Infinity International Ltd are a customer of Cloud Innovation >>> and in the course received rights to use 156.241.3.0/24 from them. >>> Beginning December, 2019, we delegated the right to announce this prefix to >>> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA >>> authorizing them to announce the space which was subsequently received. >>> IPDC subsequently and without our knowledge delegated this space to one of >>> their customers and allowed them to originate it from AS37353. >>> >>> This announcement was not authorized by us, nor is it permitted by the >>> LOA provided by Cloud Innovation. >>> >>> Unfortunately, we were not aware of the situation until after it had >>> already been resolved. >>> >>> It was never our intent to violate the LOA or to allow the prefix to be >>> announced from a hijacked ASN. We do not condone this and apologize >>> sincerely to the community for what has happened here. >>> >>> Sincere Apologies, >>> >>> >>> *Paul Wollner:* >>> >>> >>> 8 May 2020 >>> >>> TO WHOM IT MAY CONCERN >>> >>> In the light of the recent email on NAPAfrica mailing list, I would just >>> like to clear the air. >>> >>> >>> The IP route objects were created by myself for Cloud Innovation when >>> they signed up as a client of Macrolan ( now SEACOM) as they didn't have >>> their own AS. >>> >>> At the time I was working for Macrolan (now SEACOM). I left the >>> employment of SEACOM in October 2019. >>> >>> It appears that when Cloud Innovation's contract with SEACOM came to an >>> end, the route objects were never cleaned up. >>> >>> This occurred after I left SEACOM's employment. Since leaving, I have no >>> access to these objects. >>> >>> Regards >>> >>> Paul Wollner >>> 082-786-9776 >>> >>> >>> >>> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: >>> >>>> 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. >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>> >>> >>> -- >>> -- >>> Kind regards. >>> Lu >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.chirwa at afrinic.net Tue May 26 15:27:51 2020 From: james.chirwa at afrinic.net (James) Date: Tue, 26 May 2020 19:27:51 +0400 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: <959458c5-1eaf-c71c-6278-c53628f4e0ff@afrinic.net> Dear Gregoire, Let me first of all thank you for sharing your concern as well as? seeking clarification regarding the matter under hand. You have sought? from AFRINIC an explanation as regard the term ? delegation of IP block?. As far as AFRINIC is concerned , it does not practice ? delegation of IP Block?. Its handling of IP Blocks involves only allocation, sub-allocation or assignment . You may contact? the operator/member who has utilised? the said term for more clarification. Regards, James On 23/05/2020 18:21, Gregoire EHOUMI via Community-Discuss wrote: > Hello, > > Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. > > I carefully read your report and also the Cloud Innovation Limited > quick response including their attachments as justifications. > > I note that; > > ? the service contract with Cloud Innovation covering the announcement > of their prefixes by SEACOM AS37353 was terminated? by SEACOM. > > ? some stale IRR route objects existed after termination of the contract. > > ? through some multiple layer distribution an organisation in Manila > Philippines was ?delegated? an IP block from Cloud Innovation address > space. > > ? both upstream ISP and the customer in Manila set up a BGP session > using SEACOM's AS37353 as the ASN of the Manila customer. > > ? there was a prompt reaction from the involved parties that included > apologies to SEACOM and the wider internet community. > > ? there were promises from said parties to be a better netizen which > would mean, them not hijacking other networks ASN's. > > ? there was clear refusal to disclose the details of the customer in > Manila Philippines who hijacked the affected SEACOM ASN. > > All put together, demonstrates that what happened was an impersonation > and not a BGP configuration error, nor an oversight in checking the > right to use of the SEACOM ASN. > > 1. Why is it that the real customer did not bother presenting its > apologies to the community > > 2. Why is there refusal to reveal customer?s details? > > 3. Why is it that the said prefix is no longer seen in the routing > table originated by the genius ASN or any other ASN? > > 4. Which networks were involved and what happened to the end users? > > Can someone from AFRINIC explain what ?delegation of IP block? mean? > > Note: The self organised Internet knows how to deal with bad net > citizens.! > > Best regards? > Gregoire Ehoumi? > > > -------- Original message -------- > From: Lu Heng > Date: 2020-05-09 5:41 a.m. (GMT-05:00) > To: General Discussions of AFRINIC > Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor, > If Not Criminal, Netizenship > > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud > Innovation was abusing an ASN (37353) that didn?t belong to them > (Cloud Innovation) but rather belonged to Seacom through their > acquisition of MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was > criminal or bad netizenship on the part of Cloud Innovation is without > foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of > Macrolan who created IRR routes to allow Macrolan to announce Cloud > Innovation's prefix); letter from Link Infinity International Ltd. > (Link Infinity), A customer of Cloud Innovation; and attached LOA from > LARUS authorizing IPDC Solutions to announce the prefix with origin > AS134190.? And a Letter from IPDC. This was an innocent mistake > committed by third parties and had nothing to do with any action by > Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in > December 2019. > > > Link Infinity further delegated that same /24 to IPDC and asked > Cloud innovation to issue an LOA, which we did. The LOA > specifically required IPDC to use its own ASN to announce the > space (AS134190). > > IPDC subsequently authorized one of its customers to use the said > prefix. > > > For reasons still unknown to Cloud Innovation, IPDC and their > customer set up a BGP session wherein their customer used AS37353 > as the origin to advertise prefix?156.241.3.0/24 > . > > > Upon discovering the announcement, rather than contact Cloud > Innovation, Mark contacted IPDC who provided him with an > incomplete explanation blaming their customer and Mark, not > realizing that Cloud Innovation was not the customer in question > posted far and wide about the event. It is unclear to us why he > chose to do this rather than contact us to try and resolve the issue. > > > A contributing factor to the erroneous BGP configuration by IPDC's > customer may have been data contained in some outdated IRR route > objects for?156.241.0.0/16 ?which have > subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began > to investigate the situation. As soon as it was clear that this was > the result of third-party actions, we reached out to Mark privately to > let him know what we knew and that we were still investigating. We > delayed making a public statement in order to try and ascertain all of > the facts of the situation. We prefer not to make public statements > based on incomplete information. > > We apologize to the community for our small part in this unfortunate > incident and assure you that we work very hard to remain good netizens > and will address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1.Letter from Paul Wollner > 2.Letter from Link Infinity > 3.LOA Issued to IPDC Solutions for announcing?156.241.3.0/24 > ?from AS134190 > ? ? ? ? 4.? ? ?Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, > while LARUS is also providing IP management service to other third > parties in all regions, for full disclosure, LARUS and Cloud > Innovation are headed by same CEO. > > Content of those letters have been posted here for your convince: > > *IPDC:* > * > * > > FOR IMMEDIATE RELEASE?[Perusal of Cloud Innovation Ltd] > > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd > and over the course of our corporate relationship we were given the > authority to use address block?156.241.3.0/24 > ?since 9th December 2019.? > > > On 12th December 2019, we have delegated that address block to our > client. Following which our client further instructed us to announce > the prefix with AS37353.?In good will after minimal verification > through WHOIS? IP Prefix we have proceeded to execute our client?s > request.? > > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate > holder of record for that ASN and have since learned that the > customer?s use of that ASN was erroneous and not permitted by SEACOM > and immediate action has been taken to rectify this situation.? > > > IPDC would like to apologize for our lack of attention in conducting > thorough verification and wish to highlight that the involvement of > Cloud Innovation Ltd in the entire process was providing the addresses > to us and that we truly apologize as we understand that this incident > may have indirectly implicated Cloud Innovation Ltd.? > > > IPDC however, does not wish to disclose our client information and our > client information shall remain confidential under present > circumstances. Once again, we apologize for our shortcomings.? > > > *Link Infinity:* > > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation > and in the course received rights to use?156.241.3.0/24 > ?from them. Beginning December, 2019, we > delegated the right to announce this prefix to IPDC Solutions Pte Ltd. > (IPDC). We asked Cloud Innovation to provide an LOA authorizing them > to announce the space which was subsequently received. IPDC > subsequently and without our knowledge delegated this space to one of > their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the > LOA provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had > already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to > be announced from a hijacked ASN. We do not condone this and apologize > sincerely to the community for what has happened here. > > Sincere Apologies, > > > *Paul Wollner:* > > > 8 May 2020 > > TO WHOM IT MAY CONCERN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > > In the light of the recent email on NAPAfrica mailing list, I would > just like to clear the air.? > > > The IP route objects were created by myself for Cloud Innovation when > they signed up as a client of Macrolan ( now SEACOM) as they didn't > have their own AS. > > At the time I was working for Macrolan (now SEACOM). I left the > employment of SEACOM in October 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to > an end, the route objects were never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have > no access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud > Innovation was abusing an ASN (37353) that didn?t belong to them > (Cloud Innovation) but rather belonged to Seacom through their > acquisition of MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was > criminal or bad netizenship on the part of Cloud Innovation is without > foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of > Macrolan who created IRR routes to allow Macrolan to announce Cloud > Innovation's prefix); letter from Link Infinity International Ltd. > (Link Infinity), A customer of Cloud Innovation; and attached LOA from > LARUS authorizing IPDC Solutions to announce the prefix with origin > AS134190.? And a Letter from IPDC. This was an innocent mistake > committed by third parties and had nothing to do with any action by > Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in > December 2019. > > > Link Infinity further delegated that same /24 to IPDC and asked > Cloud innovation to issue an LOA, which we did. The LOA > specifically required IPDC to use its own ASN to announce the > space (AS134190). > > IPDC subsequently authorized one of its customers to use the said > prefix. > > > For reasons still unknown to Cloud Innovation, IPDC and their > customer set up a BGP session wherein their customer used AS37353 > as the origin to advertise prefix?156.241.3.0/24 > . > > > Upon discovering the announcement, rather than contact Cloud > Innovation, Mark contacted IPDC who provided him with an > incomplete explanation blaming their customer and Mark, not > realizing that Cloud Innovation was not the customer in question > posted far and wide about the event. It is unclear to us why he > chose to do this rather than contact us to try and resolve the issue. > > > A contributing factor to the erroneous BGP configuration by IPDC's > customer may have been data contained in some outdated IRR route > objects for?156.241.0.0/16 ?which have > subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began > to investigate the situation. As soon as it was clear that this was > the result of third-party actions, we reached out to Mark privately to > let him know what we knew and that we were still investigating. We > delayed making a public statement in order to try and ascertain all of > the facts of the situation. We prefer not to make public statements > based on incomplete information. > > We apologize to the community for our small part in this unfortunate > incident and assure you that we work very hard to remain good netizens > and will address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1.Letter from Paul Wollner > 2.Letter from Link Infinity > 3.LOA Issued to IPDC Solutions for announcing?156.241.3.0/24 > ?from AS134190 > ? ? ? ? 4.? ? ?Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, > while LARUS is also providing IP management service to other third > parties in all regions, for full disclosure, LARUS and Cloud > Innovation are headed by same CEO. > > Content of those letters have been posted here for your convince: > > *IPDC:* > * > * > > FOR IMMEDIATE RELEASE?[Perusal of Cloud Innovation Ltd] > > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd > and over the course of our corporate relationship we were given the > authority to use address block?156.241.3.0/24 > ?since 9th December 2019.? > > > On 12th December 2019, we have delegated that address block to our > client. Following which our client further instructed us to announce > the prefix with AS37353.?In good will after minimal verification > through WHOIS? IP Prefix we have proceeded to execute our client?s > request.? > > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate > holder of record for that ASN and have since learned that the > customer?s use of that ASN was erroneous and not permitted by SEACOM > and immediate action has been taken to rectify this situation.? > > > IPDC would like to apologize for our lack of attention in conducting > thorough verification and wish to highlight that the involvement of > Cloud Innovation Ltd in the entire process was providing the addresses > to us and that we truly apologize as we understand that this incident > may have indirectly implicated Cloud Innovation Ltd.? > > > IPDC however, does not wish to disclose our client information and our > client information shall remain confidential under present > circumstances. Once again, we apologize for our shortcomings.? > > > *Link Infinity:* > > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation > and in the course received rights to use?156.241.3.0/24 > ?from them. Beginning December, 2019, we > delegated the right to announce this prefix to IPDC Solutions Pte Ltd. > (IPDC). We asked Cloud Innovation to provide an LOA authorizing them > to announce the space which was subsequently received. IPDC > subsequently and without our knowledge delegated this space to one of > their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the > LOA provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had > already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to > be announced from a hijacked ASN. We do not condone this and apologize > sincerely to the community for what has happened here. > > Sincere Apologies, > > > *Paul Wollner:* > > > 8 May 2020 > > TO WHOM IT MAY CONCERN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > > In the light of the recent email on NAPAfrica mailing list, I would > just like to clear the air.? > > > The IP route objects were created by myself for Cloud Innovation when > they signed up as a client of Macrolan ( now SEACOM) as they didn't > have their own AS. > > At the time I was working for Macrolan (now SEACOM). I left the > employment of SEACOM in October 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to > an end, the route objects were never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have > no access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > > > On Fri, 8 May 2020 at 22:08, Mark Tinka > wrote: > > 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. > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > > -- > -- > Kind regards. > Lu > > > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss -- James Chirwa Acting Manager, Member Services Department AFRINIC Ltd. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w: www.afrinic.net SM: facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia ____________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ubah.tonyiyke at gmail.com Tue May 26 18:09:01 2020 From: ubah.tonyiyke at gmail.com (Anthony Ubah) Date: Tue, 26 May 2020 19:09:01 +0100 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: I feel this is gradually brewing up and steering up unnecessary tension within the community. I took the time to go through the trail, the post shared by the CEO of Cloud Innovation contained an email by IPDC in which they have already openly apologized for their mistake(s). On the other hand, heaping all blame on Cloud Innovation isn?t totally logical. >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. Predicting it?s customer?s behaviour is scarcely possible, hardly any company can. Also is the company in the position/business to care for it per se, and without violation of privacy? 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? Thus, whatever the problem is IPDC should settle its differences directly with SEACOM Best Regards, Anthony On Tue, May 26, 2020 at 1:00 PM wrote: > > Send Community-Discuss mailing list submissions to > community-discuss at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/community-discuss > or, via email, send a message with subject or body 'help' to > community-discuss-request at afrinic.net > > You can reach the person managing the list at > community-discuss-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Community-Discuss digest..." > > > Today's Topics: > > 1. Re: [rpd] Cloud Innovation Displays Very Poor, If Not > Criminal, Netizenship (libren at tuta.io) > 2. Re: [rpd] Cloud Innovation Displays Very Poor, If Not > Criminal, Netizenship (libren at tuta.io) > 3. Re: [rpd] Cloud Innovation Displays Very Poor, If Not > Criminal, Netizenship (Arnaud AMELINA) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 May 2020 15:47:06 +0200 (CEST) > From: libren at tuta.io > To: community-discuss at afrinic.net > Cc: community-discuss at afrinic.net > Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very > Poor, If Not Criminal, Netizenship > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hello, > Very interesting question of 3 x /11 allocated to Cloud Innovations. > > Regards, > Libren > -- > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: > https://tutanota.com > > > May 25, 2020, 15:00 by community-discuss-request at afrinic.net: > > > Send Community-Discuss mailing list submissions to > > community-discuss at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/community-discuss > > or, via email, send a message with subject or body 'help' to > > community-discuss-request at afrinic.net > > > > You can reach the person managing the list at > > community-discuss-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Community-Discuss digest..." > > > > > > Today's Topics: > > > > 1. Re: [rpd] Cloud Innovation Displays Very Poor, If Not > > Criminal, Netizenship (Arnaud AMELINA) > > 2. Re: [rpd] Cloud Innovation Displays Very Poor, If Not > > Criminal, Netizenship (ABDULKARIM AYOPO OLOYEDE) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 25 May 2020 01:28:10 +0000 > > From: Arnaud AMELINA > > To: Gregoire EHOUMI > > Cc: General Discussions of AFRINIC , > > "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" > > > > Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very > > Poor, If Not Criminal, Netizenship > > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > > > Hello, community > > > > +1 @Gregoire and @Mark Tinka > > > > *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* > > with *no ASN*. Interesting, and no *v6* > > > > While the bylaws defines LIR as followed: > > ++++++ > > Local Internet Registry (LIR): > > any Network Operator that provides Internet services to distinct end-users > > and end-sites > > ++++++ > > > > I wonder which network does cloud innovation operate and which internet > > services it provides to end-users and end-sites in *Africa*. > > > > How does this network *managing 3 x /11 of IPv4* *operate*? > > > > There is something here for the community to learn about. > > > > Regards > > > > -- > > Arnaud > > > > Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a > > ?crit : > > > >> Hello, > >> > >> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. > >> > >> I carefully read your report and also the Cloud Innovation Limited quick > >> response including their attachments as justifications. > >> > >> I note that; > >> > >> ? the service contract with Cloud Innovation covering the announcement of > >> their prefixes by SEACOM AS37353 was terminated by SEACOM. > >> > >> ? some stale IRR route objects existed after termination of the contract. > >> > >> ? through some multiple layer distribution an organisation in Manila > >> Philippines was ?delegated? an IP block from Cloud Innovation address space. > >> > >> ? both upstream ISP and the customer in Manila set up a BGP session using > >> SEACOM's AS37353 as the ASN of the Manila customer. > >> > >> ? there was a prompt reaction from the involved parties that included > >> apologies to SEACOM and the wider internet community. > >> > >> ? there were promises from said parties to be a better netizen which would > >> mean, them not hijacking other networks ASN's. > >> > >> ? there was clear refusal to disclose the details of the customer in > >> Manila Philippines who hijacked the affected SEACOM ASN. > >> > >> All put together, demonstrates that what happened was an impersonation and > >> not a BGP configuration error, nor an oversight in checking the right to > >> use of the SEACOM ASN. > >> > >> 1. Why is it that the real customer did not bother presenting its > >> apologies to the community > >> > >> 2. Why is there refusal to reveal customer?s details? > >> > >> 3. Why is it that the said prefix is no longer seen in the routing table > >> originated by the genius ASN or any other ASN? > >> > >> 4. Which networks were involved and what happened to the end users? > >> > >> Can someone from AFRINIC explain what ?delegation of IP block? mean? > >> > >> Note: The self organised Internet knows how to deal with bad net citizens.! > >> > >> Best regards > >> Gregoire Ehoumi > >> > >> > >> -------- Original message -------- > >> From: Lu Heng > >> Date: 2020-05-09 5:43 a.m. (GMT-05:00) > >> To: Mark Tinka > >> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < > >> rpd at afrinic.net> > >> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, > >> Netizenship > >> > >> To whom it may concern, > >> > >> On May 8, Mark Think posted a claim to multiple lists that Cloud > >> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > >> Innovation) but rather belonged to Seacom through their acquisition of > >> MacroLAN. > >> > >> While we regret this unfortunate incident, Mark?s claims that it was > >> criminal or bad netizenship on the part of Cloud Innovation is without > >> foundation and utterly incorrect. > >> > >> As shown below in the attached document from Paul Wollner(Ex-CTO of > >> Macrolan who created IRR routes to allow Macrolan to announce Cloud > >> Innovation's prefix); letter from Link Infinity International Ltd. (Link > >> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > >> authorizing IPDC Solutions to announce the prefix with origin AS134190. > >> And a Letter from IPDC. This was an innocent mistake committed by third > >> parties and had nothing to do with any action by Cloud Innovation or LARUS. > >> > >> Here?s what happened: > >> > >> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. > >> > >> > >> Link Infinity further delegated that same /24 to IPDC and asked Cloud > >> innovation to issue an LOA, which we did. The LOA specifically required > >> IPDC to use its own ASN to announce the space (AS134190). > >> > >> IPDC subsequently authorized one of its customers to use the said prefix. > >> > >> > >> For reasons still unknown to Cloud Innovation, IPDC and their customer set > >> up a BGP session wherein their customer used AS37353 as the origin to > >> advertise prefix 156.241.3.0/24. > >> > >> > >> Upon discovering the announcement, rather than contact Cloud Innovation, > >> Mark contacted IPDC who provided him with an incomplete explanation blaming > >> their customer and Mark, not realizing that Cloud Innovation was not the > >> customer in question posted far and wide about the event. It is unclear to > >> us why he chose to do this rather than contact us to try and resolve the > >> issue. > >> > >> > >> A contributing factor to the erroneous BGP configuration by IPDC's > >> customer may have been data contained in some outdated IRR route objects > >> for 156.241.0.0/16 which have subsequently been deleted. > >> > >> As soon as we became aware of the problem (via Mark?s email), we began to > >> investigate the situation. As soon as it was clear that this was the result > >> of third-party actions, we reached out to Mark privately to let him know > >> what we knew and that we were still investigating. We delayed making a > >> public statement in order to try and ascertain all of the facts of the > >> situation. We prefer not to make public statements based on incomplete > >> information. > >> > >> We apologize to the community for our small part in this unfortunate > >> incident and assure you that we work very hard to remain good netizens and > >> will address any concerns promptly when they come to our attention. > >> > >> > >> Sincerely, > >> > >> Lu Heng > >> CEO > >> Cloud Innovations > >> > >> Attached: > >> 1. Letter from Paul Wollner > >> 2. Letter from Link Infinity > >> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > >> AS134190 > >> 4. Letter from IPDC > >> > >> FYI: LARUS is proving IP management service for Cloud Innovation, while > >> LARUS is also providing IP management service to other third parties in all > >> regions, for full disclosure, LARUS and Cloud Innovation are headed by same > >> CEO. > >> > >> Content of those letters have been posted here for your convince: > >> > >> *IPDC:* > >> > >> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > >> > >> > >> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > >> over the course of our corporate relationship we were given the authority > >> to use address block 156.241.3.0/24 since 9th December 2019. > >> > >> > >> On 12th December 2019, we have delegated that address block to our client. > >> Following which our client further instructed us to announce the prefix > >> with AS37353. In good will after minimal verification through WHOIS? IP > >> Prefix we have proceeded to execute our client?s request. > >> > >> > >> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > >> of record for that ASN and have since learned that the customer?s use of > >> that ASN was erroneous and not permitted by SEACOM and immediate action has > >> been taken to rectify this situation. > >> > >> > >> IPDC would like to apologize for our lack of attention in conducting > >> thorough verification and wish to highlight that the involvement of Cloud > >> Innovation Ltd in the entire process was providing the addresses to us and > >> that we truly apologize as we understand that this incident may have > >> indirectly implicated Cloud Innovation Ltd. > >> > >> > >> IPDC however, does not wish to disclose our client information and our > >> client information shall remain confidential under present circumstances. > >> Once again, we apologize for our shortcomings. > >> > >> > >> *Link Infinity:* > >> > >> > >> To whom it may concern, > >> > >> We at HK Infinity International Ltd are a customer of Cloud Innovation and > >> in the course received rights to use 156.241.3.0/24 from them. Beginning > >> December, 2019, we delegated the right to announce this prefix to IPDC > >> Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > >> authorizing them to announce the space which was subsequently received. > >> IPDC subsequently and without our knowledge delegated this space to one of > >> their customers and allowed them to originate it from AS37353. > >> > >> This announcement was not authorized by us, nor is it permitted by the LOA > >> provided by Cloud Innovation. > >> > >> Unfortunately, we were not aware of the situation until after it had > >> already been resolved. > >> > >> It was never our intent to violate the LOA or to allow the prefix to be > >> announced from a hijacked ASN. We do not condone this and apologize > >> sincerely to the community for what has happened here. > >> > >> Sincere Apologies, > >> > >> > >> *Paul Wollner:* > >> > >> > >> 8 May 2020 > >> > >> TO WHOM IT MAY CONCERN > >> > >> In the light of the recent email on NAPAfrica mailing list, I would just > >> like to clear the air. > >> > >> > >> The IP route objects were created by myself for Cloud Innovation when they > >> signed up as a client of Macrolan ( now SEACOM) as they didn't have their > >> own AS. > >> > >> At the time I was working for Macrolan (now SEACOM). I left the employment > >> of SEACOM in October 2019. > >> > >> It appears that when Cloud Innovation's contract with SEACOM came to an > >> end, the route objects were never cleaned up. > >> > >> This occurred after I left SEACOM's employment. Since leaving, I have no > >> access to these objects. > >> > >> Regards > >> > >> Paul Wollner > >> 082-786-9776 > >> > >> > >> > >> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: > >> > >>> 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. > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >> > >> > >> -- > >> -- > >> Kind regards. > >> Lu > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < https://lists.afrinic.net/pipermail/community-discuss/attachments/20200525/9e76e35e/attachment-0001.html > > > > > ------------------------------ > > > > Message: 2 > > Date: Mon, 25 May 2020 13:00:22 +0100 > > From: ABDULKARIM AYOPO OLOYEDE > > To: Paschal Ochang > > Cc: General Discussions of AFRINIC , > > "rpd >> AfriNIC Resource Policy" > > Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very > > Poor, If Not Criminal, Netizenship > > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > > > Dear All, > > Please let us all be reminded that this mailing list is to discuss > > policies and directly related issues. > > There are other mailing lists where issues like this can be discussed but > > definitely not here because the issue is *out of scope* for this mailing > > list > > Please, Co-Chairs would like us to put an end to this discussion. > > > > CO-Chairs > > PDWG > > > > > > On Mon, May 25, 2020 at 12:31 PM Paschal Ochang wrote: > > > >> This sounds like a personal attack in my opinion instead of a justified > >> accusation. Why is this topic allowed to be discussed here when it?s rather > >> irrelevant?. The parties involved have tendered formal apologies as > >> reflected in their letters which is a sign of admittance and promotes the > >> intent of good netizenship. It?s just irrelevant. > >> > >> On Monday, May 25, 2020, Arnaud AMELINA wrote: > >> > >>> Hello, community > >>> > >>> +1 @Gregoire and @Mark Tinka > >>> > >>> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* > >>> with *no ASN*. Interesting, and no *v6* > >>> > >>> While the bylaws defines LIR as followed: > >>> ++++++ > >>> Local Internet Registry (LIR): > >>> any Network Operator that provides Internet services to distinct > >>> end-users and end-sites > >>> ++++++ > >>> > >>> I wonder which network does cloud innovation operate and which internet > >>> services it provides to end-users and end-sites in *Africa*. > >>> > >>> How does this network *managing 3 x /11 of IPv4* *operate*? > >>> > >>> There is something here for the community to learn about. > >>> > >>> Regards > >>> > >>> -- > >>> Arnaud > >>> > >>> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a > >>> ?crit : > >>> > >>>> Hello, > >>>> > >>>> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. > >>>> > >>>> I carefully read your report and also the Cloud Innovation Limited quick > >>>> response including their attachments as justifications. > >>>> > >>>> I note that; > >>>> > >>>> ? the service contract with Cloud Innovation covering the announcement > >>>> of their prefixes by SEACOM AS37353 was terminated by SEACOM. > >>>> > >>>> ? some stale IRR route objects existed after termination of the contract. > >>>> > >>>> ? through some multiple layer distribution an organisation in Manila > >>>> Philippines was ?delegated? an IP block from Cloud Innovation address space. > >>>> > >>>> ? both upstream ISP and the customer in Manila set up a BGP session > >>>> using SEACOM's AS37353 as the ASN of the Manila customer. > >>>> > >>>> ? there was a prompt reaction from the involved parties that included > >>>> apologies to SEACOM and the wider internet community. > >>>> > >>>> ? there were promises from said parties to be a better netizen which > >>>> would mean, them not hijacking other networks ASN's. > >>>> > >>>> ? there was clear refusal to disclose the details of the customer in > >>>> Manila Philippines who hijacked the affected SEACOM ASN. > >>>> > >>>> All put together, demonstrates that what happened was an impersonation > >>>> and not a BGP configuration error, nor an oversight in checking the right > >>>> to use of the SEACOM ASN. > >>>> > >>>> 1. Why is it that the real customer did not bother presenting its > >>>> apologies to the community > >>>> > >>>> 2. Why is there refusal to reveal customer?s details? > >>>> > >>>> 3. Why is it that the said prefix is no longer seen in the routing table > >>>> originated by the genius ASN or any other ASN? > >>>> > >>>> 4. Which networks were involved and what happened to the end users? > >>>> > >>>> Can someone from AFRINIC explain what ?delegation of IP block? mean? > >>>> > >>>> Note: The self organised Internet knows how to deal with bad net > >>>> citizens.! > >>>> > >>>> Best regards > >>>> Gregoire Ehoumi > >>>> > >>>> > >>>> -------- Original message -------- > >>>> From: Lu Heng > >>>> Date: 2020-05-09 5:43 a.m. (GMT-05:00) > >>>> To: Mark Tinka > >>>> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < > >>>> rpd at afrinic.net> > >>>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, > >>>> Netizenship > >>>> > >>>> To whom it may concern, > >>>> > >>>> On May 8, Mark Think posted a claim to multiple lists that Cloud > >>>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > >>>> Innovation) but rather belonged to Seacom through their acquisition of > >>>> MacroLAN. > >>>> > >>>> While we regret this unfortunate incident, Mark?s claims that it was > >>>> criminal or bad netizenship on the part of Cloud Innovation is without > >>>> foundation and utterly incorrect. > >>>> > >>>> As shown below in the attached document from Paul Wollner(Ex-CTO of > >>>> Macrolan who created IRR routes to allow Macrolan to announce Cloud > >>>> Innovation's prefix); letter from Link Infinity International Ltd. (Link > >>>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > >>>> authorizing IPDC Solutions to announce the prefix with origin AS134190. > >>>> And a Letter from IPDC. This was an innocent mistake committed by third > >>>> parties and had nothing to do with any action by Cloud Innovation or LARUS. > >>>> > >>>> Here?s what happened: > >>>> > >>>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December > >>>> 2019. > >>>> > >>>> > >>>> Link Infinity further delegated that same /24 to IPDC and asked Cloud > >>>> innovation to issue an LOA, which we did. The LOA specifically required > >>>> IPDC to use its own ASN to announce the space (AS134190). > >>>> > >>>> IPDC subsequently authorized one of its customers to use the said prefix. > >>>> > >>>> > >>>> For reasons still unknown to Cloud Innovation, IPDC and their customer > >>>> set up a BGP session wherein their customer used AS37353 as the origin to > >>>> advertise prefix 156.241.3.0/24. > >>>> > >>>> > >>>> Upon discovering the announcement, rather than contact Cloud Innovation, > >>>> Mark contacted IPDC who provided him with an incomplete explanation blaming > >>>> their customer and Mark, not realizing that Cloud Innovation was not the > >>>> customer in question posted far and wide about the event. It is unclear to > >>>> us why he chose to do this rather than contact us to try and resolve the > >>>> issue. > >>>> > >>>> > >>>> A contributing factor to the erroneous BGP configuration by IPDC's > >>>> customer may have been data contained in some outdated IRR route objects > >>>> for 156.241.0.0/16 which have subsequently been deleted. > >>>> > >>>> As soon as we became aware of the problem (via Mark?s email), we began > >>>> to investigate the situation. As soon as it was clear that this was the > >>>> result of third-party actions, we reached out to Mark privately to let him > >>>> know what we knew and that we were still investigating. We delayed making a > >>>> public statement in order to try and ascertain all of the facts of the > >>>> situation. We prefer not to make public statements based on incomplete > >>>> information. > >>>> > >>>> We apologize to the community for our small part in this unfortunate > >>>> incident and assure you that we work very hard to remain good netizens and > >>>> will address any concerns promptly when they come to our attention. > >>>> > >>>> > >>>> Sincerely, > >>>> > >>>> Lu Heng > >>>> CEO > >>>> Cloud Innovations > >>>> > >>>> Attached: > >>>> 1. Letter from Paul Wollner > >>>> 2. Letter from Link Infinity > >>>> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > >>>> AS134190 > >>>> 4. Letter from IPDC > >>>> > >>>> FYI: LARUS is proving IP management service for Cloud Innovation, while > >>>> LARUS is also providing IP management service to other third parties in all > >>>> regions, for full disclosure, LARUS and Cloud Innovation are headed by same > >>>> CEO. > >>>> > >>>> Content of those letters have been posted here for your convince: > >>>> > >>>> *IPDC:* > >>>> > >>>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > >>>> > >>>> > >>>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > >>>> over the course of our corporate relationship we were given the authority > >>>> to use address block 156.241.3.0/24 since 9th December 2019. > >>>> > >>>> > >>>> On 12th December 2019, we have delegated that address block to our > >>>> client. Following which our client further instructed us to announce the > >>>> prefix with AS37353. In good will after minimal verification through WHOIS? > >>>> IP Prefix we have proceeded to execute our client?s request. > >>>> > >>>> > >>>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > >>>> of record for that ASN and have since learned that the customer?s use of > >>>> that ASN was erroneous and not permitted by SEACOM and immediate action has > >>>> been taken to rectify this situation. > >>>> > >>>> > >>>> IPDC would like to apologize for our lack of attention in conducting > >>>> thorough verification and wish to highlight that the involvement of Cloud > >>>> Innovation Ltd in the entire process was providing the addresses to us and > >>>> that we truly apologize as we understand that this incident may have > >>>> indirectly implicated Cloud Innovation Ltd. > >>>> > >>>> > >>>> IPDC however, does not wish to disclose our client information and our > >>>> client information shall remain confidential under present circumstances. > >>>> Once again, we apologize for our shortcomings. > >>>> > >>>> > >>>> *Link Infinity:* > >>>> > >>>> > >>>> To whom it may concern, > >>>> > >>>> We at HK Infinity International Ltd are a customer of Cloud Innovation > >>>> and in the course received rights to use 156.241.3.0/24 from them. > >>>> Beginning December, 2019, we delegated the right to announce this prefix to > >>>> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > >>>> authorizing them to announce the space which was subsequently received. > >>>> IPDC subsequently and without our knowledge delegated this space to one of > >>>> their customers and allowed them to originate it from AS37353. > >>>> > >>>> This announcement was not authorized by us, nor is it permitted by the > >>>> LOA provided by Cloud Innovation. > >>>> > >>>> Unfortunately, we were not aware of the situation until after it had > >>>> already been resolved. > >>>> > >>>> It was never our intent to violate the LOA or to allow the prefix to be > >>>> announced from a hijacked ASN. We do not condone this and apologize > >>>> sincerely to the community for what has happened here. > >>>> > >>>> Sincere Apologies, > >>>> > >>>> > >>>> *Paul Wollner:* > >>>> > >>>> > >>>> 8 May 2020 > >>>> > >>>> TO WHOM IT MAY CONCERN > >>>> > >>>> In the light of the recent email on NAPAfrica mailing list, I would just > >>>> like to clear the air. > >>>> > >>>> > >>>> The IP route objects were created by myself for Cloud Innovation when > >>>> they signed up as a client of Macrolan ( now SEACOM) as they didn't have > >>>> their own AS. > >>>> > >>>> At the time I was working for Macrolan (now SEACOM). I left the > >>>> employment of SEACOM in October 2019. > >>>> > >>>> It appears that when Cloud Innovation's contract with SEACOM came to an > >>>> end, the route objects were never cleaned up. > >>>> > >>>> This occurred after I left SEACOM's employment. Since leaving, I have no > >>>> access to these objects. > >>>> > >>>> Regards > >>>> > >>>> Paul Wollner > >>>> 082-786-9776 > >>>> > >>>> > >>>> > >>>> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: > >>>> > >>>>> 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. > >>>>> _______________________________________________ > >>>>> RPD mailing list > >>>>> RPD at afrinic.net > >>>>> https://lists.afrinic.net/mailman/listinfo/rpd > >>>>> > >>>> > >>>> > >>>> -- > >>>> -- > >>>> Kind regards. > >>>> Lu > >>>> > >>>> _______________________________________________ > >>>> RPD mailing list > >>>> RPD at afrinic.net > >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >>>> > >>> _______________________________________________ > >>> > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > > > > -- > > Website ,?Weekly Bulletin > > ?UGPortal > > PGPortal > > > > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < https://lists.afrinic.net/pipermail/community-discuss/attachments/20200525/cfbfa5dd/attachment-0001.html > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > Community-Discuss mailing list > > Community-Discuss at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > > > > ------------------------------ > > > > End of Community-Discuss Digest, Vol 616, Issue 1 > > ************************************************* > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < https://lists.afrinic.net/pipermail/community-discuss/attachments/20200525/42e243a0/attachment-0001.html > > > ------------------------------ > > Message: 2 > Date: Mon, 25 May 2020 15:57:23 +0200 (CEST) > From: libren at tuta.io > To: Community Discuss > Cc: Community Discuss > Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very > Poor, If Not Criminal, Netizenship > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hello, > Seems cloud Innovation is using USA Data Center Multacom and using their ASN. > Maybe these are legacy blocks and Afrinic has no control over it? > If they are not legacy blocks then what was the ip justification for acquiring these IP and what Afrinic was policy? > > https://bgp.he.net/AS35916#_prefixes > > > 45.199.0.0/16 Cloud Innovation Ltd > 45.201.0.0/16 Cloud Innovation Ltd > 45.205.0.0/16 Cloud Innovation Ltd > 154.81.0.0/16 Cloud Innovation Ltd > 154.82.0.0/16 Cloud Innovation Ltd > 154.83.0.0/16 Cloud Innovation Ltd > 154.84.0.0/16 Cloud Innovation Ltd > 154.85.0.0/16 Cloud Innovation Ltd > 154.86.0.0/16 Cloud Innovation Ltd > 154.87.0.0/16 Cloud Innovation Ltd > 154.88.0.0/16 Cloud Innovation Ltd > 154.90.0.0/16 Cloud Innovation Ltd > 154.92.0.0/14 Cloud Innovation Ltd > 154.193.0.0/16 Cloud Innovation Ltd > 154.195.0.0/16 Cloud Innovation Ltd > 154.198.0.0/16 Cloud Innovation Ltd > 154.201.0.0/16 Cloud Innovation Ltd > 154.202.0.0/16 Cloud Innovation Ltd > 154.205.0.0/16 Cloud Innovation Ltd > 154.208.0.0/16 Cloud Innovation Ltd > 154.209.0.0/16 Cloud Innovation Ltd > 154.212.0.0/16 Cloud Innovation Ltd > 154.213.0.0/16 CloudInnovation infrastructure > 154.214.0.0/16 Cloud Innovation Ltd > 154.215.0.0/16 Cloud Innovation Ltd > 154.216.0.0/16 CloudInnovation infrastructure > 154.217.0.0/16 CloudInnovation infrastructure > 154.218.0.0/16 Cloud Innovation Ltd > 154.218.0.0/17 Cloud Innovation Ltd > 154.219.0.0/16 Cloud Innovation Ltd > 154.220.0.0/16 CloudInnovation infrastructure > 154.221.0.0/16 Cloud Innovation Ltd > 156.229.0.0/16 Cloud Innovation Ltd > 156.231.0.0/16 Cloud Innovation Ltd > 156.232.0.0/16 Cloud Innovation Ltd > 156.235.0.0/16 Cloud Innovation Ltd > 156.236.0.0/16 Cloud Innovation Ltd > 156.237.0.0/16 Cloud Innovation Ltd > 156.238.0.0/16 Cloud Innovation Ltd > 156.239.0.0/16 Cloud Innovation Ltd > 156.242.0.0/16 Cloud Innovation Ltd > 156.243.0.0/16 Cloud Innovation Ltd > 156.247.0.0/16 Cloud Innovation Ltd > 156.249.0.0/16 Cloud Innovation Ltd > 156.251.0.0/16 Cloud Innovation Ltd > 156.252.0.0/24 Cloud Innovation_infrastructure > > > > > Regards, > Libren > > > -- > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: > https://tutanota.com > > > May 25, 2020, 16:47 by libren at tuta.io: > > > Hello, > > Very interesting question of 3 x /11 allocated to Cloud Innovations. > > > > Regards, > > Libren > > > > -- > > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: > > https://tutanota.com > > > > > > May 25, 2020, 15:00 by community-discuss-request at afrinic.net: > > > >> Send Community-Discuss mailing list submissions to > >> community-discuss at afrinic.net > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.afrinic.net/mailman/listinfo/community-discuss > >> or, via email, send a message with subject or body 'help' to > >> community-discuss-request at afrinic.net > >> > >> You can reach the person managing the list at > >> community-discuss-owner at afrinic.net > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of Community-Discuss digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: [rpd] Cloud Innovation Displays Very Poor, If Not > >> Criminal, Netizenship (Arnaud AMELINA) > >> 2. Re: [rpd] Cloud Innovation Displays Very Poor, If Not > >> Criminal, Netizenship (ABDULKARIM AYOPO OLOYEDE) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Mon, 25 May 2020 01:28:10 +0000 > >> From: Arnaud AMELINA > >> To: Gregoire EHOUMI > >> Cc: General Discussions of AFRINIC , > >> "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" > >> > >> Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very > >> Poor, If Not Criminal, Netizenship > >> Message-ID: > >> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Hello, community > >> > >> +1 @Gregoire and @Mark Tinka > >> > >> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* > >> with *no ASN*. Interesting, and no *v6* > >> > >> While the bylaws defines LIR as followed: > >> ++++++ > >> Local Internet Registry (LIR): > >> any Network Operator that provides Internet services to distinct end-users > >> and end-sites > >> ++++++ > >> > >> I wonder which network does cloud innovation operate and which internet > >> services it provides to end-users and end-sites in *Africa*. > >> > >> How does this network *managing 3 x /11 of IPv4* *operate*? > >> > >> There is something here for the community to learn about. > >> > >> Regards > >> > >> -- > >> Arnaud > >> > >> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a > >> ?crit : > >> > >>> Hello, > >>> > >>> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. > >>> > >>> I carefully read your report and also the Cloud Innovation Limited quick > >>> response including their attachments as justifications. > >>> > >>> I note that; > >>> > >>> ? the service contract with Cloud Innovation covering the announcement of > >>> their prefixes by SEACOM AS37353 was terminated by SEACOM. > >>> > >>> ? some stale IRR route objects existed after termination of the contract. > >>> > >>> ? through some multiple layer distribution an organisation in Manila > >>> Philippines was ?delegated? an IP block from Cloud Innovation address space. > >>> > >>> ? both upstream ISP and the customer in Manila set up a BGP session using > >>> SEACOM's AS37353 as the ASN of the Manila customer. > >>> > >>> ? there was a prompt reaction from the involved parties that included > >>> apologies to SEACOM and the wider internet community. > >>> > >>> ? there were promises from said parties to be a better netizen which would > >>> mean, them not hijacking other networks ASN's. > >>> > >>> ? there was clear refusal to disclose the details of the customer in > >>> Manila Philippines who hijacked the affected SEACOM ASN. > >>> > >>> All put together, demonstrates that what happened was an impersonation and > >>> not a BGP configuration error, nor an oversight in checking the right to > >>> use of the SEACOM ASN. > >>> > >>> 1. Why is it that the real customer did not bother presenting its > >>> apologies to the community > >>> > >>> 2. Why is there refusal to reveal customer?s details? > >>> > >>> 3. Why is it that the said prefix is no longer seen in the routing table > >>> originated by the genius ASN or any other ASN? > >>> > >>> 4. Which networks were involved and what happened to the end users? > >>> > >>> Can someone from AFRINIC explain what ?delegation of IP block? mean? > >>> > >>> Note: The self organised Internet knows how to deal with bad net citizens.! > >>> > >>> Best regards > >>> Gregoire Ehoumi > >>> > >>> > >>> -------- Original message -------- > >>> From: Lu Heng > >>> Date: 2020-05-09 5:43 a.m. (GMT-05:00) > >>> To: Mark Tinka > >>> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < > >>> rpd at afrinic.net> > >>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, > >>> Netizenship > >>> > >>> To whom it may concern, > >>> > >>> On May 8, Mark Think posted a claim to multiple lists that Cloud > >>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > >>> Innovation) but rather belonged to Seacom through their acquisition of > >>> MacroLAN. > >>> > >>> While we regret this unfortunate incident, Mark?s claims that it was > >>> criminal or bad netizenship on the part of Cloud Innovation is without > >>> foundation and utterly incorrect. > >>> > >>> As shown below in the attached document from Paul Wollner(Ex-CTO of > >>> Macrolan who created IRR routes to allow Macrolan to announce Cloud > >>> Innovation's prefix); letter from Link Infinity International Ltd. (Link > >>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > >>> authorizing IPDC Solutions to announce the prefix with origin AS134190. > >>> And a Letter from IPDC. This was an innocent mistake committed by third > >>> parties and had nothing to do with any action by Cloud Innovation or LARUS. > >>> > >>> Here?s what happened: > >>> > >>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. > >>> > >>> > >>> Link Infinity further delegated that same /24 to IPDC and asked Cloud > >>> innovation to issue an LOA, which we did. The LOA specifically required > >>> IPDC to use its own ASN to announce the space (AS134190). > >>> > >>> IPDC subsequently authorized one of its customers to use the said prefix. > >>> > >>> > >>> For reasons still unknown to Cloud Innovation, IPDC and their customer set > >>> up a BGP session wherein their customer used AS37353 as the origin to > >>> advertise prefix 156.241.3.0/24. > >>> > >>> > >>> Upon discovering the announcement, rather than contact Cloud Innovation, > >>> Mark contacted IPDC who provided him with an incomplete explanation blaming > >>> their customer and Mark, not realizing that Cloud Innovation was not the > >>> customer in question posted far and wide about the event. It is unclear to > >>> us why he chose to do this rather than contact us to try and resolve the > >>> issue. > >>> > >>> > >>> A contributing factor to the erroneous BGP configuration by IPDC's > >>> customer may have been data contained in some outdated IRR route objects > >>> for 156.241.0.0/16 which have subsequently been deleted. > >>> > >>> As soon as we became aware of the problem (via Mark?s email), we began to > >>> investigate the situation. As soon as it was clear that this was the result > >>> of third-party actions, we reached out to Mark privately to let him know > >>> what we knew and that we were still investigating. We delayed making a > >>> public statement in order to try and ascertain all of the facts of the > >>> situation. We prefer not to make public statements based on incomplete > >>> information. > >>> > >>> We apologize to the community for our small part in this unfortunate > >>> incident and assure you that we work very hard to remain good netizens and > >>> will address any concerns promptly when they come to our attention. > >>> > >>> > >>> Sincerely, > >>> > >>> Lu Heng > >>> CEO > >>> Cloud Innovations > >>> > >>> Attached: > >>> 1. Letter from Paul Wollner > >>> 2. Letter from Link Infinity > >>> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > >>> AS134190 > >>> 4. Letter from IPDC > >>> > >>> FYI: LARUS is proving IP management service for Cloud Innovation, while > >>> LARUS is also providing IP management service to other third parties in all > >>> regions, for full disclosure, LARUS and Cloud Innovation are headed by same > >>> CEO. > >>> > >>> Content of those letters have been posted here for your convince: > >>> > >>> *IPDC:* > >>> > >>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > >>> > >>> > >>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > >>> over the course of our corporate relationship we were given the authority > >>> to use address block 156.241.3.0/24 since 9th December 2019. > >>> > >>> > >>> On 12th December 2019, we have delegated that address block to our client. > >>> Following which our client further instructed us to announce the prefix > >>> with AS37353. In good will after minimal verification through WHOIS? IP > >>> Prefix we have proceeded to execute our client?s request. > >>> > >>> > >>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > >>> of record for that ASN and have since learned that the customer?s use of > >>> that ASN was erroneous and not permitted by SEACOM and immediate action has > >>> been taken to rectify this situation. > >>> > >>> > >>> IPDC would like to apologize for our lack of attention in conducting > >>> thorough verification and wish to highlight that the involvement of Cloud > >>> Innovation Ltd in the entire process was providing the addresses to us and > >>> that we truly apologize as we understand that this incident may have > >>> indirectly implicated Cloud Innovation Ltd. > >>> > >>> > >>> IPDC however, does not wish to disclose our client information and our > >>> client information shall remain confidential under present circumstances. > >>> Once again, we apologize for our shortcomings. > >>> > >>> > >>> *Link Infinity:* > >>> > >>> > >>> To whom it may concern, > >>> > >>> We at HK Infinity International Ltd are a customer of Cloud Innovation and > >>> in the course received rights to use 156.241.3.0/24 from them. Beginning > >>> December, 2019, we delegated the right to announce this prefix to IPDC > >>> Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > >>> authorizing them to announce the space which was subsequently received. > >>> IPDC subsequently and without our knowledge delegated this space to one of > >>> their customers and allowed them to originate it from AS37353. > >>> > >>> This announcement was not authorized by us, nor is it permitted by the LOA > >>> provided by Cloud Innovation. > >>> > >>> Unfortunately, we were not aware of the situation until after it had > >>> already been resolved. > >>> > >>> It was never our intent to violate the LOA or to allow the prefix to be > >>> announced from a hijacked ASN. We do not condone this and apologize > >>> sincerely to the community for what has happened here. > >>> > >>> Sincere Apologies, > >>> > >>> > >>> *Paul Wollner:* > >>> > >>> > >>> 8 May 2020 > >>> > >>> TO WHOM IT MAY CONCERN > >>> > >>> In the light of the recent email on NAPAfrica mailing list, I would just > >>> like to clear the air. > >>> > >>> > >>> The IP route objects were created by myself for Cloud Innovation when they > >>> signed up as a client of Macrolan ( now SEACOM) as they didn't have their > >>> own AS. > >>> > >>> At the time I was working for Macrolan (now SEACOM). I left the employment > >>> of SEACOM in October 2019. > >>> > >>> It appears that when Cloud Innovation's contract with SEACOM came to an > >>> end, the route objects were never cleaned up. > >>> > >>> This occurred after I left SEACOM's employment. Since leaving, I have no > >>> access to these objects. > >>> > >>> Regards > >>> > >>> Paul Wollner > >>> 082-786-9776 > >>> > >>> > >>> > >>> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: > >>> > >>>> 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. > >>>> _______________________________________________ > >>>> RPD mailing list > >>>> RPD at afrinic.net > >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >>>> > >>> > >>> > >>> -- > >>> -- > >>> Kind regards. > >>> Lu > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < https://lists.afrinic.net/pipermail/community-discuss/attachments/20200525/9e76e35e/attachment-0001.html > > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Mon, 25 May 2020 13:00:22 +0100 > >> From: ABDULKARIM AYOPO OLOYEDE > >> To: Paschal Ochang > >> Cc: General Discussions of AFRINIC , > >> "rpd >> AfriNIC Resource Policy" > >> Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very > >> Poor, If Not Criminal, Netizenship > >> Message-ID: > >> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Dear All, > >> Please let us all be reminded that this mailing list is to discuss > >> policies and directly related issues. > >> There are other mailing lists where issues like this can be discussed but > >> definitely not here because the issue is *out of scope* for this mailing > >> list > >> Please, Co-Chairs would like us to put an end to this discussion. > >> > >> CO-Chairs > >> PDWG > >> > >> > >> On Mon, May 25, 2020 at 12:31 PM Paschal Ochang wrote: > >> > >>> This sounds like a personal attack in my opinion instead of a justified > >>> accusation. Why is this topic allowed to be discussed here when it?s rather > >>> irrelevant?. The parties involved have tendered formal apologies as > >>> reflected in their letters which is a sign of admittance and promotes the > >>> intent of good netizenship. It?s just irrelevant. > >>> > >>> On Monday, May 25, 2020, Arnaud AMELINA wrote: > >>> > >>>> Hello, community > >>>> > >>>> +1 @Gregoire and @Mark Tinka > >>>> > >>>> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* > >>>> with *no ASN*. Interesting, and no *v6* > >>>> > >>>> While the bylaws defines LIR as followed: > >>>> ++++++ > >>>> Local Internet Registry (LIR): > >>>> any Network Operator that provides Internet services to distinct > >>>> end-users and end-sites > >>>> ++++++ > >>>> > >>>> I wonder which network does cloud innovation operate and which internet > >>>> services it provides to end-users and end-sites in *Africa*. > >>>> > >>>> How does this network *managing 3 x /11 of IPv4* *operate*? > >>>> > >>>> There is something here for the community to learn about. > >>>> > >>>> Regards > >>>> > >>>> -- > >>>> Arnaud > >>>> > >>>> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a > >>>> ?crit : > >>>> > >>>>> Hello, > >>>>> > >>>>> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. > >>>>> > >>>>> I carefully read your report and also the Cloud Innovation Limited quick > >>>>> response including their attachments as justifications. > >>>>> > >>>>> I note that; > >>>>> > >>>>> ? the service contract with Cloud Innovation covering the announcement > >>>>> of their prefixes by SEACOM AS37353 was terminated by SEACOM. > >>>>> > >>>>> ? some stale IRR route objects existed after termination of the contract. > >>>>> > >>>>> ? through some multiple layer distribution an organisation in Manila > >>>>> Philippines was ?delegated? an IP block from Cloud Innovation address space. > >>>>> > >>>>> ? both upstream ISP and the customer in Manila set up a BGP session > >>>>> using SEACOM's AS37353 as the ASN of the Manila customer. > >>>>> > >>>>> ? there was a prompt reaction from the involved parties that included > >>>>> apologies to SEACOM and the wider internet community. > >>>>> > >>>>> ? there were promises from said parties to be a better netizen which > >>>>> would mean, them not hijacking other networks ASN's. > >>>>> > >>>>> ? there was clear refusal to disclose the details of the customer in > >>>>> Manila Philippines who hijacked the affected SEACOM ASN. > >>>>> > >>>>> All put together, demonstrates that what happened was an impersonation > >>>>> and not a BGP configuration error, nor an oversight in checking the right > >>>>> to use of the SEACOM ASN. > >>>>> > >>>>> 1. Why is it that the real customer did not bother presenting its > >>>>> apologies to the community > >>>>> > >>>>> 2. Why is there refusal to reveal customer?s details? > >>>>> > >>>>> 3. Why is it that the said prefix is no longer seen in the routing table > >>>>> originated by the genius ASN or any other ASN? > >>>>> > >>>>> 4. Which networks were involved and what happened to the end users? > >>>>> > >>>>> Can someone from AFRINIC explain what ?delegation of IP block? mean? > >>>>> > >>>>> Note: The self organised Internet knows how to deal with bad net > >>>>> citizens.! > >>>>> > >>>>> Best regards > >>>>> Gregoire Ehoumi > >>>>> > >>>>> > >>>>> -------- Original message -------- > >>>>> From: Lu Heng > >>>>> Date: 2020-05-09 5:43 a.m. (GMT-05:00) > >>>>> To: Mark Tinka > >>>>> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < > >>>>> rpd at afrinic.net> > >>>>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, > >>>>> Netizenship > >>>>> > >>>>> To whom it may concern, > >>>>> > >>>>> On May 8, Mark Think posted a claim to multiple lists that Cloud > >>>>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > >>>>> Innovation) but rather belonged to Seacom through their acquisition of > >>>>> MacroLAN. > >>>>> > >>>>> While we regret this unfortunate incident, Mark?s claims that it was > >>>>> criminal or bad netizenship on the part of Cloud Innovation is without > >>>>> foundation and utterly incorrect. > >>>>> > >>>>> As shown below in the attached document from Paul Wollner(Ex-CTO of > >>>>> Macrolan who created IRR routes to allow Macrolan to announce Cloud > >>>>> Innovation's prefix); letter from Link Infinity International Ltd. (Link > >>>>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > >>>>> authorizing IPDC Solutions to announce the prefix with origin AS134190. > >>>>> And a Letter from IPDC. This was an innocent mistake committed by third > >>>>> parties and had nothing to do with any action by Cloud Innovation or LARUS. > >>>>> > >>>>> Here?s what happened: > >>>>> > >>>>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December > >>>>> 2019. > >>>>> > >>>>> > >>>>> Link Infinity further delegated that same /24 to IPDC and asked Cloud > >>>>> innovation to issue an LOA, which we did. The LOA specifically required > >>>>> IPDC to use its own ASN to announce the space (AS134190). > >>>>> > >>>>> IPDC subsequently authorized one of its customers to use the said prefix. > >>>>> > >>>>> > >>>>> For reasons still unknown to Cloud Innovation, IPDC and their customer > >>>>> set up a BGP session wherein their customer used AS37353 as the origin to > >>>>> advertise prefix 156.241.3.0/24. > >>>>> > >>>>> > >>>>> Upon discovering the announcement, rather than contact Cloud Innovation, > >>>>> Mark contacted IPDC who provided him with an incomplete explanation blaming > >>>>> their customer and Mark, not realizing that Cloud Innovation was not the > >>>>> customer in question posted far and wide about the event. It is unclear to > >>>>> us why he chose to do this rather than contact us to try and resolve the > >>>>> issue. > >>>>> > >>>>> > >>>>> A contributing factor to the erroneous BGP configuration by IPDC's > >>>>> customer may have been data contained in some outdated IRR route objects > >>>>> for 156.241.0.0/16 which have subsequently been deleted. > >>>>> > >>>>> As soon as we became aware of the problem (via Mark?s email), we began > >>>>> to investigate the situation. As soon as it was clear that this was the > >>>>> result of third-party actions, we reached out to Mark privately to let him > >>>>> know what we knew and that we were still investigating. We delayed making a > >>>>> public statement in order to try and ascertain all of the facts of the > >>>>> situation. We prefer not to make public statements based on incomplete > >>>>> information. > >>>>> > >>>>> We apologize to the community for our small part in this unfortunate > >>>>> incident and assure you that we work very hard to remain good netizens and > >>>>> will address any concerns promptly when they come to our attention. > >>>>> > >>>>> > >>>>> Sincerely, > >>>>> > >>>>> Lu Heng > >>>>> CEO > >>>>> Cloud Innovations > >>>>> > >>>>> Attached: > >>>>> 1. Letter from Paul Wollner > >>>>> 2. Letter from Link Infinity > >>>>> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > >>>>> AS134190 > >>>>> 4. Letter from IPDC > >>>>> > >>>>> FYI: LARUS is proving IP management service for Cloud Innovation, while > >>>>> LARUS is also providing IP management service to other third parties in all > >>>>> regions, for full disclosure, LARUS and Cloud Innovation are headed by same > >>>>> CEO. > >>>>> > >>>>> Content of those letters have been posted here for your convince: > >>>>> > >>>>> *IPDC:* > >>>>> > >>>>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > >>>>> > >>>>> > >>>>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > >>>>> over the course of our corporate relationship we were given the authority > >>>>> to use address block 156.241.3.0/24 since 9th December 2019. > >>>>> > >>>>> > >>>>> On 12th December 2019, we have delegated that address block to our > >>>>> client. Following which our client further instructed us to announce the > >>>>> prefix with AS37353. In good will after minimal verification through WHOIS? > >>>>> IP Prefix we have proceeded to execute our client?s request. > >>>>> > >>>>> > >>>>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > >>>>> of record for that ASN and have since learned that the customer?s use of > >>>>> that ASN was erroneous and not permitted by SEACOM and immediate action has > >>>>> been taken to rectify this situation. > >>>>> > >>>>> > >>>>> IPDC would like to apologize for our lack of attention in conducting > >>>>> thorough verification and wish to highlight that the involvement of Cloud > >>>>> Innovation Ltd in the entire process was providing the addresses to us and > >>>>> that we truly apologize as we understand that this incident may have > >>>>> indirectly implicated Cloud Innovation Ltd. > >>>>> > >>>>> > >>>>> IPDC however, does not wish to disclose our client information and our > >>>>> client information shall remain confidential under present circumstances. > >>>>> Once again, we apologize for our shortcomings. > >>>>> > >>>>> > >>>>> *Link Infinity:* > >>>>> > >>>>> > >>>>> To whom it may concern, > >>>>> > >>>>> We at HK Infinity International Ltd are a customer of Cloud Innovation > >>>>> and in the course received rights to use 156.241.3.0/24 from them. > >>>>> Beginning December, 2019, we delegated the right to announce this prefix to > >>>>> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > >>>>> authorizing them to announce the space which was subsequently received. > >>>>> IPDC subsequently and without our knowledge delegated this space to one of > >>>>> their customers and allowed them to originate it from AS37353. > >>>>> > >>>>> This announcement was not authorized by us, nor is it permitted by the > >>>>> LOA provided by Cloud Innovation. > >>>>> > >>>>> Unfortunately, we were not aware of the situation until after it had > >>>>> already been resolved. > >>>>> > >>>>> It was never our intent to violate the LOA or to allow the prefix to be > >>>>> announced from a hijacked ASN. We do not condone this and apologize > >>>>> sincerely to the community for what has happened here. > >>>>> > >>>>> Sincere Apologies, > >>>>> > >>>>> > >>>>> *Paul Wollner:* > >>>>> > >>>>> > >>>>> 8 May 2020 > >>>>> > >>>>> TO WHOM IT MAY CONCERN > >>>>> > >>>>> In the light of the recent email on NAPAfrica mailing list, I would just > >>>>> like to clear the air. > >>>>> > >>>>> > >>>>> The IP route objects were created by myself for Cloud Innovation when > >>>>> they signed up as a client of Macrolan ( now SEACOM) as they didn't have > >>>>> their own AS. > >>>>> > >>>>> At the time I was working for Macrolan (now SEACOM). I left the > >>>>> employment of SEACOM in October 2019. > >>>>> > >>>>> It appears that when Cloud Innovation's contract with SEACOM came to an > >>>>> end, the route objects were never cleaned up. > >>>>> > >>>>> This occurred after I left SEACOM's employment. Since leaving, I have no > >>>>> access to these objects. > >>>>> > >>>>> Regards > >>>>> > >>>>> Paul Wollner > >>>>> 082-786-9776 > >>>>> > >>>>> > >>>>> > >>>>> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: > >>>>> > >>>>>> 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. > >>>>>> _______________________________________________ > >>>>>> RPD mailing list > >>>>>> RPD at afrinic.net > >>>>>> https://lists.afrinic.net/mailman/listinfo/rpd > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> -- > >>>>> Kind regards. > >>>>> Lu > >>>>> > >>>>> _______________________________________________ > >>>>> RPD mailing list > >>>>> RPD at afrinic.net > >>>>> https://lists.afrinic.net/mailman/listinfo/rpd > >>>>> > >>>> _______________________________________________ > >>>> > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >> > >> -- > >> Website ,?Weekly Bulletin > >> ?UGPortal > >> PGPortal > >> > >> > >> > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < https://lists.afrinic.net/pipermail/community-discuss/attachments/20200525/cfbfa5dd/attachment-0001.html > > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> Community-Discuss mailing list > >> Community-Discuss at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/community-discuss > >> > >> > >> ------------------------------ > >> > >> End of Community-Discuss Digest, Vol 616, Issue 1 > >> ************************************************* > >> > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < https://lists.afrinic.net/pipermail/community-discuss/attachments/20200525/34ebdf6b/attachment-0001.html > > > ------------------------------ > > Message: 3 > Date: Mon, 25 May 2020 23:00:43 +0000 > From: Arnaud AMELINA > To: Paschal Ochang > Cc: General Discussions of AFRINIC , > "rpd >> AfriNIC Resource Policy" > Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very > Poor, If Not Criminal, Netizenship > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Paschal, > > Please explain why it?s a personal attack when no person was mentioned? > > Please be enlightened that the topic under discussion is allowed because > its application of policy with implications. > > FWIW, Cloud Innovation Ltd, rendering an apology does not make the problem > go away and the working group has to solve the real problem at hand > > Let us be aware that, the way internet deals with bad netizens may cause > damage to parents and even to the whole region if nothing is done to stop > it > > -- > Arnaud > > Le lun. 25 mai 2020 ? 11:30, Paschal Ochang a ?crit : > > > This sounds like a personal attack in my opinion instead of a justified > > accusation. Why is this topic allowed to be discussed here when it?s rather > > irrelevant?. The parties involved have tendered formal apologies as > > reflected in their letters which is a sign of admittance and promotes the > > intent of good netizenship. It?s just irrelevant. > > > > On Monday, May 25, 2020, Arnaud AMELINA wrote: > > > >> Hello, community > >> > >> +1 @Gregoire and @Mark Tinka > >> > >> *cloud innovation* were allocated *big bunch of IPv4* space as a *LIR* > >> with *no ASN*. Interesting, and no *v6* > >> > >> While the bylaws defines LIR as followed: > >> ++++++ > >> Local Internet Registry (LIR): > >> any Network Operator that provides Internet services to distinct > >> end-users and end-sites > >> ++++++ > >> > >> I wonder which network does cloud innovation operate and which internet > >> services it provides to end-users and end-sites in *Africa*. > >> > >> How does this network *managing 3 x /11 of IPv4* *operate*? > >> > >> There is something here for the community to learn about. > >> > >> Regards > >> > >> -- > >> Arnaud > >> > >> Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD a > >> ?crit : > >> > >>> Hello, > >>> > >>> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. > >>> > >>> I carefully read your report and also the Cloud Innovation Limited quick > >>> response including their attachments as justifications. > >>> > >>> I note that; > >>> > >>> ? the service contract with Cloud Innovation covering the announcement > >>> of their prefixes by SEACOM AS37353 was terminated by SEACOM. > >>> > >>> ? some stale IRR route objects existed after termination of the contract. > >>> > >>> ? through some multiple layer distribution an organisation in Manila > >>> Philippines was ?delegated? an IP block from Cloud Innovation address space. > >>> > >>> ? both upstream ISP and the customer in Manila set up a BGP session > >>> using SEACOM's AS37353 as the ASN of the Manila customer. > >>> > >>> ? there was a prompt reaction from the involved parties that included > >>> apologies to SEACOM and the wider internet community. > >>> > >>> ? there were promises from said parties to be a better netizen which > >>> would mean, them not hijacking other networks ASN's. > >>> > >>> ? there was clear refusal to disclose the details of the customer in > >>> Manila Philippines who hijacked the affected SEACOM ASN. > >>> > >>> All put together, demonstrates that what happened was an impersonation > >>> and not a BGP configuration error, nor an oversight in checking the right > >>> to use of the SEACOM ASN. > >>> > >>> 1. Why is it that the real customer did not bother presenting its > >>> apologies to the community > >>> > >>> 2. Why is there refusal to reveal customer?s details? > >>> > >>> 3. Why is it that the said prefix is no longer seen in the routing table > >>> originated by the genius ASN or any other ASN? > >>> > >>> 4. Which networks were involved and what happened to the end users? > >>> > >>> Can someone from AFRINIC explain what ?delegation of IP block? mean? > >>> > >>> Note: The self organised Internet knows how to deal with bad net > >>> citizens.! > >>> > >>> Best regards > >>> Gregoire Ehoumi > >>> > >>> > >>> -------- Original message -------- > >>> From: Lu Heng > >>> Date: 2020-05-09 5:43 a.m. (GMT-05:00) > >>> To: Mark Tinka > >>> Cc: "rpd at afrinic.net >> AfriNIC Resource Policy Discussion List" < > >>> rpd at afrinic.net> > >>> Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, > >>> Netizenship > >>> > >>> To whom it may concern, > >>> > >>> On May 8, Mark Think posted a claim to multiple lists that Cloud > >>> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > >>> Innovation) but rather belonged to Seacom through their acquisition of > >>> MacroLAN. > >>> > >>> While we regret this unfortunate incident, Mark?s claims that it was > >>> criminal or bad netizenship on the part of Cloud Innovation is without > >>> foundation and utterly incorrect. > >>> > >>> As shown below in the attached document from Paul Wollner(Ex-CTO of > >>> Macrolan who created IRR routes to allow Macrolan to announce Cloud > >>> Innovation's prefix); letter from Link Infinity International Ltd. (Link > >>> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > >>> authorizing IPDC Solutions to announce the prefix with origin AS134190. > >>> And a Letter from IPDC. This was an innocent mistake committed by third > >>> parties and had nothing to do with any action by Cloud Innovation or LARUS. > >>> > >>> Here?s what happened: > >>> > >>> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December > >>> 2019. > >>> > >>> > >>> Link Infinity further delegated that same /24 to IPDC and asked Cloud > >>> innovation to issue an LOA, which we did. The LOA specifically required > >>> IPDC to use its own ASN to announce the space (AS134190). > >>> > >>> IPDC subsequently authorized one of its customers to use the said prefix. > >>> > >>> > >>> For reasons still unknown to Cloud Innovation, IPDC and their customer > >>> set up a BGP session wherein their customer used AS37353 as the origin to > >>> advertise prefix 156.241.3.0/24. > >>> > >>> > >>> Upon discovering the announcement, rather than contact Cloud Innovation, > >>> Mark contacted IPDC who provided him with an incomplete explanation blaming > >>> their customer and Mark, not realizing that Cloud Innovation was not the > >>> customer in question posted far and wide about the event. It is unclear to > >>> us why he chose to do this rather than contact us to try and resolve the > >>> issue. > >>> > >>> > >>> A contributing factor to the erroneous BGP configuration by IPDC's > >>> customer may have been data contained in some outdated IRR route objects > >>> for 156.241.0.0/16 which have subsequently been deleted. > >>> > >>> As soon as we became aware of the problem (via Mark?s email), we began > >>> to investigate the situation. As soon as it was clear that this was the > >>> result of third-party actions, we reached out to Mark privately to let him > >>> know what we knew and that we were still investigating. We delayed making a > >>> public statement in order to try and ascertain all of the facts of the > >>> situation. We prefer not to make public statements based on incomplete > >>> information. > >>> > >>> We apologize to the community for our small part in this unfortunate > >>> incident and assure you that we work very hard to remain good netizens and > >>> will address any concerns promptly when they come to our attention. > >>> > >>> > >>> Sincerely, > >>> > >>> Lu Heng > >>> CEO > >>> Cloud Innovations > >>> > >>> Attached: > >>> 1. Letter from Paul Wollner > >>> 2. Letter from Link Infinity > >>> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > >>> AS134190 > >>> 4. Letter from IPDC > >>> > >>> FYI: LARUS is proving IP management service for Cloud Innovation, while > >>> LARUS is also providing IP management service to other third parties in all > >>> regions, for full disclosure, LARUS and Cloud Innovation are headed by same > >>> CEO. > >>> > >>> Content of those letters have been posted here for your convince: > >>> > >>> *IPDC:* > >>> > >>> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > >>> > >>> > >>> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > >>> over the course of our corporate relationship we were given the authority > >>> to use address block 156.241.3.0/24 since 9th December 2019. > >>> > >>> > >>> On 12th December 2019, we have delegated that address block to our > >>> client. Following which our client further instructed us to announce the > >>> prefix with AS37353. In good will after minimal verification through WHOIS? > >>> IP Prefix we have proceeded to execute our client?s request. > >>> > >>> > >>> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > >>> of record for that ASN and have since learned that the customer?s use of > >>> that ASN was erroneous and not permitted by SEACOM and immediate action has > >>> been taken to rectify this situation. > >>> > >>> > >>> IPDC would like to apologize for our lack of attention in conducting > >>> thorough verification and wish to highlight that the involvement of Cloud > >>> Innovation Ltd in the entire process was providing the addresses to us and > >>> that we truly apologize as we understand that this incident may have > >>> indirectly implicated Cloud Innovation Ltd. > >>> > >>> > >>> IPDC however, does not wish to disclose our client information and our > >>> client information shall remain confidential under present circumstances. > >>> Once again, we apologize for our shortcomings. > >>> > >>> > >>> *Link Infinity:* > >>> > >>> > >>> To whom it may concern, > >>> > >>> We at HK Infinity International Ltd are a customer of Cloud Innovation > >>> and in the course received rights to use 156.241.3.0/24 from them. > >>> Beginning December, 2019, we delegated the right to announce this prefix to > >>> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > >>> authorizing them to announce the space which was subsequently received. > >>> IPDC subsequently and without our knowledge delegated this space to one of > >>> their customers and allowed them to originate it from AS37353. > >>> > >>> This announcement was not authorized by us, nor is it permitted by the > >>> LOA provided by Cloud Innovation. > >>> > >>> Unfortunately, we were not aware of the situation until after it had > >>> already been resolved. > >>> > >>> It was never our intent to violate the LOA or to allow the prefix to be > >>> announced from a hijacked ASN. We do not condone this and apologize > >>> sincerely to the community for what has happened here. > >>> > >>> Sincere Apologies, > >>> > >>> > >>> *Paul Wollner:* > >>> > >>> > >>> 8 May 2020 > >>> > >>> TO WHOM IT MAY CONCERN > >>> > >>> In the light of the recent email on NAPAfrica mailing list, I would just > >>> like to clear the air. > >>> > >>> > >>> The IP route objects were created by myself for Cloud Innovation when > >>> they signed up as a client of Macrolan ( now SEACOM) as they didn't have > >>> their own AS. > >>> > >>> At the time I was working for Macrolan (now SEACOM). I left the > >>> employment of SEACOM in October 2019. > >>> > >>> It appears that when Cloud Innovation's contract with SEACOM came to an > >>> end, the route objects were never cleaned up. > >>> > >>> This occurred after I left SEACOM's employment. Since leaving, I have no > >>> access to these objects. > >>> > >>> Regards > >>> > >>> Paul Wollner > >>> 082-786-9776 > >>> > >>> > >>> > >>> On Fri, 8 May 2020 at 22:10, Mark Tinka wrote: > >>> > >>>> 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. > >>>> _______________________________________________ > >>>> RPD mailing list > >>>> RPD at afrinic.net > >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >>>> > >>> > >>> > >>> -- > >>> -- > >>> Kind regards. > >>> Lu > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >> _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < https://lists.afrinic.net/pipermail/community-discuss/attachments/20200525/1ba40a18/attachment-0001.html > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > ------------------------------ > > End of Community-Discuss Digest, Vol 617, Issue 1 > ************************************************* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed May 27 07:46:06 2020 From: owen at delong.com (Owen DeLong) Date: Wed, 27 May 2020 00:46:06 -0700 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: <959458c5-1eaf-c71c-6278-c53628f4e0ff@afrinic.net> References: <959458c5-1eaf-c71c-6278-c53628f4e0ff@afrinic.net> Message-ID: > On May 26, 2020, at 08:27 , James wrote: > > Dear Gregoire, > > > Let me first of all thank you for sharing your concern as well as seeking clarification regarding the matter under hand. > > You have sought from AFRINIC an explanation as regard the term ? delegation of IP block?. > > As far as AFRINIC is concerned , it does not practice ? delegation of IP Block?. Its handling of IP Blocks involves only allocation, sub-allocation or assignment . > In this context, delegation is used as a superset of the terms allocation, sub-allocation, and assignment. From the dictionary: delegate (verb) to commit (powers, functions, etc.) to another as agent or deputy. delegation (noun) The act of delegating When number resources are allocated, sub-allocated, or assigned, the RIR, NIR, or LIR is, in fact, committing the administrative functions over said addresses to the recipient. This is well understood throughout the IP using community and I am surprised by James statement, especially in light of the following: https://www.afrinic.net/services/123-afrinic-policy-for-reverse-delegation-on-allocated-ip-addresses And of course, CPM 2.6: (https://afrinic.net/policy/manual) 2.6 Assignment An assignment is an IP address block given by an LIR to its end-users for their own usage. To "assign" means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. Owen > You may contact the operator/member who has utilised the said term for more clarification. > > Regards, > > James > > On 23/05/2020 18:21, Gregoire EHOUMI via Community-Discuss wrote: >> Hello, >> >> Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. >> >> I carefully read your report and also the Cloud Innovation Limited quick response including their attachments as justifications. >> >> I note that; >> >> ? the service contract with Cloud Innovation covering the announcement of their prefixes by SEACOM AS37353 was terminated by SEACOM. >> >> ? some stale IRR route objects existed after termination of the contract. >> >> ? through some multiple layer distribution an organisation in Manila Philippines was ?delegated? an IP block from Cloud Innovation address space. >> >> ? both upstream ISP and the customer in Manila set up a BGP session using SEACOM's AS37353 as the ASN of the Manila customer. >> >> ? there was a prompt reaction from the involved parties that included apologies to SEACOM and the wider internet community. >> >> ? there were promises from said parties to be a better netizen which would mean, them not hijacking other networks ASN's. >> >> ? there was clear refusal to disclose the details of the customer in Manila Philippines who hijacked the affected SEACOM ASN. >> >> All put together, demonstrates that what happened was an impersonation and not a BGP configuration error, nor an oversight in checking the right to use of the SEACOM ASN. >> >> 1. Why is it that the real customer did not bother presenting its apologies to the community >> >> 2. Why is there refusal to reveal customer?s details? >> >> 3. Why is it that the said prefix is no longer seen in the routing table originated by the genius ASN or any other ASN? >> >> 4. Which networks were involved and what happened to the end users? >> >> Can someone from AFRINIC explain what ?delegation of IP block? mean? >> >> Note: The self organised Internet knows how to deal with bad net citizens.! >> >> Best regards >> Gregoire Ehoumi >> >> >> -------- Original message -------- >> From: Lu Heng >> Date: 2020-05-09 5:41 a.m. (GMT-05:00) >> To: General Discussions of AFRINIC >> Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship >> >> To whom it may concern, >> >> On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather belonged to Seacom through their acquisition of MacroLAN. >> >> While we regret this unfortunate incident, Mark?s claims that it was criminal or bad netizenship on the part of Cloud Innovation is without foundation and utterly incorrect. >> >> As shown below in the attached document from Paul Wollner(Ex-CTO of Macrolan who created IRR routes to allow Macrolan to announce Cloud Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A customer of Cloud Innovation; and attached LOA from LARUS authorizing IPDC Solutions to announce the prefix with origin AS134190. And a Letter from IPDC. This was an innocent mistake committed by third parties and had nothing to do with any action by Cloud Innovation or LARUS. >> >> Here?s what happened: >> >> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. >> >> Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation to issue an LOA, which we did. The LOA specifically required IPDC to use its own ASN to announce the space (AS134190). >> >> IPDC subsequently authorized one of its customers to use the said prefix. >> >> For reasons still unknown to Cloud Innovation, IPDC and their customer set up a BGP session wherein their customer used AS37353 as the origin to advertise prefix 156.241.3.0/24 . >> >> Upon discovering the announcement, rather than contact Cloud Innovation, Mark contacted IPDC who provided him with an incomplete explanation blaming their customer and Mark, not realizing that Cloud Innovation was not the customer in question posted far and wide about the event. It is unclear to us why he chose to do this rather than contact us to try and resolve the issue. >> >> A contributing factor to the erroneous BGP configuration by IPDC's customer may have been data contained in some outdated IRR route objects for 156.241.0.0/16 which have subsequently been deleted. >> >> As soon as we became aware of the problem (via Mark?s email), we began to investigate the situation. As soon as it was clear that this was the result of third-party actions, we reached out to Mark privately to let him know what we knew and that we were still investigating. We delayed making a public statement in order to try and ascertain all of the facts of the situation. We prefer not to make public statements based on incomplete information. >> >> We apologize to the community for our small part in this unfortunate incident and assure you that we work very hard to remain good netizens and will address any concerns promptly when they come to our attention. >> >> >> Sincerely, >> >> Lu Heng >> CEO >> Cloud Innovations >> >> Attached: >> 1. Letter from Paul Wollner >> 2. Letter from Link Infinity >> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from AS134190 >> 4. Letter from IPDC >> >> FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is also providing IP management service to other third parties in all regions, for full disclosure, LARUS and Cloud Innovation are headed by same CEO. >> >> Content of those letters have been posted here for your convince: >> >> IPDC: >> >> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] >> >> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate relationship we were given the authority to use address block 156.241.3.0/24 since 9th December 2019. >> >> On 12th December 2019, we have delegated that address block to our client. Following which our client further instructed us to announce the prefix with AS37353. In good will after minimal verification through WHOIS? IP Prefix we have proceeded to execute our client?s request. >> >> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and immediate action has been taken to rectify this situation. >> >> IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud Innovation Ltd. >> >> IPDC however, does not wish to disclose our client information and our client information shall remain confidential under present circumstances. Once again, we apologize for our shortcomings. >> >> Link Infinity: >> >> To whom it may concern, >> >> We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to use 156.241.3.0/24 from them. Beginning December, 2019, we delegated the right to announce this prefix to IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to announce the space which was subsequently received. IPDC subsequently and without our knowledge delegated this space to one of their customers and allowed them to originate it from AS37353. >> >> This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation. >> >> Unfortunately, we were not aware of the situation until after it had already been resolved. >> >> It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We do not condone this and apologize sincerely to the community for what has happened here. >> >> Sincere Apologies, >> >> Paul Wollner: >> >> 8 May 2020 >> >> TO WHOM IT MAY CONCERN >> >> In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air. >> >> The IP route objects were created by myself for Cloud Innovation when they signed up as a client of Macrolan ( now SEACOM) as they didn't have their own AS. >> >> At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October 2019. >> >> It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were never cleaned up. >> >> This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects. >> >> Regards >> >> Paul Wollner >> 082-786-9776 >> To whom it may concern, >> >> On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather belonged to Seacom through their acquisition of MacroLAN. >> >> While we regret this unfortunate incident, Mark?s claims that it was criminal or bad netizenship on the part of Cloud Innovation is without foundation and utterly incorrect. >> >> As shown below in the attached document from Paul Wollner(Ex-CTO of Macrolan who created IRR routes to allow Macrolan to announce Cloud Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A customer of Cloud Innovation; and attached LOA from LARUS authorizing IPDC Solutions to announce the prefix with origin AS134190. And a Letter from IPDC. This was an innocent mistake committed by third parties and had nothing to do with any action by Cloud Innovation or LARUS. >> >> Here?s what happened: >> >> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. >> >> Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation to issue an LOA, which we did. The LOA specifically required IPDC to use its own ASN to announce the space (AS134190). >> >> IPDC subsequently authorized one of its customers to use the said prefix. >> >> For reasons still unknown to Cloud Innovation, IPDC and their customer set up a BGP session wherein their customer used AS37353 as the origin to advertise prefix 156.241.3.0/24 . >> >> Upon discovering the announcement, rather than contact Cloud Innovation, Mark contacted IPDC who provided him with an incomplete explanation blaming their customer and Mark, not realizing that Cloud Innovation was not the customer in question posted far and wide about the event. It is unclear to us why he chose to do this rather than contact us to try and resolve the issue. >> >> A contributing factor to the erroneous BGP configuration by IPDC's customer may have been data contained in some outdated IRR route objects for 156.241.0.0/16 which have subsequently been deleted. >> >> As soon as we became aware of the problem (via Mark?s email), we began to investigate the situation. As soon as it was clear that this was the result of third-party actions, we reached out to Mark privately to let him know what we knew and that we were still investigating. We delayed making a public statement in order to try and ascertain all of the facts of the situation. We prefer not to make public statements based on incomplete information. >> >> We apologize to the community for our small part in this unfortunate incident and assure you that we work very hard to remain good netizens and will address any concerns promptly when they come to our attention. >> >> >> Sincerely, >> >> Lu Heng >> CEO >> Cloud Innovations >> >> Attached: >> 1. Letter from Paul Wollner >> 2. Letter from Link Infinity >> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from AS134190 >> 4. Letter from IPDC >> >> FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is also providing IP management service to other third parties in all regions, for full disclosure, LARUS and Cloud Innovation are headed by same CEO. >> >> Content of those letters have been posted here for your convince: >> >> IPDC: >> >> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] >> >> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate relationship we were given the authority to use address block 156.241.3.0/24 since 9th December 2019. >> >> On 12th December 2019, we have delegated that address block to our client. Following which our client further instructed us to announce the prefix with AS37353. In good will after minimal verification through WHOIS? IP Prefix we have proceeded to execute our client?s request. >> >> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and immediate action has been taken to rectify this situation. >> >> IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud Innovation Ltd. >> >> IPDC however, does not wish to disclose our client information and our client information shall remain confidential under present circumstances. Once again, we apologize for our shortcomings. >> >> Link Infinity: >> >> To whom it may concern, >> >> We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to use 156.241.3.0/24 from them. Beginning December, 2019, we delegated the right to announce this prefix to IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to announce the space which was subsequently received. IPDC subsequently and without our knowledge delegated this space to one of their customers and allowed them to originate it from AS37353. >> >> This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation. >> >> Unfortunately, we were not aware of the situation until after it had already been resolved. >> >> It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We do not condone this and apologize sincerely to the community for what has happened here. >> >> Sincere Apologies, >> >> Paul Wollner: >> >> 8 May 2020 >> >> TO WHOM IT MAY CONCERN >> >> In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air. >> >> The IP route objects were created by myself for Cloud Innovation when they signed up as a client of Macrolan ( now SEACOM) as they didn't have their own AS. >> >> At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October 2019. >> >> It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were never cleaned up. >> >> This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects. >> >> Regards >> >> Paul Wollner >> 082-786-9776 >> >> On Fri, 8 May 2020 at 22:08, Mark Tinka > wrote: >> 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. >> _______________________________________________ >> Community-Discuss mailing list >> Community-Discuss at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/community-discuss >> >> >> -- >> -- >> Kind regards. >> Lu >> >> >> >> _______________________________________________ >> Community-Discuss mailing list >> Community-Discuss at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/community-discuss > -- > James Chirwa > Acting Manager, Member Services Department > AFRINIC Ltd. > t: +230 403 51 00 | f: +230 466 6758 | > tt: @afrinic | w: www.afrinic.net > SM: facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > ____________________________ > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulos at sdnp.org.mw Wed May 27 09:07:49 2020 From: paulos at sdnp.org.mw (Dr P Nyirenda) Date: Wed, 27 May 2020 11:07:49 +0200 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: , <959458c5-1eaf-c71c-6278-c53628f4e0ff@afrinic.net>, Message-ID: <5ECE2DE5.20873.2929874C@paulos.sdnp.org.mw> On 27 May 2020 at 0:46, Owen DeLong wrote: > On May 26, 2020, at 08:27 , James wrote: > > Dear Gregoire, > > Let me first of all thank you for sharing your concern as well as? seeking clarification regarding > the matter under hand. > You have sought? from AFRINIC an explanation as regard the term " delegation of IP block". > As far as AFRINIC is concerned , it does not practice " delegation of IP Block". Its handling > of IP Blocks involves only allocation, sub-allocation or assignment . > > In this context, delegation is used as a superset of the terms allocation, sub-allocation, and > assignment. Mmmm ... I am with James Chirwa on this one. I think allowing "superset of the terms" in ploicy documents will lead to major confusion where the need to be precise is paramount. > From the dictionary: Policy documents contain a section on definitions that are precisely put there to avoid common dictionary definitions like these, specifically to avoid confusion. > ... cut ... < > When number resources are allocated, sub-allocated, or assigned, the RIR, NIR, or LIR is, in fact, > committing the administrative functions > over said addresses to the recipient. > > This is well understood throughout the IP using community and I am surprised by James > statement, especially in light of the following: > > https://www.afrinic.net/services/123-afrinic-policy-for-reverse-delegation-on-allocated-ip-addresse > s This applies to DNS and not to IP address allocations and/or assignments. I would like to refer you to extensive work done by the CCNSO Framework of Interpretation Working Group (FOIWG) which did a lot of work in this area of DNS and produced its report in 2014, see: https://ccnso.icann.org/sites/default/files/filefield_46435/foi-final-07oct14-en.pdf We did this work in that working group to avoid this kind of confusion that you appear to have here when using such words as "delegation" in identifiers. > And of course, CPM 2.6: (https://afrinic.net/policy/manual ) > > 2.6 Assignment > An assignment is an IP address block given by an LIR to its end-users for their own usage. To > "assign" means to delegate address space to an ISP or End User for specific use within the > Internet infrastructure they operate.?Assignments must only be made for specific purposes > documented by specific organisations and are not to be sub-assigned to other parties. The policy document here refers to the action "by an LIR" and not that of an RIR, lets not confuse the two. Regards, Paulos ====================== Dr Paulos B Nyirenda NIC.MW & .mw ccTLD http://www.registrar.mw Tel: +265-(0)-882 089 166 Cell: +265-(0)-888-824787 WhatsApp: +265-(0)-887386433 > Owen > > You may contact? the operator/member who has utilised? the said term for more clarification. > Regards, > James > On 23/05/2020 18:21, Gregoire EHOUMI via Community-Discuss wrote: > Hello, > > Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. > > I carefully read your report and also the Cloud Innovation Limited quick response > including their attachments as justifications. > > I note that; > > the service contract with Cloud Innovation covering the announcement of their > prefixes by SEACOM AS37353 was terminated? by SEACOM. > > some stale IRR route objects existed after termination of the contract. > > through some multiple layer distribution an organisation in Manila Philippines was > "delegated" an IP block from Cloud Innovation address space. > > both upstream ISP and the customer in Manila set up a BGP session using > SEACOM's AS37353 as the ASN of the Manila customer. > > there was a prompt reaction from the involved parties that included apologies to > SEACOM and the wider internet community. > > there were promises from said parties to be a better netizen which would mean, > them not hijacking other networks ASN's. > > there was clear refusal to disclose the details of the customer in Manila Philippines > who hijacked the affected SEACOM ASN. > > All put together, demonstrates that what happened was an impersonation and not a > BGP configuration error, nor an oversight in checking the right to use of the SEACOM > ASN. > > 1. Why is it that the real customer did not bother presenting its apologies to the > community > > 2. Why is there refusal to reveal customer?s details? > > 3. Why is it that the said prefix is no longer seen in the routing table originated by the > genius ASN or any other ASN? > > 4. Which networks were involved and what happened to the end users? > > Can someone from AFRINIC explain what "delegation of IP block" mean? > > Note: The self organised Internet knows how to deal with bad net citizens.! > > Best regards? > Gregoire Ehoumi? > > > -------- Original message -------- > From: Lu Heng > Date: 2020-05-09 5:41 a.m. (GMT-05:00) > To: General Discussions of AFRINIC > Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not > Criminal, Netizenship > > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was > abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather > belonged to Seacom through their acquisition of MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was criminal or bad > netizenship on the part of Cloud Innovation is without foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of > Macrolan who created IRR routes to allow Macrolan to announce Cloud > Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A > customer of Cloud Innovation; and attached LOA from LARUS authorizing > IPDC Solutions to announce the prefix with origin AS134190.? And a Letter > from IPDC. This was an innocent mistake committed by third parties and had > nothing to do with any action by Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in December > 2019. > > Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation > to issue an LOA, which we did. The LOA specifically required IPDC to use its > own ASN to announce the space (AS134190). > > IPDC subsequently authorized one of its customers to use the said > prefix. > > For reasons still unknown to Cloud Innovation, IPDC and their customer > set up a BGP session wherein their customer used AS37353 as the > origin to advertise prefix?156.241.3.0/24. > > Upon discovering the announcement, rather than contact Cloud > Innovation, Mark contacted IPDC who provided him with an incomplete > explanation blaming their customer and Mark, not realizing that Cloud > Innovation was not the customer in question posted far and wide about > the event. It is unclear to us why he chose to do this rather than contact > us to try and resolve the issue. > > A contributing factor to the erroneous BGP configuration by IPDC's customer > may have been data contained in some outdated IRR route objects > for?156.241.0.0/16?which have subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began to > investigate the situation. As soon as it was clear that this was the result of > third-party actions, we reached out to Mark privately to let him know what we > knew and that we were still investigating. We delayed making a public > statement in order to try and ascertain all of the facts of the situation. We > prefer not to make public statements based on incomplete information. > > We apologize to the community for our small part in this unfortunate incident > and assure you that we work very hard to remain good netizens and will > address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1. Letter from Paul Wollner > 2. Letter from Link Infinity > 3. LOA Issued to IPDC Solutions for announcing?156.241.3.0/24?from AS134190 > ? ? ? ? 4.? ? ?Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is > also providing IP management service to other third parties in all regions, for full > disclosure, LARUS and Cloud Innovation are headed by same CEO. > > Content of those letters have been posted here for your convince: > > IPDC: > > FOR IMMEDIATE RELEASE?[Perusal of Cloud Innovation Ltd] > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate > relationship we were given the authority to use address block?156.241.3.0/24?since 9th December 2019.? > > On 12th December 2019, we have delegated that address block to our client. Following which our client > further instructed us to announce the prefix with AS37353.?In good will after minimal verification through > WHOIS? IP Prefix we have proceeded to execute our client?s request.? > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and > have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and > immediate action has been taken to rectify this situation.? > > IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to > highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to > us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud > Innovation Ltd.? > > IPDC however, does not wish to disclose our client information and our client information shall remain > confidential under present circumstances. Once again, we apologize for our shortcomings.? > > Link Infinity: > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to > use?156.241.3.0/24?from them. Beginning December, 2019, we delegated the right to announce this prefix to > IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to > announce the space which was subsequently received. IPDC subsequently and without our knowledge > delegated this space to one of their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We > do not condone this and apologize sincerely to the community for what has happened here. > > Sincere Apologies, > > Paul Wollner: > > 8 May 2020 > > TO WHOM IT MAY CONCERN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > > In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air.? > > The IP route objects were created by myself for Cloud Innovation when they signed up as a client of > Macrolan ( now SEACOM) as they didn't have their own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October > 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were > never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was > abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather > belonged to Seacom through their acquisition of MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was criminal or bad > netizenship on the part of Cloud Innovation is without foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of > Macrolan who created IRR routes to allow Macrolan to announce Cloud > Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A > customer of Cloud Innovation; and attached LOA from LARUS authorizing > IPDC Solutions to announce the prefix with origin AS134190.? And a Letter > from IPDC. This was an innocent mistake committed by third parties and had > nothing to do with any action by Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in December > 2019. > > Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation > to issue an LOA, which we did. The LOA specifically required IPDC to use its > own ASN to announce the space (AS134190). > > IPDC subsequently authorized one of its customers to use the said > prefix. > > For reasons still unknown to Cloud Innovation, IPDC and their customer > set up a BGP session wherein their customer used AS37353 as the > origin to advertise prefix?156.241.3.0/24. > > Upon discovering the announcement, rather than contact Cloud > Innovation, Mark contacted IPDC who provided him with an incomplete > explanation blaming their customer and Mark, not realizing that Cloud > Innovation was not the customer in question posted far and wide about > the event. It is unclear to us why he chose to do this rather than contact > us to try and resolve the issue. > > A contributing factor to the erroneous BGP configuration by IPDC's customer > may have been data contained in some outdated IRR route objects > for?156.241.0.0/16?which have subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began to > investigate the situation. As soon as it was clear that this was the result of > third-party actions, we reached out to Mark privately to let him know what we > knew and that we were still investigating. We delayed making a public > statement in order to try and ascertain all of the facts of the situation. We > prefer not to make public statements based on incomplete information. > > We apologize to the community for our small part in this unfortunate incident > and assure you that we work very hard to remain good netizens and will > address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1. Letter from Paul Wollner > 2. Letter from Link Infinity > 3. LOA Issued to IPDC Solutions for announcing?156.241.3.0/24?from AS134190 > ? ? ? ? 4.? ? ?Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is > also providing IP management service to other third parties in all regions, for full > disclosure, LARUS and Cloud Innovation are headed by same CEO. > > Content of those letters have been posted here for your convince: > > IPDC: > > FOR IMMEDIATE RELEASE?[Perusal of Cloud Innovation Ltd] > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate > relationship we were given the authority to use address block?156.241.3.0/24?since 9th December 2019.? > > On 12th December 2019, we have delegated that address block to our client. Following which our client > further instructed us to announce the prefix with AS37353.?In good will after minimal verification through > WHOIS? IP Prefix we have proceeded to execute our client?s request.? > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and > have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and > immediate action has been taken to rectify this situation.? > > IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to > highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to > us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud > Innovation Ltd.? > > IPDC however, does not wish to disclose our client information and our client information shall remain > confidential under present circumstances. Once again, we apologize for our shortcomings.? > > Link Infinity: > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to > use?156.241.3.0/24?from them. Beginning December, 2019, we delegated the right to announce this prefix to > IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to > announce the space which was subsequently received. IPDC subsequently and without our knowledge > delegated this space to one of their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We > do not condone this and apologize sincerely to the community for what has happened here. > > Sincere Apologies, > > Paul Wollner: > > 8 May 2020 > > TO WHOM IT MAY CONCERN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > > In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air.? > > The IP route objects were created by myself for Cloud Innovation when they signed up as a client of > Macrolan ( now SEACOM) as they didn't have their own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October > 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were > never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > > On Fri, 8 May 2020 at 22:08, Mark Tinka wrote: > 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. > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > > -- > -- > Kind regards. > Lu > > > > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > -- > James Chirwa > Acting Manager, Member Services Department > AFRINIC Ltd. > t: +230 403 51 00 | f: +230 466 6758 | > tt: @afrinic | w: www.afrinic.net > SM: facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > ____________________________ > > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > -- This email has been checked for viruses by AVG. https://www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nkeramugaba at isoc.org Wed May 27 12:04:14 2020 From: Nkeramugaba at isoc.org (Ghislain Nkeramugaba) Date: Wed, 27 May 2020 12:04:14 +0000 Subject: [Community-Discuss] =?utf-8?q?Forum_du_Peering_d=27Afrique_Centra?= =?utf-8?q?le_=28FPAC/CAPF=29_-_Aujourd=27hui=2C_Mercredi_27_Mai_2020_?= =?utf-8?b?w6AgMTU6MDAtMTc6MDAgV0FUICgxNDowMC0xNjowMCBUVSk=?= Message-ID: <9FF03FF7-3815-4435-AFD8-89165566A050@isoc.org> *Apology for cross-posting/Veuillez excuser les envois multiples* -English version below- Bonjour- Face ? la pand?mie de COVID-19, il est important plus que jamais de maintenir des discussions et des ?changes sur la fa?on de d?velopper l'interconnexion, le peering et la croissance d'Internet en Afrique Centrale. Nous avons r?uni un groupe d'experts de conf?renciers locaux, r?gionaux et mondiaux pour partager leur expertise et leurs id?es sur l'impact de COVID-19 et comment planifier une nouvelle normalit?. Rejoignez-nous en ligne au Forum sur le Peering d?Afrique Central, aujourd'hui, Mercredi 27 mai ? 15:00-17:00 (WAT ou UTC+1). [27 Mai 2020 14:00-16:00 UTC] Inscrivez-vous pour votre place gratuite maintenant: https://www.internetsociety.org/events/central-africa-peering-forum/registration/ Cordialement, Ghislain, ISOC -------------------------------------------------------- Hi everyone- In the face of the COVID-19 pandemic, it is more important than ever to keep conversations alive about how to develop interconnection, peering and Internet growth across Central Africa. We?ve gathered an expert panel of local, regional and global speakers to share their expertise and insights on the impact of COVID-19 and how to plan for a new normal. Join us online at the Central Africa Peering Forum, Today Wednesday 27 May at 15:00-17:00 (WAT or UTC+1), [May 27, 2020 14:00-16:00 UTC] Register for your free place now: https://www.internetsociety.org/fr/events/central-africa-peering-forum/registration/ Regards, Ghislain, ISOC Ghislain -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregoire.ehoumi at yahoo.fr Wed May 27 14:21:16 2020 From: gregoire.ehoumi at yahoo.fr (Gregoire EHOUMI) Date: Wed, 27 May 2020 10:21:16 -0400 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: Message-ID: Hi Owen,As Dr. Paulos has clarified to you indeed, James referred to the accepted technical terms used to IP management.Your reference to reverse dns delegation is irrelevant as we are not discussing reverse DNS name space.Thanks for reminding us the definition of ?assignment? from section 2.6 of the CPM.2.6 referred to:1- an IP address block given by an LIR to its end-users for their own usage. 2- delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. 3- Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.How come a block which is ?delegated? to Link Infinity Technology Limited by cloud innovation got delegated to IPDC By Link Infinity? and then ?delegated? to a customer by IPDC according to documents provided by Cloud innovation?A clear violation of policies.-- Gregoire -------- Original message --------From: Dr P Nyirenda Date: 2020-05-27 5:09 a.m. (GMT-05:00) To: Owen DeLong , community-discuss at afrinic.net Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship On 27 May 2020 at 0:46, Owen DeLong wrote: >???? On May 26, 2020, at 08:27 , James wrote: > >???? Dear Gregoire, > >???? Let me first of all thank you for sharing your concern as well as? seeking clarification regarding >???? the matter under hand. >???? You have sought? from AFRINIC an explanation as regard the term ? delegation of IP block?. >???? As far as AFRINIC is concerned , it does not practice ? delegation of IP Block?. Its handling >???? of IP Blocks involves only allocation, sub-allocation or assignment . > > In this context, delegation is used as a superset of the terms allocation, sub-allocation, and > assignment. Mmmm ... I am with James Chirwa on this one. I think allowing " superset of the terms " in ploicy documents will lead to major confusion where the need to be precise is paramount. > From the dictionary: Policy documents contain a section on definitions that are precisely put there to avoid common dictionary definitions like these, specifically to avoid confusion. > ... cut ... < ? > When number resources are allocated, sub-allocated, or assigned, the RIR, NIR, or LIR is, in fact, > committing the administrative functions > over said addresses to the recipient. > > This is well understood throughout the IP using community and I am surprised by James > statement, especially in light of the following: > > https://www.afrinic.net/services/123-afrinic-policy-for-reverse-delegation-on-allocated-ip-addresse > s This applies to DNS and not to IP address allocations and/or assignments. I would like to refer you to extensive work done by the CCNSO Framework of Interpretation??? Working Group (FOIWG) which did a lot of work in this area of DNS and produced its report in 2014, see: https://ccnso.icann.org/sites/default/files/filefield_46435/foi-final-07oct14-en.pdf We did this work in that working group to avoid this kind of confusion that you appear to have here when using such words as "delegation" in identifiers. > And of course, CPM 2.6: (https://afrinic.net/policy/manual ) > > 2.6 Assignment > An assignment is an IP address block given by an LIR to its end-users for their own usage. To > "assign" means to delegate address space to an ISP or End User for specific use within the > Internet infrastructure they operate.?Assignments must only be made for specific purposes > documented by specific organisations and are not to be sub-assigned to other parties. The policy document here refers to the action " by an LIR" and not that of an RIR, lets not confuse the two. Regards, Paulos ====================== Dr Paulos B Nyirenda NIC.MW & .mw ccTLD http://www.registrar.mw Tel:? +265-(0)-882 089 166 Cell: +265-(0)-888-824787 WhatsApp: +265-(0)-887386433 ? > Owen > >???? You may contact? the operator/member who has utilised? the said term for more clarification. >???? Regards, >???? James >???? On 23/05/2020 18:21, Gregoire EHOUMI via Community-Discuss wrote: >???? Hello, >???? >???? Thanks Mark for exposing the details of the SEACOM AS37353 hijacking. >???? >???? I carefully read your report and also the Cloud Innovation Limited quick response >???? including their attachments as justifications. >???? >???? I note that; >???? >???? ? the service contract with Cloud Innovation covering the announcement of their >???? prefixes by SEACOM AS37353 was terminated? by SEACOM. >???? >???? ? some stale IRR route objects existed after termination of the contract. >???? >???? ? through some multiple layer distribution an organisation in Manila Philippines was >???? ?delegated? an IP block from Cloud Innovation address space. >???? >???? ? both upstream ISP and the customer in Manila set up a BGP session using >???? SEACOM's AS37353 as the ASN of the Manila customer. >???? >???? ? there was a prompt reaction from the involved parties that included apologies to >???? SEACOM and the wider internet community. >???? >???? ? there were promises from said parties to be a better netizen which would mean, >???? them not hijacking other networks ASN's. >???? >???? ? there was clear refusal to disclose the details of the customer in Manila Philippines >???? who hijacked the affected SEACOM ASN. >???? >???? All put together, demonstrates that what happened was an impersonation and not a >???? BGP configuration error, nor an oversight in checking the right to use of the SEACOM >???? ASN. >???? >???? 1. Why is it that the real customer did not bother presenting its apologies to the >???? community >???? >???? 2. Why is there refusal to reveal customer?s details? >???? >???? 3. Why is it that the said prefix is no longer seen in the routing table originated by the >???? genius ASN or any other ASN? >???? >???? 4. Which networks were involved and what happened to the end users? >???? >???? Can someone from AFRINIC explain what ?delegation of IP block? mean? >???? >???? Note: The self organised Internet knows how to deal with bad net citizens.! >???? >???? Best regards? >???? Gregoire Ehoumi? > > >???? -------- Original message -------- >???? From: Lu Heng >???? Date: 2020-05-09 5:41 a.m. (GMT-05:00) >???? To: General Discussions of AFRINIC >???? Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not >???? Criminal, Netizenship > >???? To whom it may concern, > >???? On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was >???? abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather >???? belonged to Seacom through their acquisition of MacroLAN. > >???? While we regret this unfortunate incident, Mark?s claims that it was criminal or bad >???? netizenship on the part of Cloud Innovation is without foundation and utterly incorrect. > >???? As shown below in the attached document from Paul Wollner(Ex-CTO of >???? Macrolan who created IRR routes to allow Macrolan to announce Cloud >???? Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A >???? customer of Cloud Innovation; and attached LOA from LARUS authorizing >???? IPDC Solutions to announce the prefix with origin AS134190.? And a Letter >???? from IPDC. This was an innocent mistake committed by third parties and had >???? nothing to do with any action by Cloud Innovation or LARUS. > >???? Here?s what happened: > >???? Cloud Innovation delegated a /24 to Link Infinity, an ISP in December >???? 2019. > >???? Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation >???? to issue an LOA, which we did. The LOA specifically required IPDC to use its >???? own ASN to announce the space (AS134190). > >???? IPDC subsequently authorized one of its customers to use the said >???? prefix. > >???? For reasons still unknown to Cloud Innovation, IPDC and their customer >???? set up a BGP session wherein their customer used AS37353 as the >???? origin to advertise prefix?156.241.3.0/24. > >???? Upon discovering the announcement, rather than contact Cloud >???? Innovation, Mark contacted IPDC who provided him with an incomplete >???? explanation blaming their customer and Mark, not realizing that Cloud >???? Innovation was not the customer in question posted far and wide about >???? the event. It is unclear to us why he chose to do this rather than contact >???? us to try and resolve the issue. > >???? A contributing factor to the erroneous BGP configuration by IPDC's customer >???? may have been data contained in some outdated IRR route objects >???? for?156.241.0.0/16?which have subsequently been deleted. > >???? As soon as we became aware of the problem (via Mark?s email), we began to >???? investigate the situation. As soon as it was clear that this was the result of >???? third-party actions, we reached out to Mark privately to let him know what we >???? knew and that we were still investigating. We delayed making a public >???? statement in order to try and ascertain all of the facts of the situation. We >???? prefer not to make public statements based on incomplete information. > >???? We apologize to the community for our small part in this unfortunate incident >???? and assure you that we work very hard to remain good netizens and will >???? address any concerns promptly when they come to our attention. > > >???? Sincerely, > >???? Lu Heng >???? CEO >???? Cloud Innovations > >???? Attached: >???? 1. Letter from Paul Wollner >???? 2. Letter from Link Infinity >???? 3. LOA Issued to IPDC Solutions for announcing?156.241.3.0/24?from AS134190 >???? ? ? ? ? 4.? ? ?Letter from IPDC > >???? FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is >???? also providing IP management service to other third parties in all regions, for full >???? disclosure, LARUS and Cloud Innovation are headed by same CEO. > >???? Content of those letters have been posted here for your convince: > >???? IPDC: > > FOR IMMEDIATE RELEASE?[Perusal of Cloud Innovation Ltd] > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate > relationship we were given the authority to use address block?156.241.3.0/24?since 9th December 2019.? > > On 12th December 2019, we have delegated that address block to our client. Following which our client > further instructed us to announce the prefix with AS37353.?In good will after minimal verification through > WHOIS? IP Prefix we have proceeded to execute our client?s request.? > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and > have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and > immediate action has been taken to rectify this situation.? > > IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to > highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to > us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud > Innovation Ltd.? > > IPDC however, does not wish to disclose our client information and our client information shall remain > confidential under present circumstances. Once again, we apologize for our shortcomings.? > > Link Infinity: > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to > use?156.241.3.0/24?from them. Beginning December, 2019, we delegated the right to announce this prefix to > IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to > announce the space which was subsequently received. IPDC subsequently and without our knowledge > delegated this space to one of their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We > do not condone this and apologize sincerely to the community for what has happened here. > > Sincere Apologies, > > Paul Wollner: > > 8 May 2020 > > TO WHOM IT MAY CONCERN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > > In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air.? > > The IP route objects were created by myself for Cloud Innovation when they signed up as a client of > Macrolan ( now SEACOM) as they didn't have their own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October > 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were > never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects. > > Regards > > Paul Wollner > 082-786-9776 >???? To whom it may concern, > >???? On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was >???? abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather >???? belonged to Seacom through their acquisition of MacroLAN. > >???? While we regret this unfortunate incident, Mark?s claims that it was criminal or bad >???? netizenship on the part of Cloud Innovation is without foundation and utterly incorrect. > >???? As shown below in the attached document from Paul Wollner(Ex-CTO of >???? Macrolan who created IRR routes to allow Macrolan to announce Cloud >???? Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A >???? customer of Cloud Innovation; and attached LOA from LARUS authorizing >???? IPDC Solutions to announce the prefix with origin AS134190.? And a Letter >???? from IPDC. This was an innocent mistake committed by third parties and had >???? nothing to do with any action by Cloud Innovation or LARUS. > >???? Here?s what happened: > >???? Cloud Innovation delegated a /24 to Link Infinity, an ISP in December >???? 2019. > >???? Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation >???? to issue an LOA, which we did. The LOA specifically required IPDC to use its >???? own ASN to announce the space (AS134190). > >???? IPDC subsequently authorized one of its customers to use the said >???? prefix. > >???? For reasons still unknown to Cloud Innovation, IPDC and their customer >???? set up a BGP session wherein their customer used AS37353 as the >???? origin to advertise prefix?156.241.3.0/24. > >???? Upon discovering the announcement, rather than contact Cloud >???? Innovation, Mark contacted IPDC who provided him with an incomplete >???? explanation blaming their customer and Mark, not realizing that Cloud >???? Innovation was not the customer in question posted far and wide about >???? the event. It is unclear to us why he chose to do this rather than contact >???? us to try and resolve the issue. > >???? A contributing factor to the erroneous BGP configuration by IPDC's customer >???? may have been data contained in some outdated IRR route objects >???? for?156.241.0.0/16?which have subsequently been deleted. > >???? As soon as we became aware of the problem (via Mark?s email), we began to >???? investigate the situation. As soon as it was clear that this was the result of >???? third-party actions, we reached out to Mark privately to let him know what we >???? knew and that we were still investigating. We delayed making a public >???? statement in order to try and ascertain all of the facts of the situation. We >???? prefer not to make public statements based on incomplete information. > >???? We apologize to the community for our small part in this unfortunate incident >???? and assure you that we work very hard to remain good netizens and will >???? address any concerns promptly when they come to our attention. > > >???? Sincerely, > >???? Lu Heng >???? CEO >???? Cloud Innovations > >???? Attached: >???? 1. Letter from Paul Wollner >???? 2. Letter from Link Infinity >???? 3. LOA Issued to IPDC Solutions for announcing?156.241.3.0/24?from AS134190 >???? ? ? ? ? 4.? ? ?Letter from IPDC > >???? FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is >???? also providing IP management service to other third parties in all regions, for full >???? disclosure, LARUS and Cloud Innovation are headed by same CEO. > >???? Content of those letters have been posted here for your convince: > >???? IPDC: > > FOR IMMEDIATE RELEASE?[Perusal of Cloud Innovation Ltd] > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate > relationship we were given the authority to use address block?156.241.3.0/24?since 9th December 2019.? > > On 12th December 2019, we have delegated that address block to our client. Following which our client > further instructed us to announce the prefix with AS37353.?In good will after minimal verification through > WHOIS? IP Prefix we have proceeded to execute our client?s request.? > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and > have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and > immediate action has been taken to rectify this situation.? > > IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to > highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to > us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud > Innovation Ltd.? > > IPDC however, does not wish to disclose our client information and our client information shall remain > confidential under present circumstances. Once again, we apologize for our shortcomings.? > > Link Infinity: > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to > use?156.241.3.0/24?from them. Beginning December, 2019, we delegated the right to announce this prefix to > IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to > announce the space which was subsequently received. IPDC subsequently and without our knowledge > delegated this space to one of their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We > do not condone this and apologize sincerely to the community for what has happened here. > > Sincere Apologies, > > Paul Wollner: > > 8 May 2020 > > TO WHOM IT MAY CONCERN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > > In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air.? > > The IP route objects were created by myself for Cloud Innovation when they signed up as a client of > Macrolan ( now SEACOM) as they didn't have their own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October > 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were > never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > >???? On Fri, 8 May 2020 at 22:08, Mark Tinka wrote: >???? 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. >???? _______________________________________________ >???? Community-Discuss mailing list >???? Community-Discuss at afrinic.net >???? https://lists.afrinic.net/mailman/listinfo/community-discuss > >???? -- >???? -- >???? Kind regards. >???? Lu > > >???? >???? _______________________________________________ >???? Community-Discuss mailing list >???? Community-Discuss at afrinic.net >???? https://lists.afrinic.net/mailman/listinfo/community-discuss > >???? >???? -- >???? James Chirwa >???? Acting Manager, Member Services Department >???? AFRINIC Ltd. >???? t: +230 403 51 00 | f: +230 466 6758 | >???? tt: @afrinic | w: www.afrinic.net >???? SM: facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia >???? ____________________________ > >???? _______________________________________________ >???? Community-Discuss mailing list >???? Community-Discuss at afrinic.net >???? https://lists.afrinic.net/mailman/listinfo/community-discuss > ?? Virus-free. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrobert at africacert.org Thu May 28 20:29:00 2020 From: hrobert at africacert.org (Jean-Robert Hountomey) Date: Thu, 28 May 2020 16:29:00 -0400 (EDT) Subject: [Community-Discuss] Invitation to the AUC-ATU-ISOC Webinar on Internet Resilience during COVID-19 to take place June 1st, 2020 Message-ID: <1590697740.891811050@apps.rackspace.com> Invitation to Participate in a Webinar on Internet Resilience in Africa during COVID-19 FRENCH BELOW- FRANCAIS PLUS BAS African Union Commission in collaboration with African Telecommunications Union (ATU) and Internet Society Africa (ISOC Africa) is convening a Webinar on Internet Resilience in Africa in the context of COVID-19. In this new era of lockdowns and travel restrictions triggered by the COVID-19 pandemic, more Africans are on the Internet for livelihoods, education, businesses and for entertainment. Many Africans are discovering the importance of Internet during these social distancing times. This exceptional moment has also shown the resilience of Internet as well as the shortcomings of Africa's Internet infrastructure and digital economy. This webinar is the first of a series of webinars on Internet Resilience in Africa. It assesses the growing impact of COVID-19 on livelihoods and work in Africa and the readiness of the continent's Internet infrastructure to help mitigate those challenges. The webinar will discuss the quick and major changes in the use of Internet that occurred in the last few months have affected the operations of organizations such as AFRINIC, Internet Service Providers and Cable operators. It also discusses how Internet has allowed business continuity during lockdown and how governments, regulators, operators and the private sector have used the Internet to ease the disruption of our social and economic life. Last but not least, it will discuss how the Internet is being used in the fight against COVID-19. The webinar is expected to deliver comprehensive policy and regulatory recommendations that enable governments and regulators to better understand how to create a stronger Internet to help Africa not only during COVID-19 times and but also after the pandemic. Webinar Information: Date and Time: ? Date: 01 June 2020 ? Time: 14:00 to 15:30 (GMT+3) Registration to the Webinar: Please complete the registration form in the following link to receive instructions how to join the webinar through your email address. Please ensure that the email address you enter in the form is correct. [ https://zoom.us/j/96008198078?pwd=WG9VSkdkZmRGaFJXdDRlYVlwQXNaZz09 ]( https://zoom.us/j/96008198078?pwd=WG9VSkdkZmRGaFJXdDRlYVlwQXNaZz09 ) For More Information: Please visit the following event page for the draft Agenda, concept notes and other relevant information: [ https://au.int/en/newsevents/20200601/internet-resilience-africa-webinar-series ]( https://au.int/en/newsevents/20200601/internet-resilience-africa-webinar-series ) ?------- FRANCAIS Invitation ? participer ? un webinaire sur la r?silience de l?Internet en Afrique pendant le COVID-19 La Commission de l?Union africaine, en collaboration avec l?Union africaine des t?l?communications (UAT) et Internet Society Africa (ISOC Africa) organise un Webinaire sur la r?silience de l?Internet en Afrique dans pendant la crise du COVID-19. Dans cette nouvelle ?re de blocages et de restrictions de voyage d?clench?es par la pand?mie du COVID-19, un plus grand nombre d?Africains utilisent l?Internet pour leurs survies, l??ducation, les affaires et pour le divertissement. De nombreux Africains d?couvrent l?importance de l?Internet en ces temps de distanciation sociale. Cette p?riode exceptionnelle a ?galement montr? la r?silience ainsi que les lacunes de l?infrastructure de l?Internet et de l??conomie num?rique de l?Afrique. Ce webinaire est le premier d?une s?rie de webinaires sur la r?silience d?Internet en Afrique. Il devrait ?valuer l?impact croissant du COVID-19 sur les moyens de subsistance et le travail en Afrique et l??tat de pr?paration de l?infrastructure de l?Internet du continent pour aider ? att?nuer ces d?fis. Le webinaire discutera des changements rapides et majeurs dans l?utilisation de l?Internet qui se sont produits au cours des derniers mois et qui ont affect? les op?rations d?organisations telles que l?AFRINIC, les fournisseurs de services Internet et les c?blodistributeurs. Il traite ?galement de la fa?on dont Internet a permis la continuit? des activit?s pendant le confinement et comment les gouvernements, les organes de r?gulation, les exploitants et le secteur priv? ont utilis? l?Internet pour att?nuer la perturbation de notre vie sociale et ?conomique. Enfin, il discutera de la fa?on dont l?Internet est utilis? dans la lutte contre le COVID-19. Le webinaire devrait pr?senter des recommandations politiques et r?glementaires compl?tes qui permettent aux gouvernements et aux organismes de r?gulation de mieux comprendre comment cr?er un Internet plus fort pour aider l?Afrique non seulement pendant la p?riode du COVID-19 et aussi apr?s la pand?mie. Informations sur le webinaire: Date et heure: ? Date : 01 juin 2020 ? Heure : 14h00 ? 15h30 (GMT+3) Inscription au Webinaire: Veuillez remplir le formulaire d?inscription contenu dans le lien suivant pour recevoir des instructions sur la fa?on de rejoindre le webinaire par l?interm?diaire de votre adresse e-mail. Assurez-vous s?il vous pla?t que l?adresse e-mail que vous entrez dans le formulaire est correcte. [ https://zoom.us/j/96008198078?pwd=WG9VSkdkZmRGaFJXdDRlYVlwQXNaZz09 ]( https://ssl.microsofttranslator.com/bv.aspx?ref=TAns&from=&to=fr&a=https%3A%2F%2Fzoom.us%2Fj%2F96008198078%3Fpwd%3DWG9VSkdkZmRGaFJXdDRlYVlwQXNaZz09 ) Pour plus d?informations: Veuillez visiter la page de l??v?nement suivant pour le projet d?ordre du jour, les notes conceptuelles et d?autres informations pertinentes : [ https://au.int/en/newsevents/20200601/internet-resilience-africa-webinar-series ]( https://ssl.microsofttranslator.com/bv.aspx?ref=TAns&from=&to=fr&a=https%3A%2F%2Fau.int%2Fen%2Fnewsevents%2F20200601%2Finternet-resilience-africa-webinar-series ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From amelnaud at gmail.com Thu May 28 20:05:38 2020 From: amelnaud at gmail.com (Arnaud AMELINA) Date: Thu, 28 May 2020 20:05:38 +0000 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Hi, all communities It was said that the hijacking of AS37353 was a configuration mistake, coupled with poor oversight in checking the right to use of the ASN by a certain IPDC customer. It was also said that this would have been facilitated by old and stalled IRR objects from MacroLAN before the service contract ended in December 2019. It was also stated that the BGP announcement was stopped and some actions taken to delete the stalled routing registry object from IRR. Below are some data which gives some extra information and confirm previous claim that this incident was not accidental. NB: All data are collected from their source, Today, 28 May 2020, at 10:00 UTC. IRRs created in March 2020 with AS37353 as Origin for 156.241.3.0/24 by HGC $ whois -h whois.radb.net '156.241.3.0/24' route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS37353 notify: matthew.chan at hgc.com.hk mnt-by: MAINT-HGC-INTL changed: matthew.chan at hgc.com.hk 20200304 source: RADB ===== route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS37353 remarks: This is a HGC customer route-object remarks: which is being exported under this origin AS. remarks: remarks: This route object was created because no existing remarks: route object with the same origin was found. remarks: remarks: Please contact radb at hutchcity.com if you have any remarks: questions regarding this object. notify: radb at hutchcity.com mnt-by: MAINT-AS9304 changed: radb at hutchcity.com 20200304 source: NTTCOM ==== https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0%2F24&-T+option=&ip_option=&-i+option= These objects havent been deleted. An in-depth check of the routing status of 156.241.3.0/24 shows the followings: Hurricane Electric BGP tool https://bgp.he.net/net/156.241.3.0/24 Origin AS Announcement Description AS37353 156.241.3.0/24 IRR Valid HONGKONG LINK INFINITY TECHNOLOGY LIMITED RIPESTAT https://stat.ripe.net/widget/looking-glass#w.resource=156.241.3.0%2F24 AS37353 is seen as the origin by 1 peer. 103.200.115.1 ?103.200.115.1 is announcing route AS64271 AS9304 AS4809 AS4809 AS4809 AS134190 AS37353. Even with the limited view, the prefix is still being originated and routed and the route objects still exist. Regards -- Arnaud Le sam. 9 mai 2020 ? 09:44, Lu Heng a ?crit : > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud > Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > Innovation) but rather belonged to Seacom through their acquisition of > MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was > criminal or bad netizenship on the part of Cloud Innovation is without > foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of > Macrolan who created IRR routes to allow Macrolan to announce Cloud > Innovation's prefix); letter from Link Infinity International Ltd. (Link > Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > authorizing IPDC Solutions to announce the prefix with origin AS134190. > And a Letter from IPDC. This was an innocent mistake committed by third > parties and had nothing to do with any action by Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. > > > Link Infinity further delegated that same /24 to IPDC and asked Cloud > innovation to issue an LOA, which we did. The LOA specifically required > IPDC to use its own ASN to announce the space (AS134190). > > IPDC subsequently authorized one of its customers to use the said prefix. > > > For reasons still unknown to Cloud Innovation, IPDC and their customer set > up a BGP session wherein their customer used AS37353 as the origin to > advertise prefix 156.241.3.0/24. > > > Upon discovering the announcement, rather than contact Cloud Innovation, > Mark contacted IPDC who provided him with an incomplete explanation blaming > their customer and Mark, not realizing that Cloud Innovation was not the > customer in question posted far and wide about the event. It is unclear to > us why he chose to do this rather than contact us to try and resolve the > issue. > > > A contributing factor to the erroneous BGP configuration by IPDC's > customer may have been data contained in some outdated IRR route objects > for 156.241.0.0/16 which have subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began to > investigate the situation. As soon as it was clear that this was the result > of third-party actions, we reached out to Mark privately to let him know > what we knew and that we were still investigating. We delayed making a > public statement in order to try and ascertain all of the facts of the > situation. We prefer not to make public statements based on incomplete > information. > > We apologize to the community for our small part in this unfortunate > incident and assure you that we work very hard to remain good netizens and > will address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1. Letter from Paul Wollner > 2. Letter from Link Infinity > 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > AS134190 > 4. Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, while > LARUS is also providing IP management service to other third parties in all > regions, for full disclosure, LARUS and Cloud Innovation are headed by same > CEO. > > Content of those letters have been posted here for your convince: > > *IPDC:* > > FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > over the course of our corporate relationship we were given the authority > to use address block 156.241.3.0/24 since 9th December 2019. > > > On 12th December 2019, we have delegated that address block to our client. > Following which our client further instructed us to announce the prefix > with AS37353. In good will after minimal verification through WHOIS? IP > Prefix we have proceeded to execute our client?s request. > > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > of record for that ASN and have since learned that the customer?s use of > that ASN was erroneous and not permitted by SEACOM and immediate action has > been taken to rectify this situation. > > > IPDC would like to apologize for our lack of attention in conducting > thorough verification and wish to highlight that the involvement of Cloud > Innovation Ltd in the entire process was providing the addresses to us and > that we truly apologize as we understand that this incident may have > indirectly implicated Cloud Innovation Ltd. > > > IPDC however, does not wish to disclose our client information and our > client information shall remain confidential under present circumstances. > Once again, we apologize for our shortcomings. > > > *Link Infinity:* > > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and > in the course received rights to use 156.241.3.0/24 from them. Beginning > December, 2019, we delegated the right to announce this prefix to IPDC > Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > authorizing them to announce the space which was subsequently received. > IPDC subsequently and without our knowledge delegated this space to one of > their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA > provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had > already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be > announced from a hijacked ASN. We do not condone this and apologize > sincerely to the community for what has happened here. > > Sincere Apologies, > > > *Paul Wollner:* > > > 8 May 2020 > > TO WHOM IT MAY CONCERN > > In the light of the recent email on NAPAfrica mailing list, I would just > like to clear the air. > > > The IP route objects were created by myself for Cloud Innovation when they > signed up as a client of Macrolan ( now SEACOM) as they didn't have their > own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment > of SEACOM in October 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an > end, the route objects were never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no > access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud > Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > Innovation) but rather belonged to Seacom through their acquisition of > MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was > criminal or bad netizenship on the part of Cloud Innovation is without > foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of > Macrolan who created IRR routes to allow Macrolan to announce Cloud > Innovation's prefix); letter from Link Infinity International Ltd. (Link > Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > authorizing IPDC Solutions to announce the prefix with origin AS134190. > And a Letter from IPDC. This was an innocent mistake committed by third > parties and had nothing to do with any action by Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. > > > Link Infinity further delegated that same /24 to IPDC and asked Cloud > innovation to issue an LOA, which we did. The LOA specifically required > IPDC to use its own ASN to announce the space (AS134190). > > IPDC subsequently authorized one of its customers to use the said prefix. > > > For reasons still unknown to Cloud Innovation, IPDC and their customer set > up a BGP session wherein their customer used AS37353 as the origin to > advertise prefix 156.241.3.0/24. > > > Upon discovering the announcement, rather than contact Cloud Innovation, > Mark contacted IPDC who provided him with an incomplete explanation blaming > their customer and Mark, not realizing that Cloud Innovation was not the > customer in question posted far and wide about the event. It is unclear to > us why he chose to do this rather than contact us to try and resolve the > issue. > > > A contributing factor to the erroneous BGP configuration by IPDC's > customer may have been data contained in some outdated IRR route objects > for 156.241.0.0/16 which have subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began to > investigate the situation. As soon as it was clear that this was the result > of third-party actions, we reached out to Mark privately to let him know > what we knew and that we were still investigating. We delayed making a > public statement in order to try and ascertain all of the facts of the > situation. We prefer not to make public statements based on incomplete > information. > > We apologize to the community for our small part in this unfortunate > incident and assure you that we work very hard to remain good netizens and > will address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1. Letter from Paul Wollner > 2. Letter from Link Infinity > 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > AS134190 > 4. Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, while > LARUS is also providing IP management service to other third parties in all > regions, for full disclosure, LARUS and Cloud Innovation are headed by same > CEO. > > Content of those letters have been posted here for your convince: > > *IPDC:* > > FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > over the course of our corporate relationship we were given the authority > to use address block 156.241.3.0/24 since 9th December 2019. > > > On 12th December 2019, we have delegated that address block to our client. > Following which our client further instructed us to announce the prefix > with AS37353. In good will after minimal verification through WHOIS? IP > Prefix we have proceeded to execute our client?s request. > > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > of record for that ASN and have since learned that the customer?s use of > that ASN was erroneous and not permitted by SEACOM and immediate action has > been taken to rectify this situation. > > > IPDC would like to apologize for our lack of attention in conducting > thorough verification and wish to highlight that the involvement of Cloud > Innovation Ltd in the entire process was providing the addresses to us and > that we truly apologize as we understand that this incident may have > indirectly implicated Cloud Innovation Ltd. > > > IPDC however, does not wish to disclose our client information and our > client information shall remain confidential under present circumstances. > Once again, we apologize for our shortcomings. > > > *Link Infinity:* > > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and > in the course received rights to use 156.241.3.0/24 from them. Beginning > December, 2019, we delegated the right to announce this prefix to IPDC > Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > authorizing them to announce the space which was subsequently received. > IPDC subsequently and without our knowledge delegated this space to one of > their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA > provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had > already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be > announced from a hijacked ASN. We do not condone this and apologize > sincerely to the community for what has happened here. > > Sincere Apologies, > > > *Paul Wollner:* > > > 8 May 2020 > > TO WHOM IT MAY CONCERN > > In the light of the recent email on NAPAfrica mailing list, I would just > like to clear the air. > > > The IP route objects were created by myself for Cloud Innovation when they > signed up as a client of Macrolan ( now SEACOM) as they didn't have their > own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment > of SEACOM in October 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an > end, the route objects were never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no > access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > > On Fri, 8 May 2020 at 22:08, Mark Tinka wrote: > >> 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. >> _______________________________________________ >> Community-Discuss mailing list >> Community-Discuss at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/community-discuss >> > > > -- > -- > Kind regards. > Lu > > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amelnaud at gmail.com Thu May 28 19:32:06 2020 From: amelnaud at gmail.com (Arnaud AMELINA) Date: Thu, 28 May 2020 19:32:06 +0000 Subject: [Community-Discuss] [RPKI-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Hi, all communities It was said that the hijacking of AS37353 was a configuration mistake, coupled with poor oversight in checking the right to use of the ASN by a certain IPDC customer. It was also said that this would have been facilitated by old and stalled IRR objects from MacroLAN before the service contract ended in December 2019. It was also stated that the BGP announcement was stopped and some actions taken to delete the stalled routing registry object from IRR. Below are some data which gives some extra information and confirm previous claim that this incident was not accidental. NB: All data are collected from their source, Today, 28 May 2020, at 10:00 UTC. IRRs created in March 2020 with AS37353 as Origin for 156.241.3.0/24 by HGC $ whois -h whois.radb.net '156.241.3.0/24' route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS37353 notify: matthew.chan at hgc.com.hk mnt-by: MAINT-HGC-INTL changed: matthew.chan at hgc.com.hk 20200304 source: RADB ===== route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS37353 remarks: This is a HGC customer route-object remarks: which is being exported under this origin AS. remarks: remarks: This route object was created because no existing remarks: route object with the same origin was found. remarks: remarks: Please contact radb at hutchcity.com if you have any remarks: questions regarding this object. notify: radb at hutchcity.com mnt-by: MAINT-AS9304 changed: radb at hutchcity.com 20200304 source: NTTCOM ==== https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0%2F24&-T+option=&ip_option=&-i+option= These objects havent been deleted. An in-depth check of the routing status of 156.241.3.0/24 shows the followings: Hurricane Electric BGP tool https://bgp.he.net/net/156.241.3.0/24 Origin AS Announcement Description AS37353 156.241.3.0/24 IRR Valid HONGKONG LINK INFINITY TECHNOLOGY LIMITED RIPESTAT https://stat.ripe.net/widget/looking-glass#w.resource=156.241.3.0%2F24 AS37353 is seen as the origin by 1 peer. 103.200.115.1 ?103.200.115.1 is announcing route AS64271 AS9304 AS4809 AS4809 AS4809 AS134190 AS37353. Even with the limited view, the prefix is still being originated and routed and the route objects still exist. Regards -- Arnaud Le sam. 9 mai 2020 ? 10:02, Lu Heng a ?crit : > Due to size of attachment the attachment is not in this list, but you may > easily find in all the others. > > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud > Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > Innovation) but rather belonged to Seacom through their acquisition of > MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was > criminal or bad netizenship on the part of Cloud Innovation is without > foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of > Macrolan who created IRR routes to allow Macrolan to announce Cloud > Innovation's prefix); letter from Link Infinity International Ltd. (Link > Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > authorizing IPDC Solutions to announce the prefix with origin AS134190. > And a Letter from IPDC. This was an innocent mistake committed by third > parties and had nothing to do with any action by Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. > > > Link Infinity further delegated that same /24 to IPDC and asked Cloud > innovation to issue an LOA, which we did. The LOA specifically required > IPDC to use its own ASN to announce the space (AS134190). > > IPDC subsequently authorized one of its customers to use the said prefix. > > > For reasons still unknown to Cloud Innovation, IPDC and their customer set > up a BGP session wherein their customer used AS37353 as the origin to > advertise prefix 156.241.3.0/24. > > > Upon discovering the announcement, rather than contact Cloud Innovation, > Mark contacted IPDC who provided him with an incomplete explanation blaming > their customer and Mark, not realizing that Cloud Innovation was not the > customer in question posted far and wide about the event. It is unclear to > us why he chose to do this rather than contact us to try and resolve the > issue. > > > A contributing factor to the erroneous BGP configuration by IPDC's > customer may have been data contained in some outdated IRR route objects > for 156.241.0.0/16 which have subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began to > investigate the situation. As soon as it was clear that this was the result > of third-party actions, we reached out to Mark privately to let him know > what we knew and that we were still investigating. We delayed making a > public statement in order to try and ascertain all of the facts of the > situation. We prefer not to make public statements based on incomplete > information. > > We apologize to the community for our small part in this unfortunate > incident and assure you that we work very hard to remain good netizens and > will address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1. Letter from Paul Wollner > 2. Letter from Link Infinity > 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > AS134190 > 4. Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, while > LARUS is also providing IP management service to other third parties in all > regions, for full disclosure, LARUS and Cloud Innovation are headed by same > CEO. > > Content of those letters have been posted here for your convince: > > *IPDC:* > > FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > over the course of our corporate relationship we were given the authority > to use address block 156.241.3.0/24 since 9th December 2019. > > > On 12th December 2019, we have delegated that address block to our client. > Following which our client further instructed us to announce the prefix > with AS37353. In good will after minimal verification through WHOIS? IP > Prefix we have proceeded to execute our client?s request. > > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > of record for that ASN and have since learned that the customer?s use of > that ASN was erroneous and not permitted by SEACOM and immediate action has > been taken to rectify this situation. > > > IPDC would like to apologize for our lack of attention in conducting > thorough verification and wish to highlight that the involvement of Cloud > Innovation Ltd in the entire process was providing the addresses to us and > that we truly apologize as we understand that this incident may have > indirectly implicated Cloud Innovation Ltd. > > > IPDC however, does not wish to disclose our client information and our > client information shall remain confidential under present circumstances. > Once again, we apologize for our shortcomings. > > > *Link Infinity:* > > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and > in the course received rights to use 156.241.3.0/24 from them. Beginning > December, 2019, we delegated the right to announce this prefix to IPDC > Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA > authorizing them to announce the space which was subsequently received. > IPDC subsequently and without our knowledge delegated this space to one of > their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA > provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had > already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be > announced from a hijacked ASN. We do not condone this and apologize > sincerely to the community for what has happened here. > > Sincere Apologies, > > > *Paul Wollner:* > > > 8 May 2020 > > TO WHOM IT MAY CONCERN > > In the light of the recent email on NAPAfrica mailing list, I would just > like to clear the air. > > > The IP route objects were created by myself for Cloud Innovation when they > signed up as a client of Macrolan ( now SEACOM) as they didn't have their > own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment > of SEACOM in October 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an > end, the route objects were never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no > access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > > > > -- > -- > Kind regards. > Lu > > _______________________________________________ > RPKI-Discuss mailing list > RPKI-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpki-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedrick.mbeyet at afrinic.net Thu May 28 22:37:50 2020 From: cedrick.mbeyet at afrinic.net (Cedrick Adrien Mbeyet) Date: Fri, 29 May 2020 02:37:50 +0400 Subject: [Community-Discuss] AFRINIC service degradation - 28 May 2020 Message-ID: <80b414f9-6877-8652-75f9-6b964a1e5ca4@afrinic.net> Dear all, This is a quick note to let you know that some of you may have experienced issues accessing www.afrinic.net and some other web services. While we are still investigating further on the root cause of the problem, we apologize for the inconvenient caused. The NOC team is working on a report that will be shared accordingly. Regards, -- _______________________________________________________________ Cedrick Adrien Mbeyet Infrastructure Unit Manager, AFRINIC Ltd. t: +230 403 5100 / 403 5115 | f: +230 466 6758 | tt: @afrinic | w: www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia ______________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri May 29 00:59:26 2020 From: owen at delong.com (Owen DeLong) Date: Thu, 28 May 2020 17:59:26 -0700 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Arnaud, You are mistaken on a number of points. > On May 28, 2020, at 13:05 , Arnaud AMELINA wrote: > > Hi, all communities > > It was said that the hijacking of AS37353 was a configuration mistake, coupled with poor oversight in checking the right to use of the ASN by a certain IPDC customer. > > It was also said that this would have been facilitated by old and stalled IRR objects from MacroLAN before the service contract ended in December 2019. > > It was also stated that the BGP announcement was stopped and some actions taken to delete the stalled routing registry object from IRR. Yes? The registry objects created by MacroLAN have been deleted. > Below are some data which gives some extra information and confirm previous claim that this incident was not accidental. Below is some very redacted data which gives virtually no information. > NB: All data are collected from their source, Today, 28 May 2020, at 10:00 UTC. > > IRRs created in March 2020 with AS37353 as Origin for 156.241.3.0/24 by HGC > > $ whois -h whois.radb.net '156.241.3.0/24 ' > > route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS37353 notify: matthew.chan at hgc.com.hk mnt-by: MAINT-HGC-INTL changed: matthew.chan at hgc.com.hk 20200304 source: RADB > > ===== > route: 156.241.3.0/24 > descr: Proxy-registered route object origin: AS37353 > remarks: This is a HGC customer route-object > remarks: which is being exported under this origin AS. > remarks: > remarks: This route object was created because no existing remarks: route object with the same origin was found. > remarks: > remarks: Please contact radb at hutchcity.com if you have any remarks: questions regarding this object. > notify: radb at hutchcity.com > mnt-by: MAINT-AS9304 > changed: radb at hutchcity.com 20200304 > source: NTTCOM > ==== We haven changed anything, but here?s the full text of that whois command: owen (121) ~ % whois -h whois.radb.net 156.241.3.0/24 2020/05/28 16:58:50 route: 156.241.3.0/24 origin: AS138145 descr: Customer-AS45250 admin-c: MAINT-AS138145 tech-c: MAINT-AS138145 mnt-by: MAINT-AS138145 changed: admin at cloudix.online 20200512 #18:26:20Z source: RADB route: 156.241.3.0/24 origin: AS134190 descr: IPDC Solution PteLtd mnt-by: MAINT-LARUS changed: t.t.xu at laruscloudservice.net 20200508 #10:43:19Z source: RADB route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS37353 notify: matthew.chan at hgc.com.hk mnt-by: MAINT-HGC-INTL changed: matthew.chan at hgc.com.hk 20200304 source: RADB route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS134548 changed: radb at hgcbroadband.com 20191003 source: RADB route: 156.241.0.0/16 origin: AS37353 mnt-by: paulwollner mnt-by: hk-larus-1-mnt created: 2017-08-07T12:27:22Z last-modified: 2018-09-04T18:54:09Z source: RIPE-NONAUTH remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS37353 remarks: This is a HGC customer route-object remarks: which is being exported under this origin AS. remarks: remarks: This route object was created because no existing remarks: route object with the same origin was found. remarks: remarks: Please contact radb at hutchcity.com if you have any remarks: questions regarding this object. notify: radb at hutchcity.com mnt-by: MAINT-AS9304 changed: radb at hutchcity.com 20200304 source: NTTCOM route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS134548 remarks: This is a HGC customer route-object remarks: which is being exported under this origin AS. remarks: remarks: This route object was created because no existing remarks: route object with the same origin was found. remarks: remarks: Please contact radb at hgcbroadband.com if you have any remarks: questions regarding this object. notify: radb at hgcbroadband.com mnt-by: MAINT-AS9304 changed: radb at hgcbroadband.com 20191003 source: NTTCOM mntner: MAINT-AS138145 descr: Advanced Information Co., Ltd. admin-c: ADVANCED-APNIC tech-c: ADVANCED-APNIC upd-to: noc at cloudix.online mnt-nfy: noc at cloudix.online auth: CRYPT-PW HIDDENCRYPTPW # notify: noc at cloudix.online mnt-by: MAINT-AS138145 changed: admin at cloudix.online 20200511 #03:10:36Z source: RADB 0.000u 0.001s 0:00.19 0.0% 0+0k 0+0io 0pf+0w owen (122) ~ % 2020/05/28 16:58:53 Looks like there?s additional cruft left in some routing registries that we still haven?t removed. I?ve asked people to get on that. However, just because it?s in RADB doesn?t mean it?s advertised. Nonetheless, we are actively working to get those errant entries cleaned up. Thank you for bringing them to our attention. > https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0%2F24&-T+option=&ip_option=&-i+option= > > These objects havent been deleted. > > An in-depth check of the routing status of 156.241.3.0/24 shows the followings: > > Hurricane Electric BGP tool > > https://bgp.he.net/net/156.241.3.0/24 > > Origin AS Announcement Description AS37353 156.241.3.0/24 IRR Valid HONGKONG LINK INFINITY TECHNOLOGY LIMITED The HE BGP tool doesn?t mean what you think it means. It retains routes which have been withdrawn for a very long time after they have been withdrawn, especially if they are not superseded by other announcements. OTOH, the HE BGP Looking glass shows: > > > RIPESTAT > > https://stat.ripe.net/widget/looking-glass#w.resource=156.241.3.0%2F24 > > AS37353 is seen as the origin by 1 peer. > > 103.200.115.1 ?103.200.115.1 is announcing route AS64271 AS9304 AS4809 AS4809 AS4809 AS134190 AS37353. Well? That?s historic data. If you view it in BGPLAY, you will see that the last transaction for this prefix was on May 7 (Mark?s initial on-list complaint came May 8). > Even with the limited view, the prefix is still being originated and routed and the route objects still exist. No, you are looking at data from May 7. Current data as above (HE looking glass). From Route-views and several other route servers (I have redacted the transcript to leave out banner text and other irrelevant data. All routing queries are included full prompt to prompt without editing): route-views>show ip bgp 156.241.3.0/24 % Network not in table route-views> owen (122) ~ % telnet route-views.oregon-ix.net 2020/05/28 16:58:53 Trying 128.223.51.103... Connected to route-views.oregon-ix.net. Escape character is '^]'. User Access Verification Username: Kerberos: No default realm defined for Kerberos! rviews route-views>show ip bgp 156.241.3.0/24 % Network not in table route-views>q Connection closed by foreign host. 0.007u 0.014s 1:49.98 0.0% 0+0k 0+0io 21pf+0w Exit 1 owen (123) ~ % telnet route-views.optus.net.au 2020/05/28 17:26:50 Trying 203.202.125.6... Connected to route-views.optus.net.au. Escape character is '^]'. route-views.optus.net.au>Kerberos: No default realm defined for Kerberos! show ip bgp 156.241.3.0/24 % Network not in table route-views.optus.net.au>q Connection closed by foreign host. 0.007u 0.005s 0:21.89 0.0% 0+0k 0+0io 0pf+0w Exit 1 owen (127) ~ % telnet route-views.ab.bb.telus.com 2020/05/28 17:28:00 Trying 154.11.98.18... Connected to route-views.ab.bb.telus.com. Escape character is '^]'. c route-views.ab>Kerberos: No default realm defined for Kerberos! show ip bgp 156.241.3.0/24 % Network not in table route-views.ab>q Connection closed by foreign host. 0.006u 0.005s 0:05.23 0.0% 0+0k 0+0io 0pf+0w Exit 1 owen (131) ~ % telnet route-server.tinet.net 2020/05/28 17:28:45 Trying 213.200.64.94... Connected to route-server.tinet.net. Escape character is '^]'. login: public Password: Last login: Thu May 28 18:44:36 from vinci.rdsnet.ro --- JUNOS 15.1F6-S5.6 Kernel 64-bit JNPR-10.3-20161130.340898_build {master} public at route-server.as3257.net-re0> show route 156.241.3.0/24 all extensive {master} public at route-server.as3257.net-re0> public at route-server.as3257.net-re0> quit Connection closed by foreign host. 0.007u 0.009s 0:40.46 0.0% 0+0k 0+0io 0pf+0w Exit 1 owen (132) ~ % telnet route-server.eu.gblx.net 2020/05/28 17:29:35 Trying 2001:450:2001:1000::670:1708:1187... Connected to loop0.route-server.ams2.gblx.net. Escape character is '^]'. route-server.ams2>Kerberos: No default realm defined for Kerberos! show ip bgp 156.241.3.0/24 % Network not in table route-server.ams2>q Connection closed by foreign host. 0.006u 0.005s 0:05.51 0.0% 0+0k 0+0io 0pf+0w Exit 1 owen (134) ~ % telnet route-server.opentransit.net 2020/05/28 17:30:09 Trying 204.59.3.38... Connected to route-server.opentransit.net. Escape character is '^]'. User Access Verification Username: Kerberos: No default realm defined for Kerberos! rviews Password: OAKRS1#show ip bgp 156.241.3.0/24 % Network not in table OAKRS1#exit Connection closed by foreign host. 0.007u 0.008s 0:29.00 0.0% 0+0k 0+0io 0pf+0w Exit 1 owen (141) ~ % telnet route-server.host.net 2020/05/28 17:32:15 Trying 2001:5b8:fffe::10... telnet: connect to address 2001:5b8:fffe::10: Connection refused Trying 75.119.191.74... Connected to route-server.host.net. Escape character is '^]'. User Access Verification Password: route-server> show ip bgp 156.241.3.0/24 % Network not in table route-server> q Connection closed by foreign host. 0.006u 0.006s 0:06.21 0.0% 0+0k 0+0io 0pf+0w Exit 1 As you can see, from many different internet perspectives, the prefix simply isn?t in the table. So, Arnaud, your data is flawed and your conclusions are in error. The prefix has not been announced since May 7. I don?t know how much you?ve tried to remove obsolete or erroneous entries from RADB and its ilk generated by others, but I can assure you that it is much like the game of whack-a-mole. We appreciate your calling these entries to our attention and we will pursue them, but there has been no further incidence of use of AS37353 by our customers and the actual problem was, in fact, corrected prior to Mark?s initial post. Nothing you have posted indicates otherwise and your claims could be considered defamatory. Im not sure about the law where you are, but here, defamation requires 4 elements: 1. A false statement purporting to be fact. Your claims above that the hijack was an action by Larus (false) and that it was malicious (false) and that it continues (false) qualify here. 2. Publication or communication of that statement to a third person. By posting this on multiple lists, you have more than met this test. 3. Fault amounting to at least negligence. This one is a bit more of a grey area, but your failure to investigate realtime sources instead of relying on sources known to use historical data is, IMHO, negligent. 4. Damages or some harm caused to the person or entity. If nothing else, the collective time wasted on this continued discussion of a minor mistake represents significant harm to the community as a whole. Were your statements not so blatantly and easily disproven, or should they be believed by anyone, then there is also the question of harm to the good name of Larus as a company. Owen > > Regards > > -- > Arnaud > > Le sam. 9 mai 2020 ? 09:44, Lu Heng > a ?crit : > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather belonged to Seacom through their acquisition of MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was criminal or bad netizenship on the part of Cloud Innovation is without foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of Macrolan who created IRR routes to allow Macrolan to announce Cloud Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A customer of Cloud Innovation; and attached LOA from LARUS authorizing IPDC Solutions to announce the prefix with origin AS134190. And a Letter from IPDC. This was an innocent mistake committed by third parties and had nothing to do with any action by Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. > > Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation to issue an LOA, which we did. The LOA specifically required IPDC to use its own ASN to announce the space (AS134190). > > IPDC subsequently authorized one of its customers to use the said prefix. > > For reasons still unknown to Cloud Innovation, IPDC and their customer set up a BGP session wherein their customer used AS37353 as the origin to advertise prefix 156.241.3.0/24 . > > Upon discovering the announcement, rather than contact Cloud Innovation, Mark contacted IPDC who provided him with an incomplete explanation blaming their customer and Mark, not realizing that Cloud Innovation was not the customer in question posted far and wide about the event. It is unclear to us why he chose to do this rather than contact us to try and resolve the issue. > > A contributing factor to the erroneous BGP configuration by IPDC's customer may have been data contained in some outdated IRR route objects for 156.241.0.0/16 which have subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began to investigate the situation. As soon as it was clear that this was the result of third-party actions, we reached out to Mark privately to let him know what we knew and that we were still investigating. We delayed making a public statement in order to try and ascertain all of the facts of the situation. We prefer not to make public statements based on incomplete information. > > We apologize to the community for our small part in this unfortunate incident and assure you that we work very hard to remain good netizens and will address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1. Letter from Paul Wollner > 2. Letter from Link Infinity > 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from AS134190 > 4. Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is also providing IP management service to other third parties in all regions, for full disclosure, LARUS and Cloud Innovation are headed by same CEO. > > Content of those letters have been posted here for your convince: > > IPDC: > > FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate relationship we were given the authority to use address block 156.241.3.0/24 since 9th December 2019. > > On 12th December 2019, we have delegated that address block to our client. Following which our client further instructed us to announce the prefix with AS37353. In good will after minimal verification through WHOIS? IP Prefix we have proceeded to execute our client?s request. > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and immediate action has been taken to rectify this situation. > > IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud Innovation Ltd. > > IPDC however, does not wish to disclose our client information and our client information shall remain confidential under present circumstances. Once again, we apologize for our shortcomings. > > Link Infinity: > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to use 156.241.3.0/24 from them. Beginning December, 2019, we delegated the right to announce this prefix to IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to announce the space which was subsequently received. IPDC subsequently and without our knowledge delegated this space to one of their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We do not condone this and apologize sincerely to the community for what has happened here. > > Sincere Apologies, > > Paul Wollner: > > 8 May 2020 > > TO WHOM IT MAY CONCERN > > In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air. > > The IP route objects were created by myself for Cloud Innovation when they signed up as a client of Macrolan ( now SEACOM) as they didn't have their own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > To whom it may concern, > > On May 8, Mark Think posted a claim to multiple lists that Cloud Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud Innovation) but rather belonged to Seacom through their acquisition of MacroLAN. > > While we regret this unfortunate incident, Mark?s claims that it was criminal or bad netizenship on the part of Cloud Innovation is without foundation and utterly incorrect. > > As shown below in the attached document from Paul Wollner(Ex-CTO of Macrolan who created IRR routes to allow Macrolan to announce Cloud Innovation's prefix); letter from Link Infinity International Ltd. (Link Infinity), A customer of Cloud Innovation; and attached LOA from LARUS authorizing IPDC Solutions to announce the prefix with origin AS134190. And a Letter from IPDC. This was an innocent mistake committed by third parties and had nothing to do with any action by Cloud Innovation or LARUS. > > Here?s what happened: > > Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019. > > Link Infinity further delegated that same /24 to IPDC and asked Cloud innovation to issue an LOA, which we did. The LOA specifically required IPDC to use its own ASN to announce the space (AS134190). > > IPDC subsequently authorized one of its customers to use the said prefix. > > For reasons still unknown to Cloud Innovation, IPDC and their customer set up a BGP session wherein their customer used AS37353 as the origin to advertise prefix 156.241.3.0/24 . > > Upon discovering the announcement, rather than contact Cloud Innovation, Mark contacted IPDC who provided him with an incomplete explanation blaming their customer and Mark, not realizing that Cloud Innovation was not the customer in question posted far and wide about the event. It is unclear to us why he chose to do this rather than contact us to try and resolve the issue. > > A contributing factor to the erroneous BGP configuration by IPDC's customer may have been data contained in some outdated IRR route objects for 156.241.0.0/16 which have subsequently been deleted. > > As soon as we became aware of the problem (via Mark?s email), we began to investigate the situation. As soon as it was clear that this was the result of third-party actions, we reached out to Mark privately to let him know what we knew and that we were still investigating. We delayed making a public statement in order to try and ascertain all of the facts of the situation. We prefer not to make public statements based on incomplete information. > > We apologize to the community for our small part in this unfortunate incident and assure you that we work very hard to remain good netizens and will address any concerns promptly when they come to our attention. > > > Sincerely, > > Lu Heng > CEO > Cloud Innovations > > Attached: > 1. Letter from Paul Wollner > 2. Letter from Link Infinity > 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from AS134190 > 4. Letter from IPDC > > FYI: LARUS is proving IP management service for Cloud Innovation, while LARUS is also providing IP management service to other third parties in all regions, for full disclosure, LARUS and Cloud Innovation are headed by same CEO. > > Content of those letters have been posted here for your convince: > > IPDC: > > FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > > IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and over the course of our corporate relationship we were given the authority to use address block 156.241.3.0/24 since 9th December 2019. > > On 12th December 2019, we have delegated that address block to our client. Following which our client further instructed us to announce the prefix with AS37353. In good will after minimal verification through WHOIS? IP Prefix we have proceeded to execute our client?s request. > > On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder of record for that ASN and have since learned that the customer?s use of that ASN was erroneous and not permitted by SEACOM and immediate action has been taken to rectify this situation. > > IPDC would like to apologize for our lack of attention in conducting thorough verification and wish to highlight that the involvement of Cloud Innovation Ltd in the entire process was providing the addresses to us and that we truly apologize as we understand that this incident may have indirectly implicated Cloud Innovation Ltd. > > IPDC however, does not wish to disclose our client information and our client information shall remain confidential under present circumstances. Once again, we apologize for our shortcomings. > > Link Infinity: > > To whom it may concern, > > We at HK Infinity International Ltd are a customer of Cloud Innovation and in the course received rights to use 156.241.3.0/24 from them. Beginning December, 2019, we delegated the right to announce this prefix to IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA authorizing them to announce the space which was subsequently received. IPDC subsequently and without our knowledge delegated this space to one of their customers and allowed them to originate it from AS37353. > > This announcement was not authorized by us, nor is it permitted by the LOA provided by Cloud Innovation. > > Unfortunately, we were not aware of the situation until after it had already been resolved. > > It was never our intent to violate the LOA or to allow the prefix to be announced from a hijacked ASN. We do not condone this and apologize sincerely to the community for what has happened here. > > Sincere Apologies, > > Paul Wollner: > > 8 May 2020 > > TO WHOM IT MAY CONCERN > > In the light of the recent email on NAPAfrica mailing list, I would just like to clear the air. > > The IP route objects were created by myself for Cloud Innovation when they signed up as a client of Macrolan ( now SEACOM) as they didn't have their own AS. > > At the time I was working for Macrolan (now SEACOM). I left the employment of SEACOM in October 2019. > > It appears that when Cloud Innovation's contract with SEACOM came to an end, the route objects were never cleaned up. > > This occurred after I left SEACOM's employment. Since leaving, I have no access to these objects. > > Regards > > Paul Wollner > 082-786-9776 > > On Fri, 8 May 2020 at 22:08, Mark Tinka > wrote: > 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. > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > -- > -- > Kind regards. > Lu > > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2020-05-28 at 17.13.51 .png Type: image/png Size: 104109 bytes Desc: not available URL: From paulw at wollner.za.net Fri May 29 03:17:41 2020 From: paulw at wollner.za.net (Paul Wollner) Date: Fri, 29 May 2020 05:17:41 +0200 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: I have been watching this thread and I feel that I should respond as it was I that created the route objects in AFRINIC and RIPE on behalf of Cloud Innovation. In light of the accusations that have been made on 8 May, I feel that SEACOM neglected their duty to remove these objects when the client's contract came to an end. As the ISP created the records in the first place, the records should have been updated or deleted by them too. This shows poor corporate governance by SEACOM and it is ironic that their own employee in charge of these duties wished to make this public in an attempt to place blame elsewhere whilst the incompetence lies largely, if not solely, with SEACOM. I was the person who created the objects in the respective databases, however I was no longer in the employment of SEACOM when Cloud Innovation's contract came to an end and hence no longer had rights to the route objects. It is now almost a month later and the amount of resources wasted on dealing with this issue when it could have been resolved quickly and safely by the relevant parties is astounding and personally quite unsettling. This matter should be put to rest now. As a global community we are dealing with far bigger issues and we should be putting our efforts towards the greater good, not petty infighting fueled by drama and misinformation. On Fri, May 29, 2020 at 3:00 AM Owen DeLong wrote: > Arnaud, > > You are mistaken on a number of points. > > > On May 28, 2020, at 13:05 , Arnaud AMELINA wrote: > > Hi, all communities > > It was said that the hijacking of AS37353 was a configuration mistake, > coupled with poor oversight in checking the right to use of the ASN by a > certain IPDC customer. > > It was also said that this would have been facilitated by old and stalled > IRR objects from MacroLAN before the service contract ended in December > 2019. > > It was also stated that the BGP announcement was stopped and some actions > taken to delete the stalled routing registry object from IRR. > > > Yes? The registry objects created by MacroLAN have been deleted. > > Below are some data which gives some extra information and confirm > previous claim that this incident was not accidental. > > > Below is some very redacted data which gives virtually no information. > > NB: All data are collected from their source, Today, 28 May 2020, at 10:00 > UTC. > > IRRs created in March 2020 with AS37353 as Origin for 156.241.3.0/24 by > HGC > > $ whois -h whois.radb.net '156.241.3.0/24' > > route: 156.241.3.0/24 descr: Proxy-registered route object > origin: AS37353 notify: matthew.chan at hgc.com.hk mnt-by: > MAINT-HGC-INTL changed: matthew.chan at hgc.com.hk 20200304 source: > RADB > > ===== > route: 156.241.3.0/24 > descr: Proxy-registered route object origin: AS37353 > remarks: This is a HGC customer route-object > remarks: which is being exported under this origin AS. > remarks: > remarks: This route object was created because no existing > remarks: route object with the same origin was found. > remarks: > remarks: Please contact radb at hutchcity.com if you have any > remarks: questions regarding this object. > notify: radb at hutchcity.com > mnt-by: MAINT-AS9304 > changed: radb at hutchcity.com 20200304 > source: NTTCOM > ==== > > > We haven changed anything, but here?s the full text of that whois command: > owen (121) ~ % whois -h whois.radb.net 156.241.3.0/24 > 2020/05/28 16:58:50 > route: 156.241.3.0/24 > origin: AS138145 > descr: Customer-AS45250 > admin-c: MAINT-AS138145 > tech-c: MAINT-AS138145 > mnt-by: MAINT-AS138145 > changed: admin at cloudix.online 20200512 #18:26:20Z > source: RADB > > route: 156.241.3.0/24 > origin: AS134190 > descr: IPDC Solution PteLtd > mnt-by: MAINT-LARUS > changed: t.t.xu at laruscloudservice.net 20200508 #10:43:19Z > source: RADB > > route: 156.241.3.0/24 > descr: Proxy-registered route object > origin: AS37353 > notify: matthew.chan at hgc.com.hk > mnt-by: MAINT-HGC-INTL > changed: matthew.chan at hgc.com.hk 20200304 > source: RADB > > route: 156.241.3.0/24 > descr: Proxy-registered route object > origin: AS134548 > changed: radb at hgcbroadband.com 20191003 > source: RADB > > route: 156.241.0.0/16 > origin: AS37353 > mnt-by: paulwollner > mnt-by: hk-larus-1-mnt > created: 2017-08-07T12:27:22Z > last-modified: 2018-09-04T18:54:09Z > source: RIPE-NONAUTH > remarks: **************************** > remarks: * THIS OBJECT IS MODIFIED > remarks: * Please note that all data that is generally regarded as > personal > remarks: * data has been removed from this object. > remarks: * To view the original object, please query the RIPE > Database at: > remarks: * http://www.ripe.net/whois > remarks: **************************** > > route: 156.241.3.0/24 > descr: Proxy-registered route object > origin: AS37353 > remarks: This is a HGC customer route-object > remarks: which is being exported under this origin AS. > remarks: > remarks: This route object was created because no existing > remarks: route object with the same origin was found. > remarks: > remarks: Please contact radb at hutchcity.com if you have any > remarks: questions regarding this object. > notify: radb at hutchcity.com > mnt-by: MAINT-AS9304 > changed: radb at hutchcity.com 20200304 > source: NTTCOM > > route: 156.241.3.0/24 > descr: Proxy-registered route object > origin: AS134548 > remarks: This is a HGC customer route-object > remarks: which is being exported under this origin AS. > remarks: > remarks: This route object was created because no existing > remarks: route object with the same origin was found. > remarks: > remarks: Please contact radb at hgcbroadband.com if you have any > remarks: questions regarding this object. > notify: radb at hgcbroadband.com > mnt-by: MAINT-AS9304 > changed: radb at hgcbroadband.com 20191003 > source: NTTCOM > > mntner: MAINT-AS138145 > descr: Advanced Information Co., Ltd. > admin-c: ADVANCED-APNIC > tech-c: ADVANCED-APNIC > upd-to: noc at cloudix.online > mnt-nfy: noc at cloudix.online > auth: CRYPT-PW HIDDENCRYPTPW # > notify: noc at cloudix.online > mnt-by: MAINT-AS138145 > changed: admin at cloudix.online 20200511 #03:10:36Z > source: RADB > 0.000u 0.001s 0:00.19 0.0% 0+0k 0+0io 0pf+0w > owen (122) ~ % > 2020/05/28 16:58:53 > > Looks like there?s additional cruft left in some routing registries that > we still haven?t removed. I?ve asked people to get on that. > > However, just because it?s in RADB doesn?t mean it?s advertised. > Nonetheless, we are actively working to get those errant entries cleaned > up. Thank you for bringing them to our attention. > > > https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0%2F24&-T+option=&ip_option=&-i+option= > > > These objects havent been deleted. > > An in-depth check of the routing status of 156.241.3.0/24 shows the > followings: > > Hurricane Electric BGP tool > > https://bgp.he.net/net/156.241.3.0/24 > > Origin AS Announcement Description AS37353 > 156.241.3.0/24 IRR Valid HONGKONG LINK INFINITY TECHNOLOGY LIMITED > > > The HE BGP tool doesn?t mean what you think it means. > > It retains routes which have been withdrawn for a very long time after > they have been withdrawn, especially if they are not superseded by other > announcements. > > OTOH, the HE BGP Looking glass shows: > > > > RIPESTAT > > https://stat.ripe.net/widget/looking-glass#w.resource=156.241.3.0%2F24 > > > AS37353 is seen as the origin by 1 peer. > > 103.200.115.1 ?103.200.115.1 is announcing route AS64271 AS9304 AS4809 > AS4809 AS4809 AS134190 AS37353. > > > Well? That?s historic data. If you view it in BGPLAY, you will see that > the last transaction for this prefix was on May 7 (Mark?s initial on-list > complaint came May 8). > > Even with the limited view, the prefix is still being originated and > routed and the route objects still exist. > > > No, you are looking at data from May 7. Current data as above (HE looking > glass). > > From Route-views and several other route servers (I have redacted the > transcript to leave out banner text and other irrelevant data. All routing > queries are included full prompt to prompt without editing): > route-views>show ip bgp 156.241.3.0/24 > % Network not in table > route-views> > > > owen (122) ~ % telnet route-views.oregon-ix.net > 2020/05/28 16:58:53 > Trying 128.223.51.103... > Connected to route-views.oregon-ix.net. > Escape character is '^]'. > > User Access Verification > > Username: Kerberos: No default realm defined for Kerberos! > rviews > > route-views>show ip bgp 156.241.3.0/24 > % Network not in table > route-views>q > Connection closed by foreign host. > 0.007u 0.014s 1:49.98 0.0% 0+0k 0+0io 21pf+0w > Exit 1 > owen (123) ~ % telnet route-views.optus.net.au > 2020/05/28 17:26:50 > Trying 203.202.125.6... > Connected to route-views.optus.net.au. > Escape character is '^]'. > > route-views.optus.net.au>Kerberos: No default realm defined for Kerberos! > show ip bgp 156.241.3.0/24 > % Network not in table > route-views.optus.net.au>q > Connection closed by foreign host. > 0.007u 0.005s 0:21.89 0.0% 0+0k 0+0io 0pf+0w > Exit 1 > > owen (127) ~ % telnet route-views.ab.bb.telus.com > 2020/05/28 17:28:00 > Trying 154.11.98.18... > Connected to route-views.ab.bb.telus.com. > Escape character is '^]'. > c > > route-views.ab>Kerberos: No default realm defined for Kerberos! > show ip bgp 156.241.3.0/24 > % Network not in table > route-views.ab>q > Connection closed by foreign host. > 0.006u 0.005s 0:05.23 0.0% 0+0k 0+0io 0pf+0w > Exit 1 > owen (131) ~ % telnet route-server.tinet.net > 2020/05/28 17:28:45 > Trying 213.200.64.94... > Connected to route-server.tinet.net. > Escape character is '^]'. > login: public > Password: > Last login: Thu May 28 18:44:36 from vinci.rdsnet.ro > > --- JUNOS 15.1F6-S5.6 Kernel 64-bit JNPR-10.3-20161130.340898_build > > {master} > public at route-server.as3257.net-re0> show route 156.241.3.0/24 all > extensive > > {master} > public at route-server.as3257.net-re0> > public at route-server.as3257.net-re0> quit > > Connection closed by foreign host. > 0.007u 0.009s 0:40.46 0.0% 0+0k 0+0io 0pf+0w > Exit 1 > owen (132) ~ % telnet route-server.eu.gblx.net > 2020/05/28 17:29:35 > Trying 2001:450:2001:1000::670:1708:1187... > Connected to loop0.route-server.ams2.gblx.net. > Escape character is '^]'. > > route-server.ams2>Kerberos: No default realm defined for Kerberos! > show ip bgp 156.241.3.0/24 > % Network not in table > route-server.ams2>q > Connection closed by foreign host. > 0.006u 0.005s 0:05.51 0.0% 0+0k 0+0io 0pf+0w > Exit 1 > owen (134) ~ % telnet route-server.opentransit.net > 2020/05/28 17:30:09 > Trying 204.59.3.38... > Connected to route-server.opentransit.net. > Escape character is '^]'. > User Access Verification > > Username: Kerberos: No default realm defined for Kerberos! > rviews > Password: > OAKRS1#show ip bgp 156.241.3.0/24 > % Network not in table > OAKRS1#exit > Connection closed by foreign host. > 0.007u 0.008s 0:29.00 0.0% 0+0k 0+0io 0pf+0w > Exit 1 > owen (141) ~ % telnet route-server.host.net > 2020/05/28 17:32:15 > Trying 2001:5b8:fffe::10... > telnet: connect to address 2001:5b8:fffe::10: Connection refused > Trying 75.119.191.74... > Connected to route-server.host.net. > Escape character is '^]'. > > User Access Verification > > Password: > route-server> show ip bgp 156.241.3.0/24 > % Network not in table > route-server> q > Connection closed by foreign host. > 0.006u 0.006s 0:06.21 0.0% 0+0k 0+0io 0pf+0w > Exit 1 > > > As you can see, from many different internet perspectives, the prefix > simply isn?t in the table. > > So, Arnaud, your data is flawed and your conclusions are in error. The > prefix has not been announced since May 7. I don?t know how much you?ve > tried to remove obsolete or erroneous entries from RADB and its ilk > generated by others, but I can assure you that it is much like the game of > whack-a-mole. We appreciate your calling these entries to our attention and > we will pursue them, but there has been no further incidence of use of > AS37353 by our customers and the actual problem was, in fact, corrected > prior to Mark?s initial post. > > Nothing you have posted indicates otherwise and your claims could be > considered defamatory. > Im not sure about the law where you are, but here, defamation requires 4 > elements: > 1. A false statement purporting to be fact. Your claims above that the > hijack was an action by Larus (false) and that it was malicious (false) and > that it continues (false) qualify here. > 2. Publication or communication of that statement to a third person. By > posting this on multiple lists, you have more than met this test. > 3. Fault amounting to at least negligence. This one is a bit more of a > grey area, but your failure to investigate realtime sources instead of > relying on sources known to use historical data is, IMHO, negligent. > 4. Damages or some harm caused to the person or entity. If nothing else, > the collective time wasted on this continued discussion of a minor mistake > represents significant harm to the community as a whole. > Were your statements not so blatantly and easily disproven, or should they > be believed by anyone, then there is also the question of harm to the good > name of Larus as a company. > > Owen > > > Regards > > -- > Arnaud > > Le sam. 9 mai 2020 ? 09:44, Lu Heng a ?crit : > >> To whom it may concern, >> >> On May 8, Mark Think posted a claim to multiple lists that Cloud >> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud >> Innovation) but rather belonged to Seacom through their acquisition of >> MacroLAN. >> >> While we regret this unfortunate incident, Mark?s claims that it was >> criminal or bad netizenship on the part of Cloud Innovation is without >> foundation and utterly incorrect. >> >> As shown below in the attached document from Paul Wollner(Ex-CTO of >> Macrolan who created IRR routes to allow Macrolan to announce Cloud >> Innovation's prefix); letter from Link Infinity International Ltd. (Link >> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS >> authorizing IPDC Solutions to announce the prefix with origin AS134190. >> And a Letter from IPDC. This was an innocent mistake committed by third >> parties and had nothing to do with any action by Cloud Innovation or LARUS. >> >> Here?s what happened: >> >> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December >> 2019. >> >> >> Link Infinity further delegated that same /24 to IPDC and asked Cloud >> innovation to issue an LOA, which we did. The LOA specifically required >> IPDC to use its own ASN to announce the space (AS134190). >> >> IPDC subsequently authorized one of its customers to use the said prefix. >> >> >> For reasons still unknown to Cloud Innovation, IPDC and their customer >> set up a BGP session wherein their customer used AS37353 as the origin to >> advertise prefix 156.241.3.0/24. >> >> >> Upon discovering the announcement, rather than contact Cloud Innovation, >> Mark contacted IPDC who provided him with an incomplete explanation blaming >> their customer and Mark, not realizing that Cloud Innovation was not the >> customer in question posted far and wide about the event. It is unclear to >> us why he chose to do this rather than contact us to try and resolve the >> issue. >> >> >> A contributing factor to the erroneous BGP configuration by IPDC's >> customer may have been data contained in some outdated IRR route objects >> for 156.241.0.0/16 which have subsequently been deleted. >> >> As soon as we became aware of the problem (via Mark?s email), we began to >> investigate the situation. As soon as it was clear that this was the result >> of third-party actions, we reached out to Mark privately to let him know >> what we knew and that we were still investigating. We delayed making a >> public statement in order to try and ascertain all of the facts of the >> situation. We prefer not to make public statements based on incomplete >> information. >> >> We apologize to the community for our small part in this unfortunate >> incident and assure you that we work very hard to remain good netizens and >> will address any concerns promptly when they come to our attention. >> >> >> Sincerely, >> >> Lu Heng >> CEO >> Cloud Innovations >> >> Attached: >> 1. Letter from Paul Wollner >> 2. Letter from Link Infinity >> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from >> AS134190 >> 4. Letter from IPDC >> >> FYI: LARUS is proving IP management service for Cloud Innovation, while >> LARUS is also providing IP management service to other third parties in all >> regions, for full disclosure, LARUS and Cloud Innovation are headed by same >> CEO. >> >> Content of those letters have been posted here for your convince: >> >> *IPDC:* >> >> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] >> >> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and >> over the course of our corporate relationship we were given the authority >> to use address block 156.241.3.0/24 since 9th December 2019. >> >> On 12th December 2019, we have delegated that address block to our >> client. Following which our client further instructed us to announce the >> prefix with AS37353. In good will after minimal verification through WHOIS? >> IP Prefix we have proceeded to execute our client?s request. >> >> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder >> of record for that ASN and have since learned that the customer?s use of >> that ASN was erroneous and not permitted by SEACOM and immediate action has >> been taken to rectify this situation. >> >> IPDC would like to apologize for our lack of attention in conducting >> thorough verification and wish to highlight that the involvement of Cloud >> Innovation Ltd in the entire process was providing the addresses to us and >> that we truly apologize as we understand that this incident may have >> indirectly implicated Cloud Innovation Ltd. >> >> IPDC however, does not wish to disclose our client information and our >> client information shall remain confidential under present circumstances. >> Once again, we apologize for our shortcomings. >> >> *Link Infinity:* >> >> To whom it may concern, >> >> We at HK Infinity International Ltd are a customer of Cloud Innovation >> and in the course received rights to use 156.241.3.0/24 from them. >> Beginning December, 2019, we delegated the right to announce this prefix to >> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA >> authorizing them to announce the space which was subsequently received. >> IPDC subsequently and without our knowledge delegated this space to one of >> their customers and allowed them to originate it from AS37353. >> >> This announcement was not authorized by us, nor is it permitted by the >> LOA provided by Cloud Innovation. >> >> Unfortunately, we were not aware of the situation until after it had >> already been resolved. >> >> It was never our intent to violate the LOA or to allow the prefix to be >> announced from a hijacked ASN. We do not condone this and apologize >> sincerely to the community for what has happened here. >> >> Sincere Apologies, >> >> *Paul Wollner:* >> >> 8 May 2020 >> >> TO WHOM IT MAY CONCERN >> >> In the light of the recent email on NAPAfrica mailing list, I would just >> like to clear the air. >> >> The IP route objects were created by myself for Cloud Innovation when >> they signed up as a client of Macrolan ( now SEACOM) as they didn't have >> their own AS. >> >> At the time I was working for Macrolan (now SEACOM). I left the >> employment of SEACOM in October 2019. >> >> It appears that when Cloud Innovation's contract with SEACOM came to an >> end, the route objects were never cleaned up. >> >> This occurred after I left SEACOM's employment. Since leaving, I have no >> access to these objects. >> >> Regards >> >> Paul Wollner >> 082-786-9776 >> To whom it may concern, >> >> On May 8, Mark Think posted a claim to multiple lists that Cloud >> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud >> Innovation) but rather belonged to Seacom through their acquisition of >> MacroLAN. >> >> While we regret this unfortunate incident, Mark?s claims that it was >> criminal or bad netizenship on the part of Cloud Innovation is without >> foundation and utterly incorrect. >> >> As shown below in the attached document from Paul Wollner(Ex-CTO of >> Macrolan who created IRR routes to allow Macrolan to announce Cloud >> Innovation's prefix); letter from Link Infinity International Ltd. (Link >> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS >> authorizing IPDC Solutions to announce the prefix with origin AS134190. >> And a Letter from IPDC. This was an innocent mistake committed by third >> parties and had nothing to do with any action by Cloud Innovation or LARUS. >> >> Here?s what happened: >> >> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December >> 2019. >> >> >> Link Infinity further delegated that same /24 to IPDC and asked Cloud >> innovation to issue an LOA, which we did. The LOA specifically required >> IPDC to use its own ASN to announce the space (AS134190). >> >> IPDC subsequently authorized one of its customers to use the said prefix. >> >> >> For reasons still unknown to Cloud Innovation, IPDC and their customer >> set up a BGP session wherein their customer used AS37353 as the origin to >> advertise prefix 156.241.3.0/24. >> >> >> Upon discovering the announcement, rather than contact Cloud Innovation, >> Mark contacted IPDC who provided him with an incomplete explanation blaming >> their customer and Mark, not realizing that Cloud Innovation was not the >> customer in question posted far and wide about the event. It is unclear to >> us why he chose to do this rather than contact us to try and resolve the >> issue. >> >> >> A contributing factor to the erroneous BGP configuration by IPDC's >> customer may have been data contained in some outdated IRR route objects >> for 156.241.0.0/16 which have subsequently been deleted. >> >> As soon as we became aware of the problem (via Mark?s email), we began to >> investigate the situation. As soon as it was clear that this was the result >> of third-party actions, we reached out to Mark privately to let him know >> what we knew and that we were still investigating. We delayed making a >> public statement in order to try and ascertain all of the facts of the >> situation. We prefer not to make public statements based on incomplete >> information. >> >> We apologize to the community for our small part in this unfortunate >> incident and assure you that we work very hard to remain good netizens and >> will address any concerns promptly when they come to our attention. >> >> >> Sincerely, >> >> Lu Heng >> CEO >> Cloud Innovations >> >> Attached: >> 1. Letter from Paul Wollner >> 2. Letter from Link Infinity >> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from >> AS134190 >> 4. Letter from IPDC >> >> FYI: LARUS is proving IP management service for Cloud Innovation, while >> LARUS is also providing IP management service to other third parties in all >> regions, for full disclosure, LARUS and Cloud Innovation are headed by same >> CEO. >> >> Content of those letters have been posted here for your convince: >> >> *IPDC:* >> >> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] >> >> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and >> over the course of our corporate relationship we were given the authority >> to use address block 156.241.3.0/24 since 9th December 2019. >> >> On 12th December 2019, we have delegated that address block to our >> client. Following which our client further instructed us to announce the >> prefix with AS37353. In good will after minimal verification through WHOIS? >> IP Prefix we have proceeded to execute our client?s request. >> >> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder >> of record for that ASN and have since learned that the customer?s use of >> that ASN was erroneous and not permitted by SEACOM and immediate action has >> been taken to rectify this situation. >> >> IPDC would like to apologize for our lack of attention in conducting >> thorough verification and wish to highlight that the involvement of Cloud >> Innovation Ltd in the entire process was providing the addresses to us and >> that we truly apologize as we understand that this incident may have >> indirectly implicated Cloud Innovation Ltd. >> >> IPDC however, does not wish to disclose our client information and our >> client information shall remain confidential under present circumstances. >> Once again, we apologize for our shortcomings. >> >> *Link Infinity:* >> >> To whom it may concern, >> >> We at HK Infinity International Ltd are a customer of Cloud Innovation >> and in the course received rights to use 156.241.3.0/24 from them. >> Beginning December, 2019, we delegated the right to announce this prefix to >> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA >> authorizing them to announce the space which was subsequently received. >> IPDC subsequently and without our knowledge delegated this space to one of >> their customers and allowed them to originate it from AS37353. >> >> This announcement was not authorized by us, nor is it permitted by the >> LOA provided by Cloud Innovation. >> >> Unfortunately, we were not aware of the situation until after it had >> already been resolved. >> >> It was never our intent to violate the LOA or to allow the prefix to be >> announced from a hijacked ASN. We do not condone this and apologize >> sincerely to the community for what has happened here. >> >> Sincere Apologies, >> >> *Paul Wollner:* >> >> 8 May 2020 >> >> TO WHOM IT MAY CONCERN >> >> In the light of the recent email on NAPAfrica mailing list, I would just >> like to clear the air. >> >> The IP route objects were created by myself for Cloud Innovation when >> they signed up as a client of Macrolan ( now SEACOM) as they didn't have >> their own AS. >> >> At the time I was working for Macrolan (now SEACOM). I left the >> employment of SEACOM in October 2019. >> >> It appears that when Cloud Innovation's contract with SEACOM came to an >> end, the route objects were never cleaned up. >> >> This occurred after I left SEACOM's employment. Since leaving, I have no >> access to these objects. >> >> Regards >> >> Paul Wollner >> 082-786-9776 >> >> On Fri, 8 May 2020 at 22:08, Mark Tinka wrote: >> >>> 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. >>> _______________________________________________ >>> Community-Discuss mailing list >>> Community-Discuss at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/community-discuss >>> >> >> >> -- >> -- >> Kind regards. >> Lu >> >> _______________________________________________ >> Community-Discuss mailing list >> Community-Discuss at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/community-discuss >> > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2020-05-28 at 17.13.51 .png Type: image/png Size: 104109 bytes Desc: not available URL: From amelnaud at gmail.com Fri May 29 08:07:08 2020 From: amelnaud at gmail.com (Arnaud AMELINA) Date: Fri, 29 May 2020 08:07:08 +0000 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Hi Owen, I won?t respond to your intimidation but focus on the real technical issues. See my response below inline Le ven. 29 mai 2020 ? 00:59, Owen DeLong a ?crit : > Arnaud, > > You are mistaken on a number of points. > > > On May 28, 2020, at 13:05 , Arnaud AMELINA wrote: > > Hi, all communities > > It was said that the hijacking of AS37353 was a configuration mistake, > coupled with poor oversight in checking the right to use of the ASN by a > certain IPDC customer. > > It was also said that this would have been facilitated by old and stalled > IRR objects from MacroLAN before the service contract ended in December > 2019. > > It was also stated that the BGP announcement was stopped and some actions > taken to delete the stalled routing registry object from IRR. > > > Yes? The registry objects created by MacroLAN have been deleted. > > Below are some data which gives some extra information and confirm > previous claim that this incident was not accidental. > > > Below is some very redacted data which gives virtually no information. > > NB: All data are collected from their source, Today, 28 May 2020, at 10:00 > UTC. > > IRRs created in March 2020 with AS37353 as Origin for 156.241.3.0/24 by > HGC > > $ whois -h whois.radb.net '156.241.3.0/24' > > route: 156.241.3.0/24 descr: Proxy-registered route object > origin: AS37353 notify: matthew.chan at hgc.com.hk mnt-by: > MAINT-HGC-INTL changed: matthew.chan at hgc.com.hk 20200304 source: > RADB > > ===== > route: 156.241.3.0/24 > descr: Proxy-registered route object origin: AS37353 > remarks: This is a HGC customer route-object > remarks: which is being exported under this origin AS. > remarks: > remarks: This route object was created because no existing > remarks: route object with the same origin was found. > remarks: > remarks: Please contact radb at hutchcity.com if you have any > remarks: questions regarding this object. > notify: radb at hutchcity.com > mnt-by: MAINT-AS9304 > changed: radb at hutchcity.com 20200304 > source: NTTCOM > ==== > > > We haven changed anything, but here?s the full text of that whois command: > ... > changed: admin at cloudix.online 20200511 #03:10:36Z > source: RADB > 0.000u 0.001s 0:00.19 0.0% 0+0k 0+0io 0pf+0w > owen (122) ~ % > 2020/05/28 16:58:53 > > Looks like there?s additional cruft left in some routing registries that > we still haven?t removed. I?ve asked people to get on that. > > Good.. this is the reason for my mail. Draw attention on these route objects which should have never existed on RADB and get them cleaned up by your customer who is the maintainer of the route object as per the records. > However, just because it?s in RADB doesn?t mean it?s advertised. > The routing visibility I referred to was not because route objects are in RADB or in NTT routing registries.. Even though the prefix is no longer seen in global routing table, it is been seen by some route collectors. One route collector at RIPE Stat sees as shown in the picture as at now. [ picture] And the ASPATH speaks for itself. > Nonetheless, we are actively working to get those errant entries cleaned > up. Thank you for bringing them to our attention. > > Please let the community know when everything is cleaned. Thank you -- Arnaud ... > _______________________________________________ >> Community-Discuss mailing list >> Community-Discuss at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/community-discuss >> > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_20200529_074734_512.jpg Type: image/jpeg Size: 62307 bytes Desc: not available URL: From taiwo.oyewande88 at gmail.com Fri May 29 08:43:48 2020 From: taiwo.oyewande88 at gmail.com (Taiwo Oyewande) Date: Fri, 29 May 2020 09:43:48 +0100 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship Message-ID: <353A9A34-D8DB-403D-BDF8-780E364E1E8D@gmail.com> Good day, I agree with Paul here. In this entire matter, the authors have blamed the wrong party - i think it should be a SEACOM issue in the first place. This makes me wonder -why did the authors put the blame on Cloud Innovation? They should have known what and how this happened probably better than most people on this thread? I was thinking why - now Paul?s comment has a lot to say about that. - it?s not exaggerating to say that this whole drama looks like an attempt to defame The name of the targeted party. Targeted attacks using provided community communication platforms should not be part of this community. If there is a problem, solution is what we should proffer. let us try to fix things instead of wasting time and resources making unnecessary noise within this community. I wish everyone a nice day. And please, do stay safe. Taiwo From noah at neo.co.tz Fri May 29 09:33:29 2020 From: noah at neo.co.tz (Noah) Date: Fri, 29 May 2020 12:33:29 +0300 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Paul, On Fri, May 29, 2020 at 6:22 AM Paul Wollner wrote: > I feel that SEACOM neglected their duty to remove these objects when the > client's contract came to an end. As the ISP created the records in the > first place, the records should have been updated or deleted by them too. > >From the data posted by Arnaud and Owen, the route object records for the Cloud Innovation Limited prefix156.241.3.0/24 in question are those created as recently as 4th March 2020 by Mattew Chan of HonKong Link Infinity Limited on the RADB IRR database using AS37353 again to originate the prefix. Surely, this does not look like a mistake if indeed the contract with the customer was terminated as far back as December 2020. [image: link infinity.png] The route object as seen on the data presented by Arnaud and Owen has a change log that indicates " *changed: matthew.chan at hgc.com.hk 20200304*" which means it was created on 04-03-2020 two months since December 2019. I believe Owen has indicated that he is following up the matter with their customer so that it's fixed and those records cleared from RADB. Cheers, Noah -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: link infinity.png Type: image/png Size: 327990 bytes Desc: not available URL: From mark.tinka at seacom.mu Fri May 29 11:44:28 2020 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 29 May 2020 13:44:28 +0200 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: <161dde92-2fea-c8a5-522f-8981ca2dc4b8@seacom.mu> On 29/May/20 05:17, Paul Wollner wrote: > > In light of the accusations that have been made on 8 May, I feel that > SEACOM neglected their duty to remove these objects when the client's > contract came to an end. As the ISP created the records in the first > place, the records should have been updated or deleted by them too. > This shows poor corporate governance by SEACOM and it is ironic that > their own employee in charge of these duties wished to make this > public in an attempt to place blame elsewhere whilst the incompetence > lies largely, if not solely, with SEACOM. Not to state the obvious, but IRR objects do not create eBGP sessions - people with beating hearts create BGP sessions. > > I was the person who created the objects in the respective databases, > however I was no longer in the employment of SEACOM when Cloud > Innovation's contract came to an end and hence no longer had rights to > the route objects. That may very well be so, Paul, but the RADB entry did not create itself. And no one from SEACOM (present or past) asked anyone at Hutch to create that entry in RADB. > > It is now almost a month later and the amount of resources wasted on > dealing with this issue when it could have been resolved quickly and > safely by the relevant parties is astounding and personally quite > unsettling. This matter should be put to rest now. As a global > community we are dealing with far bigger issues and we should be > putting our efforts towards the greater good, not petty infighting > fueled by drama and misinformation. On the contrary. The community need to understand that this isn't an issue that RPKI can protect against in its current form, and that we should do everything we can to avoid such issues from every re-surfacing, as today it's affecting SEACOM, but tomorrow, it's affecting another operator. Don't know what's more important - within our community - than a safer, more secure, Internet. Mark. From mark.tinka at seacom.mu Fri May 29 11:45:21 2020 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 29 May 2020 13:45:21 +0200 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: <8193adb3-1fd1-2281-6978-9bfaa9717603@seacom.mu> On 29/May/20 05:17, Paul Wollner wrote: > In light of the accusations that have been made on 8 May, I feel that > SEACOM neglected their duty to remove these objects when the client's > contract came to an end. As the ISP created the records in the first > place, the records should have been updated or deleted by them too. > This shows poor corporate governance by SEACOM and it is ironic that > their own employee in charge of these duties wished to make this > public in an attempt to place blame elsewhere whilst the incompetence > lies largely, if not solely, with SEACOM. Not to state the obvious, but IRR objects do not create eBGP sessions - people with beating hearts create BGP sessions. > I was the person who created the objects in the respective databases, > however I was no longer in the employment of SEACOM when Cloud > Innovation's contract came to an end and hence no longer had rights to > the route objects. That may very well be so, Paul, but the RADB entry did not create itself. And no one from SEACOM (present or past) asked anyone at Hutch to create that entry in RADB. > It is now almost a month later and the amount of resources wasted on > dealing with this issue when it could have been resolved quickly and > safely by the relevant parties is astounding and personally quite > unsettling. This matter should be put to rest now. As a global > community we are dealing with far bigger issues and we should be > putting our efforts towards the greater good, not petty infighting > fueled by drama and misinformation. On the contrary. The community need to understand that this isn't an issue that RPKI can protect against in its current form, and that we should do everything we can to avoid such issues from every re-surfacing, as today it's affecting SEACOM, but tomorrow, it's affecting another operator. Don't know what's more important - within our community - than a safer, more secure, Internet. Mark. From oloyede.aa at unilorin.edu.ng Fri May 29 11:48:47 2020 From: oloyede.aa at unilorin.edu.ng (ABDULKARIM AYOPO OLOYEDE) Date: Fri, 29 May 2020 12:48:47 +0100 Subject: [Community-Discuss] [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Dear Community, You would notice that we Co-chairs decided to back off when the direction of discussion moved towards proposing a policy. However, it seems we are deviating again. This mailing list or PDWG has no power to determine who is to right or wrong on this issue and therefore posting issues on who to blame or not on here is a total distraction, a waste of time and should be considered as spam. There are other mailing lists where the blame game can be discussed. At this point, we would like to issue a final warning *specifically for the blame thing (directly or indirectly) or mentioning the names of any individual or a company*. We do not mind having the discussion around policies in a constructive manner but definitely without names or an individual or a company. Am sorry to say but we have no choice *but to moderate the email of anyone doing otherwise after this email*. Thank you Co-Chair PDWG On Fri, May 29, 2020 at 10:35 AM Noah wrote: > Paul, > > On Fri, May 29, 2020 at 6:22 AM Paul Wollner wrote: > > >> I feel that SEACOM neglected their duty to remove these objects when the >> client's contract came to an end. As the ISP created the records in the >> first place, the records should have been updated or deleted by them too. >> > > From the data posted by Arnaud and Owen, the route object records for the > Cloud Innovation Limited prefix156.241.3.0/24 in question are those created > as recently as 4th March 2020 by Mattew Chan of HonKong Link Infinity > Limited on the RADB IRR database using AS37353 again to originate the > prefix. > > Surely, this does not look like a mistake if indeed the contract with the > customer was terminated as far back as December 2020. > > > [image: link infinity.png] > > The route object as seen on the data presented by Arnaud and Owen has a > change log that indicates " *changed: matthew.chan at hgc.com.hk > 20200304*" > which means it was created on 04-03-2020 two months since December 2019. > > I believe Owen has indicated that he is following up the matter with their > customer so that it's fixed and those records cleared from RADB. > > Cheers, > Noah > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -- Website ,?Weekly Bulletin ?UGPortal PGPortal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: link infinity.png Type: image/png Size: 327990 bytes Desc: not available URL: From oloyede.aa at unilorin.edu.ng Fri May 29 12:06:24 2020 From: oloyede.aa at unilorin.edu.ng (ABDULKARIM AYOPO OLOYEDE) Date: Fri, 29 May 2020 13:06:24 +0100 Subject: [Community-Discuss] [rpd] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Hi Apologies, My last email was meant for the RPD mailing list and not the general discussion Cheers On Fri, May 29, 2020 at 12:48 PM ABDULKARIM AYOPO OLOYEDE < oloyede.aa at unilorin.edu.ng> wrote: > Dear Community, > You would notice that we Co-chairs decided to back off when the direction > of discussion moved towards proposing a policy. However, it seems we are > deviating again. This mailing list or PDWG has no power to determine who > is to right or wrong on this issue and therefore posting issues on who to > blame or not on here is a total distraction, a waste of time and should be > considered as spam. There are other mailing lists where the blame game can > be discussed. At this point, we would like to issue a final warning *specifically > for the blame thing (directly or indirectly) or mentioning the names of any > individual or a company*. We do not mind having the discussion around > policies in a constructive manner but definitely without names or an > individual or a company. Am sorry to say but we have no choice *but to > moderate the email of anyone doing otherwise after this email*. > Thank you > Co-Chair > PDWG > > On Fri, May 29, 2020 at 10:35 AM Noah wrote: > >> Paul, >> >> On Fri, May 29, 2020 at 6:22 AM Paul Wollner >> wrote: >> >> >>> I feel that SEACOM neglected their duty to remove these objects when the >>> client's contract came to an end. As the ISP created the records in the >>> first place, the records should have been updated or deleted by them too. >>> >> >> From the data posted by Arnaud and Owen, the route object records for the >> Cloud Innovation Limited prefix156.241.3.0/24 in question are those created >> as recently as 4th March 2020 by Mattew Chan of HonKong Link Infinity >> Limited on the RADB IRR database using AS37353 again to originate the >> prefix. >> >> Surely, this does not look like a mistake if indeed the contract with the >> customer was terminated as far back as December 2020. >> >> >> [image: link infinity.png] >> >> The route object as seen on the data presented by Arnaud and Owen has a >> change log that indicates " *changed: matthew.chan at hgc.com.hk >> 20200304*" >> which means it was created on 04-03-2020 two months since December 2019. >> >> I believe Owen has indicated that he is following up the matter with >> their customer so that it's fixed and those records cleared from RADB. >> >> Cheers, >> Noah >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > -- Website ,?Weekly Bulletin ?UGPortal PGPortal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: link infinity.png Type: image/png Size: 327990 bytes Desc: not available URL: From ubah.tonyiyke at gmail.com Fri May 29 13:33:13 2020 From: ubah.tonyiyke at gmail.com (Anthony Ubah) Date: Fri, 29 May 2020 14:33:13 +0100 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: Hi Paul, This echos my previous post. It beams light on the grey areas. 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. >From whatever perspective the onus is on SEACOM and IPDC. 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. Kind regards, Anthony On Fri, May 29, 2020, 09:07 wrote: > Send Community-Discuss mailing list submissions to > community-discuss at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/community-discuss > or, via email, send a message with subject or body 'help' to > community-discuss-request at afrinic.net > > You can reach the person managing the list at > community-discuss-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Community-Discuss digest..." > > > Today's Topics: > > 1. Re: Cloud Innovation Displays Very Poor, If Not Criminal, > Netizenship (Paul Wollner) > 2. Re: Cloud Innovation Displays Very Poor, If Not Criminal, > Netizenship (Arnaud AMELINA) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 May 2020 05:17:41 +0200 > From: Paul Wollner > To: Owen DeLong > Cc: General Discussions of AFRINIC , > "rpd >> AfriNIC Resource Policy" > Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor, > If Not Criminal, Netizenship > Message-ID: > D0WUwLg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I have been watching this thread and I feel that I should respond as it was > I that created the route objects in > AFRINIC and RIPE on behalf of Cloud Innovation. > > In light of the accusations that have been made on 8 May, I feel that > SEACOM neglected their duty to remove these objects when the client's > contract came to an end. As the ISP created the records in the first place, > the records should have been updated or deleted by them too. This shows > poor corporate governance by SEACOM and it is ironic that their own > employee in charge of these duties wished to make this public in an attempt > to place blame elsewhere whilst the incompetence lies largely, if not > solely, with SEACOM. > > I was the person who created the objects in the respective databases, > however I was no longer in the employment of SEACOM when Cloud Innovation's > contract came to an end and hence no longer had rights to the route > objects. > > It is now almost a month later and the amount of resources wasted on > dealing with this issue when it could have been resolved quickly and safely > by the relevant parties is astounding and personally quite unsettling. This > matter should be put to rest now. As a global community we are dealing with > far bigger issues and we should be putting our efforts towards the greater > good, not petty infighting fueled by drama and misinformation. > > > > On Fri, May 29, 2020 at 3:00 AM Owen DeLong wrote: > > > Arnaud, > > > > You are mistaken on a number of points. > > > > > > On May 28, 2020, at 13:05 , Arnaud AMELINA wrote: > > > > Hi, all communities > > > > It was said that the hijacking of AS37353 was a configuration mistake, > > coupled with poor oversight in checking the right to use of the ASN by a > > certain IPDC customer. > > > > It was also said that this would have been facilitated by old and stalled > > IRR objects from MacroLAN before the service contract ended in December > > 2019. > > > > It was also stated that the BGP announcement was stopped and some actions > > taken to delete the stalled routing registry object from IRR. > > > > > > Yes? The registry objects created by MacroLAN have been deleted. > > > > Below are some data which gives some extra information and confirm > > previous claim that this incident was not accidental. > > > > > > Below is some very redacted data which gives virtually no information. > > > > NB: All data are collected from their source, Today, 28 May 2020, at > 10:00 > > UTC. > > > > IRRs created in March 2020 with AS37353 as Origin for 156.241.3.0/24 by > > HGC > > > > $ whois -h whois.radb.net '156.241.3.0/24' > > > > route: 156.241.3.0/24 descr: Proxy-registered route object > > origin: AS37353 notify: matthew.chan at hgc.com.hk mnt-by: > > MAINT-HGC-INTL changed: matthew.chan at hgc.com.hk 20200304 source: > > RADB > > > > ===== > > route: 156.241.3.0/24 > > descr: Proxy-registered route object origin: AS37353 > > remarks: This is a HGC customer route-object > > remarks: which is being exported under this origin AS. > > remarks: > > remarks: This route object was created because no existing > > remarks: route object with the same origin was found. > > remarks: > > remarks: Please contact radb at hutchcity.com if you have any > > remarks: questions regarding this object. > > notify: radb at hutchcity.com > > mnt-by: MAINT-AS9304 > > changed: radb at hutchcity.com 20200304 > > source: NTTCOM > > ==== > > > > > > We haven changed anything, but here?s the full text of that whois > command: > > owen (121) ~ % whois -h whois.radb.net 156.241.3.0/24 > > 2020/05/28 16:58:50 > > route: 156.241.3.0/24 > > origin: AS138145 > > descr: Customer-AS45250 > > admin-c: MAINT-AS138145 > > tech-c: MAINT-AS138145 > > mnt-by: MAINT-AS138145 > > changed: admin at cloudix.online 20200512 #18:26:20Z > > source: RADB > > > > route: 156.241.3.0/24 > > origin: AS134190 > > descr: IPDC Solution PteLtd > > mnt-by: MAINT-LARUS > > changed: t.t.xu at laruscloudservice.net 20200508 #10:43:19Z > > source: RADB > > > > route: 156.241.3.0/24 > > descr: Proxy-registered route object > > origin: AS37353 > > notify: matthew.chan at hgc.com.hk > > mnt-by: MAINT-HGC-INTL > > changed: matthew.chan at hgc.com.hk 20200304 > > source: RADB > > > > route: 156.241.3.0/24 > > descr: Proxy-registered route object > > origin: AS134548 > > changed: radb at hgcbroadband.com 20191003 > > source: RADB > > > > route: 156.241.0.0/16 > > origin: AS37353 > > mnt-by: paulwollner > > mnt-by: hk-larus-1-mnt > > created: 2017-08-07T12:27:22Z > > last-modified: 2018-09-04T18:54:09Z > > source: RIPE-NONAUTH > > remarks: **************************** > > remarks: * THIS OBJECT IS MODIFIED > > remarks: * Please note that all data that is generally regarded as > > personal > > remarks: * data has been removed from this object. > > remarks: * To view the original object, please query the RIPE > > Database at: > > remarks: * http://www.ripe.net/whois > > remarks: **************************** > > > > route: 156.241.3.0/24 > > descr: Proxy-registered route object > > origin: AS37353 > > remarks: This is a HGC customer route-object > > remarks: which is being exported under this origin AS. > > remarks: > > remarks: This route object was created because no existing > > remarks: route object with the same origin was found. > > remarks: > > remarks: Please contact radb at hutchcity.com if you have any > > remarks: questions regarding this object. > > notify: radb at hutchcity.com > > mnt-by: MAINT-AS9304 > > changed: radb at hutchcity.com 20200304 > > source: NTTCOM > > > > route: 156.241.3.0/24 > > descr: Proxy-registered route object > > origin: AS134548 > > remarks: This is a HGC customer route-object > > remarks: which is being exported under this origin AS. > > remarks: > > remarks: This route object was created because no existing > > remarks: route object with the same origin was found. > > remarks: > > remarks: Please contact radb at hgcbroadband.com if you have any > > remarks: questions regarding this object. > > notify: radb at hgcbroadband.com > > mnt-by: MAINT-AS9304 > > changed: radb at hgcbroadband.com 20191003 > > source: NTTCOM > > > > mntner: MAINT-AS138145 > > descr: Advanced Information Co., Ltd. > > admin-c: ADVANCED-APNIC > > tech-c: ADVANCED-APNIC > > upd-to: noc at cloudix.online > > mnt-nfy: noc at cloudix.online > > auth: CRYPT-PW HIDDENCRYPTPW # > > notify: noc at cloudix.online > > mnt-by: MAINT-AS138145 > > changed: admin at cloudix.online 20200511 #03:10:36Z > > source: RADB > > 0.000u 0.001s 0:00.19 0.0% 0+0k 0+0io 0pf+0w > > owen (122) ~ % > > 2020/05/28 16:58:53 > > > > Looks like there?s additional cruft left in some routing registries that > > we still haven?t removed. I?ve asked people to get on that. > > > > However, just because it?s in RADB doesn?t mean it?s advertised. > > Nonetheless, we are actively working to get those errant entries cleaned > > up. Thank you for bringing them to our attention. > > > > > > > https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0%2F24&-T+option=&ip_option=&-i+option= > > < > https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0/24&-T+option=&ip_option=&-i+option= > > > > > > These objects havent been deleted. > > > > An in-depth check of the routing status of 156.241.3.0/24 shows the > > followings: > > > > Hurricane Electric BGP tool > > > > https://bgp.he.net/net/156.241.3.0/24 > > > > Origin AS Announcement Description AS37353 > > 156.241.3.0/24 IRR Valid HONGKONG LINK INFINITY TECHNOLOGY LIMITED > > > > > > The HE BGP tool doesn?t mean what you think it means. > > > > It retains routes which have been withdrawn for a very long time after > > they have been withdrawn, especially if they are not superseded by other > > announcements. > > > > OTOH, the HE BGP Looking glass shows: > > > > > > > > RIPESTAT > > > > https://stat.ripe.net/widget/looking-glass#w.resource=156.241.3.0%2F24 > > > > > > AS37353 is seen as the origin by 1 peer. > > > > 103.200.115.1 ?103.200.115.1 is announcing route AS64271 AS9304 AS4809 > > AS4809 AS4809 AS134190 AS37353. > > > > > > Well? That?s historic data. If you view it in BGPLAY, you will see that > > the last transaction for this prefix was on May 7 (Mark?s initial on-list > > complaint came May 8). > > > > Even with the limited view, the prefix is still being originated and > > routed and the route objects still exist. > > > > > > No, you are looking at data from May 7. Current data as above (HE looking > > glass). > > > > From Route-views and several other route servers (I have redacted the > > transcript to leave out banner text and other irrelevant data. All > routing > > queries are included full prompt to prompt without editing): > > route-views>show ip bgp 156.241.3.0/24 > > % Network not in table > > route-views> > > > > > > owen (122) ~ % telnet route-views.oregon-ix.net > > 2020/05/28 16:58:53 > > Trying 128.223.51.103... > > Connected to route-views.oregon-ix.net. > > Escape character is '^]'. > > > > User Access Verification > > > > Username: Kerberos: No default realm defined for Kerberos! > > rviews > > > > route-views>show ip bgp 156.241.3.0/24 > > % Network not in table > > route-views>q > > Connection closed by foreign host. > > 0.007u 0.014s 1:49.98 0.0% 0+0k 0+0io 21pf+0w > > Exit 1 > > owen (123) ~ % telnet route-views.optus.net.au > > 2020/05/28 17:26:50 > > Trying 203.202.125.6... > > Connected to route-views.optus.net.au. > > Escape character is '^]'. > > > > route-views.optus.net.au>Kerberos: No default realm defined for > Kerberos! > > show ip bgp 156.241.3.0/24 > > % Network not in table > > route-views.optus.net.au>q > > Connection closed by foreign host. > > 0.007u 0.005s 0:21.89 0.0% 0+0k 0+0io 0pf+0w > > Exit 1 > > > > owen (127) ~ % telnet route-views.ab.bb.telus.com > > 2020/05/28 17:28:00 > > Trying 154.11.98.18... > > Connected to route-views.ab.bb.telus.com. > > Escape character is '^]'. > > c > > > > route-views.ab>Kerberos: No default realm defined for Kerberos! > > show ip bgp 156.241.3.0/24 > > % Network not in table > > route-views.ab>q > > Connection closed by foreign host. > > 0.006u 0.005s 0:05.23 0.0% 0+0k 0+0io 0pf+0w > > Exit 1 > > owen (131) ~ % telnet route-server.tinet.net > > 2020/05/28 17:28:45 > > Trying 213.200.64.94... > > Connected to route-server.tinet.net. > > Escape character is '^]'. > > login: public > > Password: > > Last login: Thu May 28 18:44:36 from vinci.rdsnet.ro > > > > --- JUNOS 15.1F6-S5.6 Kernel 64-bit JNPR-10.3-20161130.340898_build > > > > {master} > > public at route-server.as3257.net-re0> show route 156.241.3.0/24 all > > extensive > > > > {master} > > public at route-server.as3257.net-re0> > > public at route-server.as3257.net-re0> quit > > > > Connection closed by foreign host. > > 0.007u 0.009s 0:40.46 0.0% 0+0k 0+0io 0pf+0w > > Exit 1 > > owen (132) ~ % telnet route-server.eu.gblx.net > > 2020/05/28 17:29:35 > > Trying 2001:450:2001:1000::670:1708:1187... > > Connected to loop0.route-server.ams2.gblx.net. > > Escape character is '^]'. > > > > route-server.ams2>Kerberos: No default realm defined for Kerberos! > > show ip bgp 156.241.3.0/24 > > % Network not in table > > route-server.ams2>q > > Connection closed by foreign host. > > 0.006u 0.005s 0:05.51 0.0% 0+0k 0+0io 0pf+0w > > Exit 1 > > owen (134) ~ % telnet route-server.opentransit.net > > 2020/05/28 17:30:09 > > Trying 204.59.3.38... > > Connected to route-server.opentransit.net. > > Escape character is '^]'. > > User Access Verification > > > > Username: Kerberos: No default realm defined for Kerberos! > > rviews > > Password: > > OAKRS1#show ip bgp 156.241.3.0/24 > > % Network not in table > > OAKRS1#exit > > Connection closed by foreign host. > > 0.007u 0.008s 0:29.00 0.0% 0+0k 0+0io 0pf+0w > > Exit 1 > > owen (141) ~ % telnet route-server.host.net > > 2020/05/28 17:32:15 > > Trying 2001:5b8:fffe::10... > > telnet: connect to address 2001:5b8:fffe::10: Connection refused > > Trying 75.119.191.74... > > Connected to route-server.host.net. > > Escape character is '^]'. > > > > User Access Verification > > > > Password: > > route-server> show ip bgp 156.241.3.0/24 > > % Network not in table > > route-server> q > > Connection closed by foreign host. > > 0.006u 0.006s 0:06.21 0.0% 0+0k 0+0io 0pf+0w > > Exit 1 > > > > > > As you can see, from many different internet perspectives, the prefix > > simply isn?t in the table. > > > > So, Arnaud, your data is flawed and your conclusions are in error. The > > prefix has not been announced since May 7. I don?t know how much you?ve > > tried to remove obsolete or erroneous entries from RADB and its ilk > > generated by others, but I can assure you that it is much like the game > of > > whack-a-mole. We appreciate your calling these entries to our attention > and > > we will pursue them, but there has been no further incidence of use of > > AS37353 by our customers and the actual problem was, in fact, corrected > > prior to Mark?s initial post. > > > > Nothing you have posted indicates otherwise and your claims could be > > considered defamatory. > > Im not sure about the law where you are, but here, defamation requires 4 > > elements: > > 1. A false statement purporting to be fact. Your claims above that the > > hijack was an action by Larus (false) and that it was malicious (false) > and > > that it continues (false) qualify here. > > 2. Publication or communication of that statement to a third person. By > > posting this on multiple lists, you have more than met this test. > > 3. Fault amounting to at least negligence. This one is a bit more of a > > grey area, but your failure to investigate realtime sources instead of > > relying on sources known to use historical data is, IMHO, negligent. > > 4. Damages or some harm caused to the person or entity. If nothing else, > > the collective time wasted on this continued discussion of a minor > mistake > > represents significant harm to the community as a whole. > > Were your statements not so blatantly and easily disproven, or should > they > > be believed by anyone, then there is also the question of harm to the > good > > name of Larus as a company. > > > > Owen > > > > > > Regards > > > > -- > > Arnaud > > > > Le sam. 9 mai 2020 ? 09:44, Lu Heng a ?crit : > > > >> To whom it may concern, > >> > >> On May 8, Mark Think posted a claim to multiple lists that Cloud > >> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > >> Innovation) but rather belonged to Seacom through their acquisition of > >> MacroLAN. > >> > >> While we regret this unfortunate incident, Mark?s claims that it was > >> criminal or bad netizenship on the part of Cloud Innovation is without > >> foundation and utterly incorrect. > >> > >> As shown below in the attached document from Paul Wollner(Ex-CTO of > >> Macrolan who created IRR routes to allow Macrolan to announce Cloud > >> Innovation's prefix); letter from Link Infinity International Ltd. (Link > >> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > >> authorizing IPDC Solutions to announce the prefix with origin AS134190. > >> And a Letter from IPDC. This was an innocent mistake committed by third > >> parties and had nothing to do with any action by Cloud Innovation or > LARUS. > >> > >> Here?s what happened: > >> > >> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December > >> 2019. > >> > >> > >> Link Infinity further delegated that same /24 to IPDC and asked Cloud > >> innovation to issue an LOA, which we did. The LOA specifically required > >> IPDC to use its own ASN to announce the space (AS134190). > >> > >> IPDC subsequently authorized one of its customers to use the said > prefix. > >> > >> > >> For reasons still unknown to Cloud Innovation, IPDC and their customer > >> set up a BGP session wherein their customer used AS37353 as the origin > to > >> advertise prefix 156.241.3.0/24. > >> > >> > >> Upon discovering the announcement, rather than contact Cloud Innovation, > >> Mark contacted IPDC who provided him with an incomplete explanation > blaming > >> their customer and Mark, not realizing that Cloud Innovation was not the > >> customer in question posted far and wide about the event. It is unclear > to > >> us why he chose to do this rather than contact us to try and resolve the > >> issue. > >> > >> > >> A contributing factor to the erroneous BGP configuration by IPDC's > >> customer may have been data contained in some outdated IRR route objects > >> for 156.241.0.0/16 which have subsequently been deleted. > >> > >> As soon as we became aware of the problem (via Mark?s email), we began > to > >> investigate the situation. As soon as it was clear that this was the > result > >> of third-party actions, we reached out to Mark privately to let him know > >> what we knew and that we were still investigating. We delayed making a > >> public statement in order to try and ascertain all of the facts of the > >> situation. We prefer not to make public statements based on incomplete > >> information. > >> > >> We apologize to the community for our small part in this unfortunate > >> incident and assure you that we work very hard to remain good netizens > and > >> will address any concerns promptly when they come to our attention. > >> > >> > >> Sincerely, > >> > >> Lu Heng > >> CEO > >> Cloud Innovations > >> > >> Attached: > >> 1. Letter from Paul Wollner > >> 2. Letter from Link Infinity > >> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > >> AS134190 > >> 4. Letter from IPDC > >> > >> FYI: LARUS is proving IP management service for Cloud Innovation, while > >> LARUS is also providing IP management service to other third parties in > all > >> regions, for full disclosure, LARUS and Cloud Innovation are headed by > same > >> CEO. > >> > >> Content of those letters have been posted here for your convince: > >> > >> *IPDC:* > >> > >> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > >> > >> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > >> over the course of our corporate relationship we were given the > authority > >> to use address block 156.241.3.0/24 since 9th December 2019. > >> > >> On 12th December 2019, we have delegated that address block to our > >> client. Following which our client further instructed us to announce the > >> prefix with AS37353. In good will after minimal verification through > WHOIS? > >> IP Prefix we have proceeded to execute our client?s request. > >> > >> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > >> of record for that ASN and have since learned that the customer?s use of > >> that ASN was erroneous and not permitted by SEACOM and immediate action > has > >> been taken to rectify this situation. > >> > >> IPDC would like to apologize for our lack of attention in conducting > >> thorough verification and wish to highlight that the involvement of > Cloud > >> Innovation Ltd in the entire process was providing the addresses to us > and > >> that we truly apologize as we understand that this incident may have > >> indirectly implicated Cloud Innovation Ltd. > >> > >> IPDC however, does not wish to disclose our client information and our > >> client information shall remain confidential under present > circumstances. > >> Once again, we apologize for our shortcomings. > >> > >> *Link Infinity:* > >> > >> To whom it may concern, > >> > >> We at HK Infinity International Ltd are a customer of Cloud Innovation > >> and in the course received rights to use 156.241.3.0/24 from them. > >> Beginning December, 2019, we delegated the right to announce this > prefix to > >> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an > LOA > >> authorizing them to announce the space which was subsequently received. > >> IPDC subsequently and without our knowledge delegated this space to one > of > >> their customers and allowed them to originate it from AS37353. > >> > >> This announcement was not authorized by us, nor is it permitted by the > >> LOA provided by Cloud Innovation. > >> > >> Unfortunately, we were not aware of the situation until after it had > >> already been resolved. > >> > >> It was never our intent to violate the LOA or to allow the prefix to be > >> announced from a hijacked ASN. We do not condone this and apologize > >> sincerely to the community for what has happened here. > >> > >> Sincere Apologies, > >> > >> *Paul Wollner:* > >> > >> 8 May 2020 > >> > >> TO WHOM IT MAY CONCERN > >> > >> In the light of the recent email on NAPAfrica mailing list, I would just > >> like to clear the air. > >> > >> The IP route objects were created by myself for Cloud Innovation when > >> they signed up as a client of Macrolan ( now SEACOM) as they didn't have > >> their own AS. > >> > >> At the time I was working for Macrolan (now SEACOM). I left the > >> employment of SEACOM in October 2019. > >> > >> It appears that when Cloud Innovation's contract with SEACOM came to an > >> end, the route objects were never cleaned up. > >> > >> This occurred after I left SEACOM's employment. Since leaving, I have no > >> access to these objects. > >> > >> Regards > >> > >> Paul Wollner > >> 082-786-9776 > >> To whom it may concern, > >> > >> On May 8, Mark Think posted a claim to multiple lists that Cloud > >> Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud > >> Innovation) but rather belonged to Seacom through their acquisition of > >> MacroLAN. > >> > >> While we regret this unfortunate incident, Mark?s claims that it was > >> criminal or bad netizenship on the part of Cloud Innovation is without > >> foundation and utterly incorrect. > >> > >> As shown below in the attached document from Paul Wollner(Ex-CTO of > >> Macrolan who created IRR routes to allow Macrolan to announce Cloud > >> Innovation's prefix); letter from Link Infinity International Ltd. (Link > >> Infinity), A customer of Cloud Innovation; and attached LOA from LARUS > >> authorizing IPDC Solutions to announce the prefix with origin AS134190. > >> And a Letter from IPDC. This was an innocent mistake committed by third > >> parties and had nothing to do with any action by Cloud Innovation or > LARUS. > >> > >> Here?s what happened: > >> > >> Cloud Innovation delegated a /24 to Link Infinity, an ISP in December > >> 2019. > >> > >> > >> Link Infinity further delegated that same /24 to IPDC and asked Cloud > >> innovation to issue an LOA, which we did. The LOA specifically required > >> IPDC to use its own ASN to announce the space (AS134190). > >> > >> IPDC subsequently authorized one of its customers to use the said > prefix. > >> > >> > >> For reasons still unknown to Cloud Innovation, IPDC and their customer > >> set up a BGP session wherein their customer used AS37353 as the origin > to > >> advertise prefix 156.241.3.0/24. > >> > >> > >> Upon discovering the announcement, rather than contact Cloud Innovation, > >> Mark contacted IPDC who provided him with an incomplete explanation > blaming > >> their customer and Mark, not realizing that Cloud Innovation was not the > >> customer in question posted far and wide about the event. It is unclear > to > >> us why he chose to do this rather than contact us to try and resolve the > >> issue. > >> > >> > >> A contributing factor to the erroneous BGP configuration by IPDC's > >> customer may have been data contained in some outdated IRR route objects > >> for 156.241.0.0/16 which have subsequently been deleted. > >> > >> As soon as we became aware of the problem (via Mark?s email), we began > to > >> investigate the situation. As soon as it was clear that this was the > result > >> of third-party actions, we reached out to Mark privately to let him know > >> what we knew and that we were still investigating. We delayed making a > >> public statement in order to try and ascertain all of the facts of the > >> situation. We prefer not to make public statements based on incomplete > >> information. > >> > >> We apologize to the community for our small part in this unfortunate > >> incident and assure you that we work very hard to remain good netizens > and > >> will address any concerns promptly when they come to our attention. > >> > >> > >> Sincerely, > >> > >> Lu Heng > >> CEO > >> Cloud Innovations > >> > >> Attached: > >> 1. Letter from Paul Wollner > >> 2. Letter from Link Infinity > >> 3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from > >> AS134190 > >> 4. Letter from IPDC > >> > >> FYI: LARUS is proving IP management service for Cloud Innovation, while > >> LARUS is also providing IP management service to other third parties in > all > >> regions, for full disclosure, LARUS and Cloud Innovation are headed by > same > >> CEO. > >> > >> Content of those letters have been posted here for your convince: > >> > >> *IPDC:* > >> > >> FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd] > >> > >> IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and > >> over the course of our corporate relationship we were given the > authority > >> to use address block 156.241.3.0/24 since 9th December 2019. > >> > >> On 12th December 2019, we have delegated that address block to our > >> client. Following which our client further instructed us to announce the > >> prefix with AS37353. In good will after minimal verification through > WHOIS? > >> IP Prefix we have proceeded to execute our client?s request. > >> > >> On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder > >> of record for that ASN and have since learned that the customer?s use of > >> that ASN was erroneous and not permitted by SEACOM and immediate action > has > >> been taken to rectify this situation. > >> > >> IPDC would like to apologize for our lack of attention in conducting > >> thorough verification and wish to highlight that the involvement of > Cloud > >> Innovation Ltd in the entire process was providing the addresses to us > and > >> that we truly apologize as we understand that this incident may have > >> indirectly implicated Cloud Innovation Ltd. > >> > >> IPDC however, does not wish to disclose our client information and our > >> client information shall remain confidential under present > circumstances. > >> Once again, we apologize for our shortcomings. > >> > >> *Link Infinity:* > >> > >> To whom it may concern, > >> > >> We at HK Infinity International Ltd are a customer of Cloud Innovation > >> and in the course received rights to use 156.241.3.0/24 from them. > >> Beginning December, 2019, we delegated the right to announce this > prefix to > >> IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an > LOA > >> authorizing them to announce the space which was subsequently received. > >> IPDC subsequently and without our knowledge delegated this space to one > of > >> their customers and allowed them to originate it from AS37353. > >> > >> This announcement was not authorized by us, nor is it permitted by the > >> LOA provided by Cloud Innovation. > >> > >> Unfortunately, we were not aware of the situation until after it had > >> already been resolved. > >> > >> It was never our intent to violate the LOA or to allow the prefix to be > >> announced from a hijacked ASN. We do not condone this and apologize > >> sincerely to the community for what has happened here. > >> > >> Sincere Apologies, > >> > >> *Paul Wollner:* > >> > >> 8 May 2020 > >> > >> TO WHOM IT MAY CONCERN > >> > >> In the light of the recent email on NAPAfrica mailing list, I would just > >> like to clear the air. > >> > >> The IP route objects were created by myself for Cloud Innovation when > >> they signed up as a client of Macrolan ( now SEACOM) as they didn't have > >> their own AS. > >> > >> At the time I was working for Macrolan (now SEACOM). I left the > >> employment of SEACOM in October 2019. > >> > >> It appears that when Cloud Innovation's contract with SEACOM came to an > >> end, the route objects were never cleaned up. > >> > >> This occurred after I left SEACOM's employment. Since leaving, I have no > >> access to these objects. > >> > >> Regards > >> > >> Paul Wollner > >> 082-786-9776 > >> > >> On Fri, 8 May 2020 at 22:08, Mark Tinka wrote: > >> > >>> 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. > >>> _______________________________________________ > >>> Community-Discuss mailing list > >>> Community-Discuss at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/community-discuss > >>> > >> > >> > >> -- > >> -- > >> Kind regards. > >> Lu > >> > >> _______________________________________________ > >> Community-Discuss mailing list > >> Community-Discuss at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/community-discuss > >> > > _______________________________________________ > > Community-Discuss mailing list > > Community-Discuss at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > > > > _______________________________________________ > > Community-Discuss mailing list > > Community-Discuss at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/604d4eb2/attachment-0001.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: Screen Shot 2020-05-28 at 17.13.51 .png > Type: image/png > Size: 104109 bytes > Desc: not available > URL: < > https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/604d4eb2/attachment-0001.png > > > > ------------------------------ > > Message: 2 > Date: Fri, 29 May 2020 08:07:08 +0000 > From: Arnaud AMELINA > To: Owen DeLong > Cc: General Discussions of AFRINIC , > "rpd >> AfriNIC Resource Policy" > Subject: Re: [Community-Discuss] Cloud Innovation Displays Very Poor, > If Not Criminal, Netizenship > Message-ID: > 9O7-Hg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Owen, > I won?t respond to your intimidation but focus on the real technical > issues. See my response below inline > > Le ven. 29 mai 2020 ? 00:59, Owen DeLong a ?crit : > > > Arnaud, > > > > You are mistaken on a number of points. > > > > > > On May 28, 2020, at 13:05 , Arnaud AMELINA wrote: > > > > Hi, all communities > > > > It was said that the hijacking of AS37353 was a configuration mistake, > > coupled with poor oversight in checking the right to use of the ASN by a > > certain IPDC customer. > > > > It was also said that this would have been facilitated by old and stalled > > IRR objects from MacroLAN before the service contract ended in December > > 2019. > > > > It was also stated that the BGP announcement was stopped and some actions > > taken to delete the stalled routing registry object from IRR. > > > > > > Yes? The registry objects created by MacroLAN have been deleted. > > > > Below are some data which gives some extra information and confirm > > previous claim that this incident was not accidental. > > > > > > Below is some very redacted data which gives virtually no information. > > > > NB: All data are collected from their source, Today, 28 May 2020, at > 10:00 > > UTC. > > > > IRRs created in March 2020 with AS37353 as Origin for 156.241.3.0/24 by > > HGC > > > > $ whois -h whois.radb.net '156.241.3.0/24' > > > > route: 156.241.3.0/24 descr: Proxy-registered route object > > origin: AS37353 notify: matthew.chan at hgc.com.hk mnt-by: > > MAINT-HGC-INTL changed: matthew.chan at hgc.com.hk 20200304 source: > > RADB > > > > ===== > > route: 156.241.3.0/24 > > descr: Proxy-registered route object origin: AS37353 > > remarks: This is a HGC customer route-object > > remarks: which is being exported under this origin AS. > > remarks: > > remarks: This route object was created because no existing > > remarks: route object with the same origin was found. > > remarks: > > remarks: Please contact radb at hutchcity.com if you have any > > remarks: questions regarding this object. > > notify: radb at hutchcity.com > > mnt-by: MAINT-AS9304 > > changed: radb at hutchcity.com 20200304 > > source: NTTCOM > > ==== > > > > > > We haven changed anything, but here?s the full text of that whois > command: > > ... > > changed: admin at cloudix.online 20200511 #03:10:36Z > > source: RADB > > 0.000u 0.001s 0:00.19 0.0% 0+0k 0+0io 0pf+0w > > owen (122) ~ % > > 2020/05/28 16:58:53 > > > > Looks like there?s additional cruft left in some routing registries that > > we still haven?t removed. I?ve asked people to get on that. > > > > > Good.. this is the reason for my mail. > Draw attention on these route objects which should have never existed on > RADB and get them cleaned up by your customer who is the maintainer of the > route object as per the records. > > > > However, just because it?s in RADB doesn?t mean it?s advertised. > > > > The routing visibility I referred to was not because route objects are in > RADB or in NTT routing registries.. > > Even though the prefix is no longer seen in global routing table, it is > been seen by some route collectors. > > One route collector at RIPE Stat sees as shown in the picture as at now. > > [ picture] > And the ASPATH speaks for itself. > > > > Nonetheless, we are actively working to get those errant entries cleaned > > up. Thank you for bringing them to our attention. > > > > Please let the community know when everything is cleaned. > Thank you > > -- > Arnaud > > ... > > > _______________________________________________ > >> Community-Discuss mailing list > >> Community-Discuss at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/community-discuss > >> > > _______________________________________________ > > Community-Discuss mailing list > > Community-Discuss at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/288a5518/attachment.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: IMG_20200529_074734_512.jpg > Type: image/jpeg > Size: 62307 bytes > Desc: not available > URL: < > https://lists.afrinic.net/pipermail/community-discuss/attachments/20200529/288a5518/attachment.jpg > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Community-Discuss mailing list > Community-Discuss at afrinic.net > https://lists.afrinic.net/mailman/listinfo/community-discuss > > > ------------------------------ > > End of Community-Discuss Digest, Vol 620, Issue 2 > ************************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Fri May 29 14:13:23 2020 From: comms at afrinic.net (AFRINIC Communication) Date: Fri, 29 May 2020 18:13:23 +0400 Subject: [Community-Discuss] Website outage report Message-ID: [French, Portuguese and Arabic versions below] Dear Colleagues, On May 28, AFRINIC experienced a partial service outage for its Web (http) service. For clarity, AFRINIC hosts redundant infrastructure at two datacentres in Johannesburg, South Africa. These are fully redundant, and are meant to operate in concert with each other or as part of normal network operations. They can also operate independently. We were notified of scheduled emergency maintenace at one of these sites. Our team made an assessment of the risks involved, and concluded that this would be catered for within our resliency plan. The expected maintenace was meant to run from 18:00 to 22:00 UTC. However, around 18:50 UTC, the NOC team started getting alerts that the Web service was unavailable. Working from these alarms, and with industry friends from various vantage points, we determined that there appeared to be a localised routing issue getting to services at one of the datacentres. Unfortuantely, this meant that our primary website - https://www.afrinic.net - was unavailable during this time, depending on which location (datacentre) you were routed to. Full service availability was restored at 21:33:21 UTC. Our website is usually the first port of call for people seeking information or clarification on any issue. So we recognise the seriousness of this outage, and are working hard to not just remedy the issue that caused this but also to improve our monitoring and visibility for these types of faults. Notably, from our testing, and reports that we received from the field, RPKI, DNS and WHOIS services were functional during the period of the Web service unavailability. Over the next few weeks, we intend to implement additional service instances and checks that we believe will resolve any problems. Meanwhile, we sincerely apologise for any inconvenience caused. AFRINIC ??????????????. Chers coll?gues, Le 28 mai, l'AFRINIC a connu une panne partielle de son service Web (http). Pour plus de clart?, l'AFRINIC h?berge une infrastructure redondante dans deux centres de donn?es ? Johannesburg, et en Afrique du Sud. Ces centres sont enti?rement redondants et sont cens?s fonctionner de concert ou dans le cadre de l'exploitation normale du r?seau. Ils peuvent ?galement fonctionner de mani?re ind?pendante. Nous avons ?t? inform?s de la maintenance d'urgence pr?vue sur l'un de ces sites. Notre ?quipe a proc?d? ? une ?valuation des risques encourus et en a conclu que notre plan de secours en tiendrait compte. La maintenance pr?vue devait se d?rouler de 18h00 ? 22h00 UTC. Cependant, vers 18h50 UTC, l'?quipe du NOC a commenc? ? recevoir des alertes indiquant que le service Web n'?tait pas disponible. En travaillant ? partir de ces alertes, et avec des amis de l'industrie de diff?rents secteurs, nous avons d?termin? qu'il semblait y avoir un probl?me de routage localis? pour acc?der aux services d'un des centres de donn?es. Malheureusement, cela signifiait que notre site web principal - https://www.afrinic.net - ?tait indisponible pendant cette p?riode, selon l'endroit (centre de donn?es) vers lequel vous ?tiez dirig?. La disponibilit? totale du service a ?t? r?tablie ? 21:33:21 UTC. Notre site web est g?n?ralement le premier point de contact pour les personnes qui cherchent des informations ou des ?claircissements sur un sujet quelconque. Nous sommes donc conscients de la gravit? de cette panne et nous nous effor?ons non seulement de rem?dier au probl?me qui en est ? l'origine, mais aussi d'am?liorer notre surveillance et notre visibilit? pour ce type de d?fauts. Notamment, d'apr?s nos tests et les rapports que nous avons re?us du terrain, les services RPKI, DNS et WHOIS ?taient fonctionnels pendant la p?riode d'indisponibilit? du service Web. Au cours des prochaines semaines, nous avons l'intention de mettre en ?uvre des instances de service et des contr?les suppl?mentaires qui, selon nous, r?soudront les probl?mes ?ventuels. En attendant, nous nous excusons sinc?rement pour les d?sagr?ments caus?s. AFRINIC ??????.. Em 28 de Maio, a AFRINIC sofreu uma interrup??o parcial do seu servi?o Web (http). Para maior clareza, a AFRINIC acolhe infra-estruturas redundantes em dois centros de dados em Joanesburgo, na ?frica do Sul. Estes s?o totalmente redundantes e destinam-se a funcionar em concerta??o entre si ou como parte de opera??es de rede normais. Podem tamb?m funcionar de forma independente. Fomos notificados de uma manuten??o de emerg?ncia programada num desses locais. A nossa equipa procedeu a uma avalia??o dos riscos envolvidos e concluiu que esta seria contemplada no ?mbito do nosso plano de resili?ncia. A manuten??o prevista deveria decorrer entre as 18:00 e as 22:00 UTC. No entanto, por volta das 18:50 UTC, a equipa NOC come?ou a receber alertas de que o servi?o Web n?o estava dispon?vel. Trabalhando a partir destes alarmes, e com amigos da ind?stria de v?rios pontos de vista, determin?mos que parecia haver um problema de encaminhamento localizado para chegar aos servi?os num dos centros de dados. Infelizmente, isto significava que o nosso website principal - https://www.afrinic.net - n?o estava dispon?vel durante este tempo, dependendo da localiza??o (datacenter) para onde era encaminhado. A disponibilidade total do servi?o foi restaurada ?s 21:33:21 UTC. O nosso website ? normalmente o primeiro porto de escala para pessoas que procuram informa??es ou esclarecimentos sobre qualquer assunto. Por isso, reconhecemos a gravidade desta falha e estamos a trabalhar arduamente n?o s? para resolver o problema que a causou, mas tamb?m para melhorar a nossa monitoriza??o e visibilidade para este tipo de falhas. Nomeadamente, os nossos testes e relat?rios que recebemos do terreno, RPKI, DNS e servi?os WHOIS estiveram funcionais durante o per?odo de indisponibilidade do servi?o Web. Ao longo das pr?ximas semanas, pretendemos implementar inst?ncias de servi?o adicionais e verifica??es que acreditamos ir?o resolver quaisquer problemas. Entretanto, pedimos as nossas sinceras desculpas por qualquer inconveniente causado. AFRINIC ?????????.. ???? ??????? ??? 28 ???? ?????? ???? ????? ????? (http) ???????? ?????? ??????? ???? ????? ???????? ?? ????? ????? ???????????? ???? ???????. ????? ??? ??????? ???????? ????? ??? ???????? ?? ??????? ???????? ? ??? ???? ???? ??????? ???? ????? ?? ??????? ?????? ????? ??????? ???? ???????? ????? ???? ????? ?????? ??????? ???????? ??? ???? . ????? ??? ??? ???? ????? ??? ?????? ??? ?? ???? ??? ?????????? ?????? ?????? ???????. ??? ?? ??????? ?? ??? ??????? ??????? ?? ?????? ?? 18:00 ??? 22:00 ???????? ??????? ?????? UTC ?? ????? ?????? 18:50 ???????? ??????? ??????? ??? ?????? ??????? ?? ??????? NOC ??????? ??????? ??? ???? ????? ??? ??????. ?? ???? ????? ??? ????? ????? ??????? ?????????? ??????? ?????? ???????? ?? ????? ???? ??? ???? ????? ??????? ??????? ?????? ??? ??????? ???? ????? ???????. ????? ??? ??? ???? ??????? ?????? ??? ???? ??????? ?????????? https://www.afrinic.net ???? ??????? ??? ?????? (???? ???????) ???? ??? ?????? ????. ?? ?? ??????? ????? ?????? ??????????? ?????? 21:33:21 ???????? ??????? ?????? UTC ??? ???? ?? ?????? ?????????? ?? ????? ?????? ???????? ?????? ????? ??????? ????? ?? ???? ???? ?????. ???? ??? ???? ????? ??? ????????? ????? ?????? ??? ??? ??????? ??????? ???? ????? ?? ???? ???? ???? ?????? ????? ????? ?????????? ?? ???????. ????? ??????? ??? ?? ????? RPKI ?DNS ?WHOIS ?? ???? ?????????? ????????? ???? ???????? ?? ??????? ???? ???? ???? ???? ??? ???? ???? ?????. ???? ??? ???????? ??????? ???????? ???? ??? ????? ????? ???? ?????? ?????? ????? ???? ?????? ?? ?? ??? ???????. ??? ????? ???? ?? ?? ????? ??? ??????????... -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Fri May 29 23:41:20 2020 From: noah at neo.co.tz (Noah) Date: Sat, 30 May 2020 02:41:20 +0300 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: <353A9A34-D8DB-403D-BDF8-780E364E1E8D@gmail.com> References: <353A9A34-D8DB-403D-BDF8-780E364E1E8D@gmail.com> Message-ID: Hi Taiwo, On Fri, May 29, 2020 at 11:46 AM Taiwo Oyewande wrote: > Good day, > I agree with Paul here. In this entire matter, the authors have blamed the > wrong party - i think it should be a SEACOM issue in the first place. This > makes me wonder -why did the authors put the blame on Cloud Innovation? So if you cared to really read the original email, you would have realized that the issue that was reported involved an incident where SEACOM's AS37353 was being used by a network in Manila to announce an IPv4 prefix 156.241.3.0/24 that forms part of the IPv4 address blocks assigned to Cloud Innovation Ltd by AfriNIC. Therefore it's safe to say that as per the RIR database entries, Cloud Innovation Ltd is responsible for the prefix as guided by AfriNIC's CPM and their multiple customers whom they delegate (sub-allocate) to the same prefix. As such, its widely well know that the best standard practice within the Internet community dictates that any internet number resources abuse issues and/or common routing threats concerned with a prefix would attract the attention of the LIR the prefix was assigned too by AfriNIC and in this case, Cloud Innovation Ltd, which is bestowed with that responsibility, which is why among the documents folks from Cloud Innovation Ltd shared with the Internet community in their apology as pertains to this incident, were attachments of some LOA (Letters of Authorization) in reference to their customers IPDC and HongKong Link Infinity Technology Ltd who were " delegated" the same prefix by their LIR Cloud Innovation Ltd. Word is that one of them mistakenly announced the prefix using SEACOM's AS37353 instead of the ASN they had been advised to use in the LOA provided to them by Cloud Innovation Ltd. The Issue then becomes that; "if the LOA clearly informs you to use AS134190 and in your bgp configuration you take it upon yourself to use AS37353 instead", then that becomes very doggy for some customer in Manila who has nothing to do with AS37353. BGP configurations are done by conscious humans manually and sometimes through careful automation. Cloud Innovation Ltd was put to task and the issue was resolved immediately and I hope by now you get the idea why they became a party of interest as far as fixing this issue was concerned for the best interest of a secure Internet and routing norms. ------------------------ Hi Ubah, On Fri, May 29, 2020 at 4:37 PM Anthony Ubah wrote: > Hi Paul, > > 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. > It's not SEACOM's problem at all and I will explain why. So in turns out that on *4th March 2020* just over two months ago, the same customer of Cloud Innovation Ltd, that is HongKong Link Infinity Technology Ltd created a route object for the same prefix 156.241.3.0/24 on the RADB IRR and then associated the prefix with SEACOM AS37353 again. This action was not authorized by SEACOM for the record. A good member of the Internet community shared some data to the above effect on a previous thread earlier. A renowned patron of Cloud Innovation Ltd responded acknowledging the fact which also shared more data which contained exactly the issue that was being pointed out and he thanked the good member for pointing this out to Cloud Innovation Ltd. He asked his people to get on the issue and immediately fix the issue and when you look at the current RADB entry, of the said prefix, you will realise that the issue has been fixed as the route object was deleted with immediate effect. > > From whatever perspective the onus is on SEACOM and IPDC. > I beg to correct you that for this particular case the issue was a conscious and deliberate creation of a route object for the prefix 156.241.3.0/24 that belongs to Cloud Innovation Limited by their customer HongKong Link Infinity Technology Ltd on *4th March 2020* and associated it with SEACOM ASN again. Neither of them was a SEACOM customer at the time of creation of this route object and the real change like I said was done on 2020-03-04 by one Matthew Chan under MNT-BY: MAINT-HGC-INTL. $ whois -h whois.radb.net '156.241.3.0/24' route: 156.241.3.0/24 descr: Proxy-registered route object*origin: AS37353* notify: matthew.chan at hgc.com.hk mnt-by: MAINT-HGC-INTL*changed: matthew.chan at hgc.com.hk 20200304* source: RADB NOTE: The good news is that, after the issue was raised by the good members of the internet community, the object above has since been deleted and removed by those who had created it as per link below. https://www.radb.net/query?advanced_query=1&keywords=156.241.3.0%2F24&-T+option=&ip_option=&-i+option PS: ASN hijacks happen often across the Internet and even though projects like MANRS offers some mechanism for a fix (and in this case as relates to apparent bgp miss configurations by some IPDC customer or unauthorized IRR database entries by HongKong Link Infinity Ltd), more than anything is often the *open* and *transparent* calling out of parties involved in the abuses related to *routing threats* that ensure the continued mutual functioning of a *healthy global internet*. SEACOM ensures to play its part for the best interest of the Internet and like Mark said, today it is SEACOM tomorrow it can be some other network. I hope I have endeavoured to clarify to you both and that you realize that the responsibility is with all of us to collectively ensure a safe and secure Internet and those involved in abuses are held accountable. Cheers, Noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat May 30 01:24:28 2020 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2020 18:24:28 -0700 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: <566F84E8-2749-4A44-8324-381E95EE6555@delong.com> Arnaud, I am not sure what you mean by intimidation. I have no intent to intimidate anyone. I merely point out the areas where you are mistaken in your statements and your accusation. > Even though the prefix is no longer seen in global routing table, it is been seen by some route collectors. > > One route collector at RIPE Stat sees as shown in the picture as at now. Yes? Route collectors keep route data for a long time after the routes are withdrawn, especially if they do not get replaced with a conflicting announcement for the same prefix. That is the case here. The route hasn?t been present on any router for months. You are looking at historical data and acting like it is current data. > > [ picture] > And the ASPATH speaks for itself. Yes, that was the errant AS PATH months ago when the prefix was last announced. LOOK AT the BGPLAY link I sent. Even RIPE database shows that the data is historical and not current. > > Nonetheless, we are actively working to get those errant entries cleaned up. Thank you for bringing them to our attention. > > Please let the community know when everything is cleaned. > Thank you Everything we can control has been cleaned. Seem my reply to Noah which will be next. Owen > > -- > Arnaud > > ... >> _______________________________________________ >> Community-Discuss mailing list >> Community-Discuss at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/community-discuss >> _______________________________________________ >> Community-Discuss mailing list >> Community-Discuss at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/community-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Sat May 30 01:48:36 2020 From: owen at delong.com (Owen DeLong) Date: Fri, 29 May 2020 18:48:36 -0700 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: References: Message-ID: <1AFBD8E1-8254-4E3C-B667-A3C18F8D016D@delong.com> Since this is discussion about non-policy matters, I have trimmed rpd from the list of recipients. You are mistaking ?Changed? for ?Created?. Further, that is an entry not created by Larus, but by HGC. The contract with IPDC and Larus for the PREFIX was in effect in March. It appears that the IRR entry was created by HGC in response to request from a customer of IPDC who was a customer of Larus. That entry was not created by Seacom and was not authorized by Seacom OR Larus. The following entries were created by Larus (Note they do not contain AS37353): route: 156.241.3.0/24 origin: AS134190 descr: IPDC Solution PteLtd mnt-by: MAINT-LARUS changed: t.t.xu at laruscloudservice.net 20200508 #10:43:19Z source: RADB The following entries were created by unknown third parties ? Neither Larus nor Seacom have any actual control over them: route: 156.241.3.0/24 origin: AS138145 descr: Customer-AS45250 admin-c: MAINT-AS138145 tech-c: MAINT-AS138145 mnt-by: MAINT-AS138145 changed: admin at cloudix.online 20200512 #18:26:20Z source: RADB route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS37353 notify: matthew.chan at hgc.com.hk mnt-by: MAINT-HGC-INTL changed: matthew.chan at hgc.com.hk 20200304 source: RADB route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS134548 notify: radb at hgcbroadband.com mnt-by: MAINT-AS9304 changed: radb at hgcbroadband.com 20191003 source: RADB route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS37353 remarks: This is a HGC customer route-object remarks: which is being exported under this origin AS. remarks: remarks: This route object was created because no existing remarks: route object with the same origin was found. remarks: remarks: Please contact radb at hutchcity.com if you have any remarks: questions regarding this object. notify: radb at hutchcity.com mnt-by: MAINT-AS9304 changed: radb at hutchcity.com 20200304 source: NTTCOM route: 156.241.3.0/24 descr: Proxy-registered route object origin: AS134548 remarks: This is a HGC customer route-object remarks: which is being exported under this origin AS. remarks: remarks: This route object was created because no existing remarks: route object with the same origin was found. remarks: remarks: Please contact radb at hgcbroadband.com if you have any remarks: questions regarding this object. notify: radb at hgcbroadband.com mnt-by: MAINT-AS9304 changed: radb at hgcbroadband.com 20191003 source: NTTCOM mntner: MAINT-AS138145 descr: Advanced Information Co., Ltd. admin-c: ADVANCED-APNIC tech-c: ADVANCED-APNIC upd-to: noc at cloudix.online mnt-nfy: noc at cloudix.online auth: CRYPT-PW HIDDENCRYPTPW # notify: noc at cloudix.online mnt-by: MAINT-AS138145 changed: admin at cloudix.online 20200511 #03:10:36Z source: RADB The following entries were created by a company acquired by Seacom ? the failure to delete them falls on Seacom: Historically: route: 156.241.0.0/16 origin: AS37353 mnt-by: paulwollner mnt-by: hk-larus-1-mnt created: 2017-08-07T12:27:22Z last-modified: 2018-09-04T18:54:09Z source: RIPE-NONAUTH remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** I have arranged for the prefix to be re-announced from a different ASN which will hopefully clear out the stale route collector data that Arnaud is so fond of pretending represents current information. Owen > On May 29, 2020, at 02:33 , Noah wrote: > > Paul, > > On Fri, May 29, 2020 at 6:22 AM Paul Wollner > wrote: > > I feel that SEACOM neglected their duty to remove these objects when the client's contract came to an end. As the ISP created the records in the first place, the records should have been updated or deleted by them too. > > From the data posted by Arnaud and Owen, the route object records for the Cloud Innovation Limited prefix156.241.3.0/24 in question are those created as recently as 4th March 2020 by Mattew Chan of HonKong Link Infinity Limited on the RADB IRR database using AS37353 again to originate the prefix. > > Surely, this does not look like a mistake if indeed the contract with the customer was terminated as far back as December 2020. > > > > > The route object as seen on the data presented by Arnaud and Owen has a change log that indicates " changed: matthew.chan at hgc.com.hk 20200304" > which means it was created on 04-03-2020 two months since December 2019. > > I believe Owen has indicated that he is following up the matter with their customer so that it's fixed and those records cleared from RADB. > > Cheers, > Noah > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: link infinity.png Type: image/png Size: 594197 bytes Desc: not available URL: From noah at neo.co.tz Sat May 30 08:14:06 2020 From: noah at neo.co.tz (Noah) Date: Sat, 30 May 2020 11:14:06 +0300 Subject: [Community-Discuss] Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship In-Reply-To: <1AFBD8E1-8254-4E3C-B667-A3C18F8D016D@delong.com> References: <1AFBD8E1-8254-4E3C-B667-A3C18F8D016D@delong.com> Message-ID: On Sat, 30 May 2020, 04:49 Owen DeLong, wrote: > > You are mistaking ?Changed? for ?Created?. > Owen really :-) in March 2020. I mean what was being changed? The prefix in question or ASN?. Below you say the contract was in effect in March and therefore I am assuming they Created the object in March hence the radb Changed log of 20200304. But HGC would ensure that a wrong ASN is not associated with the prefix or delete the object as it was done yesterday. > Further, that is an entry not created by Larus, but by HGC. > The contract with IPDC and Larus for the PREFIX was in effect in March. > Ok It appears that the IRR entry was created by HGC in response to request > from a customer of IPDC who was a customer of Larus. > So we can assume they then created the object in March. That entry was not created by Seacom and was not authorized by Seacom OR > Larus. > What is important is that the route object has now been removed. Cheers, Noah -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: link infinity.png Type: image/png Size: 594197 bytes Desc: not available URL: