[lacnog] Hijack de prefixo em IRR

[Douglas Fischer]

Hello Job.

Our analysis was focused just in Brazilian prefixes mostly because those
are "familiar to me and my friend.
But also because that database of 'ASN vs Prefixes' is very tight.

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.

And it could be used for example as a PUBLIC SHAME LIST.
- Shame on Mantainers, that are creating wrong entries.
- Shame on Owner of the Resources, that are not doing their preventive work.
- And, MOSTLY, Shame on IRRs bases, that are accepting anything.
(OK, this is not very "politically correct", but it is the best we have.
And it works! At least with good persons who doesn't like to be seen as a
fat finger.)

For example the prefix that I Mentioned in my first email, you look at
whois of registro.br you will see that who "owns" this prefix is AS267553.
https://registro.br/tecnologia/ferramentas/whois/?search=45.70.72.0

And if you look to RADB you will see a bunch of of atrocities...
https://www.radb.net/query?advanced_query=&keywords=45.70.72.0%2F22&-T+option=&ip_option=&-i+option=

- The only one correct entry is from "OI MAINT-AS8167", that created a
proxyed entry for the original Owner.
- That "Internexa MAINT-AS18678", has said that the prefix is hers.
- That "Smart MAINT-AS28310", has said that the prefix is hers.
- 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??

Well... If Two basic rules would be implemented by RADB and all the others
IRRs
 A - Just de Owner(RIR) of the prefix can create a "Route" Object with
"Origin" different that his on ASN.
 B - Proxyed "Route" objects can only be create with the "Origin" of the
ASN of the Owner(RIR).
It would solve 95% of the problems...
What does not comply with these rules should be purged.



Em sex, 13 de set de 2019 às 11:09, Job Snijders <job en ntt.net> escreveu:

> Dear fellow networkers,
>
> I want to highlight two efforts that I believe will help reduce the
> number of erroneous route objects that exist in the various databases.
>
> effort 1) The RIPE Routing Working Group is working on a policy proposal
> that would give mandate to RIPE NCC to remove route objects from the
> RIPE-NONAUTH database that are in conflict with published RPKI ROAs. A
> tool to analyse some of the changes this would bring can be found here
> https://github.com/job/ripe-proposal-2018-06 and the full proposal can
> be read here: https://www.ripe.net/participate/policies/proposals/2018-06
>
> effort 2) NTT is working on extending the IRRd software (IRRd is the
> software that insecure DBs like RADB, NTTCOM, ALTDB, etc run) to
> incorporate the RPKI Origin Validation process into the IRR workflow.
> Similar to proposal 2018-06, the IRRd software can be modified to
> automatically delete IRR route objects that are in conflict with
> published RPKI ROAs. This means that the moment you create a ROA...
> GLOBALLY the conflicting route objects will be hidden or deleted. IRRd
> 4's developement can be tracked via https://github.com/irrdnet/irrd4 - I
> hope that this specific feature will be available this year, in 2019!
>
> My recommendation to everyone is: create RPKI ROAs for your prefixes...
> and just wait a few months. Significant change is coming to the IRR
> ecosystem, it'll be much safer quite soon!
>
> 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/20190913/81110fb3/attachment.html>