Summary of proposal:

This proposal instructs the RIPE NCC to create a SLURM file containing assertions ROAs for all unallocated and unassigned address space under its control with originating ASN AS0. 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 a SLURM file containing assertions ROAs with origin AS0 for all the unallocated and unassigned address space (IPv4 and IPv6) for which it is the current administrator. The file will be available for download from a well-known URL published by the RIPE NCC, so that Relying Parties (the so-called Validators) will be able to, in an automated way, fetch them and make use of them as described in RFC 8416.

Any resource holder can create AS0 (zero) ROAs for the resources they have under their account/administration. Creating a SLURM file containing similar information has the same effect on Relying Parties.

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. An table, whereas an RPKI ROA for the same prefixes with AS0 (zero) origin shows a negative intent – indicating that from the resource holder does not want the prefixes to be to have the prefixes advertised in the global BGP routing table.

SLURM files can convey the same exact information as AS0 ROAs, thus making this distribution mechanism equivalent to having attestations in the repository. SLURM files add flexibility on the Relying Parties. A configuration directive could add or remove the processing of these files.

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. While this 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;
• Creating and publishing a SLURM file gives users the chance to decide if they want to use the information or not for their networks. Relying Parties can decide to incorporate all the assertions from this file, or they can be left out.
• The SLURM file could be distributed using a CDN, and it should be frequently updated to reflect the status of the unallocated and unassigned address space held by RIPE NCC. This would easily allow for increased security in routing.
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;
• The authors note that it is possible to circumvent the protection of the assertions included in the SLURM file through the announcement of a less specific covering prefix. However, it is thought that hijackers of unallocated resources are trying to stay under the radar and by announcing a supernet which by definition also spans an allocated resource they 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 assertions covering all the unassigned and unallocated space might increase the operational costs for the Relying Party software by requiring them to run using more memory needed to process all the data. For IPv4, the impact should be very limited (as pointed out by Nick Hilliard, the assertions would essentially cover the “quarantine/cooldown pool”, temporary address pool, the IXP pool, and the /16 held in reserve), whereas for IPv6 there certainly will be a considerable number of assertions to be created due to the “sparse allocation” method used for it.

Changes from previous version

• The proposal moved from proposing to create ROAs to creating a SLURM file for use with Relying Parties/Validators.
• All the language has been adapted to reflect the fact that now what is being created are “assertions” and not ROAs.
• 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.

A. RIPE NCC's Understanding of the Proposed Policy

The proposed policy instructs the RIPE NCC to create and publish a SLURM file (Simplified Local Internet Number Resource Management with the RPKI), as described in RFC 8416. The file would contain assertions with the origin “AS0” for all unallocated and unassigned address space under our control. This includes all IPv4 and IPv6 address space which is published as available or reserved in the delegated extended statistics:

• IPv4 & IPv6 address space reserved for temporary assignments
• IPv4 & IPv6 address space reserved for Internet Exchange Point (IXP) assignments
• IPv4 & IPv6 address space in quarantine
• IPv4 & IPv6 address space in the available pool
• IPv6 address space reserved for future use

There are currently around 460 IPv4 and 70,000 IPv6 blocks for which we will need to create assertions in the SLURM file.

If the policy is accepted, we will delete the relevant assertions from the SLURM file when distributing address space, notifying users that the address space might not be routable for several hours.   

We will add a new assertion with origin AS0 to the SLURM file once a block has been de-registered and returned to the free pool.

There is currently no procedure/protocol for automatic fetching of SLURM files on the relaying party’s side. Our RPKI Validator will be modified to periodically fetch the SLURM file; it will be up to other validators to implement this feature at their own discretion.

B. Impact of Policy on Registry and Addressing System

This proposal moves the RIPE NCC from “registration authority” to a more active role in RPKI.

We will publish a SLURM file containing assertions with origin AS0 for all unallocated and unassigned address space under our control. It is up to the relying parties if they decide to incorporate all of the assertions from this file.

There might be a delay between a resource being allocated and RPKI validators fetching the updated SLURM file. This means that resources may not be routable immediately after they have been allocated.

If this proposal is accepted, the deregistration of address space will have a more direct impact on routing, because it will mark possible announcements as invalid. This means that a mistake in resource deregistration could cause immediate effects on live networks. However, our deregistration procedure is very detailed and includes an internal escalation process for prefixes that are announced in BGP.

C. Impact of Policy on RIPE NCC Operations/Services

The requirements of the proposal can be met without additional equipment or data sources. We will create and publish the SLURM file on a well-known site that will be communicated once the implementation has been completed.

Additionally, our RPKI Validator will be modified to periodically fetch the SLURM file and a new mechanism will be created to keep the file in-sync with the rest of the RPKI objects and highly available.

The process of creating and deleting assertions in the SLURM file will be automated. We therefore expect only a minor increase in our workload once the proposal has been implemented.

The potential for delayed usability of prefixes after they have been issued is likely to result in questions from some LIRs.

D. Legal Impact of Policy

The current RIPE NCC documents and legal framework related to RPKI is not covering the use of a SLURM file. We would therefore have to create a framework describing its use, setting clear expectations and defining each party's responsibilities.

We would also have to update the existing deregistration procedure to mention explicitly that when we deregister resources, an assertion with origin AS0 will be created in the SLURM file.

E. Implementation

With the information currently available, we expect that implementing this proposal would have a minor impact and would take around three months to complete.