[lacnog] Bogon route objects in the LACNIC IRR

[Ronald F. Guilmette]

In message <a13a4bf8-1d55-5620-8079-0f87bc8747a6 en gmail.com>, 
"Sergio Rojas. . ." <sergio.astigarraga en gmail.com> wrote:

>What Job want to say is that each object created in the LACNIC´s IRR 
>database is generated automatically from the created ROAs in the RPKI 
>platform.

Thank you for clarifying.  This was sort-of what I had inferred from
Job's posting, however I wanted to make sure that I had understood
correctly.  Now I believe that I do.  So thanks for that.

>Using the analogy described in your e-mail, in order to clean the weeds, 
>it will be necessary that resource holders of these 20 objects you have 
>found, revoke invalid ROAs from MiLacnic portal. Once revoked, weeds in 
>the IRR database will be cleaned automatically.

Or alternatively LACNIC staff could see the problem, could recognize and
admit that these ROAs should never have been allowed to be created in the
first place, and could simply delete them.

That would be the sensible thing to do, in my opinion.  If your dog makes
a mess on your carpet, do you convene an international panel of experts
to decide what to do about that?  Do you wait until you have developed
a formal community-approved policy before you remove the stinky steaming
pile from your carpet?  No, of course not.

The twenty route objects that I identified and listed here are provably
bogus.  And yet when I raised the issue of such "bogon" route objects
previously, in private emails with certain LACNIC officials, I was
informed that no action would be taken by LACNIC in relation to such
bogon route objects the absence of a formal, community-approved policy
which explicitly granted LACNIC staff permission to clean up this specific
kind of dog droppings.

I personally do not feel that such a level of fastidious formality either
is or should be required.  Other RIRs (not LACNIC) have apparentlty agreed
with my view on this point, and have already cleaned up much or all of their
provably improper published route objects.

That having been said, going back to Job's point about the system for
creating RPKI ROAs I would like to just make this one point:

Although Job is quite certainly and undoubtedly correct in what he has
said about the results of the deliberations that resulted in the overall
design of that system, and specifically about how that system explicitly
allows people to use invalid "bogon" ASNs, I am not at all persuaded
that this was in any sense a good design choice *or* that it should now
act as a constraint, preventing garbage "bogon" route objects from being
deleted by any RIR.

Job is correct that each individual RIR can, in general, only look to
its own internal records to see what has been validly allocated and
what has not been validly allocated.  It is perhaps a reasonable point
of view that the internal records of each RIR are the only things that
each of them can fully trust, *however* I see no reason why they either
cannot or should not trust the daily "stats" files that are generated
by their various brethern, nor do I believe that these files cannot be
published and transferred among and between the various RIRs in a safe
and secure manner.

In short there exists *no* technical impediment which would prevent any
RIR from fully checking *any* proposed new route *before* it is either
accepted as part of the RPKI system *or* as part of the older and non-
cryptographic predecessor system, under which the RIRs simply publish plain
text route objects with no fancy cryptographics attached.  Either way,
it is perfectly possible, as I have demonstrated, to fully check any
given proposed new route in order to insure that it refers only to
valid assigned IP space *and* only to valid assigned AS numbers.  The
fact that this can be done easly and in a way that spans the entire
globe should now be apparent and obvious to all, so there is no real
exuse anymore for any of the RIRs to be doing only a half-hearted job
in checking for the full validity of routes before they authoritatively
publish them to the entire world, either via RPKI ROAs, or otherwise.



Regards,
rfg