<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div class="content-isolator__container" style="caret-color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="protected-part"><div class="protected-content"><br class="">This is true for the following reasons:<br class="">- Non-RIR managed IRR databases exist that allow the creation of<br class=""> route(6) objects that are not covered by an RIR allocation<br class="">- Many networks do not filter by prefix based on IRR data at all<br class="">- Those that do generally do not filter their transits by prefix<br class="">- Transit-free networks generally do not filter their peers (or at least<br class=""> their transit-free peers) by prefix<br class=""><br class="">Thus, today, a de-registration probably results in a partial outage that<br class="">can be worked-around, rather than a near-total outage that cannot.<br class="">This is either a feature or a bug in the policy, depending on your point<br class="">of view regarding a specific de-registration case!<br class=""></div></div></div></div></blockquote><div><br class=""></div>The TL;DR of this boils down to “With great power comes great responsibility”.</div><div><br class=""></div><div>The reality is that working around an errant AS0 ROA wouldn’t be any more</div><div>difficult than working around an errant IRR entry. It involves a policy</div><div>change on the afflicted routers which is relatively simple to achieve.</div><div><br class=""></div><div>In fact, in large provider networks, it might be easier to work around the</div><div>AS0 ROA because most of the routers feed from a local cache where the errant</div><div>ROA could be cache-poisoned until it was resolved through the RIR.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="content-isolator__container" style="caret-color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="protected-part"><div class="protected-content">I would suggest the following modifications, in order to alleviate some<br class="">of the risks inherent in the current draft:<br class="">1. The automatic creation of AS0 ROAs should be limited to space that<br class=""> has never been allocated by an RIR or part of a legacy allocation.<br class=""></div></div></div></div></blockquote><div><br class=""></div>I could live with this, though I think it unnecessary. It doesn’t need to be</div><div>policy, it’s an operational matter for staff to consider in implementation.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="content-isolator__container" style="caret-color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="protected-part"><div class="protected-content">2. AFRINIC should require the explicit consent of the previous holder<br class=""> to issue AS0 ROAs in respect of re-claimed, returned, etc, space.<br class=""></div></div></div></div></blockquote><div><br class=""></div>I disagree here. This would essentially allow someone who obtained space, never</div><div>paid their fees and never complied with policy to continue using the space</div><div>ad infinitum because they refuse to grant permission to the RIR to issue the</div><div>AS0 ROA. Instead, I suggest a process whereby the RIR is not allowed to issue</div><div>a ROA for 90 days after reclaiming space and upon appeal of the reclamation</div><div>within that 90 days, AS0 ROAs cannot be issued until the appeal is finalized.</div><div>The appeal should be finalized within an additional 90 days.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="content-isolator__container" style="caret-color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="protected-part"><div class="protected-content">3. Any ROAs issued under this policy should be issued and published in<br class=""> a way that makes it operationally easy for an relying party to<br class=""> ignore them (probably by issuing under a separate TA)<br class=""></div></div></div></div></blockquote><div><br class=""></div>That’s already in the latest version of the policy proposal.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="content-isolator__container" style="caret-color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="protected-part"><div class="protected-content">With the above amendments I would be inclined to support the proposal.<br class=""><br class="">Cheers,<br class=""><br class="">Ben<br class=""><br class="">On 09/17, Mark Elkins wrote:<br class=""><blockquote type="cite" class="">I support the RPKI ROA policy as written. I understand the technical aspects<br class="">of the policy. I have a feeling that those objecting may not completely<br class="">understand the technical aspects which is why they are objecting.<br class=""><br class="">AFRINIC's job is to properly document the resources they have been provided<br class="">by ICANN/IANA and this is simply part of the job. When new resources are<br class="">provided to AFRINIC, they label it as such (AS0, etc). When it is then<br class="">allocated/assigned to a member, the AS0 RPKI is removed. All this means is<br class="">that the unallocated/unassigned resources that are with AFRINIC can be<br class="">(optionally) identified as such and thus can not be easily misused by bad<br class="">actors. This also means that when they are allocated/assigned to members,<br class="">they are less lightly to have been made "dirty".<br class=""><br class="">On 2020/09/17 08:26, Ibeanusi Elvis wrote:<br class=""><blockquote type="cite" class="">Dear all,<br class=""><br class="">The AFRINIC as an organization specifically focuses on the registration<br class="">database and thereby having knowledge of where the prefix belongs to and<br class="">AFRINIC should just focus on this role and should not engage in<br class="">authenticating or the authorization of various services. If such rights<br class="">are given to any organization, they have the right to assign prefixes to<br class="">servers hence, having control of the routing database at which a<br class="">technical or human error will lead to an immense catastrophe to the<br class="">internet society. This control is basically the specific definition of<br class="">centralization. This centralization is the major reason why most<br class="">providers do not trust the Resource Public Key Infrastructure (RPKI). I<br class="">am still in opposition to this policy proposal.<br class=""><br class="">Elvis.<br class=""><br class="">On Thu, Sep 17, 2020 at 3:01 PM Darwin Costa <<a href="mailto:dc@darwincosta.com" class="">dc@darwincosta.com</a><br class=""><<a href="mailto:dc@darwincosta.com" class="">mailto:dc@darwincosta.com</a>>> wrote:<br class=""><br class=""> Cmon folks….!<br class=""><br class=""> @Elvis, I really don’t see your point here and also don’t really<br class=""> understand why are you opposing against this proposal.<br class=""><br class=""> As mentioned further on the thread - RPKI won’t change Afrnic´s<br class=""> role at all…. Instead this proposal will certainly contribute to a<br class=""> more secure routing advertisement.<br class=""><br class=""> As such, other RIR´s have successfully implemented this in order<br class=""> to protect our garden so called “The Internet”.<br class=""><br class=""> Darwin-.<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class=""> On 17 Sep 2020, at 05:42, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" class="">fhfrediani@gmail.com</a><br class=""> <<a href="mailto:fhfrediani@gmail.com" class="">mailto:fhfrediani@gmail.com</a>>> wrote:<br class=""><br class=""> I think there is a serious issue by some people totally<br class=""> misunderstanding what RPKI actually is.<br class=""><br class=""> Some arguments saying something like 'Afrinic will centralize<br class=""> control of the internet and should not have such power' don't<br class=""> have relation to what what this proposal intends and the reasons<br class=""> to oppose it are not tied to real possible problems pointed.<br class=""><br class=""> This proposal only follows what have been done in APNIC and<br class=""> LACNIC and is a natural move to make an internet more secure and<br class=""> avoid organizations to use space that is not assigned to anyone else.<br class=""> Therefore I support this proposal.<br class=""><br class=""> Fernando<br class=""><br class=""> On 16/09/2020 20:42, Noah wrote:<br class=""><blockquote type="cite" class=""><br class=""> On Thu, Sep 17, 2020 at 2:30 AM Ibeanusi Elvis<br class=""> <<a href="mailto:ibeanusielvis@gmail.com" class="">ibeanusielvis@gmail.com</a><span class="Apple-converted-space"> </span><<a href="mailto:ibeanusielvis@gmail.com" class="">mailto:ibeanusielvis@gmail.com</a>>> wrote:<br class=""><br class=""><br class=""> I am strongly in opposition to this RPKI ROA proposal,<br class=""><br class=""><br class=""> You oppose yet....<br class=""><br class=""> issuing an AS0 for AFRINIC address space<br class=""><br class=""><br class=""> You must be clear on which AFRINIC address space rather than<br class=""> presenting a rather vague statement.<br class=""><br class=""> The proposal is very clear and explicit and the AFRINIC space in<br class=""> question is that which has not yet been allocated or assigned to<br class=""> any entity or resource member.<br class=""><br class=""> I will quote for you section 2.0 of the proposal as written below;<br class=""><br class=""> *2.0 Summary of how this proposal addresses the problem*<br class=""> *<br class=""> *This proposal instructs AFRINIC to create ROAs for all<br class=""> *unallocated and unassigned address space under its control.*<br class=""> This will enable networks performing RPKI-based BGP Origin<br class=""> Validation to easily reject all the bogon announcements covering<br class=""> resources managed by AFRINIC.<br class=""><br class=""> So what are you talking about?<br class=""><br class=""> Noah<br class=""><br class=""> _______________________________________________<br class=""> RPD mailing list<br class=""> <a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><span class="Apple-converted-space"> </span> <<a href="mailto:RPD@afrinic.net" class="">mailto:RPD@afrinic.net</a>><br class=""> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><span class="Apple-converted-space"> </span><<a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720490840&sdata=mOjgUTIarKfPnsD2h0TtixnR51E4wzIwqoo6rONHW%2FI%3D&reserved=0" class="">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720490840&sdata=mOjgUTIarKfPnsD2h0TtixnR51E4wzIwqoo6rONHW%2FI%3D&reserved=0</a>><br class=""></blockquote> _______________________________________________<br class=""> RPD mailing list<br class=""> <a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><span class="Apple-converted-space"> </span><<a href="mailto:RPD@afrinic.net" class="">mailto:RPD@afrinic.net</a>><br class=""> <a href="https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720510827&sdata=jlnsXCK7dATX4Jcg48%2BhurUnj1E5umTa2RZq7IMsb%2Fs%3D&reserved=0" class="">https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=02%7C01%7C%7Ca48324a7026842948aff08d85abbfbd8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637359110720510827&sdata=jlnsXCK7dATX4Jcg48%2BhurUnj1E5umTa2RZq7IMsb%2Fs%3D&reserved=0</a><br class=""></blockquote><br class=""> _______________________________________________<br class=""> RPD mailing list<br class=""> <a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><span class="Apple-converted-space"> </span><<a href="mailto:RPD@afrinic.net" class="">mailto:RPD@afrinic.net</a>><br class=""> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class=""><br class=""><br class="">_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class=""><a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class=""></blockquote>--<span class="Apple-converted-space"> </span><br class=""><br class="">Mark James ELKINS - Posix Systems - (South) Africa<br class=""><a href="mailto:mje@posix.co.za" class="">mje@posix.co.za</a> Tel: +27.826010496 <<a href="tel:+27826010496" class="">tel:+27826010496</a>><br class="">For fast, reliable, low cost Internet in ZA:<span class="Apple-converted-space"> </span><a href="https://ftth.posix.co.za/" class="">https://ftth.posix.co.za</a><br class=""><br class="">Posix SystemsVCARD for MJ Elkins<br class=""><br class=""></blockquote><br class=""><blockquote type="cite" class="">_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class=""><a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class=""></blockquote><br class=""></div></div><br class=""><iframe class="content-isolator__isolated-content" sandbox="allow-scripts" scrolling="no" width="200" height="10" data-src="data:text/html;charset=UTF-8;base64,PGlmcmFtZS1jb250ZW50IGRhdGEtaWZyYW1lLWhlaWdodD0idHJ1ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+UlBEIG1haWxpbmcgbGlzdDxCUj5SUERAYWZyaW5pYy5uZXQ8QlI+aHR0cHM6Ly9saXN0cy5hZnJpbmljLm5ldC9tYWlsbWFuL2xpc3RpbmZvL3JwZDxCUj48L2lmcmFtZS1jb250ZW50Pg==" src="data:text/html;charset=UTF-8;base64,PGlmcmFtZS1jb250ZW50IGRhdGEtaWZyYW1lLWhlaWdodD0idHJ1ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+UlBEIG1haWxpbmcgbGlzdDxCUj5SUERAYWZyaW5pYy5uZXQ8QlI+aHR0cHM6Ly9saXN0cy5hZnJpbmljLm5ldC9tYWlsbWFuL2xpc3RpbmZvL3JwZDxCUj48L2lmcmFtZS1jb250ZW50Pg==" id="iFrameResizer0" style="border: none; display: block; overflow: hidden; height: 64px;"></iframe></div><br class="Apple-interchange-newline"></div></blockquote></div><br class=""></body></html>