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

[Douglas Fischer]

B.3 - Selective creation/removal of "Route:" and "Route6:", depending on
the existence of the correct entry.
I could adapt a script created by Renato Ornelas that automates the
creation/removal of Proxyed IRR Objects. It checks the existence of the
correct IRR Objects, and just if it Doesn't exists it creates a Proxyed
Object.
 - > If the "Route:/Route6:" exists with the correct Origin, just use it on
"Route-Set:"
 - > If the "Route:/Route6:" does not exists with the correct Origin,
create it as a proxyed object and the use it on "Route-Set:".


Em ter., 14 de jan. de 2020 às 13:40, Douglas Fischer <
fischerdouglas en gmail.com> escreveu:

> OK, RPKI is the Better solution... And We should not stop it!
> But:
>  - Supposing we are in 25-30% of operational ASNs doing RPKI validation.
>  - And also supposing we will take 2-3 years to reach a percentual that
> almost eliminates propagations of invalids...
> Will we be without protection against Fat-Finger during this time?
>
>
> As you Mentioned "Route-Set:" looks a simple and effective idea! And "AS0"
> and ÏRRs dos not combine.
> But to create a Route-Set:RS-IXPsAroundTheWorld we need that the "Route:"
> and "Route6:" already created.
>
> With This, comes some doubts:
> Question A ->  Who should create those Entries?
>   A.1 - The maintainers of IXPs?
>   A.2 - Some representative institution of IXPs(Like PeeringDB or IXPDB)?
>
> Question B -> What should be the ASN used to create those "Route:" and
> "Route6:" Objects?
>   B.1 - The ASN that is used by the IXP on RouteServer Peering?
>   B.2 - A Reserved ASN(Ex.: 4242424242)?
>
>
> My opinion so far(under construction)
> -------------------------------------
> A.2 - Some representative institution creating proxy IRR entries for IXPs
> (Would be my choose.)
> Its not pretty! But since those prefixes should not be routed, it doesn't
> matter so much.
>
> B.2 - Use a Reserved ASN(Ex.: 4242424242) to create "Route:" and "Route6:"
> objects of Lan Prefixes fo IXPs.
> (Would be my choose.)
> Since those prefixes should not be accepted, the Orign information will
> not be used to nothing(Ex.: Regex of AS-Path.) So, wouldn't be a downside
> on this...
>
>
> Justifying downside of the other options
> ----------------------------------------
> A.1 - The maintainers of IXPs creating the IRR Route and Route6
> (Not my choose.)
> Maybe it can take longer than RPKI curve curve cleaning point(2-3 years is
> my guess).
> We cant be unguarded so long.
>
>
> B.1 - Use the ASN that is used by the IXP on RouteServer Peering on the
> Origin of IRR Objects
> (Not my choose.)
> B.1.A - There are some IXPs Lan Subnets that Already have "Route:" and
> "Route6:" created on IRRs.
>         Many of then, with Multiple Origns,
>         Some correct(with the ASN used in IXP Route-Server), and some
> INCORRECT created by unauthorized ASNs.
>         Example: https://imgur.com/a/QYXMyWl
>                  http://irrexplorer.nlnog.net/search/64.191.232.0/22
>         Trying to correct this is impossible, I at least have given up.
> B.1.B - There are some IXPs Lan Subnets that doesn't have any IRR objects.
>         Example:
> https://www.radb.net/query?advanced_query=&keywords=187.16.208.0%2F21
>
> https://www.radb.net/query?advanced_query=&keywords=187.16.208.0%2F20
>         And for what I understand, they don't want to have it.
> B.1.C - There are some IXPs that uses Reserved ASNs to Route-Server MPLA
>         Creating a "Route: / Route6:" with reserved ASN could be
> considered wrong (depending on usage).
>
>
>
> Em seg., 13 de jan. de 2020 às 17:27, Job Snijders <job en ntt.net> escreveu:
>
>> On Mon, Jan 13, 2020 at 10:22 PM Fernando Frediani <fhfrediani en gmail.com>
>> wrote:
>> > 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.
>>
>> Yeah, this raises a good point: not all IXPs want their Peering LAN
>> Prefix to be unreachable. So if one automatically generates a list
>> based of PeeringDB, that list is generated without consideration for
>> the IXP Operator's own wishes. A filter of sorts needs to be applied
>> on that list to know whether an IXP wants the LAN prefix to be
>> not-routed or not.
>>
>> What one could do is to take the list of IXP Peering LAN prefixes from
>> PeeringDB and intersect it with the list of all prefixes _exclusively_
>> covered by RPKI ROAs with AS0, and put that in a "route-set:" which
>> can then be used via bgpq4. Which brings kind of brings us back to
>> observing that deploying RPKI Origin Validation gives you all that for
>> free, and saves you building the aforementioned pipelines.
>>
>> Kind regards,
>>
>> Job
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>


-- 
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/20200114/39494327/attachment-0001.html>