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

[Douglas Fischer]

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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20200114/b05cd779/attachment.html>