<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Hello Job.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Our analysis was focused just in Brazilian prefixes mostly because those are "familiar to me and my friend.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">But also because that database of 'ASN vs Prefixes' is very tight.<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">I believe that if there was a tool (if it doesn't already exist) that could get the list of "ASNs vs Prefixes" delegations for each of the RIR/NIR/LIR, and put it together in a consultable way, It could be used as a substantial information to indicate, not afraid to say something unfair, that "those" entries are wrong.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">And it could be used for example as a PUBLIC SHAME LIST.<br>- Shame on Mantainers, that are creating wrong entries.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">- Shame on Owner of the Resources, that are not doing their preventive work.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">- And, MOSTLY, Shame on IRRs bases, that are accepting anything.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">(OK, this is not very "politically correct", but it is the best we have.<br>And it works! At least with good persons who doesn't like to be seen as a fat finger.)</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">For example the prefix that I Mentioned in my first email, you look at whois of <a href="http://registro.br">registro.br</a> you will see that who "owns" this prefix is AS267553.<br><a href="https://registro.br/tecnologia/ferramentas/whois/?search=45.70.72.0">https://registro.br/tecnologia/ferramentas/whois/?search=45.70.72.0</a></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">And if you look to RADB you will see a bunch of of atrocities...<div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><a href="https://www.radb.net/query?advanced_query=&keywords=45.70.72.0%2F22&-T+option=&ip_option=&-i+option=">https://www.radb.net/query?advanced_query=&keywords=45.70.72.0%2F22&-T+option=&ip_option=&-i+option=</a></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">- The only one correct entry is from "OI MAINT-AS8167", that created a proxyed entry for the original Owner.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">- That "Internexa MAINT-AS18678", has said that the prefix is hers.<br>- That "Smart MAINT-AS28310", has said that the prefix is hers.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">- And(this is the best part) "Emix - Emirate - MAINT-AS8966", has said that the same prefix is from ASNs 266319, 52965, 53144, all created in the SAME DATE, with a description from ??CHINA TELECOM??<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Well... If Two basic rules would be implemented by RADB and all the others IRRs<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> A - Just de Owner(RIR) of the prefix can create a "Route" Object with "Origin" different that his on ASN.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> B - Proxyed "Route" objects can only be create with the "Origin" of the ASN of the Owner(RIR).<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">It would solve 95% of the problems...<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">What does not comply with these rules should be purged.</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 sex, 13 de set de 2019 às 11:09, Job Snijders <<a href="mailto:job@ntt.net">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">Dear fellow networkers,<br>
<br>
I want to highlight two efforts that I believe will help reduce the<br>
number of erroneous route objects that exist in the various databases.<br>
<br>
effort 1) The RIPE Routing Working Group is working on a policy proposal<br>
that would give mandate to RIPE NCC to remove route objects from the<br>
RIPE-NONAUTH database that are in conflict with published RPKI ROAs. A<br>
tool to analyse some of the changes this would bring can be found here<br>
<a href="https://github.com/job/ripe-proposal-2018-06" rel="noreferrer" target="_blank">https://github.com/job/ripe-proposal-2018-06</a> and the full proposal can<br>
be read here: <a href="https://www.ripe.net/participate/policies/proposals/2018-06" rel="noreferrer" target="_blank">https://www.ripe.net/participate/policies/proposals/2018-06</a><br>
<br>
effort 2) NTT is working on extending the IRRd software (IRRd is the<br>
software that insecure DBs like RADB, NTTCOM, ALTDB, etc run) to<br>
incorporate the RPKI Origin Validation process into the IRR workflow.<br>
Similar to proposal 2018-06, the IRRd software can be modified to<br>
automatically delete IRR route objects that are in conflict with<br>
published RPKI ROAs. This means that the moment you create a ROA...<br>
GLOBALLY the conflicting route objects will be hidden or deleted. IRRd<br>
4's developement can be tracked via <a href="https://github.com/irrdnet/irrd4" rel="noreferrer" target="_blank">https://github.com/irrdnet/irrd4</a> - I<br>
hope that this specific feature will be available this year, in 2019!<br>
<br>
My recommendation to everyone is: create RPKI ROAs for your prefixes...<br>
and just wait a few months. Significant change is coming to the IRR<br>
ecosystem, it'll be much safer quite soon!<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" class="gmail_signature"><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>