On Tue, Aug 20, 2024 at 01:11:40PM +0100, Nick Hilliard wrote: > Wessel Sandkuijl wrote on 20/08/2024 12:51: > > I think this is something that can be improved. I suggest > > implementing the option to force-delete a route(6) object as ASN > > resource holder. This saves both the resource holder and RIPE NCC > > valuable time. > > there's definitely an issue here, but I wonder if the authorisation model is > opened up a bit, whether that would open up a can of worms (e.g. if you can > auth a delete, why shouldn't you be able auth a create?). > > Would someone from the RIPE NCC be able to provide some suggestions about > how this situation could be addressed?
Back in the olden days, creation of a 'route:' required both the prefix holder and the AS holder to 'cosign' the object into existence. This proved to be problematic in situations where the prefix was managed by RIPE NCC, and the origin ASN was managed by (for example) ARIN, in such cases the AS holder didn't have an aut-num & associated mntner object in the RIPE db, and requiring them to create one caused proliferation and duplication of data across RIR IRR databases. Re-evaluation of the route-object authorisation model was kicked off here: https://www.ripe.net/ripe/mail/archives/db-wg/2015-May/004597.html The outcome of this work was that the 'route:' authorization model was modeled similar to how RPKI ROAs are authorized: the prefix owner is the sole authorization controller. I suspect that this change drasticly reduced support burden for RIPE NCC & other RIR staff, at the cost of the odd 'route:' object referencing a random ASN as seems to have happened in Wessel's case. In the IETF work is under way to allow AS holders (such as Wessel) publish attestations about what prefixes they *might* originate, in turn also allowing Relying Parties to figure out what prefixes are considered out-of-scope from the AS holder's perspective (by virtue of not being listed in an SPL) https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-prefixlist-02.html https://www.ietf.org/archive/id/draft-sriram-sidrops-spl-verification-00.html I'd be very careful opening up the ability to AS holders to delete random "route:" objects which reference their ASN: such a system can only be made to work for ASNs managed by RIPE NCC and might increase confusion about who can delete what. I am absolutely not in favor of allowing ASN holders to create arbitrary 'route:' objects and favor continuing use of the hierarchical RPKI authorization model. Kind regards, Job ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
