[rpd] REPORT ON Appeal against the non-consensus determination on proposal AFPUB-2019-GEN-006-DRAFT02 (RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space ? Draft 2).

[Frank Habicht]

Hi,

in my opinion AfriNIC is providing a tool here. RPKI.

Where "owners" of IP address space can publish statements about which
ASNs are allowed to originate advertisements of a given address space
(or subnets). These statements are organised so that computers and
routers can confirm authenticity of the statement - with a certificate
chain from a trust anchor.

That's the tool.

Network engineers *can* use the *tool* then to make routing decisions.
One of the things that is generally considered useful among network
engineers is the decision to refuse/drop all advertisements that
correspond to "INVALID" RPKI information.

That's the network engineer's decision. Not AfriNIC's.

All of the above is the status quo. Existing now.

Like some others I'm responsible for some IP space.
Some of this is IXP peering LANs [unnecessary detail] and I want
everyone to know that this should never be advertised and seen on the
Internet. Also through RPKI.

So I published a ROA with AS0.
So everyone who wants their routers to make routing decisions based on
RPKI data will also get this information from me that 196.223.5.0/24
should not be accepted.

Now:

AfriNIC is also responsible for some address space.
We know from experience that address space held at RIRs is sometimes
advertised and used by spammers and other "bad actors".
I don't want this to happen that easily.

Why should AfriNIC not have the ability to publish information in a tool?
The routing decisions are with the network engineers.
If they want (yes, not scalable) they could tell the routers to fist
accept a certain prefix, and then apply RPKI filtering - not sure why
anyone would do that, but technically possible.

There could also be tweaks applied in the validators.

We could also ask AfriNIC to publish the ROAs for AfriNIC-held IPs with
AS0 under a separate trust anchor. We could even leave that decision to
AfriNIC staff - ie we allow them to do any of these two options.

In that case the network engineers can make the informed decision
whether to use the second trust anchor or not.

Still: AfriNIC would be publishing information in a tool. Like I am
publishing information in the same tool.

Routing decisions are made by the network engineers.
I believe that many would like to have that information in RPKI so that
they can automatically reject advertisements of 196.216.0.0/24

And what changes?
before: network engineers decide to not accept routing information where
the older of the address space stated that it should not be seen on the
internet
after this policy: network engineers decide to not accept routing
information where the older of the address space stated that it should
not be seen on the internet

I believe AfriNIC have a responsibility to use the tool to avoid
spamming and abuse through "misoriginations" of IP address space that
AfriNIC is responsible for.

PS: disputes.
In case there is a dispute about address space, AfriNIC already have the
same kind of control over IRR data like route objects.
The root cause is the dispute and it needs to get resolved - not the
publishing of information in a tool.


Thanks,
Frank
co-author


On 27/01/2021 17:47, Anthony Ubah wrote:

> Hello Jordi,

> 

> This is not an opt-in service; this is created as an additional element

> in the RPKI service and forcefully asks the operator (who accepts the

> RPKI) to accept it. Taking RPKI as an opt-in service, and claiming the

> element you have added here, are already part of that opt-in service.

> When the operator accepts it then, it would be misguiding as they may

> not admit such additional elements. However, they have no choice if this

> policy passes, so this is a valid objection and a critical one.

> 

> The very fundamental principle which I believe you fail to understand

> (and the most crucial objection) is that we do not want to get AFRINIC

> involved in routing. This is an ideological difference, and this is no

> way to address it.

> 

> *This is the very first policy to ask an RIR to proactively inject data

> into routing (something that was never done before), and this also goes

> beyond what we believe an RIR should be, simply offering a registration

> service, and if you think otherwise, that is entirely up to you. This

> would then constitute an ideological difference, and there is no

> acceptable way you can address it. This is also why this policy does not

> have consensus because forcing an ideology on others that fundamentally

> disagree with you is not how PDP works, regardless of how many appeals

> filed. Lastly, an ideological difference is the very definition of

> nonconsensus.*

> 

> *

> *

> 

> *Best Regards,*

> 

> *UBAH ANTHONY *

> 

>