Search RPD Archives
[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).
fhfrediani at gmail.com
Thu Jan 28 12:55:02 UTC 2021
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
On 28/01/2021 03:10, Frank Habicht wrote:
> 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 220.127.116.11/24
> should not be accepted.
> 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 18.104.22.168/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
> 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.
> 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
>> *Best Regards,*
>> *UBAH ANTHONY *
> RPD mailing list
> RPD at afrinic.net
More information about the RPD