[lacnog] Bogon route objects in the LACNIC IRR

[Ronald F. Guilmette]

In message <YRzmst/xz9huSEhW en bench.sobornost.net>, 
Job Snijders <job en sobornost.net> wrote:

>On Wed, Aug 18, 2021 at 12:17:17AM -0700, Ronald F. Guilmette wrote:
>> The twenty route objects that I identified and listed here are provably
>> bogus.
>
>The very same capability that permits this handful of CAs to
>'misconfigure' their RPKI ROAs (keep in mind their ability to shoot
>themselves in the foot is restricted merely to their own IP space!), is
>also what enables the other 2,940 Certificate Authorities to provide
>authorization to service ISPs both inside and outside the LACNIC region,
>Legacy ASN or not, past and future.

So, we are designing *deliberately* insecure systems, procedures and
mechanisms specifically for the benefit of profit-making Certificate
Authorities who also are... for no very well specified reasons... either
unable or unwilling to interogate the daily RIR stats files to see what
is a bogon ASN and what isn't??  Is that really what you are saying?

>Whether or not a given ASId is 'bogus' is subjective.

It appears that we will have to continue to agree to disagree on that
point.  The RIR WHOIS data bases and the RIR daily stats files would
appear to agree with my view:  There actually is such a thing as a bogon
ASN, just as there is such a thing as bogon IP space.

>For example some
>IXP operators create ROAs which reference non-existent ASNs as an
>effective method to hamper propagation of their IX Peering LAN prefixes
>(or any more-specifics) through the Default-Free Zone.

Yes, I have read something about RIRs perhaps doing something similar with
AS0, i.e. using it as a way of signaling that certain route announcements
should be considered invalid by some parties.  Ah yes!  Here it is!

https://www.manrs.org/2020/12/whats-the-as0-roa-policy-and-what-should-i-know-as-a-network-operator/

If that is what these unspecified IXP operators wish to do, then why don't
they either use AS0 or else write a short and simple new RFC which will
specify a new IANA-reserved AS number (AS654321?) exactly and only for this
somewhat special purpose?

It seems to me that there are multiple ways in which this one tiny, obscure,
and specialized need could be served, on a global basis, *without* the
necessity of rendering a whole planet's worth of BGP stuff potentially
unreliable and inaccurate.

>> 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
>
>But technical impediments do exist. You are not considering (or
>appreciating) how the RPKI is a distributed database of delegations.

Perhaps I am, and perhaps you are simply not appreciating my appreciation,
because I simply have a different set of values and priorities than you do.

The fact that RPKI is "a distributed database of delegations" does not
make it inherently differeht from the DNS.  In the DNS, if you haven't
registered your domain name, then it simply doesn't exist.  I personally
do not view this as a "bug" but rather as a feature, and one that has
untold benefits for global security.

You appear to be arguing that, unlike the DNS, an unassigned ASN may be
used, and even (unbelievably!) that some such -must- be used in certain
very obscure and limited contexts, and that no one should lift a finger
to stop that, EVEN THOUGH the use of bogon ASNs is a well known vector
of network abuse.

Will you next be suggesting that everyone should be free to demand that
unregistered domain names be given functioning NS records in the TLD
root zones?  That would seem to be the obvious DNS analog of what you
are so adamant about when it comes to bogon ASNs.

>Similar to how via LACNIC's Reverse DNS service it is possible to
>sub-delegate a zone to nameservers which are (currently/partially)
>unreachable, or for zone operator to input RFC 1918 IP space as the
>contents of an "A" records ...

What you have just described goes against published, longstanding, and
widley accepted Best Practice:

   https://tools.ietf.org/id/draft-ietf-dnsop-dontpublish-unreachable-01.txt

     "A number of instances have been observed where IP addresses that are 
     never accessible from the public Internet have nevertheless been 
     inserted into resource records in the public DNS. This document seeks 
     to prohibit such behaviour in the case of truly private addresses, 
     and to discourage it in the case of public, but unreachable, addresses."

You should continue to feel free to do whatever you may wish in the privacy
of your own bedroom, or in the privacy of your own network, but PLEASE don't
mess up the *public* DNS with RFC 1918 addresses.

