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

[Korsback, Fredrik]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210614/b2582f5e/attachment-0001.html>