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

[Fernando Frediani]

Douglas, I am not sure using PeeringDB for this would be the best thing.
Although it is a great tool it is mainly for other proposals and although
it has pretty good and updated information it will never be as precise as
Whois data from RIRs.

Best thing as you mentioned is ASNs to filter based on RPKI and of course
that will be dependent on IX to sign theie ROA. But we know this will not
be very effective for a while.

So getting it from whois seems a better middle term solution even knowing
it means a little more work than using PeeringDB.

Fernando

On Mon, 13 Jan 2020, 18:16 Douglas Fischer, <fischerdouglas en gmail.com>
wrote:

> I was delirious and a little extrapolating the idea on how to develop this
> automation, and I had a crazier idea yet...
>
> Someone who could be considered as representative of the IXPs (perhaps
> PeeringDB himself, or Euro-IX IXPDB ...) feeds some IRR with the IXP LAN
> prefixes with ASN 0, and an AS-SET for that.
>
> So anyone using BGPq3 / BGPq4, or IRRPowerTools could easily create this
> prefix-list and use it for filtering.
>
> Em seg., 13 de jan. de 2020 às 16:43, Douglas Fischer <
> fischerdouglas en gmail.com> escreveu:
>
>> 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
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> _______________________________________________
> 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/20200113/72892673/attachment.html>