[routing-wg] Routing Reg. mess [was: Re: [anti-abuse-wg] Fwd: Hijack...]

In message <B258521A-B403-4987-8860-5A7DF2CAE1E7 at ripe.net>, 
Kaveh Ranjbar <kranjbar at ripe.net> wrote:

>- RIPE NCC has operated RIPE IRR as an open IRR based on community
>requirements for years. In my opinion, a very productive first step
>towards better data quality and maintenance of RIPE IRR is for the
>community to provide RIPE NCC with an operations policy for RIPE IRR.
>At the moment there is no policy governing RIPE IRR...
>...
>	* Many operators only look into RIPE IRR and/or RADb and ask
>their users to register their routes in one of these databases before
>they can serve them, no matter in which region they are located. This
>might not be the best practice but it is the reality. Looking at IRR
>query load, RIPE Database IRR by far surpasses other RIRs routing
>databases...

Please forgive me.  I am ignorant of much or all of the history relating
to these matters, so your comments are both highly educational and highly
appreciated, by me, at least.  But I'm still trying to wrap my arms around
what, it seems, you just said.

If I have understood you correctly, you are saying that RIPE NCC has, for
some very long time now, been operating its own IRR with -zero- guidance
or instructions on how to do that from the community, -and- that this IRR...
constructed and maintained with -zero- community input or guidance... has
become, within its lifetime, the defacto ``standard'' IRR for the all of
planet earth??

>This means, restricting RIPE IRR might have a negative effect
>on documentation of routing data...

You say that like its a bad thing.

With respect to the various routes hijacked by AS201640, I think that
the world would have been a better place if the RIPE IRR had not, in
effect, endorsed the legitimacy of those.  (Note that this veneer of
legitimacy was also subsequently imported into the MERIT RADb... from
RIPE.)

>	* In many cases the ASN comes from one region and IP Prefix
>comes from another. Requirement from some IRRs (including RIPE's) to
>include auth. for both ASN and IP Prefix only makes things more complex...

Welcome to the 21st century!  Life is complex.  I don't believe that it
becomes less complex if we simply try to sweep the complexity under the
carpet, e.g. by performing only incomplete and clearly inadequate
verification of the legitimacy of route objects being added into the
data base.

>It is possible to interlink RIR auth. systems, it is possible to
>interlink RPKI and IRR, it is possible to mark resources with an auth.
>quality indicator, etc...

As I attempted to point out in my prior two postings, the things you
just mentioned, while perhaps admirable for other reasons, all seem to
me to be technological overkill when it comes to solving what is, at
base a quite simple problem, i.e. obtaining the consent/endorsement of
the actual IP block registrant before a route object is entered into
the RIPE IRR data base.  That consent/endorsement can be obtained, via
a simple automated process, essentially identical to the one used for
signups to this very mailing list, where the request for approval is
e-mailed to the contact e-mail address for the IP address block in
question.

If this simple solution would not have worked to thwart the malevolent
ill intent of AS201640 with respect to the RIPE IRR, or if it would be
at all difficult to implement, then I, for one, would appreciate it
very much if you would explain why.


Regards,
rfg