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.