[lacnog] Hijack de prefixo em IRR

[Tomas Lynch]

Douglas,

I support your initiative 100%. I am for clean IRR records. However...
[continues inline]

On Fri, Sep 13, 2019 at 4:57 PM Douglas Fischer <fischerdouglas en gmail.com>
wrote:

> Hello Job.
>
> <snip>
>
> 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.)
>
> "He that is without sin among you, let him first cast a stone at her"

Keep reading...


> 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.
>

Is it only correct because they just put some remarks and a description
that says "Proxy-registered route object"?

- That "Internexa MAINT-AS18678", has said that the prefix is hers.
> - That "Smart MAINT-AS28310", has said that the prefix is hers.
>

They say that is theirs because they do not say that is a proxy-registered
route?
So, in the SHAME list OI won't be listed, however, Internexa and Smart will
be because of they do not explicitly say that it is a proxy registration.
Thus, we will need a standard to label these objects.

- 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.
>
> Yes, even those with a proxy description or remark. However, I think there
are plenty of Internet users with a /24 or shorter that have no idea on how
to register a route object. Those still need to be proxy-registered.

Then we will need to label them as proxy-registered but shall I register
them with "Proxy-registered", "register by proxy", "rgstrprx", "this is not
mine however I registered WARNING WARNING", etc.

We have to think that out there, out of our ecosystem of knowledgeable
Internet operators, there is people that has received a /22 or a /48 and
doesn't know what to do with that except to give it to the IT person and
setup some DHCP servers.

Thus, my question is how do we educate the community to register their own
objects on an IRR? Do they want to be educated? Do they know that they can
learn by simple googling IRR? DO they have the time to do it? Or shall we
relay only on RIR's IRRs that not all the RIR's have?

I do not think that the proxy-registered issue can be solved with a SHAME
list. We will have plenty of people complaining that they are on that list
stating that a customer asked them to register their objects and after
several complains they won't care about it and the list will become
obsolete.

Kind regards,

Tomás Lynch


>
>
> 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
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190914/09ffc989/attachment-0001.html>