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