Summary of Proposal

The goal of this proposal is to change the business rules for the RIPE Internet Routing Registry (IRR) service database to allow for a better hierarchy and to document this. This will give the resource holder the ability to modify update / fix their intention regarding which AS will announce their IP resources.

Using this update, the various tools will produce a much cleaner filter set with a high level of trust in the actual resource holder’s intent on the routing of their resources.

Only non-RIPE-managed IP non-RIPE resources in the Non-Authoritative RIPE IRR Database (marked source: RIPE-NONAUTH) are RIPE Database will be affected by this policy.

Policy Text

New policy text

1.0 Introduction

Routing information can be found within the authoritative RIPE Internet Routing Registry (IRR), the RPKI ROA database, and the non-authoritative RIPE IRR Database (“RIPE-NONAUTH”). Publication of incorrect IRR. Incorrect routing information can be problematic for Internet operations, specifically in the context of the non-authoritative RIPE IRR, as the holder of a resource might have never consented to the creation of non-authoritative route/route6 objects. RIPE-managed resources will not be affected by this procedure. RIPE-NONAUTH route/route6 objects.

2.0 Policy Text

If an a non-authoritative object stored in the non-authoritative RIPE IRR (known as “RIPE-NONAUTH”) conflicts with a RIPE IRR conflicts with an RPKI ROA issued by one of the five RIRs, then the IRR object must be deleted by the RIPE NCC.

The following process will be followed:

1. To determine whether IRR objects are in conflict with RPKI ROAs, the Origin Validation procedure as outlined in RFC 6811 Link: https://tools.ietf.org/html/rfc6811 is applied, but instead of using BGP UPDATES as input into this validation process, the prefix and origin ASN pair from route/route6 objects in the RIPE-NONAUTH are used. RIPE-NONAUTH objects for which the Origin Validation procedure returned the state “invalid” are hereafter called “Conflicting RIPE-NONAUTH Objects”. 

2. When a Conflicting RIPE-NONAUTH Object is discovered, the RPSL notification attributes will be used (if present) in the Conflicting RIPE-NONAUTH Object to inform the holder of the IRR object about the upcoming deletion. 

3. When a Conflicting RIPE-NONAUTH Object is discovered, the RIR RDAP system can be used to attempt to find contact details for the IP resource owner and inform them about the upcoming deletion of the Conflicting RIPE-NONAUTH Object.

4. When the Conflicting RIPE-NONAUTH Object has been in conflict with any RPKI ROA for 14 consecutive days, the Conflicting RIPE-NONAUTH Object is deleted and a final notification is sent to the applicable contact information retrieved during step 2 and 3.

3.0 What about legacy space holders?

The RIPE Policy “RIPE NCC Services to Legacy Internet Resource Holders” Link: /publications/docs/ripe-639/ limits itself to providing services to legacy holders in the RIPE NCC service region. The policy states that any new policy should mention legacy if it also affects legacy holders. As this proposal only applies to IRR objects covering non-RIPE-managed resources in the RIPE-NONAUTH IRR, this requirement doesn’t apply.

This document was is developed by the RIPE community, specifically Job Snijders, Erik Bais, and Martin Levy. community.

Rationale

a. Arguments supporting the proposal

• Presently, Presently routing registry data can be found in the RIPE IRR, RIPE’s RPKI ROA and RIPE-NONAUTH IRR database. For the first two of these three sources, the community can trust that the owner of the resource gave explicit permission. This is not the case for RIPE-NONAUTH, which contains entries for legacy IPv4 space that is not managed by RIPE NCC, as well as other non-RIPE-managed IP resources.
within both the RIPE IRR and the RPKI ROA database. To-date, there has been no way to ensure consistency or allow clean-up between the two data sources.
• This proposal will allow a cleaner and more consistent method for deleting consistent method of creating and updating IRR data for the purpose usage of filtering by leveraging using the authoritative nature of RPKI ROAs. If no RPKI ROA exists, nothing happens with the RIPE-NONAUTH entry.
Over time, lots of information has been stored in the various IRRs and little to no clean-up has been done, resulting in a blurred view of the prefixes that have been authorised by a resource holder.
• Due to the way the lack of authorisation authorisation (or lack of authorisation) is currently set up, there is room for abuse in the RIPE-NONAUTH IRR Database, because resource holders may not be able to clean up routing information related to their resources. RIPE Database, by creating out-of-region inetnums and out-of-region ASN’s without the consent of the resource holder. Resource holders can reliably establish their routing intentions intent by using RPKI ROAs.  

No attempt is made to modify non-RIPE IRRs, except where the non-RIPE IRR is using replicated RIPE data.

RIPE members need only update one database (i.e. RPKI ROAs) to have both the legacy-IRR database and the going-forward RPKI database fully updated and synchronised.

RIPE-managed resources that are already properly authorised will not be affected by this procedure.

b. Arguments opposing the proposal

• Removal of RIPE-NONAUTH objects may lead to operational issues of an undefined nature.

  Corollary - existence of RIPE-NONAUTH objects may lead to operational issues, RPKI ROAs should be considered a data source with higher precedence. It is not in the best interest of the RIPE community to publish incorrect routing information with no recourse for the owner of the resource to correct or delete that information.

• Removing IRR objects will impact researchers’ ability to inspect historic records.

  Corollary: The RIPE NCC has no obligation to provide historic archives. Researchers can archive the RIPE-NONAUTH data set themselves. As the RIPE-NONAUTH can’t be updated (key: resource / AS number ) any copy of the RIPE-NONAUTH will provide all data for research to the current state minus the deletions.

