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.
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.
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 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.
4.0This document was is developed by the RIPE community, specifically Job Snijders, Erik Bais, and Martin Levy. community.
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.
The appendix exists for illustrative purposes and should not be considered an integral part of the Policy Proposal itself.
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
An analyser tool is available at: https://github.com/job/ripe-proposal-2018-06 Link: https://github.com/job/ripe-proposal-2018-06
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
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.
No impact is expected by this proposed policy on the registry and addressing system.
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.
There is no significant legal impact expected if this policy reaches consensus.
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.