This space is not constrained by RPKI. Do we care about alignment? Personally, I do. I think IRR and RPKI should be aligned.But, across the IRR space, route object authorisation varies. Things done in RIPE IRR will not necessarily be echoed in other IRR including ones mirrored and served by RIPE in Whois queries.
Assertions in RPSL about routes are authorised by .. whom? The prefix holder, the AS holder, or both? Depends which IRR you use. Clearly, given that route objects exist which don't reflect locally maintained ASN, there is some complexity behind "both" and as Job points out, "things can change" regarding what is delegated, so definitions of "not currently in use" ASN are not fixed. In RPKI, assertions about a ROA are authorised solely by the prefix holder. This is a huge difference when it comes to checking. Also, there are strong cryptographic tests the ROA maker intentionally did this, its not casual use of a shared password in an RPSL update. >From a records management perspective I am sympathetic to "get rid of the rubbish" But rubbish is very contextually defined. "Bogons" is loose: Some people think use of private ASN in public routing is a "Bogon" but there are reasons for making route objects and ROA for private ASN routing surely? I don't think this problem has a single simple fix. You can do a post-hoc sweep of the records periodically, with some process, and probably solve the classic 80/20 of this situation. I am not a routing person. I defer to routing people when it comes to cost/benefit/damage inside the routing function (and, I no longer manage any aspect of IRR and RPKI related activity in APNIC so my input here is less weighty than it might have been) -G On Fri, Jul 2, 2021 at 4:26 AM denis walker via db-wg <db-wg@ripe.net> wrote: > > 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 <j...@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 <ripede...@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. >