Appendix

The appendix exists for illustrative purposes and should not be considered an integral part of the Policy Proposal itself.

Validation Examples

Current as of May 13th 2019:

Example 1:

ROA(s): 129.250.0.0/16 AS 2914 (ARIN TAL)

RIPE-NONAUTH IRR: 129.250.15.0/24 AS 60068

Origin Validation result: invalid, therefore the IRR object must be deleted

Example 2: 99.122.224.0/21

ROA: 99.112.0.0/12, MaxLength: 12, Origin AS7018 (ARIN TAL)

RIPE-NONAUTH IRR entry: 99.122.224.0/21 AS 1273

Origin Validation result: invalid, therefore the IRR object must be deleted

Example 3:

ROA: 156.38.1.0/24, MaxLength 24, Origin AS328145 (AFRNIC TAL)

IRR: 156.38.1.0/24 AS328145

Origin Validation result: valid, the IRR object will not be deleted

Example 4:

ROA: n/a

IRR: 199.38.240.0/21 AS 394625

Origin Validation result: unknown, the IRR object will not be deleted

Analyser tool

An analyser tool is available at: https://github.com/job/ripe-proposal-2018-06 Link: https://github.com/job/ripe-proposal-2018-06

Size of RIPE-NONAUTH database 

The RIPE-NONAUTH database isn’t used by any routing software (and isn’t meant to be used either). It can be found at ftp://ftp.ripe.net/ripe/dbase Link: ftp://ftp.ripe.net/ripe/dbase as the file ripe-nonauth.db.gz (around 50MB uncompressed). The file breaks down as follows (May 2019).

$ curl -s ftp://ftp.ripe.net/ripe/dbase/ripe-nonauth.db.gz Link: ftp://ftp.ripe.net/ripe/dbase/ripe-nonauth.db.gz |\
gunzip | egrep '^(aut-num|(route|route6)):' | cut -d: -f1 |\
sort | uniq -c | sort -n
1750 route6
2273 aut-num
64378 route
$

none

A. RIPE NCC's Understanding of the Proposal

It is the RIPE NCC’s understanding that this policy change will introduce a new process to check if out-of-region route(6) objects in the non-authoritative RIPE Internet Routing Registry (IRR) are in conflict with Route Origin Authorisation (ROA) objects.

The scope of this policy is limited to IRR objects with the attribute ‘source: RIPE-NONAUTH’. This attribute indicates that the prefix mentioned is not registered in the RIPE region, and consequently the route(6) object itself is considered ‘out-of-region’. There are currently around 64,000 route and 1,700 route6 objects with the ‘source: RIPE-NONAUTH’ attribute.

IRR objects with the attribute ‘source: RIPE’ are not affected by this proposed policy.

If during the validation procedure, a conflict is detected between information in a ROA from another RIR and the RIPE NON-AUTH IRR object, the holder of the IRR object and the Internet resource holder will be informed about the conflict. If the conflict still exists after 14 consecutive calendar days, the route(6) object will be deleted by the RIPE NCC.

The policy refers to RFC 6811 Link: https://tools.ietf.org/html/rfc6811 for the validation procedure. It is, therefore, the RIPE NCC’s understanding that a conflict exists if a route(6) prefix is either identical to the prefix mentioned in the ROA or more specific than the prefix. Currently roughly 800 such conflicts have been observed, based on the script developed by the proposers.

The RIPE NCC will develop a fully-automated process that regularly compares the RPKI ROA database with the non-authoritative RIPE IRR. If a conflict is detected, a warning email will be sent to available email addresses that are mentioned or referenced in the relevant route(6) object. A second email will be sent to the resource holder. Available contact information from the databases of the other four Regional Internet Registries will be used, by looking for registration details of the range that are an exact match or the closest less specific range to the ROA.

The warning emails will contain details of the observed conflict as well as guidance on how to resolve the observed conflict. If deemed useful, the RIPE NCC will send additional reminders to the involved parties during the 14-day period after the conflict has been detected.

If the route(6) in the non-authoritative RIPE is legitimate (for example a European branch of the resource holder), the conflict can be resolved by the resource holder by creating a matching ROA.

If the conflict still exists after 14 days, the route(6) object will be deleted automatically. This deletion will be irreversible. Further, the non-authoritative RIPE IRR doesn’t allow the creation of new entries, following a decision of the RIPE Database Working Group Link: https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objects-in-the-ripe-database .

If after the deletion, the resource holder realizes that the deleted route(6) was actually valid, the RIPE NCC in cooperation with the other RIRs will provide guidance on how to create an alternative solution.

B. Impact of Policy on Registry and Addressing System

No impact is expected by this proposed policy on the registry and addressing system.

C. Impact of Policy on RIPE NCC Operations/Services

Currently, around 800 conflicts have been observed that could be resolved during the initial implementation phase. It is expected that over time more conflicts will be uncovered, as more related resources are protected by ROAs.

Since the process will be automated, only a minor impact on manual work carried out by the RIPE NCC is expected following policy implementation. Some contacted parties are likely to ask the RIPE NCC for further clarifications. In such cases, additional guidance will be provided, especially regarding how to resolve the conflict between ROA and IRR objects or how to find an alternative solution.

D. Legal Impact of Policy

There is no significant legal impact expected if this policy reaches consensus.

E. Implementation

With the information currently available, it is expected that implementation of this proposal is likely to take around two months in terms of the software development to facilitate the policy changes in internal RIPE NCC systems. Internal and external processes and documentation would also need to be updated.