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 file The proposed policy It is the RIPE NCC's understanding that this proposal 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” Route Origin Attestations (ROAs) with the origin ‘AS0’ for all unallocated and unassigned address space under our control. 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
There are currently around 460 IPv4 and 70,000 nearly 500 IPv4 and 69000 IPv6 blocks for which we the RIPE NCC will need to create
assertions in the SLURM file.If the 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.
We will add a new assertion with origin AS0 to the SLURM file 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.
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” shifts the RIPE NCC’s position on RPKI from a 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, theThe 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 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 maintenance and protection of the additional RPKI infrastructure will require extra resources following policy implementation.
The process of creating and deleting assertions in the SLURM file will be automated. We therefore expect ROAs will be automated, hence only a minor
increase in our workload once the proposal has been implemented.The potential for delayed usability of impact on manual work carried out by the RIPE NCC is expected following policy implementation.The delay in usability of the
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.
There are several procedures that will need to be updated to make it explicit that we will create AS0 ROAs when deregistering resources.
With the information currently available, we expect that implementing this proposal would have a minor impact and would take around three months to complete. 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.