[db-wg] 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/db-wg/attachments/20180906/e829beff/attachment.sig>