You are here: Home > Participate > Policy Development > Policy Proposals > RIPE NCC IRR Database Non-Authoritative Route Object Clean-up

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

Legend (+) Added (-) Deleted
Changed Tag Added Tag Deleted

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 revoke incorrect publications about update / fix their intentions intention regarding which AS may 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 RIPE Database (marked source: RIPE-NONAUTH) may will be affected by this policy.

delete: <h2>   delete: </h2>

Policy Text

New policy text

Content delete: </h4> delete: <p> delete: <a href="#1-introduction" data-linktype="anchor" data-val="0"> 1.0 Introduction delete: </a> delete: <br /> delete: <a href="#2-policy-text" data-linktype="anchor" data-val="1"> 2.0 Policy Text delete: </a> delete: <br /> delete: <a href="#3-walsh" data-linktype="anchor" data-val="2"> 3.0 What About Legacy Space Holders? delete: </a> delete: <br /> delete: <a href="#4-attribution" data-linktype="anchor" data-val="3"> 4.0 Attribution delete: </a> delete: </p> delete: <h5> delete: <a id="1-introduction"> delete: </a> 1.0 Introduction delete: </h5> insert: </h4>

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 delete: <strong> route(6) delete: </strong> RIPE-NONAUTH route/route6 objects. RIPE-managed resources will not be affected by this procedure. delete: </p> delete: <h5> delete: <a id="2-policy-text"> delete: </a> insert: </p>

insert: <h4>

2.0 Policy Text delete: <strong> delete: <br /> delete: </strong> delete: </h5> insert: </h4>

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

delete: <p> To determine whether IRR objects are in conflict with RPKI ROAs, the Origin Validation procedure as outlined delete: <a href="https://tools.ietf.org/html/rfc6811" data-linktype="external" data-val="https://tools.ietf.org/html/rfc6811"> in RFC 6811 delete: </a> is applied, but instead of using BGP UPDATES as input into this validation process, the prefix and origin ASN pair from delete: <strong> route(6) delete: </strong> objects in the RIPE-NONAUTH are used. delete: </p> delete: <p> 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. delete: </p> delete: <h5> delete: <a id="3-walsh"> delete: </a> insert: <h3>

3.0 What About Legacy Space Holders? delete: </h5> delete: <p> The RIPE Policy delete: <a href="../../../../../resolveuid/3bc32d39af6d485c89f3f845b703db80" data-linktype="internal" data-val="3bc32d39af6d485c89f3f845b703db80"> “RIPE NCC Services to Legacy Internet Resource Holders” delete: </a> 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. delete: </p> delete: <h5> 4 delete: <a id="4-attribution"> delete: </a> .0 Attribution delete: </h5> insert: </h3>

This document is developed by the RIPE community. delete: </p> delete: <p>  

Rationale

a. Arguments supporting the proposal

delete: <ul> delete: <li> Presently, insert: <p>

Presently routing registry data can be found within both the RIPE IRR, RIPE-NONAUTH IRR, and RIPE’s IRR and the RPKI ROA database. For the first To-date, there has been no way to ensure consistency or allow clean-up between the 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. delete: </li> delete: <li> data sources. insert: </p>

insert: <p>

This proposal will allow a cleaner and more consistent method for deleting of creating and updating IRR data for the usage of filtering by leveraging using the authoritative nature of RPKI ROAs. If insert: </p>

insert: <p>

Over time, lots of information has been stored in the various IRRs and little to no RPKI ROA exists, nothing happens with the RIPE-NONAUTH entry. delete: </li> delete: <li> 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 authorisation (or lack of authorisation authorisation) is currently set up, there is room for abuse in the RIPE-NONAUTH IRR RIPE Database, because by creating out-of-region inetnums and out-of-region ASN’s without the consent of the resource holders may not be able to clean up routing information related to their resources. holder. insert: </p>

insert: <p>

Resource holders can reliably establish their routing intentions intent by using RPKI ROAs.   delete: </li> delete: </ul> ROAs if this proposal is implemented. insert: </p>

insert: <p>

No attempt is made to modify non-RIPE IRRs, except where the non-RIPE IRR is using replicated RIPE data. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

RIPE-managed resources that are already properly authorised will not be affected by this procedure. insert: </p>

b. Arguments opposing the proposal

