[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.

[Frank Habicht]

Hi,

On 06/06/2021 20:24, aziz halim wrote:

> +1 Anthony. 

> 

> I’d also like to add that this policy should go back to discussion for

> the simple reason that it completely misreads the main role of RIRs.

> More precisely, and as many individuals have commented on the PPM, RIRs

> have nothing to do with the resource routing process,


and that doesn't change. As was explained. you're just repeating things
without digesting the responses given to exactly the same phrases.

This policy is about AfriNIC publishing data about the
unassigned/unallocated pool through new means.
Yes. AfriNIC already published that data.



> it is safe to say

> that it is totally out of their mandate scope.


Here you mean something that they are already doing, through other means.


> Their one and only

> mission is to properly register and allocate number resources to end-users. 


Incomplete. It is also AfriNIC's mission to publish that information.
For instance through the Whois Database. But not limited to that. Also
through RPKI.



> Correspondingly, the implementation of this policy will increase the

> chances of committing routing errors, which can potentially hinder

> network functioning. 


This chance is not exactly zero. As with any other change anywhere.


> In fact, AFRINIC staff has a history in committing

> such technical mistakes, jeopardizing networks.


This is where we can start a competition for suggestions how things can
be improved. But it's out of scope for this mailing list.


> It is simply not in

> AFRINIC’s mandate to inject data into the routing database.


I am sssooooo sick and tired of hearing this.
This was so often repeated (by one side) and refuted and explained (by
the other side. It sounds like a broken record. Or an echo chamber.
I would like the co-chairs to de-value any contribution from anyone who
tries this cheap phrase.



> Plus, the

> following concern that has been raised during the meeting still remains

> unaddressed : how does this policy prevents hijacking as it’s intended

> to do ?


The fact that you ask this question is telling.
I leads me now to believe that you were provided most of your other
"points" from someone else.

Co-chairs: is explaining how RPKI works within the scope of this mailing
list?

102.218.0.0/16 is "available"
AfriNIC generates a certificate that says "if you trust AfriNIC, this
prefix and sub-prefixes should not get routes on the Internet" - a ROA
with AS0
several network operators (all over the world, including in Africa, but
not limited to Africa) have decided to trust the existing AfriNIC
"Trust-Anchor". Some of them, and maybe in time some additional ones,
might decide they will also trust the other "new" AfriNIC "Trust-Anchor"
with advanced AS) features.
Because they decided that the benefits outweigh the risks (and effort).
"Trusting Party" validators and Routers get the information, including
the AS0 ROA for 102.218.0.0/16 - after active changes in configuration
in the router to enabled 'validation'.
Once that router gets an advertisement for 102.218.0.0/16 (or a subnet)
from another party (likely external), it will do with it what it's
configured to do.
Better description here:
https://rpki.readthedocs.io/en/latest/rpki/using-rpki-data.html

Best current practice is to not accept ("drop") that advertisement.
It's an advertisement for an IP block that AfriNIC has not
allocated/assigned to anyone.

And this is how it prevents (the acceptance of) hijackings.


Hope this helps.

Frank



> On Sun, Jun 6, 2021, 16:48 Anthony Ubah <ubah.tonyiyke at gmail.com

> <mailto:ubah.tonyiyke at gmail.com>> wrote:

> 

>     Dear PDWG,

> 

>     Regarding this policy, I didn't throw my weight on it for one

>     reason. There is a gray area which requires clarity and may turn

>     around to hunt service providers and resource owner in the long run. 

>     I directed a question to the Legal team at the hearing of this

>     policy, multiple times, and it was inexplicably ignored by Jordi,

>     the Co-chairs and perhaps the legal team, and I still sought clarity

>     on it. 

> 

>     My question remains; In a situation where, due to human or machine

>     error AS0 is injected by AFRINIC on already assigned resources, and

>     expectedly this result in service disconnection, thus DOS, causing

>     an SLA breach with service end users. *Who bears the final brunt for

>     the consequences (e.g.poor QoS, fines, revenue cut, and loss of

>     customers), Afrinic or resource owner?*

> 

>     I still insist this policy isn't ripe, because;

>     1. The Legal team must include this on the impact assessment,

>     clearly stating responsibility for liability.

>     2. The policy must include text stating these policies and

>     mitigation plans.

>     3. Since it has become a trend to follow other RIRs, why do you

>     think most have rejected this policy so far?

>     4. How did the RIRs who have adopted this policy tackled this

>     scenario legally?

> 

>     *Best Regards,*

> 

>     *Anthony Ubah *

> 

> 

> 

>     On Fri, Jun 4, 2021 at 11:00 AM PDWG Chair <dacostadarwin at gmail.com

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

> 

>         Dear PDWG, 

> 

>         This is to announce the official start of the last call period

>         for the following policy proposal (in line with the  provisions

>         of the CPM):

> 

>         RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space

>         AFPUB-2019-GEN-006-DRAFT03

>         URL:  https://afrinic.net/policy/proposals/2019-gen-006-d3

>         <https://afrinic.net/policy/proposals/2019-gen-006-d3>

> 

>         The proposal reached rough consensus at the Public Policy

>         Meeting held 2-3 June 2021 in online format. This last call

>         period will run for a period of two weeks as a minimum. The

>         closing date will be communicated to the mailing list depending

>         on the feedback received. 

> 

>         Regards,

>         PDWG Co-Chairs.

> 

>         _______________________________________________

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

> 

>     _______________________________________________

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

> 

> 

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

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

>