This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] avoiding RIPE IRR vs. RPKI ROA mismatches/inconsistencies
- Previous message (by thread): [db-wg] avoiding RIPE IRR vs. RPKI ROA mismatches/inconsistencies
- Next message (by thread): [db-wg] avoiding RIPE IRR vs. RPKI ROA mismatches/inconsistencies
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nathalie Trenaman
nathalie at ripe.net
Mon Sep 10 12:16:16 CEST 2018
Hi Nusenu, > Op 6 sep. 2018, om 14:57 heeft nusenu via db-wg <db-wg at ripe.net> het volgende geschreven: > > Dear DB Working Group, > > when looking into RPKI and RIPE IRR coverage I stumbled on > prefixes that are covered by a RIPE route object and a RPKI ROA, which is great, > but there are cases where these records make conflicting statements about the origin > of a prefix. > > example: 185.46.20.0/22 > origin according to ROA: AS199785 > origin according to route object: AS61952 > origin according to RIS: AS61952 (matches route object) > > Note: this is just an example to better illustrate the issue. > (I didn't do a comprehensive analysis to be able to tell how > often this is the case but for a sample of ~1900 prefixes I found > 3 such occurrences.) > > Since route objects and ROAs are created by the prefix holders > this is possible (human mistake). > > Are there any measures in place to prevent or at least warn about > the inconsistency when the IP holder creates/updates route objects and ROAs > that would result in inconsistencies? Currently, there isn’t, but we have heard this request for a while and it is on our roadmap. There was the problem however that the creation of a route(6) needed authorisation from the ASN holder and a ROA didn’t. As you know, we just fixed this last week as part of the NWI-5 implementation, so there is more “feature parity” between the two that make this change possible. > > What do you think about an UI feature that says something like: > > "You are about to change/create the route object for prefix ... > would you also like to update the existing ROA to match the route object > and help avoid inconsistencies?" > > [ ] yes [ ] no, I know what I'm doing, I'll fix the mismatch manually Exactly as you proposed, our designer is on it. However, we would like to hear your and the WGs thoughts on using the LIR Portal to (not only) create ROAs, but route(6) objects as well. Should we remove the creation of route(6) objects from Webupdates to facilitate the improvement of the IRR data? Curious to hear thoughts and ideas. > > > Should there even be a 'No' option? > Should the question even be exposed to the user or should records simply be synced automatically once one > of either is changed by the IP holder? and simply showing an info like: "We took care of updating your ROA/route object to keep in sync.” APNIC already has this in their portal for a while, so I will check with them how they set it up. Kind regards, Nathalie Trenaman RIPE NCC > > In case there are well established best practices for an ASN change of a prefix > these best practices should be incorporated > (i.e. delete the route object and ROA, change the actual announcement in BGP, > create new route and ROAs that match the announcement) > > > kind regards, > nusenu > > -- > https://twitter.com/nusenu_ > https://mastodon.social/@nusenu >
- Previous message (by thread): [db-wg] avoiding RIPE IRR vs. RPKI ROA mismatches/inconsistencies
- Next message (by thread): [db-wg] avoiding RIPE IRR vs. RPKI ROA mismatches/inconsistencies
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]