[lacnog] Bogon route objects in the LACNIC IRR

[Ariel Weher]

Dear all:

>From my point of view it is not the fault of the RIR if end users generate
"""invalid""" ROAs.

Furthermore, I am totally against the idea of the RIR executing alteration
tasks of the resources created *voluntarily* by its members when this
information does not present any risk to the rest of the community.

It seems to me correct that these anomalies are reported in this and other
lists of a technical nature, since that is one of their main objectives,
but please maintain mutual respect and good manners.

A warm greeting to all and thanks for the good work

On Thu, Aug 19, 2021 at 11:34 AM Ronald F. Guilmette <rfg en tristatelogic.com>
wrote:

> In message <CAJBrruiDNGXLGLrS+=PuqKyq8z7vB1m5oa5edshEB=
> G1cRcg7Q en mail.gmail.com>,
> Roque Gagliano <rgaglian en gmail.com> wrote:
>
> >If you really want to change how the ROAs work, please go ahead and submit
> >an IETF draft and follow the process. All your points were discussed a lot
> >during the design process.
>
> I'm sorry.  It seems that I failed to make myself clear.
>
> I have no interest whatsoever in making *any* changes at all to the
> existing
> RPKI system *or* to any of its associated ROAs, either currently existing
> ones or future ones.  I have not proposed that, I have not suggested that,
> I have not even vaguely insinuated that, and indeed I would be opposed to
> that,
> absent the kind of formal IETF process that you mentioned.
>
> No  I have spoken only of the "old world" of RIR IRRs... the old system
> under
> which the five Regional Internet Registries publish *non-cryptographic*
> route
> objects themselves, via their respective Internet Route Registries.  (I
> thought
> that I had made this clear, but apparently not.  In any case, I hope that
> I have
> made it clear now.)
>
> It's just the old RIR IRRs that concern me.  It has always been my default
> assumption that the new world of RPKI ROAs can and will take care of
> itself.
>
> With respect to the RIR IRRs... which are, in general, older than RPKI,
> except
> in the case of LACNIC, it seems... those old IRRs contain or have
> contained a
> lot of what I would call "long abandoned bogon garbage".  That's the only
> stuff
> that concerns me.
>
> Unfortunately, someone at some time within LACNIC made the decision to
> import
> the entire universe of LACNIC RPKI ROAs, blindly, and en mass, into the old
> style LACNIC IRR -without- first filtering out what I call the "bogon
> garbage".
>
> As I have previously said, I think that this could be easily rectified by
> LACNIC
> staff, and *without* just ignoring all of the thousands or tens of
> thousands
> of perfectly legitimate RKPI ROAs.  Those could all and should all still be
> imported on a route basis into the lACNIC IRR.  I have no problems with
> that,
> and in fact I think it would be Good if this continued to happen.  The
> routes
> that involve bogon AS numbers are a different matter however.  Those
> should not
> have old-style route objects auto-generated for them which are then placed
> into
> the LACNIC IRR.
>
> I'm sure that some people (Job?) may say "Well, just don't worry about
> it!  Bogon
> route objects within the IRRs of the various RIR are not actually Bad and
> are
> not really a problem." but I don't think such a claim will stand up to
> careful
> scrutiny.  If bogon route objects within RIR IRRs are not "Bad" or at least
> undesirable, when why is it the case that all four of the other Regional
> Internet Registries (ARIN, RIPE, APNIC, AFRINIC) have already taken steps
> to
> remove some or all of -their- bogon route objects from -their- respective
> IRRs?
>
>
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20210820/4477d746/attachment-0001.htm>