Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[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