Summary of proposal:
This 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.
Policy text:
New policy text:
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.
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 beforehand.
Address space can only be allocated once the ROA or ROAs with origin AS0 have been fully removed and are not visible in the repositories.
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 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.
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.