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

Hi Job

I admit to being a 'not well informed' routing person but let me try
to interpret what you have just said.

The origin ASN may or may not be registered when the ROUTE object is created.
The origin ASN can be returned (AUT-NUM deleted) after the ROUTE
object is created
The ROUTE object may or may not  be operationally significant even
though the ASN is (now) unregistered
It's not possible for the database to know if objects referencing
(now) none existing resources are meaningful

Lots of questions spring into my mind...
Does the origin ASN actually have any meaning given that it may or may
not exist now or in the past and may or may not be correct?
Should it be possible to create a new ROUTE object today with an
unregistered ASN as the origin?
Are ASNs (re)allocated when already referenced in ROUTE objects? (I
think it was agreed to ignore references in set objects)
Is it possible a new ASN resource holder can be linked to criminal
activity involving IP addresses they did not realise they are publicly
linked to?
I understand this situation can arise accidentally as in the case you
suggested, but can it also be deliberately manipulated to exist for
any reason?
If an ASN becomes unregistered when referenced in a ROUTE object
should any alarm bells start ringing, notifications get sent, ARCs
scheduled?
Given the small number in the RIPE Database this would be manageable.

If there are things that can be done to improve data quality, I don't
think we should just say it's difficult, let's live with it.

cheers
denis
co-chair DB-WG

On Thu, 1 Jul 2021 at 19:13, Job Snijders <job at sobornost.net> wrote:
>
> 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.