Mailing List Archive

YMMV, but my take:
1 - You should worry a little, but not much. Filters allowing unwanted
announcements might be created using these erroneous IRR records, but
they won't do any damage by themselves. An actual wrong BGP
announcement is required for any damage to happen, and even without
those IRR records, a wrong announcement will cause some havoc since
not everyone builds filters based on IRR and not everyone runs RPKI
validation.
2 - Most IRR databases will take reports from the RIR-registered
contact of the block seriously. Some databases will react faster than
others; for instance, in TC any such objects will be removed upon
knowledge and if the maintainer recreates those objects, the
maintainer may be permanently excluded from the database.
3 - Unfortunately there is not much you can do since this is caused by
relaxed submission filtering at IRR databases, The RIR-connected IRR
databases are usually very good in preventing such, but the
independent ones usually are not. IRRd versions prior to v4 (thanks
NTT for v4) are also more prone to accept non-compliant records and
can only eliminate them after inclusion.


Rubens



On Fri, Oct 30, 2020 at 10:11 PM Pirawat WATANAPONGSE <pirawat.w@ku.th> wrote:
>
>
> Dear Guru(s),
>
>
> I am seeking advice concerning someone else announcing IRR records on resources belonging to me.
> [.I was referred to this mailing list from the DNS-OARC community.]
>
> Context:
> I have already registered all my IP address blocks with ROA/RPKI
> [evidence: https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS9411]
> However, HE reports a lot of spurious IRR records on my resources
> [example: https://bgp.he.net/net/158.108.0.0/16#_irr]
>
> Question #1:
> Should I worry about those spurious records [Yes | No | Depends]?
> My fear is that other sites might accept those records without checking and thus be misled somewhere else, since ROV is not yet the behavior-in-majority.
> My other reasoning is that, if we are not going to keep accurate records, why bother keeping them at all anyway.
>
> Question #2:
> What can I do about it [in case the answer to Question #1 is Yes]?
> Should I notify those Database Admins? Will they consider me a nuisance?
> And most importantly: Will they erase those records for me, or will they just ignore me?
>
> Question #3:
> Did I not do something that can prevent those spurious records from happening in the first place?
> And, anything I can do now to prevent it from ever happening again?
>
>
> Thanks in advance for your advice(s),
>
> Pirawat.
>

On 10/30/20 9:26 PM, Rubens Kuhl wrote:
> 1 - You should worry a little, but not much. Filters allowing unwanted
> announcements might be created using these erroneous IRR records, but
> they won't do any damage by themselves. An actual wrong BGP
> announcement is required for any damage to happen, and even without
> those IRR records, a wrong announcement will cause some havoc since
> not everyone builds filters based on IRR and not everyone runs RPKI
> validation.

I've had problems where people who build filters on IRR will build their filters SOLELY based on IRR. That is, they are not permissive and will assume that, if there is an IRR object present for a prefix, that ONLY the announcements matching that object should be accepted. This can lead to severe reachability issues if not corrected.
--
Brandon Martin

Dear Pirawat,

On Mon, Oct 26, 2020 at 08:13:19PM +0700, Pirawat WATANAPONGSE wrote:
> I am seeking advice concerning someone else announcing IRR records on
> resources belonging to me.

Change is underway in the IRR ecosystem! The situation we are all used
to is that it is rather cumbersome to get IRR databases to remove IRR
objects. The IRR database operator may not trust your request for object
removal, or is busy doing other things. There was no industry-wide
automated process for IRR object removal.

With the introduction of "RIPE-731" (https://www.ripe.net/publications/docs/ripe-731)
in the RIPE region, the "RIPE-NONAUTH" database has slowly been
shrinking. The RIPE-NONAUTH database exclusively contains IRR objects
covering non-RIPE space. As more and more people create RPKI ROAs, which
in turn provide automated evidence whether objects in RIPE-NONAUTH are
valid or not valid. If an object is found to be invalid, it is deleted.

While RIPE-731 addressed the issue of stale objects in the RIPE-NONAUTH
database, of course it did not change anything for non-RIPE databases.
Most non-RIPE databases use software called "IRRd" (the likes of NTTCOM,
RADB, TC, etc). The IRRd software is the main entrypoint into the IRR
system, and recently IRRd v4.1.0 was released which can automatically
delete RPKI invalid IRR route objects.

A youtube video from last week with some information on IRRdv4 can be
seen here: https://www.youtube.com/watch?v=V9fsU0mNcA4

NTT has not yet upgraded from 4.0.0 -> 4.1.0, we are working on that.
RADB is also investigating a migration path. LACNIC & ARIN already are
on the v4 train.

The moment NTT and RADB have deployed 4.1.0 at rr.ntt.net and
whois.radb.net there will be an industry-wide fully automated IRR
cleanup process running which accomplishes two things:

- stale/rogue/erroneous objects (conflicting with RPKI) are deleted
- new objects which are in conflict with RPKI ROAs cannot be created

Using RPKI to clean up the IRR is a continuous process: this mechanism
helps clean up the past, but also going forward ensures that IRR does
not contain new information which is in conflict with published
cryptographically signed RPKI ROAs.

This 2018 video outlines the strategy how to migrate to an improved
state of internet routing security: https://www.youtube.com/watch?v=3BAwBClazWc
https://nlnog.net/static/nlnogday2018/9_routing_security_roadmap_nlnog_2018_snijders.pdf
Reality is now nearly synced up to all slides of the deck :-)

Kind regards,

Job