>is it possible (and an unavoidable
>necessity) for RPKI operators to issue ROAs with arbitrary ASIds.

You still have not proven that case.  All you have done is to suggest
that some tiny minority of all of the entities on the Internet (IXP
operators) *may* occasionally find it maximally convenient to just be
lazy and use some unassigned ASN as a sort of unofficial back-door way
of protecting their IP addresses.  But they could just as easly ask
their local RIR for a *real* ASN and do the same things with that real
and properly registered ASN instead.

We all get lazy sometimes.  Some weeks, I just don't feel like taking out
the garbage.  I can thererfore understand why some lazy IXP operators might
be just too lazy to get themselves one more real ASN, and I do sympathize
with their laziness, but again, I don't think that we need to compromise
a whole plaent's worth of BGP routing, just because some of them have carpal
tunnel symdrome, real or imagined, during the exact same week when they
decide that their IP addresses need some extra layer of protection.

If they need another ASN they can just get one.

Your argument based on the distributed nature of DNS is also not really
persuasive, as I have noted above.  As per the citation above, it has
been explicitly against best practice for twenty years now to use RFC 1918
addresses in public DNS records.  Anyone who is doing that as a way of
creating dead-end placeholders is screwing up and should stop.

Also, as I have noted, if you haven't registered a given domain name, then
you can't use it.  It is as simple as that and everybody knows it.  Why
then should it be any different for AS numbers?  Are we really going to make
the whole global routing system less secure just because a few IXP operators
cannot, for some reason, place their hands on their keyboards long enough
to request from their local RIR another (free) -legitimate- AS number?

>The alternative is extreme consolidation: fully centralized management
>and operation of the RPKI service and the Reverse DNS service. Complete
>centralization is the only way to enforce arbitrary rules about what
>values the ASId field (or Reverse DNS 'A' records) can contain.

I hate to break this to you Job, but we already have this "extreme
consolidation" and "fully centralized management" on the Internet that
so terrifies you.  Do you really think that there are a bunch of totally
independent go-it-alone individualists who are running the various
DNS root servers?  Nope.  Everthing ends in dot (".") and that is
effectively the property of ICANN.  Fortunately for us, and with some
occasional exceptions, they have been benign dictators, and not the
George Orwell / 1984 kind.

But this is all an irrelevant digression.  You are clearly wrong in
your assesment that "fully centralized management" is a prerequsite
to simply checking the current registration status of any given ASN.
Anyone can do this simple thing by simply fetching the five RIR daily
stats files, just as I have said, and just as I have demonstrated.
Did my actions in fetching those five modest files cause all five of the
regional Internet registries to suddenly collapse into one terrifying
and monolithic all-powerful and malevolent behemoth?  No.  Of course
not.  So what, exactly, are you worrying about?

>Indeed, the above should require the community to go through the policy
>development process. It would be a sad day if this community decides to
>turn back the clock by deprecating the Delegated RPKI functionality and
>imposing draconian restrictions on the ASId field, for no obvious
>benefit.

Methinks you do protest too much.  Is it "draconian" to reqire a domain
name to be registered before it is used?  It is "draconian" to follow
best practices and simply not publish DNS records that contain reserved
RFC 1918 addresses?

I understand that you wish to make life easy for your friends in the 
commercial Certificate Authority business, and that you are horrified
that anyone, including me, would suggest that they should maybe make
sure that the certificates they are issuing relate to valid registered
AS numbers... just as they are already doing when it comes to IP space...
but if one lone researcher (me), working with -zero- funding can do this
simple thing, then I guess that they, with all of their revenue and all
of their astute technical people, can manage to do it also. It really
isn't rocket science.

But we don't need to even argue about this, and doing so is also a mere
distraction that has nothing whatever to do with what I had hoped were
my own clearly stated and rather more modest goals.

