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.

The RIPE NCC will update the relevant entry in the SLURM file

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 at the time of allocating address space to one of its members. 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. 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;
• 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 assertions included in the SLURM file AS0 ROA through the announcement of a less specific covering prefix. However, it is thought that hijackers of unallocated resources are trying to stay likely to try staying under the radar and by announcing a supernet which by definition also spans an allocated resource they 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 assertions ROAs 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 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 assertions AS0 ROAs would essentially cover the “quarantine/cooldown pool”, the temporary address pool, the IXP pool, and the /16 held in reserve), whereas for IPv6 there certainly will be a considerable number of assertions reserve). However a significant number of ROAs will need to be created for IPv6 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.

A. RIPE NCC's Understanding of the Proposed Policy

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

• statistics:
• IPv4 & IPv6 address space reserved for temporary assignments
IPv4 & IPv6 address space statistics and includes the following categories:
• IPv4 Address Space reserved for Temporary Assignments
IPv4 Address Space reserved for Internet Exchange Point (IXP)
• assignmentsIPv4 & IPv6 address space AssignmentsIPv4 Address Space
in quarantine
• IPv4 & IPv6 address space Address Space in the available pool
• IPv6 address space 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 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.

If this

policy is accepted, we the RIPE NCC will delete the relevant assertions from the SLURM file when distributing AS0 ROAs when it distributes address space, notifying the 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 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.

B. Impact of Policy on Registry and Addressing System

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, the 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, routing because it will mark possible announcements as invalid. This means that a Thus a possible 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. 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 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.

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 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

prefixes after they have been are issued is likely to result in questions from some LIRs. lead to questions from LIRs asking for clarifications.

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.

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, 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.