RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space

1.0 Summary of the problem being addressed by this proposal

Address space managed by AFRINIC which has is either “Unallocated” or “Unassigned” is considered “Bogon address space”. As defined in RFC3871, A “Bogon” (plural: “bogons”) is a packet with an IP source address in an address block not yet allocated by IANA or the RIRs as well all addresses reserved for private or special use by RFCs.

The purpose of creating RPKI ROAs with Origin AS0 for AFRINIC’s unallocated and unassigned address space is to restrict the propagation of BGP announcements covering such bogon space. When AFRINIC issues a ROA with AS0 for unallocated address space under AFRINIC’s administration, BGP announcements covering this space will be marked as Invalid by networks doing RPKI based BGP Origin Validation using AFRINIC’s TAL.

2.0 Summary of how this proposal addresses the problem

This proposal instructs AFRINIC to create ROAs for all unallocated and unassigned address space under its control. This will enable networks performing RPKI-based BGP Origin Validation to easily reject all the bogon announcements covering resources managed by AFRINIC.

Currently, in the absence of any ROA, these bogons are marked as NotFound. Since many operators have implemented ROV and are either planning or already discarding Invalid, then all the AS0 ROAs which AFRINIC will create for unallocated address space will be discarded as well.

The process for ROA validity periods and release of ROAs before assignment/allocation by AFRINIC is left for AFRINIC staff to define following usual internal procedures.

It is suggested that, if this policy is adopted, it is placed as a new section at the end of the CPM. This editorial modification can be done by the staff, renumbering/reordering any relevant sections, even adjusting titles/subtitles for the new section to better match the adopted text.

3. Proposal

New CPM section is as follows:

4.0 References

An equivalent proposal has already reached consensus in APNIC and LACNIC.

Revision History

AFRINIC STAFF ASSESSMENT

1. Staff Interpretation & Understanding of the proposal

• This proposal requires AFRINIC to create ROAs with origin AS0 for all its unallocated and unassigned IPv4 and IPv6 address space that it currently administers. unallocated and unassigned space here means available and reserved space as per the AFRINIC extended delegated stats file.

• New prefixes received from IANA/PTI would immediately have AS0 ROAs.

• Any prefixes returned by or reclaimed from members will also have AS0 ROAs

• When AFRINIC allocates address space to one of its Resource Members, the RPKI ROA or ROAs with origin AS0 covering the space will first have to be revoked AND not be visible in the repositories, before the allocation/assignment can happen.

• The process for ROA validity periods and release of ROAs before assignment/allocation by AFRINIC is left for AFRINIC staff to define in internal procedures.

• The AS0 ROAs could be under a distinct Trust Anchor Locator (TAL), so it becomes an opt-in service and provides separate measurements, at least in the initial deployment phases.

• The validity period for these ROAs shall be 10 years (as it currently is for all ROAs) unless a specific validity period is specified by the policy proposal authors.

• AFRINIC should add ROAs to the reclaimed resources only at the end of the reclamation process.

Impact on members

No impact on members' resources as the AS0 ROAs will be created on unallocated and unassigned IPv4 and IPv6 resources. AFRINIC will ensure that the RPKI ROA or ROAs with origin AS0 covering the space will first have to be revoked AND not be visible in the repositories before the allocation/assignment can happen to a Resource Member.

2.0 AFRINIC Staff Comments on clarity of policy

None

3.0 AFRINIC Staff Clarification Requests

None.

4.0 Staff Comments On Areas of Impact

Impact on Registry Functions

• An upgrade of the AFRINIC inventory management system will be required in order to implement this policy

• Automation of the creation of AS0 ROAs for resources currently unallocated in its inventory as well as incoming resources (either from resource reclamation, returns, or replenishment of its pool from IANA/PTI)

• Adjustments of resource issuance process as well as timeframes to ensure that ROAs are revoked and that the revoked ROAs are removed from the validators repositories before the resources are issued.

• An update on AFRINIC systems interfaces & internal controls used for resource & transfer management will be required

• Improve overall monitoring to ensure that members do not consistently create ROAs with AS0 with the prefixes they need to announce in compliance with the policies under which they received these resources.

• Existing policies implemented or undergoing implementation will be put into consideration so that a check is run to determine which prefixes' usage does not require an announcement in the global routing

• Member documentation for ROAs management shall be updated

Impact on RPKI system

On the RPKI side, 3 options have been scoped notably,

1. Use the existing AFRINIC RPKI Tree

2. Additional Production certificate (0/0) for unallocated space only

3. New Trust Anchor with a single Production Certificate

AFRINIC recommends option C because it then becomes an opt-in service and does not pollute the current RPKI.

Legal Assessment

No comments

Financial Assessment

No CAPEX will be required for the implementation of this policy proposal.

5.0 Implementation

Should this proposal reaches consensus and is ratified, the implementation will be done on a new (separate) Trust Anchor so that it becomes an opt-in service and does not impact the current RPKI setup

Timeline

Since AFRINIC has planned the migration to myafrinic v2 in Q4-2021. The AFRINIC inventory of unallocated and unassigned resources will be integrated on the myafrinicv2 platform and the technical team will be able to implement the AS) ROAs on them. We have been advised that the policy can be fully implemented by Q2-2022.

Implementation Details

(In progress)