Resource Authentication Key ( RAK ) code for third party authentication

Summary of Proposal

A lot of third party databases that are currently hosting route objects used for prefix filtering (such as Level3, NTT, RADB) are currently relying on the honest customer principle or signed Letters of Authorisation (LOAs) to authorise the usage of prefixes via a certain upstream provider. It is often difficult for upstream providers to check whether these documents are accurate or forged and providers  will accept almost anything an (honest) paying customer presents them with.

To make it easier for all parties to double check the actual authorisation of inetnums to be included in a certain third party database that is not linked to an RIR system (like Level3, NTT or RADB) for authentication, I want to ask the RIPE NCC to allow all number resources to be authenticated via an API-key system, to be verifiable by third parties. Also including more specifics or partial prefixes.

This proposal will introduce a digital version of the LOA, a Resource Authentication Key or a “RAK code” in short.

Policy Text

The RIPE community requests that the RIPE NCC implement functionality that allows all number resources, in exacts and more specifics, to be authenticated via an date expiring API-key.

This service should be provided to all resource holders regardless of whether they are members or not.

Implementation requirements

The envisioned API-key should allow a third party to check (through the API interfaces) which (list of) inetnums will be routed via a specific AS Number for a certain time.

A result set could provide multiple prefixes, a single AS and a single expiry date of the key. The creation timestamp on the API key should have a similar serial numbering to a DNS SOA record, which allows for accurate data checking (latest version of the object).

The first 2 bytes of the API key MUST be an identifier to the RIR originating the API-key.

Suggested Identifiers : RIPE-00, ARIN-01, LACNIC-02, APNIC-03, AFRINIC-04 etc.

Per RIR, there could also be a test DB identifier for testing.

An API key may be renewed manually (default) by the legitimate resource holder using the UI interface to a new date in the future, prior to expiry (with optional email notifications of pending expiry sent to the resource holder).

The third party must be able to check the API key for the listed number resources authenticated via the RIR and if the API key is still valid. If the API key is no longer valid, the third party MUST remove the invalid route object for proper housekeeping. 

Integration in the provided UI with RPKI for easy ROA creation is optional and desired (this could be handled in a second phase). The provided integration should be usable without mandatory RPKI usage.

Rationale

a. Arguments supporting the proposal

Currently there is no proper way for third party applications/databases like RADB to check if the input provided for route object creation in their system is actually authenticated by the legitimate resource holder. This leads to improper announcements in BGP and no housekeeping of stale route objects. 

By closing down (without authentication) the inclusion of RIPE space as input into a third parties like RADB, this implementation will directly reduce the impact of route leaks and BGP hijacks for RIPE-protected inetnums. It will provide a much better dataset for the third party databases, which will make their data more accurate and relevant as a future industry routing information source.

Databases that are not using the new system will be seen by the industry as no longer valid sources for RIPE prefix registration for route objects with out of region AS combinations, rendering themselves out of service/usage very soon.

b. Arguments opposing the proposal

This proposal will add more digital work on the integration side and will only support the RIPE region (currently). Every international transit provider that currently registers route objects on behalf of their customers in RADB or similar will have to adhere to the new method once the third-party database will lock down the acceptance of new RIPE inetnums in route objects.