2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

Mon Apr 4 22:10:24 UTC 2022

Dear Jon, others,

On Mon, Apr 04, 2022 at 05:48:42PM -0400, Jon Lewis wrote:
> On Mon, 4 Apr 2022, Kenneth Finnegan wrote:
> > While I agree that it might be politically entertaining to let this
> > one blow up as a demonstration of how ARIN conducts business, this
> > list of networks includes too many small networks who likely don't
> > have a savy networking engineering team.
> > 
> > In my opinion, they are not acceptable collateral damage to
> > demonstrate ARIN's lack of regard for the community in shutting this
> > down without a transition plan for the RPSL objects, so as one of the
> > admins for the ALTDB IRR database, I've taken it upon myself to create
> > proxy registrations for all of these prefixes in ALTDB.
> > 
> > Like any proxy registration, asset owners are welcome to contact the
> > maint POC, and if no response from them, db-admin at altdb.net,
> > requesting that stale records be deleted, but please also note that
> > ALTDB automatically deletes any route objects which conflict with a
> > publishes RPKI ROA, so the most effective way to clean up stale IRR
> > records is to publish RPKI ROAs for your address space.
> 
> Does any other IRR do that?

An event not too dissimilar to the current situation at hand was when
the server systems on which the "SAVVIS" IRR database existed
experienced a catastrophic failure. At that time, Savvis had already
been acquired by another entity, but they were unable to
integrate/migrate dataset in time, and no backups appeared to be
available.

After some delibration and attempts to untangle the spaghetti of
potential consequences for the BGP customer cone of my then-employer, I
took the liberty to copy (proxy register) a significant number of
route+route6 objects into NTTCOM (similar to what Kenneth did) because
the alternative seemed worse. Deprecation of IRR databases is something
very few people in this industry really have hands-on experience with.

> What does ALTDB do if a route object exists (or multiple route objects exist
> for the same route with different origins) and multiple ROAs exist allowing
> the route to be originated by multiple ASNs?  Technically, some of those
> ROAs would conflict with some route objects.

I can't speak with any authority on ALTDB operational matters, but I
think they use a tool based on https://github.com/job/irr-nonauth-cleanup/

The 'irr-nonauth-cleanup' utility uses an algorithm similar to what is
described in RFC 6811 in context of classifying BGP routes, and also is
similar to what RIPE NCC uses to periodically clean up the
"RIPE-NONAUTH" IRR database. RIPE NCC's cleanup effort was codified
through community consensus and published as https://www.ripe.net/publications/docs/ripe-731

In the same spirit as RFC 6811 stipulates - RPKI ROAs never are
considered "in conflict" with each other. As long as at least one ROA
permits the specific (Prefix, Origin AS) tuple at hand to exist, the IRR
object may exist. It's fine for multiple ROAs to exist which cover the
same address space, this is what makes migrations/reconfigurations
possible.

> Are others jumping ship or planning to from ALTDB (no offense intended, and
> grateful for the service you've provided) and other non-auth IRRs like RADB
> due to networks like Tata announcing that they won't honor route objects
> created in non-authoratative IRR DBs after late last year and plan to ignore
> them entirely by late next year?  i.e.
> 
> From: https://lg.as6453.net/doc/cust-routing-policy.html
> 
>   Special note, deprecation of non-authoritative registries
> 
>   Please note that 'route' and 'route6' objects created after 2021-Aug-15
>   in non-authoritative registries like RADB, NTTCOM, ALTDB and others
>   will not work. Objects created before that date will continue to work till
>   2023-Aug-15. It is recommended to create RPKI ROA objects instead. In
>   rare cases if that's not possible, 'route' and 'route6' must be created
>   in the authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE,
>   NIC.br or IDNIC.

I very much appreciate Tata's efforts to strive to only use authoritive
data when making BGP routing decisions; however the scope of their
charter is of course confined to just Tata's own operations. Tata's
routing policies affect only Tata's customer cone.

Depending on the exact characteristics of one's customer cone it may be
feasible to only use RIR-provided IRR data sources, but it's not hard to
imagine that for some providers this is a bridge too far at this point
in time.

Kind regards,

Job