<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
<div>Hello,<br></div><div>Very interesting question of 3 x /11 allocated to Cloud Innovations.<br></div><div><br></div><div>Regards,<br></div><div>Libren</div><div><br></div><div>-- <br></div><div> Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: <br></div><div> https://tutanota.com<br></div><div><br></div><div><br></div><div>May 25, 2020, 15:00 by community-discuss-request@afrinic.net:<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>Send Community-Discuss mailing list submissions to<br></div><div> community-discuss@afrinic.net<br></div><div><br></div><div>To subscribe or unsubscribe via the World Wide Web, visit<br></div><div> https://lists.afrinic.net/mailman/listinfo/community-discuss<br></div><div>or, via email, send a message with subject or body 'help' to<br></div><div> community-discuss-request@afrinic.net<br></div><div><br></div><div>You can reach the person managing the list at<br></div><div> community-discuss-owner@afrinic.net<br></div><div><br></div><div>When replying, please edit your Subject line so it is more specific<br></div><div>than "Re: Contents of Community-Discuss digest..."<br></div><div><br></div><div><br></div><div>Today's Topics:<br></div><div><br></div><div> 1. Re: [rpd] Cloud Innovation Displays Very Poor,  If Not<br></div><div> Criminal, Netizenship (Arnaud AMELINA)<br></div><div> 2. Re: [rpd] Cloud Innovation Displays Very Poor,       If Not<br></div><div> Criminal, Netizenship (ABDULKARIM AYOPO OLOYEDE)<br></div><div><br></div><div><br></div><div>----------------------------------------------------------------------<br></div><div><br></div><div>Message: 1<br></div><div>Date: Mon, 25 May 2020 01:28:10 +0000<br></div><div>From: Arnaud AMELINA <amelnaud@gmail.com><br></div><div>To: Gregoire EHOUMI <gregoire.ehoumi@yahoo.fr><br></div><div>Cc: General Discussions of AFRINIC <community-discuss@afrinic.net>,<br></div><div> "rpd@afrinic.net >> AfriNIC Resource Policy Discussion List"<br></div><div> <rpd@afrinic.net><br></div><div>Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very<br></div><div> Poor,  If Not Criminal, Netizenship<br></div><div>Message-ID:<br></div><div> <CAGDMR_dkEAS42m8g19EqhSwVEjZeabysbVR+TOz9-UeMHpC7kQ@mail.gmail.com><br></div><div>Content-Type: text/plain; charset="utf-8"<br></div><div><br></div><div>Hello, community<br></div><div><br></div><div>+1 @Gregoire and @Mark Tinka<br></div><div><br></div><div>*cloud innovation*  were allocated  *big bunch of IPv4* space as a *LIR*<br></div><div>with *no ASN*. Interesting, and no *v6*<br></div><div><br></div><div>While the bylaws defines LIR as followed:<br></div><div>++++++<br></div><div>Local Internet Registry (LIR):<br></div><div>any Network Operator that provides Internet services to distinct end-users<br></div><div>and end-sites<br></div><div>++++++<br></div><div><br></div><div>I wonder  which network does cloud innovation operate and which internet<br></div><div>services it provides to end-users and end-sites in *Africa*.<br></div><div><br></div><div>How does this network *managing 3 x /11 of IPv4* *operate*?<br></div><div><br></div><div>There is something here for the community to learn about.<br></div><div><br></div><div>Regards<br></div><div><br></div><div>--<br></div><div>Arnaud<br></div><div><br></div><div>Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD <rpd@afrinic.net> a<br></div><div>?crit :<br></div><blockquote><div>Hello,<br></div><div><br></div><div>Thanks Mark for exposing the details of the SEACOM AS37353 hijacking.<br></div><div><br></div><div>I carefully read your report and also the Cloud Innovation Limited quick<br></div><div>response including their attachments as justifications.<br></div><div><br></div><div>I note that;<br></div><div><br></div><div>? the service contract with Cloud Innovation covering the announcement of<br></div><div>their prefixes by SEACOM AS37353 was terminated  by SEACOM.<br></div><div><br></div><div>? some stale IRR route objects existed after termination of the contract.<br></div><div><br></div><div>? through some multiple layer distribution an organisation in Manila<br></div><div>Philippines was ?delegated? an IP block from Cloud Innovation address space.<br></div><div><br></div><div>? both upstream ISP and the customer in Manila set up a BGP session using<br></div><div>SEACOM's AS37353 as the ASN of the Manila customer.<br></div><div><br></div><div>? there was a prompt reaction from the involved parties that included<br></div><div>apologies to SEACOM and the wider internet community.<br></div><div><br></div><div>? there were promises from said parties to be a better netizen which would<br></div><div>mean, them not hijacking other networks ASN's.<br></div><div><br></div><div>? there was clear refusal to disclose the details of the customer in<br></div><div>Manila Philippines who hijacked the affected SEACOM ASN.<br></div><div><br></div><div>All put together, demonstrates that what happened was an impersonation and<br></div><div>not a BGP configuration error, nor an oversight in checking the right to<br></div><div>use of the SEACOM ASN.<br></div><div><br></div><div>1. Why is it that the real customer did not bother presenting its<br></div><div>apologies to the community<br></div><div><br></div><div>2. Why is there refusal to reveal customer?s details?<br></div><div><br></div><div>3. Why is it that the said prefix is no longer seen in the routing table<br></div><div>originated by the genius ASN or any other ASN?<br></div><div><br></div><div>4. Which networks were involved and what happened to the end users?<br></div><div><br></div><div>Can someone from AFRINIC explain what ?delegation of IP block? mean?<br></div><div><br></div><div>Note: The self organised Internet knows how to deal with bad net citizens.!<br></div><div><br></div><div>Best regards<br></div><div>Gregoire Ehoumi<br></div><div><br></div><div><br></div><div>-------- Original message --------<br></div><div>From: Lu Heng <h.lu@anytimechinese.com><br></div><div>Date: 2020-05-09 5:43 a.m. (GMT-05:00)<br></div><div>To: Mark Tinka <mark.tinka@seacom.mu><br></div><div>Cc: "rpd@afrinic.net >> AfriNIC Resource Policy Discussion List" <<br></div><div>rpd@afrinic.net><br></div><div>Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal,<br></div><div>Netizenship<br></div><div><br></div><div>To whom it may concern,<br></div><div><br></div><div>On May 8, Mark Think posted a claim to multiple lists that Cloud<br></div><div>Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud<br></div><div>Innovation) but rather belonged to Seacom through their acquisition of<br></div><div>MacroLAN.<br></div><div><br></div><div>While we regret this unfortunate incident, Mark?s claims that it was<br></div><div>criminal or bad netizenship on the part of Cloud Innovation is without<br></div><div>foundation and utterly incorrect.<br></div><div><br></div><div>As shown below in the attached document from Paul Wollner(Ex-CTO of<br></div><div>Macrolan who created IRR routes to allow Macrolan to announce Cloud<br></div><div>Innovation's prefix); letter from Link Infinity International Ltd. (Link<br></div><div>Infinity), A customer of Cloud Innovation; and attached LOA from LARUS<br></div><div>authorizing IPDC Solutions to announce the prefix with origin AS134190.<br></div><div>And a Letter from IPDC. This was an innocent mistake committed by third<br></div><div>parties and had nothing to do with any action by Cloud Innovation or LARUS.<br></div><div><br></div><div>Here?s what happened:<br></div><div><br></div><div>Cloud Innovation delegated a /24 to Link Infinity, an ISP in December 2019.<br></div><div><br></div><div><br></div><div>Link Infinity further delegated that same /24 to IPDC and asked Cloud<br></div><div>innovation to issue an LOA, which we did. The LOA specifically required<br></div><div>IPDC to use its own ASN to announce the space (AS134190).<br></div><div><br></div><div>IPDC subsequently authorized one of its customers to use the said prefix.<br></div><div><br></div><div><br></div><div>For reasons still unknown to Cloud Innovation, IPDC and their customer set<br></div><div>up a BGP session wherein their customer used AS37353 as the origin to<br></div><div>advertise prefix 156.241.3.0/24.<br></div><div><br></div><div><br></div><div>Upon discovering the announcement, rather than contact Cloud Innovation,<br></div><div>Mark contacted IPDC who provided him with an incomplete explanation blaming<br></div><div>their customer and Mark, not realizing that Cloud Innovation was not the<br></div><div>customer in question posted far and wide about the event. It is unclear to<br></div><div>us why he chose to do this rather than contact us to try and resolve the<br></div><div>issue.<br></div><div><br></div><div><br></div><div>A contributing factor to the erroneous BGP configuration by IPDC's<br></div><div>customer may have been data contained in some outdated IRR route objects<br></div><div>for 156.241.0.0/16 which have subsequently been deleted.<br></div><div><br></div><div>As soon as we became aware of the problem (via Mark?s email), we began to<br></div><div>investigate the situation. As soon as it was clear that this was the result<br></div><div>of third-party actions, we reached out to Mark privately to let him know<br></div><div>what we knew and that we were still investigating. We delayed making a<br></div><div>public statement in order to try and ascertain all of the facts of the<br></div><div>situation. We prefer not to make public statements based on incomplete<br></div><div>information.<br></div><div><br></div><div>We apologize to the community for our small part in this unfortunate<br></div><div>incident and assure you that we work very hard to remain good netizens and<br></div><div>will address any concerns promptly when they come to our attention.<br></div><div><br></div><div><br></div><div>Sincerely,<br></div><div><br></div><div>Lu Heng<br></div><div>CEO<br></div><div>Cloud Innovations<br></div><div><br></div><div>Attached:<br></div><div>1. Letter from Paul Wollner<br></div><div>2. Letter from Link Infinity<br></div><div>3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from<br></div><div>AS134190<br></div><div> 4.     Letter from IPDC<br></div><div><br></div><div>FYI: LARUS is proving IP management service for Cloud Innovation, while<br></div><div>LARUS is also providing IP management service to other third parties in all<br></div><div>regions, for full disclosure, LARUS and Cloud Innovation are headed by same<br></div><div>CEO.<br></div><div><br></div><div>Content of those letters have been posted here for your convince:<br></div><div><br></div><div>*IPDC:*<br></div><div><br></div><div>FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd]<br></div><div><br></div><div><br></div><div>IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and<br></div><div>over the course of our corporate relationship we were given the authority<br></div><div>to use address block 156.241.3.0/24 since 9th December 2019.<br></div><div><br></div><div><br></div><div>On 12th December 2019, we have delegated that address block to our client.<br></div><div>Following which our client further instructed us to announce the prefix<br></div><div>with AS37353. In good will after minimal verification through WHOIS? IP<br></div><div>Prefix we have proceeded to execute our client?s request.<br></div><div><br></div><div><br></div><div>On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder<br></div><div>of record for that ASN and have since learned that the customer?s use of<br></div><div>that ASN was erroneous and not permitted by SEACOM and immediate action has<br></div><div>been taken to rectify this situation.<br></div><div><br></div><div><br></div><div>IPDC would like to apologize for our lack of attention in conducting<br></div><div>thorough verification and wish to highlight that the involvement of Cloud<br></div><div>Innovation Ltd in the entire process was providing the addresses to us and<br></div><div>that we truly apologize as we understand that this incident may have<br></div><div>indirectly implicated Cloud Innovation Ltd.<br></div><div><br></div><div><br></div><div>IPDC however, does not wish to disclose our client information and our<br></div><div>client information shall remain confidential under present circumstances.<br></div><div>Once again, we apologize for our shortcomings.<br></div><div><br></div><div><br></div><div>*Link Infinity:*<br></div><div><br></div><div><br></div><div>To whom it may concern,<br></div><div><br></div><div>We at HK Infinity International Ltd are a customer of Cloud Innovation and<br></div><div>in the course received rights to use 156.241.3.0/24 from them. Beginning<br></div><div>December, 2019, we delegated the right to announce this prefix to IPDC<br></div><div>Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA<br></div><div>authorizing them to announce the space which was subsequently received.<br></div><div>IPDC subsequently and without our knowledge delegated this space to one of<br></div><div>their customers and allowed them to originate it from AS37353.<br></div><div><br></div><div>This announcement was not authorized by us, nor is it permitted by the LOA<br></div><div>provided by Cloud Innovation.<br></div><div><br></div><div>Unfortunately, we were not aware of the situation until after it had<br></div><div>already been resolved.<br></div><div><br></div><div>It was never our intent to violate the LOA or to allow the prefix to be<br></div><div>announced from a hijacked ASN. We do not condone this and apologize<br></div><div>sincerely to the community for what has happened here.<br></div><div><br></div><div>Sincere Apologies,<br></div><div><br></div><div><br></div><div>*Paul Wollner:*<br></div><div><br></div><div><br></div><div>8 May 2020<br></div><div><br></div><div>TO WHOM IT MAY CONCERN<br></div><div><br></div><div>In the light of the recent email on NAPAfrica mailing list, I would just<br></div><div>like to clear the air.<br></div><div><br></div><div><br></div><div>The IP route objects were created by myself for Cloud Innovation when they<br></div><div>signed up as a client of Macrolan ( now SEACOM) as they didn't have their<br></div><div>own AS.<br></div><div><br></div><div>At the time I was working for Macrolan (now SEACOM). I left the employment<br></div><div>of SEACOM in October 2019.<br></div><div><br></div><div>It appears that when Cloud Innovation's contract with SEACOM came to an<br></div><div>end, the route objects were never cleaned up.<br></div><div><br></div><div>This occurred after I left SEACOM's employment. Since leaving, I have no<br></div><div>access to these objects.<br></div><div><br></div><div>Regards<br></div><div><br></div><div>Paul Wollner<br></div><div>082-786-9776<br></div><div><br></div><div><br></div><div><br></div><div>On Fri, 8 May 2020 at 22:10, Mark Tinka <mark.tinka@seacom.mu> wrote:<br></div><blockquote><div>Hi all.<br></div><div><br></div><div>I'm not one to b**ch & moan in public, but per subject, I could not let<br></div><div>this one slide.<br></div><div><br></div><div>And if you get this from multiple mailing lists, apologies for that - I'm<br></div><div>just trying to make sure that this reaches as wide an audience as possible,<br></div><div>on the continent.<br></div><div><br></div><div>SEACOM (AS37100) acquired MacroLan (AS37353) a couple of years ago.<br></div><div>MacroLan is now part of the SEACOM family, and while we are in the process<br></div><div>of integrating that network into AS37100, some existing services continue<br></div><div>to be delivered on AS37353 until that exercise is completed.<br></div><div><br></div><div>One of the customers that AS37353 was providing services to was Cloud<br></div><div>Innovation, in Cape Town. From a routing perspective, because Cloud<br></div><div>Innovation had no AS number for this service, all of their IP address space<br></div><div>was being originated by AS37353, on their behalf.<br></div><div><br></div><div>In December of 2019, AS37353 ceased providing services to Cloud<br></div><div>Innovation. That is 6 months ago.<br></div><div><br></div><div>In recent days, it came to SEACOM's attention that some of Cloud<br></div><div>Innovation's IP address space was being originated by AS37353 -<br></div><div>specifically, 156.241.3.0/24 - even though we were sure that they were<br></div><div>no longer a customer of AS37353 since December of 2019. At first, we<br></div><div>thought this was a cached entry in a number of popular looking glasses, but<br></div><div>then every looking glass had the same entry, which made this an unlikely<br></div><div>bug.<br></div><div><br></div><div>As of yesterday afternoon, see below what Telia's looking glass was<br></div><div>saying about this prefix:<br></div><div><br></div><div>*****<br></div><div><br></div><div>Path #1: Received by speaker 0<br></div><div> 4809 134190 37353<br></div><div> 2.255.249.42 (metric 2134) from 2.255.253.101 (80.91.242.40)<br></div><div> Origin incomplete, localpref 200, valid, internal, best,<br></div><div>group-best, import-candidate<br></div><div>Communities:<br></div><div><br></div><div>1299:431<br></div><div> (RPKI state Unknown)<br></div><div><br></div><div>1299:1000 1299:30000 1299:30600 23456:20413 45352:4500 45352:9204<br></div><div><br></div><div>*****<br></div><div><br></div><div>But when I run a traceroute from my house to that prefix, it clearly was<br></div><div>not ending up in Cape Town, where AS37353's main operation resides:<br></div><div><br></div><div>*****<br></div><div><br></div><div>MacBook-Pro-7:~ tinka$ traceroute -I 156.241.3.1<br></div><div>traceroute to 156.241.3.1 (156.241.3.1), 64 hops max, 72 byte packets<br></div><div> 1  172.16.0.254 (172.16.0.254)  14.824 ms  11.522 ms  3.525 ms<br></div><div> 2  xe-1-3-0-1064.er-01-jnb.za.seacomnet.com (105.22.37.13)  5.620 ms<br></div><div>9.714 ms  9.887 ms<br></div><div> 3  ce-0-2-0-0.cr-02-jnb.za.seacomnet.com (105.16.28.2)  175.232 ms<br></div><div>172.699 ms  175.896 ms<br></div><div> 4  xe-0-0-0-8.cr-02-cpt.za.seacomnet.com (105.16.9.182)  164.496 ms<br></div><div>163.578 ms  163.546 ms<br></div><div> 5  105.16.14.153 (105.16.14.153)  169.812 ms  171.272 ms  177.115 ms<br></div><div> 6  xe-0-0-0-0.br-02-lhr.uk.seacomnet.com (105.16.34.253)  168.911 ms<br></div><div>172.958 ms  165.165 ms<br></div><div> 7  82.112.115.169 (82.112.115.169)  172.700 ms  176.482 ms  174.375 ms<br></div><div> 8  ae-17.r05.londen12.uk.bb.gin.ntt.net (129.250.2.147)  672.099 ms<br></div><div>613.617 ms  615.109 ms<br></div><div> 9  ae-2.r24.londen12.uk.bb.gin.ntt.net (129.250.4.244)  181.952 ms<br></div><div>183.087 ms  187.302 ms<br></div><div>10  ae-16.r20.frnkge13.de.bb.gin.ntt.net (129.250.3.13)  190.511 ms<br></div><div>185.579 ms  187.058 ms<br></div><div>11  ae-3.r20.sngpsi07.sg.bb.gin.ntt.net (129.250.4.17)  520.882 ms<br></div><div>613.982 ms  615.275 ms<br></div><div>12  ae-9.r24.tkokhk01.hk.bb.gin.ntt.net (129.250.7.67)  612.301 ms<br></div><div>586.886 ms  436.711 ms<br></div><div>13  ae-1.r03.tkokhk01.hk.bb.gin.ntt.net (129.250.6.98)  614.470 ms<br></div><div>613.416 ms  614.281 ms<br></div><div>14  ce-0-3-0-3.r03.tkokhk01.hk.ce.gin.ntt.net (203.131.241.126)  614.128<br></div><div>ms  613.661 ms  615.416 ms<br></div><div>15  * *     *<br></div><div>16  * * *<br></div><div>17  156.241.3.1 (156.241.3.1)  494.400 ms  410.180 ms *<br></div><div>MacBook-Pro-7:~ tinka$<br></div><div><br></div><div>*****<br></div><div><br></div><div>So we, then, realized that this was a fraudulent use of MacroLan's<br></div><div>AS37353, to which we had given no express permission.<br></div><div><br></div><div>As luck would have it, due to my days living and working in Malaysia, I<br></div><div>know the good folk that operate AS134190 (IPDC Solutions), who was the<br></div><div>upstream providing transit for this prefix. So I rang them up yesterday<br></div><div>afternoon, told them what was happening, and within the hour, they got that<br></div><div>eBGP session shutdown. I am most grateful to them for their quick response<br></div><div>and immediate understanding of what was going on. Even with all the<br></div><div>technology we have today, it, many times, comes down to having good friends<br></div><div>in good places.<br></div><div><br></div><div>Anyway, it turns out the ISP that had acquired this prefix from Cloud<br></div><div>Innovation is based in Manila, Philippines. When IPDC delivered their<br></div><div>transit service to them in Manila, that ISP informed them that they should<br></div><div>use AS37353 for the eBGP session. Yes, one could argue that IPDC should<br></div><div>have done their checks to ensure that the AS number being provided by their<br></div><div>customer belongs to them, but to be honest, I'm not too bothered about that<br></div><div>compared to Cloud Innovation's thinking that it was okay to use another<br></div><div>network's AS number in order to deliver their services to their customers.<br></div><div><br></div><div>IPDC confirm that this service was activated for the Manila ISP in<br></div><div>December of 2019, right around the time Cloud Innovation's service with<br></div><div>SEACOM, in Cape Town, ended.<br></div><div><br></div><div>As it currently stands, the ISP in Manila is now off the Internet, with<br></div><div>some 12 paying customers currently without service. Their excuse - they do<br></div><div>not have an AS number of their own.<br></div><div><br></div><div>IPDC tried to find out why the ISP in Manila thought that it was okay to<br></div><div>use another network's AS number for their service, and as it turns out, the<br></div><div>network engineer at the Manila ISP that set this up has since left the<br></div><div>company. All the ones currently there do not have any history about all of<br></div><div>this.<br></div><div><br></div><div>Currently, 156.241.3.0/24 is not in the global BGP table:<br></div><div><br></div><div>*****<br></div><div><br></div><div>lg-01-ams.nl>sh ip bgp 156.241.3.0/24<br></div><div>% Network not in table<br></div><div>lg-01-ams.nl><br></div><div><br></div><div>lg-01-nbo.ke>sh ip bgp 156.241.3.0/24<br></div><div>% Network not in table<br></div><div>lg-01-nbo.ke><br></div><div><br></div><div>lg-01-cpt.za>sh ip bgp 156.241.3.0/24<br></div><div>% Network not in table<br></div><div>lg-01-cpt.za><br></div><div><br></div><div>*****<br></div><div><br></div><div>That Cloud Innovation thought it was okay for them to use MacroLan's AS<br></div><div>number to originate their own prefixes into the global BGP is as morally<br></div><div>reprehensible as it is technologically distasteful.<br></div><div><br></div><div>SEACOM have been working very closely with AFRINIC to delete previous<br></div><div>route objects from their IRR that certify a relationship between Cloud<br></div><div>Innovation's parent /16 aggregates that cover this prefix, and AS37353, but<br></div><div>this is one of those objects that cannot be removed via the MyAFRINIC<br></div><div>portal, and requires manual intervention from AFRINIC.<br></div><div><br></div><div>I have not, personally, spoken to the proprietors of Cloud Innovation<br></div><div>and/or Outside Heaven, as I don't see how anything could explain this with<br></div><div>any degree of justification.<br></div><div><br></div><div>For now, I will find some beer to wipe the foul taste from my mouth,<br></div><div>while we (SEACOM) consider what to do about this.<br></div><div><br></div><div>And yes, for those who are wondering, RPKI's ROV would not have prevented<br></div><div>this, in its current form. This is AS hijacking, and ROV, today, tries to<br></div><div>solve the prefix-hijacking problem, first.<br></div><div><br></div><div>Thank you for your attention.<br></div><div><br></div><div>Mark.<br></div><div>_______________________________________________<br></div><div>RPD mailing list<br></div><div>RPD@afrinic.net<br></div><div>https://lists.afrinic.net/mailman/listinfo/rpd<br></div></blockquote><div><br></div><div><br></div><div>--<br></div><div>--<br></div><div>Kind regards.<br></div><div>Lu<br></div><div><br></div><div>_______________________________________________<br></div><div>RPD mailing list<br></div><div>RPD@afrinic.net<br></div><div>https://lists.afrinic.net/mailman/listinfo/rpd<br></div></blockquote><div>-------------- next part --------------<br></div><div>An HTML attachment was scrubbed...<br></div><div>URL: <https://lists.afrinic.net/pipermail/community-discuss/attachments/20200525/9e76e35e/attachment-0001.html><br></div><div><br></div><div>------------------------------<br></div><div><br></div><div>Message: 2<br></div><div>Date: Mon, 25 May 2020 13:00:22 +0100<br></div><div>From: ABDULKARIM AYOPO OLOYEDE <oloyede.aa@unilorin.edu.ng><br></div><div>To: Paschal Ochang <pascosoft@gmail.com><br></div><div>Cc: General Discussions of AFRINIC <community-discuss@afrinic.net>,<br></div><div> "rpd >> AfriNIC Resource Policy" <rpd@afrinic.net><br></div><div>Subject: Re: [Community-Discuss] [rpd] Cloud Innovation Displays Very<br></div><div> Poor,        If Not Criminal, Netizenship<br></div><div>Message-ID:<br></div><div> <CAES4e9no009Fxr7+LbpsmAfEzN7GQrtm-oqcvaDBvmDwwMcwRw@mail.gmail.com><br></div><div>Content-Type: text/plain; charset="utf-8"<br></div><div><br></div><div>Dear All,<br></div><div>Please let us all be reminded that this mailing list is to discuss<br></div><div>policies and directly related issues.<br></div><div>There are other mailing lists where issues like this can be discussed but<br></div><div>definitely not here because the issue is  *out of scope* for this mailing<br></div><div>list<br></div><div>Please, Co-Chairs would like us to put an end to this discussion.<br></div><div><br></div><div>CO-Chairs<br></div><div>PDWG<br></div><div><br></div><div><br></div><div>On Mon, May 25, 2020 at 12:31 PM Paschal Ochang <pascosoft@gmail.com> wrote:<br></div><blockquote><div>This sounds like a personal attack in my opinion instead of a justified<br></div><div>accusation. Why is this topic allowed to be discussed here when it?s rather<br></div><div>irrelevant?. The parties involved have tendered formal apologies as<br></div><div>reflected in their letters which is a sign of admittance and promotes the<br></div><div>intent of good netizenship. It?s just irrelevant.<br></div><div><br></div><div>On Monday, May 25, 2020, Arnaud AMELINA <amelnaud@gmail.com> wrote:<br></div><blockquote><div>Hello, community<br></div><div><br></div><div>+1 @Gregoire and @Mark Tinka<br></div><div><br></div><div>*cloud innovation*  were allocated  *big bunch of IPv4* space as a *LIR*<br></div><div>with *no ASN*. Interesting, and no *v6*<br></div><div><br></div><div>While the bylaws defines LIR as followed:<br></div><div>++++++<br></div><div>Local Internet Registry (LIR):<br></div><div>any Network Operator that provides Internet services to distinct<br></div><div>end-users and end-sites<br></div><div>++++++<br></div><div><br></div><div>I wonder  which network does cloud innovation operate and which internet<br></div><div>services it provides to end-users and end-sites in *Africa*.<br></div><div><br></div><div>How does this network *managing 3 x /11 of IPv4* *operate*?<br></div><div><br></div><div>There is something here for the community to learn about.<br></div><div><br></div><div>Regards<br></div><div><br></div><div>--<br></div><div>Arnaud<br></div><div><br></div><div>Le sam. 23 mai 2020 ? 14:20, Gregoire EHOUMI via RPD <rpd@afrinic.net> a<br></div><div>?crit :<br></div><blockquote><div>Hello,<br></div><div><br></div><div>Thanks Mark for exposing the details of the SEACOM AS37353 hijacking.<br></div><div><br></div><div>I carefully read your report and also the Cloud Innovation Limited quick<br></div><div>response including their attachments as justifications.<br></div><div><br></div><div>I note that;<br></div><div><br></div><div>? the service contract with Cloud Innovation covering the announcement<br></div><div>of their prefixes by SEACOM AS37353 was terminated  by SEACOM.<br></div><div><br></div><div>? some stale IRR route objects existed after termination of the contract.<br></div><div><br></div><div>? through some multiple layer distribution an organisation in Manila<br></div><div>Philippines was ?delegated? an IP block from Cloud Innovation address space.<br></div><div><br></div><div>? both upstream ISP and the customer in Manila set up a BGP session<br></div><div>using SEACOM's AS37353 as the ASN of the Manila customer.<br></div><div><br></div><div>? there was a prompt reaction from the involved parties that included<br></div><div>apologies to SEACOM and the wider internet community.<br></div><div><br></div><div>? there were promises from said parties to be a better netizen which<br></div><div>would mean, them not hijacking other networks ASN's.<br></div><div><br></div><div>? there was clear refusal to disclose the details of the customer in<br></div><div>Manila Philippines who hijacked the affected SEACOM ASN.<br></div><div><br></div><div>All put together, demonstrates that what happened was an impersonation<br></div><div>and not a BGP configuration error, nor an oversight in checking the right<br></div><div>to use of the SEACOM ASN.<br></div><div><br></div><div>1. Why is it that the real customer did not bother presenting its<br></div><div>apologies to the community<br></div><div><br></div><div>2. Why is there refusal to reveal customer?s details?<br></div><div><br></div><div>3. Why is it that the said prefix is no longer seen in the routing table<br></div><div>originated by the genius ASN or any other ASN?<br></div><div><br></div><div>4. Which networks were involved and what happened to the end users?<br></div><div><br></div><div>Can someone from AFRINIC explain what ?delegation of IP block? mean?<br></div><div><br></div><div>Note: The self organised Internet knows how to deal with bad net<br></div><div>citizens.!<br></div><div><br></div><div>Best regards<br></div><div>Gregoire Ehoumi<br></div><div><br></div><div><br></div><div>-------- Original message --------<br></div><div>From: Lu Heng <h.lu@anytimechinese.com><br></div><div>Date: 2020-05-09 5:43 a.m. (GMT-05:00)<br></div><div>To: Mark Tinka <mark.tinka@seacom.mu><br></div><div>Cc: "rpd@afrinic.net >> AfriNIC Resource Policy Discussion List" <<br></div><div>rpd@afrinic.net><br></div><div>Subject: Re: [rpd] Cloud Innovation Displays Very Poor, If Not Criminal,<br></div><div>Netizenship<br></div><div><br></div><div>To whom it may concern,<br></div><div><br></div><div>On May 8, Mark Think posted a claim to multiple lists that Cloud<br></div><div>Innovation was abusing an ASN (37353) that didn?t belong to them (Cloud<br></div><div>Innovation) but rather belonged to Seacom through their acquisition of<br></div><div>MacroLAN.<br></div><div><br></div><div>While we regret this unfortunate incident, Mark?s claims that it was<br></div><div>criminal or bad netizenship on the part of Cloud Innovation is without<br></div><div>foundation and utterly incorrect.<br></div><div><br></div><div>As shown below in the attached document from Paul Wollner(Ex-CTO of<br></div><div>Macrolan who created IRR routes to allow Macrolan to announce Cloud<br></div><div>Innovation's prefix); letter from Link Infinity International Ltd. (Link<br></div><div>Infinity), A customer of Cloud Innovation; and attached LOA from LARUS<br></div><div>authorizing IPDC Solutions to announce the prefix with origin AS134190.<br></div><div>And a Letter from IPDC. This was an innocent mistake committed by third<br></div><div>parties and had nothing to do with any action by Cloud Innovation or LARUS.<br></div><div><br></div><div>Here?s what happened:<br></div><div><br></div><div>Cloud Innovation delegated a /24 to Link Infinity, an ISP in December<br></div><div>2019.<br></div><div><br></div><div><br></div><div>Link Infinity further delegated that same /24 to IPDC and asked Cloud<br></div><div>innovation to issue an LOA, which we did. The LOA specifically required<br></div><div>IPDC to use its own ASN to announce the space (AS134190).<br></div><div><br></div><div>IPDC subsequently authorized one of its customers to use the said prefix.<br></div><div><br></div><div><br></div><div>For reasons still unknown to Cloud Innovation, IPDC and their customer<br></div><div>set up a BGP session wherein their customer used AS37353 as the origin to<br></div><div>advertise prefix 156.241.3.0/24.<br></div><div><br></div><div><br></div><div>Upon discovering the announcement, rather than contact Cloud Innovation,<br></div><div>Mark contacted IPDC who provided him with an incomplete explanation blaming<br></div><div>their customer and Mark, not realizing that Cloud Innovation was not the<br></div><div>customer in question posted far and wide about the event. It is unclear to<br></div><div>us why he chose to do this rather than contact us to try and resolve the<br></div><div>issue.<br></div><div><br></div><div><br></div><div>A contributing factor to the erroneous BGP configuration by IPDC's<br></div><div>customer may have been data contained in some outdated IRR route objects<br></div><div>for 156.241.0.0/16 which have subsequently been deleted.<br></div><div><br></div><div>As soon as we became aware of the problem (via Mark?s email), we began<br></div><div>to investigate the situation. As soon as it was clear that this was the<br></div><div>result of third-party actions, we reached out to Mark privately to let him<br></div><div>know what we knew and that we were still investigating. We delayed making a<br></div><div>public statement in order to try and ascertain all of the facts of the<br></div><div>situation. We prefer not to make public statements based on incomplete<br></div><div>information.<br></div><div><br></div><div>We apologize to the community for our small part in this unfortunate<br></div><div>incident and assure you that we work very hard to remain good netizens and<br></div><div>will address any concerns promptly when they come to our attention.<br></div><div><br></div><div><br></div><div>Sincerely,<br></div><div><br></div><div>Lu Heng<br></div><div>CEO<br></div><div>Cloud Innovations<br></div><div><br></div><div>Attached:<br></div><div>1. Letter from Paul Wollner<br></div><div>2. Letter from Link Infinity<br></div><div>3. LOA Issued to IPDC Solutions for announcing 156.241.3.0/24 from<br></div><div>AS134190<br></div><div> 4.     Letter from IPDC<br></div><div><br></div><div>FYI: LARUS is proving IP management service for Cloud Innovation, while<br></div><div>LARUS is also providing IP management service to other third parties in all<br></div><div>regions, for full disclosure, LARUS and Cloud Innovation are headed by same<br></div><div>CEO.<br></div><div><br></div><div>Content of those letters have been posted here for your convince:<br></div><div><br></div><div>*IPDC:*<br></div><div><br></div><div>FOR IMMEDIATE RELEASE [Perusal of Cloud Innovation Ltd]<br></div><div><br></div><div><br></div><div>IPDC Solutions Pte Ltd (IPDC) is a customer of Cloud Innovation Ltd and<br></div><div>over the course of our corporate relationship we were given the authority<br></div><div>to use address block 156.241.3.0/24 since 9th December 2019.<br></div><div><br></div><div><br></div><div>On 12th December 2019, we have delegated that address block to our<br></div><div>client. Following which our client further instructed us to announce the<br></div><div>prefix with AS37353. In good will after minimal verification through WHOIS?<br></div><div>IP Prefix we have proceeded to execute our client?s request.<br></div><div><br></div><div><br></div><div>On 7th May 2020 IPDC was then contacted by SEACOM, the legitimate holder<br></div><div>of record for that ASN and have since learned that the customer?s use of<br></div><div>that ASN was erroneous and not permitted by SEACOM and immediate action has<br></div><div>been taken to rectify this situation.<br></div><div><br></div><div><br></div><div>IPDC would like to apologize for our lack of attention in conducting<br></div><div>thorough verification and wish to highlight that the involvement of Cloud<br></div><div>Innovation Ltd in the entire process was providing the addresses to us and<br></div><div>that we truly apologize as we understand that this incident may have<br></div><div>indirectly implicated Cloud Innovation Ltd.<br></div><div><br></div><div><br></div><div>IPDC however, does not wish to disclose our client information and our<br></div><div>client information shall remain confidential under present circumstances.<br></div><div>Once again, we apologize for our shortcomings.<br></div><div><br></div><div><br></div><div>*Link Infinity:*<br></div><div><br></div><div><br></div><div>To whom it may concern,<br></div><div><br></div><div>We at HK Infinity International Ltd are a customer of Cloud Innovation<br></div><div>and in the course received rights to use 156.241.3.0/24 from them.<br></div><div>Beginning December, 2019, we delegated the right to announce this prefix to<br></div><div>IPDC Solutions Pte Ltd. (IPDC). We asked Cloud Innovation to provide an LOA<br></div><div>authorizing them to announce the space which was subsequently received.<br></div><div>IPDC subsequently and without our knowledge delegated this space to one of<br></div><div>their customers and allowed them to originate it from AS37353.<br></div><div><br></div><div>This announcement was not authorized by us, nor is it permitted by the<br></div><div>LOA provided by Cloud Innovation.<br></div><div><br></div><div>Unfortunately, we were not aware of the situation until after it had<br></div><div>already been resolved.<br></div><div><br></div><div>It was never our intent to violate the LOA or to allow the prefix to be<br></div><div>announced from a hijacked ASN. We do not condone this and apologize<br></div><div>sincerely to the community for what has happened here.<br></div><div><br></div><div>Sincere Apologies,<br></div><div><br></div><div><br></div><div>*Paul Wollner:*<br></div><div><br></div><div><br></div><div>8 May 2020<br></div><div><br></div><div>TO WHOM IT MAY CONCERN<br></div><div><br></div><div>In the light of the recent email on NAPAfrica mailing list, I would just<br></div><div>like to clear the air.<br></div><div><br></div><div><br></div><div>The IP route objects were created by myself for Cloud Innovation when<br></div><div>they signed up as a client of Macrolan ( now SEACOM) as they didn't have<br></div><div>their own AS.<br></div><div><br></div><div>At the time I was working for Macrolan (now SEACOM). I left the<br></div><div>employment of SEACOM in October 2019.<br></div><div><br></div><div>It appears that when Cloud Innovation's contract with SEACOM came to an<br></div><div>end, the route objects were never cleaned up.<br></div><div><br></div><div>This occurred after I left SEACOM's employment. Since leaving, I have no<br></div><div>access to these objects.<br></div><div><br></div><div>Regards<br></div><div><br></div><div>Paul Wollner<br></div><div>082-786-9776<br></div><div><br></div><div><br></div><div><br></div><div>On Fri, 8 May 2020 at 22:10, Mark Tinka <mark.tinka@seacom.mu> wrote:<br></div><blockquote><div>Hi all.<br></div><div><br></div><div>I'm not one to b**ch & moan in public, but per subject, I could not let<br></div><div>this one slide.<br></div><div><br></div><div>And if you get this from multiple mailing lists, apologies for that -<br></div><div>I'm just trying to make sure that this reaches as wide an audience as<br></div><div>possible, on the continent.<br></div><div><br></div><div>SEACOM (AS37100) acquired MacroLan (AS37353) a couple of years ago.<br></div><div>MacroLan is now part of the SEACOM family, and while we are in the process<br></div><div>of integrating that network into AS37100, some existing services continue<br></div><div>to be delivered on AS37353 until that exercise is completed.<br></div><div><br></div><div>One of the customers that AS37353 was providing services to was Cloud<br></div><div>Innovation, in Cape Town. From a routing perspective, because Cloud<br></div><div>Innovation had no AS number for this service, all of their IP address space<br></div><div>was being originated by AS37353, on their behalf.<br></div><div><br></div><div>In December of 2019, AS37353 ceased providing services to Cloud<br></div><div>Innovation. That is 6 months ago.<br></div><div><br></div><div>In recent days, it came to SEACOM's attention that some of Cloud<br></div><div>Innovation's IP address space was being originated by AS37353 -<br></div><div>specifically, 156.241.3.0/24 - even though we were sure that they were<br></div><div>no longer a customer of AS37353 since December of 2019. At first, we<br></div><div>thought this was a cached entry in a number of popular looking glasses, but<br></div><div>then every looking glass had the same entry, which made this an unlikely<br></div><div>bug.<br></div><div><br></div><div>As of yesterday afternoon, see below what Telia's looking glass was<br></div><div>saying about this prefix:<br></div><div><br></div><div>*****<br></div><div><br></div><div>Path #1: Received by speaker 0<br></div><div> 4809 134190 37353<br></div><div> 2.255.249.42 (metric 2134) from 2.255.253.101 (80.91.242.40)<br></div><div> Origin incomplete, localpref 200, valid, internal, best,<br></div><div>group-best, import-candidate<br></div><div>Communities:<br></div><div><br></div><div>1299:431<br></div><div> (RPKI state Unknown)<br></div><div><br></div><div>1299:1000 1299:30000 1299:30600 23456:20413 45352:4500 45352:9204<br></div><div><br></div><div>*****<br></div><div><br></div><div>But when I run a traceroute from my house to that prefix, it clearly<br></div><div>was not ending up in Cape Town, where AS37353's main operation resides:<br></div><div><br></div><div>*****<br></div><div><br></div><div>MacBook-Pro-7:~ tinka$ traceroute -I 156.241.3.1<br></div><div>traceroute to 156.241.3.1 (156.241.3.1), 64 hops max, 72 byte packets<br></div><div> 1  172.16.0.254 (172.16.0.254)  14.824 ms  11.522 ms  3.525 ms<br></div><div> 2  xe-1-3-0-1064.er-01-jnb.za.seacomnet.com (105.22.37.13)  5.620 ms<br></div><div>9.714 ms  9.887 ms<br></div><div> 3  ce-0-2-0-0.cr-02-jnb.za.seacomnet.com (105.16.28.2)  175.232 ms<br></div><div>172.699 ms  175.896 ms<br></div><div> 4  xe-0-0-0-8.cr-02-cpt.za.seacomnet.com (105.16.9.182)  164.496 ms<br></div><div>163.578 ms  163.546 ms<br></div><div> 5  105.16.14.153 (105.16.14.153)  169.812 ms  171.272 ms  177.115 ms<br></div><div> 6  xe-0-0-0-0.br-02-lhr.uk.seacomnet.com (105.16.34.253)  168.911 ms<br></div><div>172.958 ms  165.165 ms<br></div><div> 7  82.112.115.169 (82.112.115.169)  172.700 ms  176.482 ms  174.375 ms<br></div><div> 8  ae-17.r05.londen12.uk.bb.gin.ntt.net (129.250.2.147)  672.099 ms<br></div><div>613.617 ms  615.109 ms<br></div><div> 9  ae-2.r24.londen12.uk.bb.gin.ntt.net (129.250.4.244)  181.952 ms<br></div><div>183.087 ms  187.302 ms<br></div><div>10  ae-16.r20.frnkge13.de.bb.gin.ntt.net (129.250.3.13)  190.511 ms<br></div><div>185.579 ms  187.058 ms<br></div><div>11  ae-3.r20.sngpsi07.sg.bb.gin.ntt.net (129.250.4.17)  520.882 ms<br></div><div>613.982 ms  615.275 ms<br></div><div>12  ae-9.r24.tkokhk01.hk.bb.gin.ntt.net (129.250.7.67)  612.301 ms<br></div><div>586.886 ms  436.711 ms<br></div><div>13  ae-1.r03.tkokhk01.hk.bb.gin.ntt.net (129.250.6.98)  614.470 ms<br></div><div>613.416 ms  614.281 ms<br></div><div>14  ce-0-3-0-3.r03.tkokhk01.hk.ce.gin.ntt.net (203.131.241.126)<br></div><div>614.128 ms  613.661 ms  615.416 ms<br></div><div>15  * *     *<br></div><div>16  * * *<br></div><div>17  156.241.3.1 (156.241.3.1)  494.400 ms  410.180 ms *<br></div><div>MacBook-Pro-7:~ tinka$<br></div><div><br></div><div>*****<br></div><div><br></div><div>So we, then, realized that this was a fraudulent use of MacroLan's<br></div><div>AS37353, to which we had given no express permission.<br></div><div><br></div><div>As luck would have it, due to my days living and working in Malaysia, I<br></div><div>know the good folk that operate AS134190 (IPDC Solutions), who was the<br></div><div>upstream providing transit for this prefix. So I rang them up yesterday<br></div><div>afternoon, told them what was happening, and within the hour, they got that<br></div><div>eBGP session shutdown. I am most grateful to them for their quick response<br></div><div>and immediate understanding of what was going on. Even with all the<br></div><div>technology we have today, it, many times, comes down to having good friends<br></div><div>in good places.<br></div><div><br></div><div>Anyway, it turns out the ISP that had acquired this prefix from Cloud<br></div><div>Innovation is based in Manila, Philippines. When IPDC delivered their<br></div><div>transit service to them in Manila, that ISP informed them that they should<br></div><div>use AS37353 for the eBGP session. Yes, one could argue that IPDC should<br></div><div>have done their checks to ensure that the AS number being provided by their<br></div><div>customer belongs to them, but to be honest, I'm not too bothered about that<br></div><div>compared to Cloud Innovation's thinking that it was okay to use another<br></div><div>network's AS number in order to deliver their services to their customers.<br></div><div><br></div><div>IPDC confirm that this service was activated for the Manila ISP in<br></div><div>December of 2019, right around the time Cloud Innovation's service with<br></div><div>SEACOM, in Cape Town, ended.<br></div><div><br></div><div>As it currently stands, the ISP in Manila is now off the Internet, with<br></div><div>some 12 paying customers currently without service. Their excuse - they do<br></div><div>not have an AS number of their own.<br></div><div><br></div><div>IPDC tried to find out why the ISP in Manila thought that it was okay<br></div><div>to use another network's AS number for their service, and as it turns out,<br></div><div>the network engineer at the Manila ISP that set this up has since left the<br></div><div>company. All the ones currently there do not have any history about all of<br></div><div>this.<br></div><div><br></div><div>Currently, 156.241.3.0/24 is not in the global BGP table:<br></div><div><br></div><div>*****<br></div><div><br></div><div>lg-01-ams.nl>sh ip bgp 156.241.3.0/24<br></div><div>% Network not in table<br></div><div>lg-01-ams.nl><br></div><div><br></div><div>lg-01-nbo.ke>sh ip bgp 156.241.3.0/24<br></div><div>% Network not in table<br></div><div>lg-01-nbo.ke><br></div><div><br></div><div>lg-01-cpt.za>sh ip bgp 156.241.3.0/24<br></div><div>% Network not in table<br></div><div>lg-01-cpt.za><br></div><div><br></div><div>*****<br></div><div><br></div><div>That Cloud Innovation thought it was okay for them to use MacroLan's AS<br></div><div>number to originate their own prefixes into the global BGP is as morally<br></div><div>reprehensible as it is technologically distasteful.<br></div><div><br></div><div>SEACOM have been working very closely with AFRINIC to delete previous<br></div><div>route objects from their IRR that certify a relationship between Cloud<br></div><div>Innovation's parent /16 aggregates that cover this prefix, and AS37353, but<br></div><div>this is one of those objects that cannot be removed via the MyAFRINIC<br></div><div>portal, and requires manual intervention from AFRINIC.<br></div><div><br></div><div>I have not, personally, spoken to the proprietors of Cloud Innovation<br></div><div>and/or Outside Heaven, as I don't see how anything could explain this with<br></div><div>any degree of justification.<br></div><div><br></div><div>For now, I will find some beer to wipe the foul taste from my mouth,<br></div><div>while we (SEACOM) consider what to do about this.<br></div><div><br></div><div>And yes, for those who are wondering, RPKI's ROV would not have<br></div><div>prevented this, in its current form. This is AS hijacking, and ROV, today,<br></div><div>tries to solve the prefix-hijacking problem, first.<br></div><div><br></div><div>Thank you for your attention.<br></div><div><br></div><div>Mark.<br></div><div>_______________________________________________<br></div><div>RPD mailing list<br></div><div>RPD@afrinic.net<br></div><div>https://lists.afrinic.net/mailman/listinfo/rpd<br></div></blockquote><div><br></div><div><br></div><div>--<br></div><div>--<br></div><div>Kind regards.<br></div><div>Lu<br></div><div><br></div><div>_______________________________________________<br></div><div>RPD mailing list<br></div><div>RPD@afrinic.net<br></div><div>https://lists.afrinic.net/mailman/listinfo/rpd<br></div></blockquote><div>_______________________________________________<br></div></blockquote><div>RPD mailing list<br></div><div>RPD@afrinic.net<br></div><div>https://lists.afrinic.net/mailman/listinfo/rpd<br></div></blockquote><div><br></div><div>-- <br></div><div>Website <http://www.unilorin.edu.ng>,?Weekly Bulletin <br></div><div><http://www.unilorin.edu.ng/index.php/bulletin>?UGPortal <br></div><div><http://uilugportal.unilorin.edu.ng/> PGPortal <br></div><div><https://uilpgportal.unilorin.edu.ng/><br></div><div><br></div><div><br></div><div>-------------- next part --------------<br></div><div>An HTML attachment was scrubbed...<br></div><div>URL: <https://lists.afrinic.net/pipermail/community-discuss/attachments/20200525/cfbfa5dd/attachment-0001.html><br></div><div><br></div><div>------------------------------<br></div><div><br></div><div>Subject: Digest Footer<br></div><div><br></div><div>_______________________________________________<br></div><div>Community-Discuss mailing list<br></div><div>Community-Discuss@afrinic.net<br></div><div>https://lists.afrinic.net/mailman/listinfo/community-discuss<br></div><div><br></div><div><br></div><div>------------------------------<br></div><div><br></div><div>End of Community-Discuss Digest, Vol 616, Issue 1<br></div><div>*************************************************<br></div></blockquote><div><br></div>  </body>
</html>