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

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

Fernando Frediani fhfrediani at gmail.com
Mon Jun 14 21:38:21 UTC 2021


I feel that some people have some a bigger fear of something that
requires a chain of mistakes to happen and are not willing to take any
risks even in the aim to improve things.
Some examples that have been given in this discussion (although late as
we are already in the last-call) seems rather simplistic as if a push of
single button would lead to a regional or global Internet disaster.

I think most people understand the difference between a ROA issued by a
resource holder and a ROA issues by a RIR for unallocated space.
Although RIR staff didn't detail, I find hard to believe they will
implement change processes that even with double checks could easily
lead to theoretical situations as mentioned. Also once done for first
time all the unallocated space for that RIR the further adjustments and
issues of AS0 ROA will only happen on 2 situations: 1) When some IP
space is recovered 2) When IANA allocates new space to the RIR (rarely
then). In both cases the issue of these ROAs can be done in a more
simple and safe way and more specifically.

One of the upsides of this policy is to make sure organizations will not
be able to use IP space that is not allocated to it, damage it and make
it bad for a future member who receives it.
Finally I am glad to see that organizations will have the option to
implement and use AS0 TAL in their infrastructure. I guess that was one
of the good points out of the proposal: to leave each one free to choose
whatever their prefer.

Regards
Fernando

On 14/06/2021 17:24, Korsback, Fredrik via RPD wrote:

>

> I’ll +1 Mark here.

>

> TL;DR - I do not support this policy proposal either.

>

> Context: AWS (AS16509) does RPKI-OV in thousands of routers over

> hundreds of sites in every single corner of the world, we have 99%

> coverage of ROAs on our resources and have implemented RPKI as an

> integral process in for example Bring-Your-Own-IP (BYOIP) Operations.

>

> We, and everyone else, have designed our RPKI infrastructure to

> **always** fail open. This is absolutely crucial to our operations and

> for the safety of our network and our customers This proposal suggest

> a solution which *could* lead to the opposite, almost in a

> non-recoverable way. We have already today seen examples where ROAs

> has been revoked due to the fact that there has been error in the

> billing process. Imagine that error, or any other similar error, that

> would automatically create AS0 ROAs for space can be disastrous.

> Moving away from the sentiment that a ROA always comes from the

> **customer** of an RIR, is a very slippery slope just in general (That

> I believe others have already pointed out in detail what it could be

> and lead to).

>

> The benefit on the other side I see as slim-to-none. Looking at the

> already implemented AS0 TAL in APNIC for example it comes with a great

> deal of warning-signs and “do not use” labels attached to it already,

> who in their right mind would use it? I spend a large portion of my

> days to educate and inspire, especially small ISPs in the world, to

> implement RPKI and other routing-security related features, why would

> people implement this? Especially since RPKI is hard-enough as it is

> to get going in some networks.  I can’t see the reason for this

> increase in complexity and “if and buts”

>

> Why would a RIR accept this increased liability in what they are

> delivering for their customers? For not apparent upside

>

> I do appreciate the effort to look for solutions for

> spoofers/squatters and whatnot, but I don’t see RPKI as the right tool

> to use for this but rather a One-Way door to something we cannot

> change later. I much rather see the money, time, effort and cycles to

> be spent on increasing operational stability for RPKI, better APIs,

> better GUI and better supporting features for lowering the bar of

> entry into RPKI, not specific to AFRINIC per say but for everyone.

>

> We, will not implement this AS0 TAL, nor any other AS0 TAL.

>

> /Fredrik @ AWS Networking

>

> *From: *Mark Tinka <mark.tinka at seacom.com>

> *Organisation: *SEACOM

> *Date: *Friday, 11 June 2021 at 18:51

> *To: *"rpd at afrinic.net" <rpd at afrinic.net>

> *Subject: *RE: [EXTERNAL] [rpd] Last Call - RPKI ROAs for Unallocated

> and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.

>

> *CAUTION*: This email originated from outside of the organization. Do

> not click links or open attachments unless you can confirm the sender

> and know the content is safe.

>

> Hi all.

>

> TL;DR - I do not support this policy proposal.

>

> The purpose of this proposal is to give operators another method to

> identify routes they should either ignore or filter from their routing

> domain. It is, already, feasible to do this using the data available

> from the AFRINIC WHOIS database. Implementing this policy does present

> the potential to introduce some risk in the RPKI system operated by

> AFRINIC. On the basis that the use of this policy is largely optional,

> I am not convinced that the additional risk to the AFRINIC

> infrastructure - and the folk who rely on it - outweighs the benefit.

>

> Getting RPKI out there is already significantly challenging.

> Personally, I would spend more time and energy on that, before we try

> to complicate it with a policy proposal such as this.

>

> I am less-than-interested in what the other RIR's have decided to do

> or not to do with similar policy proposals within their regions.

> Speaking purely with an African bias, I do not see how this proposal

> moves the RPKI needle forward in a meaningful and impactful way. For

> me, it's a nice-to-have, for which solutions that are well-documented

> are already in sufficient existence. I'd prefer that we did not

> encourage thought processes that could turn RPKI into a loaded gun

> that may very well lead to unintended consequences.

>

> Suggest we focus our efforts on actually getting RPKI more widely

> deployed. A case of "crawl before we can run", type-thing.

>

> I tend to prefer achieving the objective with the least amount of

> effort. If it were up to me, the only command a router would ever need

> is "on", but alas! Pushing multiple TAL's from a single RIR will only

> escalate the confusion surface area, which is more than likely to have

> a negative impact on the progression of deployment of a global RPKI,

> or worse, mis-deployment that may be touted as a BCP for generations

> to come.

>

> A policy such as this could set a precedent for significantly more

> (well-intentioned, but) disastrous use-cases for the RPKI. I'd err on

> the side of avoiding situations where centralized control of

> gratuitous blackouts of part or all of the Internet, on purpose or by

> mistake, are not given roots to emerge. Keeping the genie in the

> bottle is, for me, far better than thinking you can cage it once it

> has been set free.

>

> AS0 is unlikely to help me stop paying the annual subscription for my

> anti-spam and anti-virus system. If there is some other practical

> problem - for which a solution currently does not exist - that this

> policy proposal is looking to fix, I'd be most obliged to hear it. Thanks.

>

> Mark.

>

>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210614/1fa5671d/attachment.html>


More information about the RPD mailing list