Dear Nick,
On Sat, Oct 13, 2018 at 10:38:12PM +0100, Nick Hilliard via db-wg wrote:
> Marco Schmidt via db-wg wrote on 11/10/2018 14:18:
> > We just published the RIPE Policy proposal, 2018-06, "RIPE NCC IRR
> > Database Non-Authoritative Route Object Clean-up", to the Routing
> > Working Group mailing list.
> >
> > The goal of the proposal is to delete an non-authoritative object
> > stored in the RIPE IRR, if it conflicts with an RPKI ROA.
>
> There are some corner cases where this could cause permanent and
> unwarranted pain.
>
> 1. what's the procedure for backing out the deletion if the ROA holder
> in the other RIR makes a mistake and, for example, forgets to create a
> roa for a specific ASN and then they find their RIPE-NONAUTH route
> object deleted by accident.
When an operator makes a mistake, they've made a mistake. The same
already applies today when the operator changes the ASN in the
route/route6 object to the wrong origin ASN. The proposal does not have
a 'back out' procedure; once a route/route6 object in RIPE-NONAUTH
becomes in conflict with a RPKI ROA it should no longer exist.
A different way of looking at things: What the policy proposal in a
nutshell does is apply the RFC 6811 BGP origin validation process to IRR
data. You could view the IRR data as if they are BGP announcements in
context of 6811.
Example: An IRR route object in RIPE-NONAUTH states that for prefix
206.48.168.0/22 a possible origin is AS4663 - but a set of PKI ROAs
exists:
206.48.0.0/16 AS5511 maxlength 24
206.48.0.0/16 AS6505 maxlength 24
206.48.0.0/16 AS51964 maxlength 24
Obviously "206.48.168.0/22 AS4663" conflicts with the above set of ROAs
and would be marked with origin validation state 'invalid'.
This means that any network applying RPKI based BGP Origin Validation
will reject the BGP announcement "206.48.168.0/22 AS4663", even though
someone documented in the RIPE-NONAUTH IRR that that announcement
perhaps could exist. The RIPE-NONAUTH IRR route object describes a state
of the network that is to be discarded anyway - so deletion is warranted
as it closes holes in prefix-list based filters in networks not doing
OV.
Also note that in the above scenario the owner of the ARIN-managed
206.48.0.0/16 prefix never was consulted or consented to the creation of
the 206.48.168.0/22 route-object in the RIPE IRR. Leaving such objects
laying around is a disservice to the global community - when there is
clear and unambigious data that shows the IRR route object describes a
route announcement that is to be rejected anyway.
> 2. what happens when someone is busy creating ROAs in, for example,
> Magastan and the RIPE NCC runs a deletion process mid-way through that
> process
When someone needs to create multiple ROAs, but only publishes one - it
is an operator error. When one misconfigures things... they are
misconfigured, no big deal. This is why for example the RIPE RPKI portal
allows you to queue up RPKI ROA modifications and publish the batch in
one go. By the way, What is "magastan" and what does it have to do with
the topic at hand?
To me "quality data" means that the routing information was created with
the explicit consent of the owner of the resource - this is something
the RPKI offers us. If the owner chooses to publish incorrect routing
information (for example: wrong origin ASN) that is entirely up to them.
> 3. the above situations are complicated by RFC6382.
Why? Section 6 of RFC 6382 explicitly states:
"Additionally, this technique sets the stage to employ RPKI-enabled
machinery and more secure and explicit routing policies, which all
network operators should be considering."
What is your concern, how does RFC 6832 change anything? Perhaps you can
provide us with a tangible example scenario?
> It might be a good idea to send some warnings to the holders of the
> route/route6 objects before nuking their objects + build in a timeout
> period.
"their objects"?! We can not assume that the owner of a resource ever
asked for the objects in the first place. There are objects in the
RIPE-NONAUTH IRR that cover NTT Communications' resources where we've
never consented to their creation - since we are not the maintainer and
perhaps dont even have any relation with the creator of such objects, we
have no recourse to delete such objects. When we create RPKI ROAs
covering such route objects it is a clear public statement about which
ASNs are authorised to originate those prefixes. Any IRR information
that is in conflict with such information should be considered rogue and
a risk to our business.
It'll take time before we see a great many networks deploy BGP Origin
Validation based on RPKI data, so an incremental beneficial step forward
is to apply the same origin validation procedure to unvalidated IRR
data, this closes loopholes. To me keaving the rogue IRR objects in
place and telling the industry to just deploy Origin Validation to
mitigate the effects of RIPE-NONAUTH objects would be unreasonable.
RIPE-NONAUTH is a pile of garbage, we need to offer folks an easy way to
delete the portions of it affecting their resources (knownig that these
resource owners probably never have been aware those route/route6
objects existed in the first place!).
Kind regards,
Job