[lacnog] Bogon route objects in the LACNIC IRR

Job Snijders job en sobornost.net
Mie Ago 18 13:00:23 -03 2021

On Wed, Aug 18, 2021 at 08:03:25AM -0700, Ronald F. Guilmette wrote:
> 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.

The analogy between DNS and RPKI is more along these lines:

A) "registering your domain name" == "receiving the ability to create ROAs"
   (you pay the Domain Registar, or you pay the RIR and receive resources)

B) "running your own auth DNS servers" == "signing and publishing your own cryptographic products"
   (Many Domain Registars offer a hosted DNS product, many also permit
   delegation to your own nameservers)

C) "publishing an 'A' record in your delegated zone" == "creating a ROA covering IP space delegated to you"

D) "setting the host adddress of that 'A' record type to a RFC 1918 address" == "creating a ROA with origin AS 65000"

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

Another analogy is that receiving the ability to create a RPKI ROA is
akin to completing a DNSSEC-assisted LetsEncrypt challenge to obtain a
TLS certificate for a given FQDN, ... and of course Let's Encrypt has no
influence over the content hosted on the TLS encrypted endpoint.

Keep in mind analogies always remain approximations.

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

What you call "use of bogon ASN" is not more than someone making a typo
during the creation of an "A" or "TXT" DNS record.

Listing a RFC 1918 address in an 'A' record is not the equivalent of
having the ability to send/receive traffic at that RFC 1918 address.

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

While it may be undesirable for RFC 1918 addresses to show up behind 'A'
records (or IPv6 documentation prefixes in AAAA records), there is no
technical mechanism to prevent operators from configuring their service
in such a way.

The existence of a BCP apparently does not restrict people through
technical means from using RFC 1918 addresses in DNS zones delegated
towards them.

> 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, each operator needs understand what data
is available to make routing decisions, what the (validatable) origins
of the data are, and how it impacts traffic distribution.

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

They are not 'bogon routes', they are database entries. An IRR route
object is not the equivalent of a BGP route announcement.

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

I believe many networks have already started rejecting RPKI invalid

Do you operatore a network? Have you configured any routing equipment to
reject RPKI invalid route announcements? Can you share your experiences?



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