RIPE NCC IRR Database Non-Authoritative Route Object Clean-up

Summary of Proposal

The goal of this proposal is to change the business rules for the RIPE Internet Routing Registry (IRR) service to allow for a better hierarchy and to document this. This will give the resource holder the ability to revoke incorrect publications about their intentions regarding which AS may 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 resources in the Non-Authoritative RIPE IRR Database (marked source: RIPE-NONAUTH) may be affected by this policy.

Policy Text

New policy text

Content

1.0 Introduction
2.0 Policy Text
3.0 What About Legacy Space Holders?
4.0 Attribution

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 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(6) objects. RIPE-managed resources will not be affected by this procedure.

2.0 Policy Text

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

To determine whether IRR objects are in conflict with RPKI ROAs, the Origin Validation procedure as outlined in RFC 6811 is applied, but instead of using BGP UPDATES as input into this validation process, the prefix and origin ASN pair from route(6) objects in the RIPE-NONAUTH are used.

For RIPE-NONAUTH objects (that are in conflict with a RPKI ROA), the RPSL notification attributes will be used (if present) in the to-be-deleted RIPE-NONAUTH object, to inform the holder of the IRR object about the upcoming deletion. Seven days after the RPKI ROA has first been observed, the conflicting IRR is finally deleted.

3.0 What About Legacy Space Holders?

The RIPE Policy “RIPE NCC Services to Legacy Internet Resource Holders” limits itself to providing services to legacy holders in the RIPE NCC service region. The policy states that 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.

4.0 Attribution

This document is developed by the RIPE community.

Rationale

a. Arguments supporting the proposal

• Presently, routing registry data can be found within both the RIPE IRR, RIPE-NONAUTH IRR, and RIPE’s RPKI ROA 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, and other non-RIPE-managed IP resources.
• This proposal will allow a cleaner and more consistent method for deleting IRR data for the usage of filtering by leveraging the authoritative nature of RPKI ROAs. If no RPKI ROA exists, nothing happens with the RIPE-NONAUTH entry.
• Due to the way the 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. Resource holders can reliably establish their routing intentions by using RPKI ROAs.  

b. Arguments opposing the proposal

• Removal of RIPE-NONAUTH objects may lead to operational issues of undefined nature.
  Corollary - existence of RIPE-NONAUTH objects may lead to operational issues, RPKI ROAs should be considered a datasource with higher precedence. It is not in the best interest of the RIPE community to publish incorrect routing information with no recourse for the holder of a resource to correct or delete this information.
• Removing IRR objects will impact researchers’ ability to inspect historic records
  Corollary: 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.

4.0 Appendix 

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

4.1: 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

4.2: Analyser tool

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

4.3 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 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 |\
     gunzip | egrep '^(aut-num|(route|route6)):' | cut -d: -f1 |\
     sort | uniq -c | sort -n
    1750 route6
    2273 aut-num
    64378 route
    $