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 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 RIPE Database (marked source: RIPE-NONAUTH) are will be affected by this policy. delete: </p> delete: <p>
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 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 (known as “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. The following process will be followed: delete: </p> delete: <ol> delete: <li> 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" data-linktype="external" data-val="https://tools.ietf.org/html/rfc6811"> 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 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”. delete: </li> delete: </ol> delete: <ol start="2"> delete: <li> 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. delete: </li> delete: </ol> delete: <ol start="3"> delete: <li> 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. delete: </li> delete: </ol> delete: <ol start="4"> delete: <li> 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. delete: </li> delete: </ol> delete: <h4> insert: </p>
insert: <h3>3.0 What about legacy space holders? delete: </h4> 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 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. delete: </p> delete: <h4> 4.0 Attribution delete: </h4> insert: </h3>
This document was is developed by the RIPE community, specifically Job Snijders, Erik Bais, and Martin Levy. delete: </p> delete: <p> delete: <strong> delete: </strong> community.
Rationale
a. Arguments supporting the proposal
delete: <ul> delete: <li> Presently, insert: <p>Presently routing registry data can be found in the RIPE IRR, RIPE’s within both the RIPE IRR and the RPKI ROA and RIPE-NONAUTH IRR 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, as well as 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 purpose 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> delete: <p> 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.
b. Arguments opposing the proposal
delete: <ul> delete: <li> Removal of RIPE-NONAUTH objects may lead to operational issues of an undefined nature. delete: <br /> 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. delete: </li> delete: <li> Removing IRR objects will impact researchers’ ability to inspect historic records. delete: <br /> 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. delete: </li> delete: </ul> delete: <p> delete: </p> delete: <h2> 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: <p> delete: </p> delete: <h3> 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> 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> 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> delete: <hr /> delete: <h2> delete: <a id="impact-analysis"> delete: </a> Impact Analysis delete: </h2> delete: <h3> A. RIPE NCC's Understanding of the Proposal delete: </h3> delete: <p> It is the RIPE NCC’s understanding that this policy change will introduce a new process to check if delete: <strong> out-of-region delete: </strong> delete: <strong> route(6) delete: </strong> objects in the non-authoritative RIPE Internet Routing Registry (IRR) are in conflict with delete: <strong> Route Origin Authorisation delete: </strong> (ROA) objects. delete: </p> delete: <p> 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 delete: <strong> route(6) delete: </strong> object itself is considered ‘out-of-region’. There are currently around 64,000 delete: <strong> route delete: </strong> and 1,700 delete: <strong> route6 delete: </strong> objects with the ‘source: RIPE-NONAUTH’ attribute. delete: </p> delete: <p> IRR objects with the attribute ‘source: RIPE’ are not affected by this proposed policy. delete: </p> delete: <p> 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 delete: <strong> route(6) delete: </strong> object will be deleted by the RIPE NCC. delete: </p> delete: <p> The policy refers to delete: <a href="https://tools.ietf.org/html/rfc6811" data-linktype="external" data-val="https://tools.ietf.org/html/rfc6811"> RFC 6811 delete: </a> for the validation procedure. It is, therefore, the RIPE NCC’s understanding that a conflict exists if a delete: <strong> route(6) delete: </strong> 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. delete: </p> delete: <p> 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 delete: <strong> route(6) delete: </strong> 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. delete: </p> delete: <p> 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. delete: </p> delete: <p> If the delete: <strong> route(6) delete: </strong> 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. delete: </p> delete: <p> If the conflict still exists after 14 days, the delete: <strong> route(6) delete: </strong> 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 delete: <a href="https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objects-in-the-ripe-database"> RIPE Database Working Group delete: </a> . delete: </p> delete: <p> If after the deletion, the resource holder realizes that the deleted delete: <strong> route(6) delete: </strong> was actually valid, the RIPE NCC in cooperation with the other RIRs will provide guidance on how to create an alternative solution. delete: </p> delete: <p> delete: </p> delete: <h3> B. Impact of Policy on Registry and Addressing System delete: </h3> delete: <p> No impact is expected by this proposed policy on the registry and addressing system. delete: </p> delete: <p> delete: </p> delete: <h3> C. Impact of Policy on RIPE NCC Operations/Services delete: </h3> delete: <p> 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. delete: </p> delete: <p> 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. delete: </p> delete: <p> delete: <strong> delete: </strong> delete: </p> delete: <h3> D. Legal Impact of Policy delete: </h3> delete: <p> There is no significant legal impact expected if this policy reaches consensus. delete: </p> delete: <p> delete: <strong> delete: </strong> delete: </p> delete: <h3> E. Implementation delete: </h3> delete: <p> 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. delete: </p> delete: <p> delete: </p> insert: <p>none insert: </p>
Content
1.0 Introduction
2.0 Policy Text
delete: <a href="#3-0-what-about-legacy-space-holders-" data-linktype="anchor" data-val="3"> 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="4"> 4.0 Attribution insert: </p>
insert: <a name="1-0-introduction"> delete: </p> delete: <h3> delete: <a href="#4-0-attribution" name="1-0-introduction" data-linktype="anchor" data-val="4"> delete: </a> delete: <a href="#4-0-attribution" data-linktype="anchor" data-val="4"> 1.0 Introduction delete: </a> delete: </h3> insert: </h2>
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 RIPE-NONAUTH route/route6 objects. RIPE-managed resources will not be affected by this procedure.
delete: <p> delete: <strong> delete: </strong> delete: </p> delete: <h3> insert: <h2>2.0 Policy Text delete: </h3> insert: </h2>
If an a non-authoritative object stored in the non-authoritative RIPE IRR (known as “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. The following process will be followed:
delete: <ol> delete: <li> 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" data-linktype="external" data-val="https://tools.ietf.org/html/rfc6811"> 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 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”. delete: </li> delete: </ol> delete: <ol start="2"> delete: <li> 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. delete: </li> delete: </ol> delete: <ol start="3"> delete: <li> 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. delete: </li> delete: </ol> delete: <ol start="4"> delete: <li> 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. delete: </li> delete: </ol> delete: <p> delete: </p> delete: <h3> delete: <a name="3-0-what-about-legacy-space-holders-"> insert: <h2>insert: <a name="3-0-attribution"> 3.0 What about legacy space holders? delete: </h3> 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 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. delete: </p> delete: <p> delete: <strong> delete: </strong> delete: </p> delete: <h3> delete: <a name="4-0-attribution"> delete: </a> 4.0 Attribution delete: </h3> insert: </h2>
This document was is developed by the RIPE community, specifically Job Snijders, Erik Bais, and Martin Levy. community.