[db-wg] RIPE Policy Proposal 2018-06 Aims to Delete Conflicting Non-authorative IRR Objects

Dear Nick,

On Mon, Oct 15, 2018 at 02:21:00PM +0200, Nick Hilliard wrote:
> On 15 Oct 2018, at 13:00, Job Snijders <job at 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