You're looking at an older version: 2
The current (published) version is 3This proposal instructs the RIPE NCC to create ROAs for all unallocated and unassigned address space under its 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 ROAs with origin AS0 for all the unallocated and unassigned address space (IPv4 and IPv6) for which it is the current administrator.
Any resource holder can create AS0 (zero) ROAs for the resources they have under their account/administration.
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 RPKI ROA for the same prefixes with AS0 (zero) origin shows a negative intent from the resource holder to have the prefixes advertised in the global BGP routing table.
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 will have to be revoked.
It is the RIPE NCC's understanding that this proposal instructs the RIPE NCC to create Route Origin Attestations (ROAs) with the origin ‘AS0’ for all unallocated and unassigned address space under 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 and includes the following categories:
There are currently nearly 500 IPv4 and 69000 IPv6 blocks for which the RIPE NCC will need to create 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, the RIPE NCC will delete the relevant AS0 ROAs when it distributes 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.
The RIPE NCC will create AS0 ROAs once a block has been de-registered and returned to the free pool.
This proposal shifts the RIPE NCC’s position on RPKI from a Registration Authority to a more active 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 because it will mark possible announcements as invalid. Thus a possible 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.
The 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 ROAs will be automated, hence only a minor impact on manual work carried out by the RIPE NCC is expected following policy implementation.
The delay in usability of the prefixes after they are issued is likely to lead to questions from LIRs asking for clarifications.
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, 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.