Dear Nick, On Mon, Oct 15, 2018 at 02:21:00PM +0200, Nick Hilliard wrote: > On 15 Oct 2018, at 13:00, Job Snijders <j...@instituut.net> wrote: > > > > If we deconstruct RIPE-NONAUTH’s current state of affairs we already > > are facing a irreversible concept: if one deletes an object in > > RIPE-NONAUTH, it can never be restored. > > If someone deletes their nonauth route/route6, they’re making an > explicit request for deletion. It may be wrong and they may have made > a mistake but the outcome will happen as the result of an explicit, > password authorised instruction to the IRRDB to take a specific > action.
We can't operate under the assumption that the route object holder and the resource holder are the same and that these objects are harmless. > This proposal suggests deleting these objects on the basis of implicit > requests via a third party without any feedback mechanism to either > the creator of the roa or the holder of the route object and where the > person creating the roa may not even be aware of the consequences of > their actions. This violates the principle of least astonishment. It is not implicit - the semantical meaning of RPKI ROAs in relation to IRR or BGP make for a perfectly valid use of RPKI data to clean up piles of garbage. I repeat: there are route objects in the RIPE-NONAUTH database which cover resources belonging to NTT - and NTT has *NO* way to delete these objects. Being concerned about violating the principle of least astonishment meanwhile our resources are put at unnecessary risk strikes me as a odd approach to risk management. These objects have been created without NTT's consent and without informing us. NTT is informing the world what the authorised origin ASNs are for these resources through RPKI - so that networks deploying RPKI based BGP Origin Validation will reject announcements that align with the information stated in the RIPE-NONAUTH IRR rather than with the ROAs. If we can do origin validation in BGP based on RPKI - we can certainly do origin validation for IRR data based on RPKI. It makes no sense to protect adversarial, rogue or stale objects - why protect them? The flow chart should be simple: - Want to create RPKI ROAs? Make sure you don't misconfigure them or face the consequences. - Want to get rid of stale or fraudulent route objects? Create RPKI ROAs The owners of route objects in RIPE-NONAUTH don't get a say in any of this - they don't own the resource. But, if they *do* own the resource, they can simply create the appropriate route objects in the appropriate RIR IRR database. Kind regards, Job
