avoiding RIPE IRR vs. RPKI ROA mismatches/inconsistencies
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? 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 similarly for updating/creating ROAs. 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." 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
here is a pointer to the thread on twitter where Alex Band added his opinion: https://twitter.com/alexander_band/status/1037703145873448961 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
Hi Nusenu,
Op 6 sep. 2018, om 14:57 heeft nusenu via db-wg <db-wg@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
Hi Nathalie, Nathalie Trenaman wrote:
Currently, there isn’t, but we have heard this request for a while and it is on our roadmap.
thanks for confirming, I was already glad to hear your comment [1] on this topic at last week's NLNOG day after Job's routing security roadmap presentation. From the discussions/emails/tweets it is not yet clear which exact way will be chosen to implement it (route object creation triggering the creation/modification of ROAs or vice versa) but I'm looking forward on having route and ROA creating/modification consolidated to reduce inconsistencies and maybe even increase the rate at which ROAs are created (if every new route object would result in the creation of a matching ROA). As the commentor after Job's talk said [1]: having this in two completely different places as it is currently isn't helping with consistency and adoption. It is certainly a good idea to talk to APNIC since they are already doing it and probably gathered some experiences that you could benefit from when implementing it for the RIPE interfaces. If you can share any rough timeline for this, that would be great. kind regards, nusenu [1] https://www.youtube.com/watch?v=3BAwBClazWc&t=2586 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
participants (2)
-
Nathalie Trenaman -
nusenu