delete: <ul> delete: <li> Removal of RIPE-NONAUTH objects may lead to operational issues of undefined nature. delete: <br /> 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. delete: </li> delete: <li> Removing IRR objects will impact researchers’ ability to inspect historic records delete: <br /> 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. delete: </li> delete: </ul> delete: <p>   delete: </p> delete: <h2> 4.0 Appendix  delete: </h2> delete: <p> The appendix exists for illustrative purposes and should not be considered an integral part of the Policy Proposal itself. delete: </p> delete: <h3> 4.1: Validation Examples delete: </h3> delete: <p>     Current as of May 13th 2019:  delete: </p> delete: <p>     delete: <strong> Example 1: delete: </strong> delete: </p> delete: <p>     delete: <code> ROA(s): 129.250.0.0/16 AS 2914 (ARIN TAL) delete: </code> delete: </p> delete: <p>     delete: <code> RIPE-NONAUTH IRR: 129.250.15.0/24 AS 60068 delete: </code> delete: </p> delete: <p>     Origin Validation result: invalid, therefore the IRR object must be deleted  delete: </p> delete: <p>     delete: <strong> Example 2: delete: </strong> 99.122.224.0/21 delete: </p> delete: <p>     delete: <code> ROA: 99.112.0.0/12, MaxLength: 12, Origin AS7018 (ARIN TAL) delete: </code> delete: </p> delete: <p>     delete: <code> RIPE-NONAUTH IRR entry: 99.122.224.0/21 AS 1273 delete: </code> delete: </p> delete: <p>     Origin Validation result: invalid, therefore the IRR object must be deleted delete: </p> delete: <p>     delete: <strong> Example 3: delete: </strong> delete: </p> delete: <p>     delete: <code> ROA: 156.38.1.0/24, MaxLength 24, Origin AS328145 (AFRNIC TAL) delete: </code> delete: </p> delete: <p>     delete: <code> IRR: 156.38.1.0/24 AS328145 delete: </code> delete: </p> delete: <p>     Origin Validation result: valid, the IRR object will not be deleted delete: </p> delete: <p>     delete: <strong> Example 4: delete: </strong> delete: </p> delete: <p>     delete: <code> ROA: n/a delete: </code> delete: </p> delete: <p>     delete: <code> IRR: 199.38.240.0/21 AS 394625 delete: </code> delete: </p> delete: <p>     Origin Validation result: unknown, the IRR object will not be deleted delete: </p> delete: <h3> 4.2: Analyser tool delete: </h3> delete: <p> An analyser tool is available at: delete: <a href="https://github.com/job/ripe-proposal-2018-06"> https://github.com/job/ripe-proposal-2018-06 delete: </a> delete: </p> delete: <h3> 4.3 Size of RIPE-NONAUTH database delete: </h3> delete: <p> The RIPE-NONAUTH database isn’t used by any routing software (and isn’t meant to be used either). It can be found at delete: <a href="ftp://ftp.ripe.net/ripe/dbase"> ftp://ftp.ripe.net/ripe/dbase delete: </a> as the file ripe-nonauth.db.gz (around 50MB uncompressed). The file breaks down as follows (May 2019). delete: </p> delete: <p>      $ curl -s delete: <a href="ftp://ftp.ripe.net/ripe/dbase/ripe-nonauth.db.gz"> ftp://ftp.ripe.net/ripe/dbase/ripe-nonauth.db.gz delete: </a> |\ delete: <br />      gunzip | egrep '^(aut-num|(route|route6)):' | cut -d: -f1 |\ delete: <br />      sort | uniq -c | sort -n delete: <br />     1750 route6 delete: <br />     2273 aut-num delete: <br />     64378 route delete: <br />     $ delete: </p> insert: <p>

none insert: </p>

Content

1.0 Introduction
2.0 Policy Text
delete: <a href="#3-0-walsh" data-linktype="anchor" data-val="2"> insert: <a href="#3-0-attribution" data-linktype="anchor" data-val="3"> 3.0 What About Legacy Space Holders? Attribution
delete: <a href="#4-0-attribution" data-linktype="anchor" data-val="3"> 4.0 Attribution delete: </a>

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 delete: <strong> route(6) delete: </strong> RIPE-NONAUTH route/route6 objects. RIPE-managed resources will not be affected by this procedure.

2.0 Policy Text

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

delete: <p> To determine whether IRR objects are in conflict with RPKI ROAs, the Origin Validation procedure as outlined in delete: <a href="https://tools.ietf.org/html/rfc6811"> RFC 6811 insert: <h2>

insert: <a name="3-0-attribution"> is applied, but instead of using BGP UPDATES as input into this validation process, the prefix and origin ASN pair from delete: <strong> route(6) delete: </strong> objects in the RIPE-NONAUTH are used. delete: </p> delete: <p> 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. delete: </p> delete: <h2> delete: <a id="3-0-walsh"> delete: </a> 3.0  delete: <strong> What About Legacy Space Holders? delete: </strong> delete: </h2> delete: <p> The RIPE Policy delete: <a href="../../../../../resolveuid/3bc32d39af6d485c89f3f845b703db80" data-linktype="internal" data-val="3bc32d39af6d485c89f3f845b703db80"> “RIPE NCC Services to Legacy Internet Resource Holders” delete: </a> 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. delete: </p> delete: <h2> delete: <a id="4-0-attribution"> delete: </a> 4.0 3.0 Attribution

This document is developed by the RIPE community.

 

Get Involved

The Routing Working Group defined the RIPE Routing Registry and promoted it worldwide. The WG exchanges information about the various Routing Registries. It is concerned with the growth of routing tables on the Internet and is working to decrease their size in Europe. Anyone with an interest in routing is welcome to observe and participate. To post a message to the list, send an email to [email protected] Please note that only subscribers can post messages.

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum

Please contact if you need more information.

Stay up to date!

Follow @PDO_RIPE_NCC on Twitter.