RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space (Draft 2) Archived

Proposal

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 as 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 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 in 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 as follows:

Current

Proposed

1 RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFRINIC will create ROAs with origin AS0 for all the unallocated and unassigned address space (IPv4 and IPv6) for which it is the current administrator. Any resource holder can create AS0 (zero) ROAs for the resources they have under their account/administration. An RPKI ROA is a positive attestation that a prefix holder has authorized an Autonomous System to originate a route for this prefix to the global BGP routing table. An RPKI ROA for the same prefixes with AS0 (zero) origin shows a negative intent from the resource holder to have the prefixes advertised in the global BGP routing table. Only AFRINIC has the authority to create RPKI ROAs for address space not yet allocated or assigned to its members. If AFRINIC wants to allocate address space to one of its members, the RPKI ROA or ROAs with origin AS0 will have to be revoked beforehand. Address space can only be allocated once the ROA or ROAs with origin AS0 have been fully removed and are not visible in the repositories. 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. This and other operational details are left to the discretion of AFRINIC.

 

4.0 References

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

 

Revision History

Revision History

Date	Details
30th July 2020	Version 2: AFPUB-2019-GEN-006-DRAFT02 Distinct TAL
4th November 2019	Version 1: AFPUB-2019-GEN-006-DRAFT01 Initial Draft Posted to rpd

 

 

 

AFRINIC Policy Impact Assessment

 

AFRINIC STAFF ASSESSMENT

 

Date of Assessment	Relevant to Proposal
18 Aug 2020	AFPUB-2019-GEN-006-DRAFT02

  

1.0 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 ROA's.
• 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.

 

Impact on members

A resource member can create AS0 (zero) ROAs for the resources (e.g IXPs peering prefixes) they have under their account/administration for resources that they do not intend to announce.

Resource Members need to ensure that they do not create AS0 ROAs for resources that are required to be announced as per the Consolidated Policy Manual.

 

2.0 AFRINIC Staff Comments on the clarity of policy

None

 

3.0 AFRINIC Staff Clarification Requests

What will be the validity period of these AS0 ROAs? 10 years?

 

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 ROAsare removed from the validators repositories before the resources are issued. (James Chirwa to provide the time that this currently takes).
• 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 global routing
• Member documentation for ROAs management shall be updated 

 

Impact on RPKI

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

 

5.0 Implementation Timeline

The policy can be implemented as written within 6 months from the Last Call.