[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).

[Fernando Frediani]

Very good email Frank !
That's it. It is a tool and people looking after routing in 
organizations are free to use or not.

I encourage everyone, specially those who feared and objected this 
proposal to read carefully the message below in order to understand the 
difference.

Regards
Fernando

On 28/01/2021 03:10, Frank Habicht wrote:

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

>>

>>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

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