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.
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.
The RIPE NCC will update the relevant entry in the SLURM fileThe 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:
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.
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.
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.
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.
With the information currently available, we expect that implementing this proposal would have a minor impact and would take around three months to complete.