[lacnog] IX LAN Prefixes - Should I Automate a Discard?

Douglas Fischer fischerdouglas en gmail.com
Lun Ene 13 17:43:55 GMT+3 2020


Just to put it in context, I will report the motivation of this idea
--------------------------------------------------------------------

On 08 / Jan / 2020 IX.BR started to change the netmask in São Paulo IX.
187.16.216.0/21 -> 187.16.208.0/20

Everything should have gone well...
But we had some classmates who hadn't done their homework well and were
leaking the IX LAN prefix for their Downstreams and Upstreams as if they
were their own networks. (And to make matters worse, there were very large
people who were accepting this prefix.)

While everyone was on the same netmask, the directly connected network
metric was better than the BGP-learned network metric, and that didn't hurt.
But as some participants who were receiving this / 21 prefix from their
UPstreams changed their netmask to / 20, the more specific prefix has won
in FIB, and those participants lost connectivity to Lan IX.

We know that the "modern and beautiful" way to prevent this from happening
is that there is a ROA with ASN 0 (or the ASN of IX itself) and this
filtering happens through RPKI.

The IX.BR team reported that this is already being discussed and should be
forwarding it soon.

But I must remember that Registro.BR started supporting RPKI in late 2019,
so it is fully acceptable that this definition of ROA is still adjusting
there.
PS: Congratulations to Registro.BR staff for implementing RPKI almost
uneventfully and with EXCELLENT response time and quality for the minimum
problems that have arisen.


Speaking of the Idea itself
---------------------------
Getting back to the "Accept or Not IX LAN Prefixes Worldwide" question.
- As there are still IXes that do not have the LAN prefix ROAs properly
published.
- Since there are still many ASNs that do not validate RPKI
- Considering thar PeeringDB database is very consistent
I thought of creating a (cyclic) mechanism that takes LAN address
information from PeeringDB IX informations and creates two prefix lists (v4
and v6).
And then use this prefix-list to discard these prefixes when coming from
Upstreams.

A friend even helped me and set up the query in the PeeringDB API for this.

The question
------------
Does it make sense to automate this filtering mechanism?

-- 
Douglas Fernando Fischer
Engº de Controle e Automação
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20200113/21f30d28/attachment.html>


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