[db-wg] RIPE NONAUTH route(6) objects using unregistered space cleanup - deployment *today*

Hi all,

On Thu, Jul 01, 2021 at 06:18:11PM +0200, Edward Shryane via db-wg wrote:
> Hi Denis,
> 
> > On 30 Jun 2021, at 22:48, denis walker <ripedenis at gmail.com> wrote:
> > ...
> > Ed, have any of these ROUTE(6) objects been created recently? 
> ...
> 
> Here are the 72 route objects in the RIPE database referencing an
> unregistered origin (i.e. "available" or "reserved" in the delegated
> stats).
> 
> There is no registration date for those ASNs in the delegated stats,
> so I can't cross-check with the route creation date.
> 
> We dropped the authentication requirement for the origin as part of
> NWI-5, which went into production on 4th September 2018.

I cross-referenced these with BGP information.

I found 3 'exact' matches (where the BGP origin and prefix are matching
the route object's primary key and Origin AS)

    91.220.83.0/24    AS_PATH: 174 46414 i
    194.201.253.0/24  AS_PATH: 6453 9498 37662 37662 37305 25568 i
    2a0b:3e00::/32    AS_PATH: 174 14076 i

Furthermore, I found 33 BGP routes where the IP Prefix matches the IRR
route object's primary key, but the number in the 'origin:' attribute does not.

    83.216.160.0/19     AS_PATH: 28716 21309 i
    86.110.128.0/19     AS_PATH: 28716 21309 i
    83.216.160.0/20     AS_PATH: 174 21309 i
    83.216.176.0/20     AS_PATH: 174 21309 i
    86.110.128.0/20     AS_PATH: 174 21309 i
    86.110.144.0/20     AS_PATH: 174 21309 i
    194.99.204.0/22     AS_PATH: 13237 8569 8569 8569 8569 8569 8569 8569 ?
    193.33.110.0/23     AS_PATH: 3257 41508 i
    193.201.204.0/24    AS_PATH: 13237 47572 ?
    193.201.205.0/24    AS_PATH: 3257 42944 ?
    5.1.113.0/24        AS_PATH: 13789 13789 13789 13789 17056 i
    185.48.220.0/22     AS_PATH: 174 30742 30742 i
    77.246.74.0/24      AS_PATH: 3356 42020 42020 42020 42020 42020 42020 9051 9051 9051 9051 i
    185.106.44.0/24     AS_PATH: 29119 34471 203978 i
    158.255.59.0/24     AS_PATH: 174 13194 41898 i
    185.194.4.0/22      AS_PATH: 6762 5602 201102 i
    91.107.84.0/24      AS_PATH: 6762 31500 61400 i
    45.8.92.0/24        AS_PATH: 3356 41095 11877 13487 398083 398083 398083 398083 398083 i
    45.8.94.0/24        AS_PATH: 3257 22773 i
    45.8.95.0/24        AS_PATH: 3257 22773 i
    45.8.92.0/24        AS_PATH: 3356 41095 11877 13487 398083 398083 398083 398083 398083 i
    45.8.94.0/24        AS_PATH: 3257 22773 i
    45.8.95.0/24        AS_PATH: 3257 22773 i
    188.92.121.0/24     AS_PATH: 15169 396982 e
    193.135.119.0/24    AS_PATH: 3356 41095 11877 11877 11877 11877 13487 13487 13487 i
    45.95.0.0/24        AS_PATH: 3356 41095 11877 11877 11877 11877 13487 13487 13487 i
    45.95.1.0/24        AS_PATH: 3356 41095 11877 11877 11877 11877 13487 13487 13487 i
    45.95.2.0/24        AS_PATH: 3356 41095 11877 11877 11877 11877 13487 13487 13487 i
    45.95.3.0/24        AS_PATH: 3356 41095 11877 11877 11877 11877 13487 13487 13487 i
    193.110.94.0/24     AS_PATH: 1764 i
    2a01:9ba0::/32      AS_PATH: 174 30742 i
    2a0b:1040::/29      AS_PATH: 174 16186 50582 i
    2a0d:1a40:faf::/48  AS_PATH: 6939 202313 i
    
I imagine what happened in some cases is that "Company A" decides to do
a project (separate from it's core activities), for which they request a
new ASN. Then after some time, someone decides that operations would be
more efficient if the project is fully integrated into Company A's main
network, and they move the BGP announcement such that it originates from
the 'main' ASN... then they give the project-specific ASN back to the RIR.

In such scenarios, the visibility of the BGP route might depend on the
'erroneous' route object, which is (because of historical reasons)
perhaps references from an semi-up-to-date AS-SET.

A made-up example:

If AS 15562 originates 192.0.2.0/24 in BGP, and an IRR database contains
a route object for 192.0.2.0/24AS65123, and AS15562:AS-SNIJDERS contains
'AS65123' as member (either directly or through reference), and peers of
15562 use that AS-SET to generate filters, they'll end up generating a
prefix-list allow filter which permits 192.0.2.0/24 on the session with
15562. Removal of the 'erroneous' object might result in an outage for
192.0.2.0/24.

I spot checked the ASNs from Ed's email and all of them are referenced
in various AS-SETs in the ecosystem. This means it is hard to know
whether these objects with unregistered Origin ASNs represent a lifeline
to some operation somewhere, or are trash that should be deleted.

For sound operational reasons both in the RIPE database and in the RPKI
in general, the IP resource holder is permitted to designate any ASN
they wish as the origin. The removal of AS holder authentication
obstacle (through the work in NWI-5) removed a great deal of friction
for the operational community. It is challenging for IRR database
operators to automatically know whether the submitted AS is the correct
AS number.

Deleting objects solely because of the registration status of the AS
referenced in the 'origin:' attribute might have unintended
consequences... I'm inclined to agree with Cynthia's position.

Kind regards,

Job

-- 
No hats, just a Database Working Group contributor.