Personally, and at the moment, I don't really give a damn about whatever
silliness, expediencies, and insecurities are taking place over in the
world of RPKI and Certificate Authorities.  If the decision has been
made that RPKI should allow bogon ASNs to be used, then OK, fine.  It
is what it is, and I am obviously coming in to the party way too late
to change any of that.  But in the world of *non-cryptographic* route
registries... which the majority of us heathens are still living in
for the time being... that is where my exclusive focus has been and
continues to be.  And in this world, totally unauthorized bogons are
still an ongoing problem.  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.
The world of RPKI only intrudes into this older universe when some RIR,
e.g. LACNIC, elects to do something dumb, like automatically and routinely
mirroring provably bogus routes from their RPKI data bases into their
non-crypto-enabled old-fashioned IRRs.

I would like to see them stop doing this.  If they did, then I gather that
that simple action would make all of the 20 bogon routes that I have cited
here previous just go away.  (And note that *only* LACNIC seems to have
come up with this too-creative idea of copying everything from their RPKI
records to their old-school IRR.  None of the other RIRs is doing this,
as far as I can tell.)

>At the moment 35% of LACNIC space is covered by RPKI ROAs, the LACNIC
>RPKI infrastructure pre-dates the IRR service. The IRR service merely is
>a conduit towards legacy systems, nobody is forcing anyone to use it.

But sadly peole *do* use it.  Lots of people.  And the whole mess is
routinely imported also into RADB which, sadly, a few zillion networks
still do use.

You could make this argument about the Internet itself... "Nobody is
forcing anybody to use it."  But try just merely existing in the modern
world, and in any first-world country without the Internet these days.
Good luck with that.

The bottom line is that just saying that nobody HAS TO use the old-school
route registries, although true, misses the point.  There exist acutal
bogons out there being announced right now with the explicit blessing 
of the old-school IRRs of one or another of the five RIRs.  This is, in
my opinion, distinctly un-good.  If I get attacked or phished or ransomed
from an IP that's being routed by some unassigned ASN, who do you wish
me to complain to?  Nobody owns the ASN so I guess I get to just grumble
quietly to myself in the corner.  (And likewise also for any other victim.)

>It seems to me you are trying very hard to create the impression you
>found a big problem (it's not) and we should be thankful you are
>'solving' it (you aren't).

I never asserted that this was a "big" problem, and I never asked for
any thanks from anybody, so that's all just projection on your part.
It's a small problem and I wrote some small software tools to help me
to be able to talk in specifics about the problem.  Nobody owes me
anything.  I am doing this for myself and my family and my friends,
because none of us should be exposed to the kind of "wild west" and
"anything goes" Internet that we have at present.  A lot of us ordinary
citizens are just tired of all of this crap and all of the insecurities,
and of all of the excuses that are given for not making things any better...
not in another ten or twenty years, but NOW.

>I think there is nothing to see here. I would
>rather direct all this energy towards writing code improvements for RPKI
>& BGP software, or teaching people how to deploy RPKI-based BGP Origin
>Validation inside their network.

Please proceed.  You work towards your priorities and I will continue to
work towards mine.  You do you and I'll do me.

Until networks start dropping RPKI invalids, I'm going to keep on working
on problems that affect myself and others this week, this month, this year
and this decade.

>ps. Your strawman arguments and rudeness are not appreciated and make
>you appear immature. You would garner more respect if you demonstrated
>hands-on experience with the issuance and validation of RPKI objects, or
>the application of RPKI data towards the BGP plane.

You have it backwards, I'm afraid.  I have been entirely civil and also
respectful.  In your prior posting to this thread however your comtempt
and personal animosity were hardly even thinly veiled.  You basically
said "Ron Guilmette doesn't agree with me and thus he is stupid."

I am discussing the facts and I have made my technical arguments.  You,
in contrast, have engaged in unnecessary and very personal condescension
towards me, simply because I have rather different priorities and values
than you do.  You have also made baseless claims about my goals and
intentions, e.g. that I have either asked for or expected any thanks for
what I am doing.  (I have not.)

I can be, and I always endeavor to be just as civil towards others as
they are towards me.  Maybe if you stop calling me stupid just because
I don't happen to agree with you, that would improve the general tenor
of the dialog, overall.


Regards,
rfg