[lacnog] Bogon route objects in the LACNIC IRR

Ronald F. Guilmette rfg en tristatelogic.com
Jue Ago 19 02:45:03 -03 2021

In message <YR0ulznSLmxO/5vx en bench.sobornost.net>, 
Job Snijders <job en sobornost.net> wrote:

>Do you now understand that in the delegated model the ROA ASId contents
>are outside the mandate scope of the RIR?

Yes. Thanks.  I get it.  Individual operators are creating ROAs and some
of those are using bogon ASNs... for reasons that remain a bit murky,
if not to say totally unexplained.  (Perhaps these are all just "fat
finger" mistakes.)

The problem arises when RIRs... so far specifically and only LACNIC...
import the essence of those invalid ROAs that reference bogon ASN into
their own old-style IRRs.

As I have previously noted, as far as I have been able to determine the
only place where such importations into any RIR's own "official" IRR is
within the LACNIC region.

It seems that the problem could quite easily be solved, without having
any effect on any of the networks that are using RPKI ROAs (which we
all aggree are a good and useful thing) simply by arranging to have
LACNIC filter out those few ROAs that reference bogon ASNs before
they are just imported into the LACNIC IRR, leaving only the essence
of the good and valid ROAs to be imported.

>> EVEN THOUGH the use of bogon ASNs is a well known vector of network
>> abuse.
>I'd like to see tangible evidence of this exact vector.

I have recently compiled a lists of some 337 live & active IPv4 bogons
and some 68 live & active IPv6 bogons.  I must emphasize that these are
*not* what I have called "bogon route objects" but rather these are
actual current bogon routes being actively announced into the DFZ.
A substantial fraction of all of these live bogon announcements are in
fact using what I have called "bogon ASNs".  I will provide more specific
data as soon as I am able to write some additional code to separate out
the bogons that are using bogon ASNs from the others.  In the meantime,
I am providing this raw data covering ALL current live & active bogon
announcements so that any other motivated person can independently check
them all to see which ones, specifically, are using invalid & unassigned
ASNs.  (There are a lot of those. I am already sure of that.)


>> And this problem is made worse by the tendency of RIRs to publish good
>> old-fashioned route objects that refer to unassigned ASNs.  That is
>> the problem I am working to try to solve.
>Learn to ignore such entries...

This is excellent advice!  The only point on which we seem to differ is
that in my opinion it would be better if LACNIC itself were to ignore
these few specific RPKI ROAs (that reference bogon ASNs) before they
put them into their own public IRR.  This would obviate the need for
thousands of network operators to have to -individually- make arrangements
to ignore these specific route objects.

Isn't it better to solve the problem once, and at its source?


Más información sobre la lista de distribución LACNOG