[lacnog] Bogon route objects in the LACNIC IRR

[Sergio Rojas. . .]

Ronald,

Personally, I think the LACNIC IRR implementation is a technology 
innovation, facilitating the work of resources holders the maintenance 
of the route registries. In that way, if you change you routing table, 
you don´t need to update in two different platform, so +1 for this 
implementation.

I recognize the work you have done, specially because most of the 
community still using IRR DBs, but now a day the most reliable and safe 
tool to trust on routing table is RPKI.  Sooner or later IRR DBs will be 
obsolete and I think your researching work should be focus on RPKI 
"garbage".

	>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.

I invite you to read RPKI documentation and get deep knowledge about how 
it works before accuse the RIR that made a mistake. As far as I know, 
the MiLacnic portal alert to resources holders if there is a mistake on 
a certain ROA, so the resources holders is completely responsible for 
updating/fixing the mistake, not the RIR.

Best,

Sergio. . .

P.S.
Remember that this list has code of conduct, please try to keep 
respectful message providing valuable suggestions to the community  
instead  unfounded accusations.
For more info about code of conducts please visit 
https://lacnog.org/seccion/codigo-conducta


El 18/8/21 a las 04:17, Ronald F. Guilmette escribió:
> 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
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog