SLURM file for Unallocated and Unassigned RIPE NCC Address Space

Summary of proposal:

This proposal instructs the RIPE NCC 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 the RIPE NCC.

Policy text:

New policy text:

The RIPE NCC 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 authorised an Autonomous System to originate a route for this prefix to the global BGP routing table, whereas 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 the RIPE NCC has the authority to create RPKI ROAs for address space not yet allocated or assigned to its members.

RIPE NCC creates all its AS0 ROAs under a specific Trust Anchor, and provides a specific Trust Anchor Locator (TAL) file.  This way, tools and researchers could benefit from a distinction between operational ROAs created by holders of the address space, and ROAs created by RIPE NCC for unallocated/unassigned address space.

If the RIPE NCC wants to allocate address space to one of its members, the RPKI ROA or ROAs with origin AS0 will have to be revoked.

Rationale:

a. Arguments supporting the proposal

• Bogon Address space has been advertised in the global BGP routing table. At the moment of writing, about 300 bogon networks are being announced by about 100 ASNs according to the Routing Table Report. This should not happen, but keeping bogon lists updated has always proven to be complex, and not many operators do it. Under the proposed policy, operators would be able to leverage RPKI to make it easier to filter these wrongful announcements by having the RIPE NCC cover them with a ROA with Origin AS0, meaning they should not be seen in the routing table;
• Since IPv4 address space is running out, more and more bad actors will try to announce address space included in the "bogons". Adopting this proposal will make it harder for them to do so;
• Bogon Address space is frequently used to launch spam attacks on e-mail providers. Enabling easy bogon filtering allows such e-mail providers to inoculate themselves against these attacks, resulting in a reduction in the prevalence of spam.

b. Arguments opposing the proposal

• The RIPE NCC should not be creating ROAs arbitrarily, even for resources it manages because they are currently unallocated or unassigned. This could lead to policies or court orders to create other ROAs on behalf of its members. It should however be noted that a court can already order the RIPE NCC to either create an RPKI ROA with AS0 (zero) origin, or disband an LIR's legal entity completely, which would then trigger the RIPE NCC resource revocation procedure;
• A global policy would be preferred, which covers all address space considered unallocated, unassigned, and for special use managed by IANA, and which requests that all the Regional Registries perform the same actions for address space which they manage directly;
• Given the state of today's RPKI infrastructure, there should be a period of at least 24 hours between the revocation of the ROA or ROAs and the notification to the LIR that a given prefix has been allocated to them. This might delay allocations considerably, unless a different procedure can be created;
• The authors note that it is possible to circumvent the protection of the AS0 ROA through the announcement of a less specific covering prefix. However, it is thought that hijackers of unallocated resources are likely to try staying under the radar and by announcing a supernet which by definition also spans an allocated resource, will trigger alarms through the various DFZ monitoring services available (for example as available in the RIPE RPKI Dashboard);
• The addition of potentially a large number of ROAs covering all the unassigned and unallocated space might increase the operational costs for the RIPE NCC. It might also have an impact on the time needed by validators to process the data. For IPv4, the impact should be very limited (as pointed out by Nick Hilliard, the AS0 ROAs would essentially cover the “quarantine/cooldown pool”, the temporary address pool, the IXP pool, and the /16 held in reserve). However a significant number of ROAs will need to be created for IPv6 due to the “sparse allocation” method used for it.

A. RIPE NCC's Understanding of the Proposed Policy

It is the RIPE NCC's understanding that this proposal instructs the RIPE NCC to create Route Origin Attestations (ROAs) with the origin ‘AS0’ for all unallocated and unassigned address space under its control. The policy further clarifies that the RIPE NCC creates all its AS0 ROAs under a specific Trust Anchor and provides a specific Trust Anchor Locator (TAL) file. This includes all the IPv4 and IPv6 address space which is published as available or reserved in the delegated extended statistics and includes the following categories:

• IPv4 Address Space reserved for Temporary Assignments
• IPv4 Address Space reserved for Internet Exchange Point (IXP) Assignments
• IPv4 Address Space in quarantine
• IPv4 Address Space in the available pool
• IPv6 Address Space reserved for Temporary Assignments
• IPv6 Address Space reserved for Internet Exchange Point (IXP) Assignments
• IPv6 Address Space in quarantine
• IPv6 Address Space in the available pool
• IPv6 Address Space reserved for future use

There are currently nearly 500 IPv4 and 69000 IPv6 blocks for which the RIPE NCC will need to create ROAs.

The RIPE NCC will not be able to create a procedure to revoke the ROAs 24 hours before address distribution, because address distribution itself would be used as the trigger to start the process of the ROA revocation.

If this policy is accepted, the RIPE NCC will delete the relevant AS0 ROAs when it distributes address space, notifying the users that the address space might not be routable for several hours. After the address distribution, it can take up to 48 hours until the ROA revocation is processed globally. For most resource receivers, this 48 hour timeframe should be acceptable, as they will need time to make their own preparations prior to using the newly-provided IP range. For cases in which an immediate announcement is planned, a positive attestation (creating a ROA) by the resource holder, should mitigate the delay. 

The RIPE NCC will create AS0 ROAs once a block has been de-registered and returned to the free pool.

B. Impact of Policy on Registry and Addressing System

This proposal shifts the RIPE NCC’s position on RPKI from a Registration Authority to a more active participant.

The use of a dedicated Trust Anchor to create AS0 ROAs might also be less effective than intended as this Trust Anchor will need to be included in relying party software (validators). Additionally, the relying party software users will be able to decide whether or not they would like to include this Trust Anchor in their validation software.

The creation of a separate Trust Anchor will be consistent with the implementation in the APNIC region, where a similar policy proposal reached consensus in 2019.

The RIPE NCC already has in place a very strict and thorough deregistration procedure, which, includes an internal escalation process for BGP-announced prefixes. The deregistration of address space will have a more direct impact on routing because it will mark possible announcements as invalid. Thus a possible mistake in resource deregistration could cause immediate effects on live networks. Having a specific Trust Anchor limits the risk of a wider routing outage without remediation because the affected parties can remove the TAL.

C. Impact of Policy on RIPE NCC Operations/Services

The requirement to have a specific Trust Anchor means that there needs to be a production-grade Trust Anchor for AS0 ROAs, as well as pilot environments for testing. The RIPE NCC will have to duplicate the entire current RPKI infrastructure to accommodate the policy requirement.

The maintenance and protection of the additional RPKI infrastructure will require extra resources following policy implementation.

The process of creating and deleting ROAs will be automated, hence only a minor impact on manual work carried out by the RIPE NCC is expected following policy implementation.

The delay in usability of the prefixes after they are issued is likely to lead to questions from LIRs asking for clarifications.

D. Legal Impact of Policy

There are several procedures that will need to be updated to make it explicit that we will create AS0 ROAs when deregistering resources.

E. Implementation

With the information currently available, it is expected that implementation of this proposal is likely to take at least six months to have a separate production-grade Trust Anchor. Internal and external processes and documentation will also need to be updated.