[lacnog] Bogon route objects in the LACNIC IRR
Sergio Rojas. . .
sergio.astigarraga en gmail.com
Mie Ago 18 00:14:20 -03 2021
Hi Ronald,
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. You can read more about IRR features it in the following links:
1-
https://translate.google.com/translate?hl=&sl=es&tl=en&u=https%3A%2F%2Flabs.lacnic.net%2FUso-de-IRR-LACNIC%2F
2-
https://translate.google.com/translate?hl=&sl=es&tl=en&u=https%3A%2F%2Flabs.lacnic.net%2FIRR%2F
For example, range 179.61.238.0/24
As you can see in the routing table, this range is announced through the
AS40676 (not from bogon AS203786), having a VALID ROA, which is
basically "mirrored" in the LACNIC´s IRR database. You can check here:
route: 179.61.238.0/23
descr: LACNIC generated route for Digital Energy Technologies Chile SpA
origin:*AS40676*
remarks: LACNIC generated route for Digital Energy Technologies Chile SpA
remarks: maxLength 24
mnt-by: MNT-CL-DETC-LACNIC
changed: 20210616
source: LACNIC
However, resource holder has more INVALID ROAs, and one of them is the
example shown in your first e-mail, which is mirrored again in the IRR
database:
route: 179.61.238.0/24
descr: LACNIC generated route for Digital Energy Technologies Chile SpA
origin:*AS203786*
remarks: LACNIC generated route for Digital Energy Technologies Chile SpA
remarks: maxLength 24
mnt-by: MNT-CL-DETC-LACNIC
changed: 20210616
source: LACNIC
remarks: ***************************************************
remarks: This object may have been modified
remarks: For more information, please query whois.lacnic.net
remarks: ***************************************************
last-modified: 2021-06-16T22:05:05Z
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.
I hope this information has been useful,
BTW, excellent work!
Best,
Sergio. . .
El 14/8/21 a las 07:15, Ronald F. Guilmette escribió:
> Job Snijders suggests that DFZ routing of IP address space using
> unassigned "bogon" AS numbers is somehow necessary. In support of
> this assertion he provides only further unproven assertions, which
> he himself has made, and which he asks us all to blindly believe:
>
> "For sound operational reasons both in the RIPE database and in the RPKI
> in general, the IP resource holder is permitted to designate any ASN
> they wish as the origin."
>
> (Please note that Job does not actually bother to list any of these supposed
> "sound operational reasons".)
>
> "In many RPKI deployment scenarios it is *** technically impossible ***
> for the RIR to impose restrictions on the content of the ASId field,
> because the RIR is not involved in the issuance or publication of said
> objects."
>
> Well, it would seem that *I* am able to achieve what has previously been
> deemed by experts to be "technically impossible". Maybe I should rush down
> to my local patent office and file a patent before anyone can beat me to it!
>
> With all due respect to my friend Job, the above statement is apparently
> equivalent to saying "Ron Guilmette, working all by himself and with -zero-
> funding, can perform spectacular feats of magic that even the five Regional
> Internet Registries, with all of their money and with all of their highly
> trained and experienced staffs cannot do --- He can see, on any given day,
> which AS numbers are unassigned "bogon" ASNs and which ones aren't.
>
> Job has a perfectly valid point that no individual RIR can ever be absolutely
> and positively 100% sure that a given *assigned* ASN, particularly one that
> was issued and assigned by some -different- RIR, is or is not a valid thing
> to be using as the origin ASN for any given route to any given IP address
> block. But we are *not* taking about "valid and assigned ASNs" here.
> That is not the issue, and that is not the question. That is just an
> irrelevant distraction.
>
> The issue isn't whether or not some valid and properly registered ASN
> may or may not be used to route a given IP address block. The issue is:
> "Do we want people making route announcements into the DFZ while using
> provably INVALID (bogon) AS numbers?"
>
> I believe that anwer must be "no" and that thus it follows that no RIR
> should be, in effect, endorsing the use of bogon ASNs, e.g. by allowing
> route objects that refer to bogon ASNs into their own IRRs.
>
> And it clearly does not require any wizard level special magic in order
> to see, on any given day, which ASNs -have- been properly assigned by
> some RIR to some resource member and which ones haven't (and are thus
> "bogons"). These distinctions may be trivially made by anyone with even
> the minimal skill necessary to (a) download the daily "stats" files from
> the five different RIRs and then (b) apply to those some very minimal
> textual manipulation. (This really is not rocket science, and I do believe
> that even Job could do it, if he put his mind to it.)
>
> Fortunately for the various RIRs, I detest bogons and thus, I have already
> done all of the work necessary to find and report these bogon route objects...
> objects that refer *either* to invalid/unassigned IP addresses *or* to
> invalid and unassigned ASNs.
>
> Some RIRs, at least, have thanked me for my efforts and have already removed
> the bogon route objects in question. (LACNIC isn't one of them.)
>
> Job is quite clearly and vigorously arguing in favor of the proposition
> that the Internet should be, in effect, a lawless free-for-all where any
> party may use *any* arbitrary ASN... even provably bogus and unassigned
> ones... within route announcements that they then inject into the DFZ,
> *and* that the five RIRs should not only tolerate this aberrant and anti-
> social behavior, but that they should even endorse it by including bogon
> route objects into their own IRRs.
>
> As noted above, there is no rational basis for such a choice, or for such
> an attitude, and Job's reference to RPKI is an irrelevant smokescreen.
> The needs and limitations of RPKI are entirely irrelevant to the ongoing
> and parallel operation of (non-cryptographic) IRRs by the five Regional
> Internet Registries. These two realms are, as we say here, "apples and
> oranges", and there is no need to copy the mistakes of one realm onto the
> other or vise versa.
>
> That having been said, when and if RPKI does eventually become more widely
> deployed it is my hope that *someone* will be looking at all of *those*
> RPKI-secured route objects from time to time, to see if any of *those*
> things mention any bogon ASNs. If any do, then someone will need to clean
> up that mess also.
>
> As we say here "It's a dirty job but someone has to do it." Otherwise the
> DFZ will become like an untended garden... full of weeds and not much else.
>
> Job is, I believe, simply confused. He believes that I wish to uproot some
> of his prized tomatoes from the garden. But I don't. I'm only interested
> in getting rid of the actual weeds. And these actually are not at all
> difficult to differentiate from the stuff that Job wants to keep. Indeed,
> I have already done exactly that.
>
>
> Regards,
> rfg
>
>
> P.S. One of the more humorous aspects of this debate is that actually,
> as far as I can tell, exactly -zero- of the 20 bogon route objects that
> I previously listed here are even being used, at present, to route anything.
> These are the routing equivalent of the proverbial "Tree that falls in the
> forest when nobody is around."
>
> Perhaps Job could also be the press spokesman for Sri Lanka's Mattala
> Rajapaksa International Airport, since that also appears to have no
> actual reason for existing:
>
> https://www.forbes.com/sites/wadeshepard/2016/05/28/the-story-behind-the-worlds-emptiest-international-airport-sri-lankas-mattala-rajapaksa/
>
> _______________________________________________
> 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/20210818/18d08c38/attachment.htm>
Más información sobre la lista de distribución LACNOG