You are here: Home > Participate > Policy Development > Policy Proposals > SLURM file for Unallocated and Unassigned RIPE NCC Address Space

Changes to SLURM file for Unallocated and Unassigned RIPE NCC Address Space

Legend (+) Added (-) Deleted
Changed Tag Added Tag Deleted

Summary of proposal:

This proposal instructs the RIPE NCC to create ROAs a SLURM file containing assertions for all unallocated and unassigned address space under its control. control with originating ASN AS0. 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: insert: <strong>                            insert: </strong>

New policy text:

The RIPE NCC will create ROAs a SLURM file containing assertions 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. delete: <br /> delete: <br /> Creating a SLURM file containing similar information has the same effect on Relying Parties. insert: </p>

insert: <p>

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

insert: <p>

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. insert: </p>

insert: <p>

The RIPE NCC has the authority to create RPKI ROAs for address space not yet allocated or assigned to its members. delete: </p> delete: <p> 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. delete: <br /> delete: <br /> If the RIPE NCC wants to allocate address space to one of its members, the RPKI ROA or ROAs will update the relevant entry in the SLURM file with origin AS0 will have to be revoked. at the time of allocating address space to one of its members.

delete: <br /> 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 While 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. spam; insert: </li>
  • insert: <li>
  • 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. insert: </li>
  • insert: <li>
  • 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.
insert: <p>

  insert: <strong>   insert: </strong> insert: </p>

delete: <br /> b. Arguments opposing the proposal

    delete: <li> 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; delete: </li>
  • 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; delete: </li> delete: <li> 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 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 likely to try staying trying to stay under the radar and by announcing a supernet which by definition also spans an allocated resource, 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 ROAs assertions 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 Relying Party software by requiring them to run using more memory needed by validators to process all the data. For IPv4, the impact should be very limited (as pointed out by Nick Hilliard, the AS0 ROAs assertions would essentially cover the “quarantine/cooldown pool”, the temporary address pool, the IXP pool, and the /16 held in reserve). However a significant reserve), whereas for IPv6 there certainly will be a considerable number of ROAs will need assertions to be created for IPv6 due to the “sparse allocation” method used for it. insert: </li>
  • insert: </ul>
insert: <p>

  insert: </p>

insert: <h2>

Changes from previous version insert: </h2>

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

Impact Analysis

A. RIPE NCC's Understanding of the Proposed Policy

It is the RIPE NCC's understanding that this proposal The proposed policy instructs the RIPE NCC to create Route Origin Attestations (ROAs) 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’ “AS0” for all unallocated and unassigned address space under its our 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: statistics:

  • IPv4 Address Space & IPv6 address space reserved for Temporary Assignments temporary assignments
  • IPv4 Address Space & IPv6 address space reserved for Internet Exchange Point (IXP) Assignments assignments
  • IPv4 Address Space & IPv6 address space in quarantine
  • IPv4 Address Space & IPv6 address space in the available pool
  • IPv6 Address Space reserved for Temporary Assignments delete: </li> delete: <li> IPv6 Address Space reserved for Internet Exchange Point (IXP) Assignments delete: </li> delete: <li> IPv6 Address Space in quarantine delete: </li> delete: <li> IPv6 Address Space in the available pool delete: </li> delete: <li> IPv6 Address Space address space reserved for future use

  insert: </p>

insert: <p>

There are currently nearly 500 around 460 IPv4 and 69000 70,000 IPv6 blocks for which the RIPE NCC we will need to create ROAs. delete: </p> delete: <p> 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. assertions in the SLURM file.

If this the policy is accepted, the RIPE NCC we will delete the relevant AS0 ROAs assertions from the SLURM file when it distributes distributing 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.  delete: </p> delete: <p> The RIPE NCC will create    insert: </p>

insert: <p>

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

insert: <p>

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. insert: </p>

B. Impact of Policy on Registry and Addressing System

This proposal shifts moves the RIPE NCC’s position on RPKI NCC from a Registration Authority “registration authority” to a more active participant. delete: </p> delete: <p> The use of a dedicated Trust Anchor to create role in RPKI. insert: </p>

insert: <p>

We will publish a SLURM file containing assertions with origin AS0 ROAs 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. insert: </p>

insert: <p>

There might also be less effective than intended as 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. insert: </p>

insert: <p>

If 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. delete: </p> delete: <p> 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. delete: </p> delete: <p> 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 is accepted, the deregistration of address space will have a more direct impact on routing routing, because it will mark possible announcements as invalid. Thus a possible This means that a 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. 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 requirement to have a specific Trust Anchor means 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 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 will be communicated once the implementation has been completed. insert: </p>

insert: <p>

Additionally, our RPKI infrastructure to accommodate the policy requirement. delete: </p> delete: <p> The maintenance and protection of the additional 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 infrastructure will require extra resources following policy implementation. objects and highly available.

The process of creating and deleting ROAs will be automated, hence assertions in the SLURM file will be automated. We therefore expect only a minor impact on manual work carried out by the RIPE NCC is expected following policy implementation. increase in our workload once the proposal has been implemented.

The delay in potential for delayed usability of the prefixes after they are have been issued is likely to lead to result in questions from LIRs asking for clarifications. delete: </p> delete: <p>   some LIRs.

D. Legal Impact of Policy

There are several procedures 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. insert: </p>

insert: <p>

We would also have to update the existing deregistration procedure to mention explicitly that will need to be updated to make it explicit that when we will create deregister resources, an assertion with origin AS0 ROAs when deregistering resources. will be created in the SLURM file.

E. Implementation

With the information currently available, it is expected we expect that implementation of implementing this proposal is likely to would have a minor impact and would take at least six around three months to have a separate production-grade Trust Anchor. Internal and external processes and documentation will also need to be updated. delete: </p> complete. insert: </p>

Policy text:

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

Only the 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. insert: </p>

insert: <p>

The RIPE NCC has the authority to create RPKI ROAs for will update the relevant entry in the SLURM file with origin AS0 at the time of allocating address space not yet allocated or assigned to to one of its members.

delete: <p> 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. delete: </p> delete: <p> 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. delete: </p> delete: <p>   delete: </p>
2019-08: RPKI ROAs SLURM file for Unallocated and Unassigned RIPE NCC Address Space
RPKI ROAs SLURM file for Unallocated and Unassigned RIPE NCC Address Space
Get Involved

The Routing Working Group defined the RIPE Routing Registry and promoted it worldwide. The WG exchanges information about the various Routing Registries. It is concerned with the growth of routing tables on the Internet and is working to decrease their size in Europe. Anyone with an interest in routing is welcome to observe and participate. To post a message to the list, send an email to routing-wg@ripe.net. Please note that only subscribers can post messages.

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum

Please contact if you need more information.

Stay up to date!

Follow @PDO_RIPE_NCC on Twitter.