Search RPD Archives
[rpd] RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT02
Mark Elkins
mje at posix.co.za
Thu Sep 17 10:30:18 UTC 2020
I totally agree with you regarding...
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.
2. AFRINIC should require the explicit consent of the previous holder
to issue AS0 ROAs in respect of re-claimed, returned, etc, space.
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)
If these points are emphasised - then I have no issues at all!
I actually though that point (1) was implied by the wording already!
On 2020/09/17 11:08, Ben Maddison wrote:
> Hi all,
>
> I am currently undecided on this policy.
> As others have pointed out, the objections to the proposal on the basis
> of centralization of control are bogus: the current policy does not add
> any additional control over the routing system beyond that which AFRINIC
> already has as the result of RPKI origin validation deployment today.
>
> I agree with the fundamental basis of the proposal that:
> a) it is generally undesirable to route traffic for bogon destinations;
> and
> b) the RPKI is the best fit we have to securely communicate what is and
> isn't a bogon to relying parties in order to implement the necessary
> routing policy.
>
> However, it is also the case that the consequences (in terms of service
> availability for end users) of a de-registration would be substantially
> greater if the de-registration is accompanied by the issuance of an AS0
> ROA for that address space.
>
> 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!
>
> 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.
> 2. AFRINIC should require the explicit consent of the previous holder
> to issue AS0 ROAs in respect of re-claimed, returned, etc, space.
> 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)
>
> 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>> 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>> 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>> 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>
>>>>> 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>
>>>> _______________________________________________
>>>> RPD mailing list
>>>> 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
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net <mailto: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
>> --
>>
>> Mark James ELKINS - Posix Systems - (South) Africa
>> mje at posix.co.za Tel: +27.826010496 <tel:+27826010496>
>> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
>>
>> Posix SystemsVCARD for MJ Elkins
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
--
Mark James ELKINS - Posix Systems - (South) Africa
mje at posix.co.za Tel: +27.826010496 <tel:+27826010496>
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
Posix SystemsVCARD for MJ Elkins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200917/d8dda1a8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abessive_logo.jpg
Type: image/jpeg
Size: 6410 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200917/d8dda1a8/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QR-MJElkins.png
Type: image/png
Size: 2163 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200917/d8dda1a8/attachment-0001.png>
More information about the RPD
mailing list