[rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02

[Owen DeLong]

> 

> This is true for the following reasons:

> - Non-RIR managed IRR databases exist that allow the creation of

>  route(6) objects that are not covered by an RIR allocation

> - Many networks do not filter by prefix based on IRR data at all

> - Those that do generally do not filter their transits by prefix

> - Transit-free networks generally do not filter their peers (or at least

>  their transit-free peers) by prefix

> 

> Thus, today, a de-registration probably results in a partial outage that

> can be worked-around, rather than a near-total outage that cannot.

> This is either a feature or a bug in the policy, depending on your point

> of view regarding a specific de-registration case!


The TL;DR of this boils down to “With great power comes great responsibility”.

The reality is that working around an errant AS0 ROA wouldn’t be any more
difficult than working around an errant IRR entry. It involves a policy
change on the afflicted routers which is relatively simple to achieve.

In fact, in large provider networks, it might be easier to work around the
AS0 ROA because most of the routers feed from a local cache where the errant
ROA could be cache-poisoned until it was resolved through the RIR.


> I would suggest the following modifications, in order to alleviate some

> of the risks inherent in the current draft:

> 1.  The automatic creation of AS0 ROAs should be limited to space that

>    has never been allocated by an RIR or part of a legacy allocation.


I could live with this, though I think it unnecessary. It doesn’t need to be
policy, it’s an operational matter for staff to consider in implementation.


> 2.  AFRINIC should require the explicit consent of the previous holder

>    to issue AS0 ROAs in respect of re-claimed, returned, etc, space.


I disagree here. This would essentially allow someone who obtained space, never
paid their fees and never complied with policy to continue using the space
ad infinitum because they refuse to grant permission to the RIR to issue the
AS0 ROA. Instead, I suggest a process whereby the RIR is not allowed to issue
a ROA for 90 days after reclaiming space and upon appeal of the reclamation
within that 90 days, AS0 ROAs cannot be issued until the appeal is finalized.
The appeal should be finalized within an additional 90 days.


> 3.  Any ROAs issued under this policy should be issued and published in

>    a way that makes it operationally easy for an relying party to

>    ignore them (probably by issuing under a separate TA)


That’s already in the latest version of the policy proposal.


> With the above amendments I would be inclined to support the proposal.

> 

> Cheers,

> 

> Ben

> 

> On 09/17, Mark Elkins wrote:

>> I support the RPKI ROA policy as written. I understand the technical aspects

>> of the policy. I have a feeling that those objecting may not completely

>> understand the technical aspects which is why they are objecting.

>> 

>> AFRINIC's job is to properly document the resources they have been provided

>> by ICANN/IANA and this is simply part of the job. When new resources are

>> provided to AFRINIC, they label it as such (AS0, etc). When it is then

>> allocated/assigned to a member, the AS0 RPKI is removed. All this means is

>> that the unallocated/unassigned resources that are with AFRINIC can be

>> (optionally) identified as such and thus can not be easily misused by bad

>> actors. This also means that when they are allocated/assigned to members,

>> they are less lightly to have been made "dirty".

>> 

>> On 2020/09/17 08:26, Ibeanusi Elvis wrote:

>>> Dear all,

>>> 

>>> The AFRINIC as an organization specifically focuses on the registration

>>> database and thereby having knowledge of where the prefix belongs to and

>>> AFRINIC should just focus on this role and should not engage in

>>> authenticating or the authorization of various services. If such rights

>>> are given to any organization, they have the right to assign prefixes to

>>> servers hence, having control of the routing database at which a

>>> technical or human error will lead to an immense catastrophe to the

>>> internet society. This control is basically the specific definition of

>>> centralization. This centralization is the major reason why most

>>> providers do not trust the Resource Public Key Infrastructure (RPKI). I

>>> am still in opposition to this policy proposal.

>>> 

>>> Elvis.

>>> 

>>> On Thu, Sep 17, 2020 at 3:01 PM Darwin Costa <dc at darwincosta.com <mailto:dc at darwincosta.com>

>>> <mailto:dc at darwincosta.com <mailto:dc at darwincosta.com>>> wrote:

>>> 

>>>    Cmon folks….!

>>> 

>>>    @Elvis, I really don’t see your point here and also don’t really

>>>    understand why are you opposing against this proposal.

>>> 

>>>    As mentioned further on the thread - RPKI won’t change Afrnic´s

>>>    role at all…. Instead this proposal will certainly contribute to a

>>>    more secure routing advertisement.

>>> 

>>>    As such, other RIR´s have successfully implemented this in order

>>>    to protect our garden so called “The Internet”.

>>> 

>>>    Darwin-.

>>> 

>>> 

>>> 

>>>>    On 17 Sep 2020, at 05:42, Fernando Frediani <fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>

>>>>    <mailto:fhfrediani at gmail.com <mailto:fhfrediani at gmail.com>>> wrote:

>>>> 

>>>>    I think there is a serious issue by some people totally

>>>>    misunderstanding what RPKI actually is.

>>>> 

>>>>    Some arguments saying something like 'Afrinic will centralize

>>>>    control of the internet and should not have such power' don't

>>>>    have relation to what what this proposal intends and the reasons

>>>>    to oppose it are not tied to real possible problems pointed.

>>>> 

>>>>    This proposal only follows what have been done in APNIC and

>>>>    LACNIC and is a natural move to make an internet more secure and

>>>>    avoid organizations to use space that is not assigned to anyone else.

>>>>    Therefore I support this proposal.

>>>> 

>>>>    Fernando

>>>> 

>>>>    On 16/09/2020 20:42, Noah wrote:

>>>>> 

>>>>>    On Thu, Sep 17, 2020 at 2:30 AM Ibeanusi Elvis

>>>>>    <ibeanusielvis at gmail.com <mailto:ibeanusielvis at gmail.com> <mailto:ibeanusielvis at gmail.com <mailto:ibeanusielvis at gmail.com>>> wrote:

>>>>> 

>>>>> 

>>>>>        I am strongly in opposition to this RPKI ROA proposal,

>>>>> 

>>>>> 

>>>>>    You oppose yet....

>>>>> 

>>>>>         issuing an AS0 for AFRINIC address space

>>>>> 

>>>>> 

>>>>>    You must be clear on which AFRINIC address space rather than

>>>>>    presenting a rather vague statement.

>>>>> 

>>>>>    The proposal is very clear and explicit and the AFRINIC space in

>>>>>    question is that which has not yet been allocated or assigned to

>>>>>    any entity or resource member.

>>>>> 

>>>>>    I will quote for you section 2.0 of the proposal as written below;

>>>>> 

>>>>>    *2.0 Summary of how this proposal addresses the problem*

>>>>>    *

>>>>>    *This proposal instructs AFRINIC to create ROAs for all

>>>>>    *unallocated and unassigned address space under its control.*

>>>>>    This will enable networks performing RPKI-based BGP Origin

>>>>>    Validation to easily reject all the bogon announcements covering

>>>>>    resources managed by AFRINIC.

>>>>> 

>>>>>    So what are you talking about?

>>>>> 

>>>>>    Noah

>>>>> 

>>>>>    _______________________________________________

>>>>>    RPD mailing list

>>>>>    RPD at afrinic.net <mailto:RPD at afrinic.net>  <mailto:RPD at afrinic.net <mailto:RPD at afrinic.net>>

>>>>>    https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd> <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 <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>>

>>>>    _______________________________________________

>>>>    RPD mailing list

>>>>    RPD at afrinic.net <mailto:RPD at afrinic.net> <mailto:RPD at afrinic.net <mailto:RPD at afrinic.net>>

>>>>    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 <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>

>>> 

>>>    _______________________________________________

>>>    RPD mailing list

>>>    RPD at afrinic.net <mailto:RPD at afrinic.net> <mailto:RPD at afrinic.net <mailto:RPD at afrinic.net>>

>>>    https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>

>>> 

>>> 

>>> _______________________________________________

>>> RPD mailing list

>>> RPD at afrinic.net <mailto:RPD at afrinic.net>

>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>

>> -- 

>> 

>> Mark James ELKINS  -  Posix Systems - (South) Africa

>> mje at posix.co.za <mailto:mje at posix.co.za>       Tel: +27.826010496 <tel:+27826010496 <tel:+27826010496>>

>> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za <https://ftth.posix.co.za/>

>> 

>> Posix SystemsVCARD for MJ Elkins

>> 

> 

>> _______________________________________________

>> RPD mailing list

>> RPD at afrinic.net <mailto:RPD at afrinic.net>

>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>

> 

> 

> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210212/9fa8dd74/attachment-0001.html>