RIPE NONAUTH route(6) objects using unregistered space cleanup - deployment *today*
Dear colleagues, The implementation of the cleanup of RIPE NONAUTH route(6) objects using unregistered space is now complete, we plan to deploy to production *today*. This means that the cleanup job will run for the first time tonight. * Each night, all RIPE NONAUTH route(6) objects with an unregistered prefix ("available" or "reserved" in delegated stats) are selected. * If a prefix remains unregistered for 1 week, notify the maintainers of any related route(6) objects. * The maintainer can ask to make an exception, not to delete a route(6) object. * Otherwise, after a further 2 weeks, delete the route(6) objects. See the solution definition for more details: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html Note for now, the AS origin status is *not* considered. Please discuss further whether this should be included. If you have any feedback, please let us know. Regards Ed Shryane RIPE NCC
Hi Ed, Thanks for implementing this :) I mainly wanted to give my initial take on the AS origin status part which is in short: I don't think we should clean up based on origin AS. This is as you do not need any technical authorization from the AS holder to create a route(6) object. Additionally, I don't think this is validated in RIPE AUTH, but I could be wrong on that part. I might have a different opinion if it is a huge amount of objects that could be cleaned up or if it is such a tiny amount that maybe just contacting the maintainers manually would be enough. Summary: I don't think it is a good idea unless it is either a very large amount of objects, a very trivial task, or there is another good reason to do so. -Cynthia On Tue, Jun 29, 2021 at 11:27 AM Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
The implementation of the cleanup of RIPE NONAUTH route(6) objects using unregistered space is now complete, we plan to deploy to production *today*.
This means that the cleanup job will run for the first time tonight.
* Each night, all RIPE NONAUTH route(6) objects with an unregistered prefix ("available" or "reserved" in delegated stats) are selected. * If a prefix remains unregistered for 1 week, notify the maintainers of any related route(6) objects. * The maintainer can ask to make an exception, not to delete a route(6) object. * Otherwise, after a further 2 weeks, delete the route(6) objects.
See the solution definition for more details: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
Note for now, the AS origin status is *not* considered. Please discuss further whether this should be included.
If you have any feedback, please let us know.
Regards Ed Shryane RIPE NCC
Cynthia Revström via db-wg wrote on 29/06/2021 14:00:
I might have a different opinion if it is a huge amount of objects that could be cleaned up or if it is such a tiny amount that maybe just contacting the maintainers manually would be enough. Summary: I don't think it is a good idea unless it is either a very large amount of objects, a very trivial task, or there is another good reason to do so.
If the information is incorrect and can't be corrected, then the outcome of removing those objects will be an improvement in the quality of the data in the db, with no downsides. So, can a route/route6 object with valid prefix but invalid origin asn be updated to correct the asn? My understanding is not, and that an attempt to update the object with a different origin will create a new DB object. I.e. route/route6 objects with invalid origin ASN should be deleted, as they're both incorrect and unfixable. Nick
In message <CAKw1M3O2SmQLFQtnD=y+cypFjzV2G=OagAszRuysbXsV987k9w@mail.gmail.com>, =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me@cynthia.re> wrote:
I mainly wanted to give my initial take on the AS origin status part which is in short: I don't think we should clean up based on origin AS. This is as you do not need any technical authorization from the AS holder
I'm not sure what "technical authorization from the AS holder" has to do with this. BY DEFINITION, a route object that exists currently in the data base and that makes reference to a bogon AS number -does not- have any kind of authorization from the "AS holder" because -nobody- has been assigned that ASN.
Additionally, I don't think this is validated in RIPE AUTH, but I could be wrong on that part.
It is clear to me, based on my analysis so far, that nobody has -ever- been verifying that any of the AS numbers mentioned in *any* route(6) objects are non-bogus. This seems to be true in the case of -both- the regular data base and also within the NONAUTH data base.
I might have a different opinion if it is a huge amount of objects that could be cleaned up...
As I previously noted, there currently exist on the order of about 80+ route objects within the regular data base that make reference to bogon AS numbers. Within the NONAUTH data base, there are on the order of over 1,500+ of these. So far, in my limited inspection of these, the vast majority of all of these objects appear to be long-abandoned relics of an earlier age. Some were even likely abandoned 20+ years ago, and they have just been sitting and languishing in the data base, just waiting for some clever miscreant to come along and start making massive mischief with them.
Summary: I don't think it is a good idea unless it is either a very large amount of objects...
It is a substantial amount of objects, and it can be easily verified that the overwheling majority of these rout objects DO NOT correspond to any actual routing that is actually occurring on the Internet here in the year 2021. (I believe that some of the route(6) object in question even refer to AS numbers that are, and that always have been, "reserved" AS numbers, based upon long-established RFCs.)
... or there is another good reason to do so.
It has been my long experience, especially over that past 20 years, that there is essentially nothing that exists on or in relation to the Internet that creative miscreants will not find a way to treat as if it were an unattended bicycle. They routinely squat on stolen and/or unassigned "bogon" IP address space, and also and likewise, they routinely make use of stolen and/or abandoned AS numbers. The existance, in the data base, of route objects that refer to bogon AS numbers represents a kind of invitation to such miscreants... enticing them to engage in untoward funny business and in a way that could not then easily be attributed (since nobody "owns" the AS numbers in question). The bottom line is that if it was wise to remove route(6) objects from the data base that made reference to unassigned IP address blocks... and I believe that it most certainly was... then buy the exact same logic it is also wise to remove from the data base all route(6) objecct that refer to bogon ASNs. The reasoning, the rationale, and the logic is the same in both cases. Regards, rfg
Hi Cynthia,
On 29 Jun 2021, at 15:00, Cynthia Revström <me@cynthia.re> wrote:
Hi Ed,
Thanks for implementing this :)
Thanks for your feedback.
I mainly wanted to give my initial take on the AS origin status part which is in short: I don't think we should clean up based on origin AS. This is as you do not need any technical authorization from the AS holder to create a route(6) object. Additionally, I don't think this is validated in RIPE AUTH, but I could be wrong on that part.
I might have a different opinion if it is a huge amount of objects that could be cleaned up or if it is such a tiny amount that maybe just contacting the maintainers manually would be enough. Summary: I don't think it is a good idea unless it is either a very large amount of objects, a very trivial task, or there is another good reason to do so.
-Cynthia
I found 1,577 route objects (out of 55,960) and 43 route6 objects (out of 1,522) in the RIPE-NONAUTH database which reference an unregistered AS number (i.e. "available" or "reserved" in any RIRs delegated stats). Of these, there are 169 distinct unregistered AS numbers referenced by route(6) objects in RIPE-NONAUTH. As we don't validate the origin AS number in the RIPE database (apart from excluding bogon space according to: http://www.team-cymru.com/bogon-reference.html), I also checked route(6) objects there. I found 72 routes and 20 route6 objects in the RIPE database which reference an unregistered AS number (41 distinct AS numbers). Regards Ed Shryane RIPE NCC
Hi Ed, Thanks for the data, based on this I will stand by my opinion that there should be no action taken here currently. This opinion is also mainly based on the fact that it is not validated in the RIPE database. I am not sure if this is right or not, but I think it should probably not be cleaned up in RIPE-NONAUTH if it is not validated in RIPE. But once again if someone has a better reason then I could change my mind. Also if/when we get to a point that these objects are a very significant part of the remaining objects in RIPE-NONAUTH then it might be worth discussing again. I feel like in this case when there is no real personal data (afaik), we should value not breaking things we didn't think of way higher than cleaning up ~1600 route(6) objects. (Assuming the resource holders can contact the NCC to request to have them removed) -Cynthia On Wed, Jun 30, 2021 at 1:40 PM Edward Shryane <eshryane@ripe.net> wrote:
Hi Cynthia,
On 29 Jun 2021, at 15:00, Cynthia Revström <me@cynthia.re> wrote:
Hi Ed,
Thanks for implementing this :)
Thanks for your feedback.
I mainly wanted to give my initial take on the AS origin status part which is in short: I don't think we should clean up based on origin AS. This is as you do not need any technical authorization from the AS holder to create a route(6) object. Additionally, I don't think this is validated in RIPE AUTH, but I could be wrong on that part.
I might have a different opinion if it is a huge amount of objects that could be cleaned up or if it is such a tiny amount that maybe just contacting the maintainers manually would be enough. Summary: I don't think it is a good idea unless it is either a very large amount of objects, a very trivial task, or there is another good reason to do so.
-Cynthia
I found 1,577 route objects (out of 55,960) and 43 route6 objects (out of 1,522) in the RIPE-NONAUTH database which reference an unregistered AS number (i.e. "available" or "reserved" in any RIRs delegated stats).
Of these, there are 169 distinct unregistered AS numbers referenced by route(6) objects in RIPE-NONAUTH.
As we don't validate the origin AS number in the RIPE database (apart from excluding bogon space according to: http://www.team-cymru.com/bogon-reference.html), I also checked route(6) objects there.
I found 72 routes and 20 route6 objects in the RIPE database which reference an unregistered AS number (41 distinct AS numbers).
Regards Ed Shryane RIPE NCC
Hi Guys To create a ROUTE(6) object in the RIPE Database, the referenced origin AUT-NUM object doesn't need to exist in the RIPE Database. But should the ASN have been allocated by one of the RIRs? So perhaps the first questions to answer aren't about whether or not we should delete these ROUTE(6) objects referencing non allocated or reserved ASNs. Maybe we should ask questions like "does such a ROUTE(6) object have any operational value?". Does it have any legitimacy being in either the RIPE or RIPE-NONAUTH database? Can the existence of such an object cause any harm? If deleting such a ROUTE(6) object breaks something, but that 'something' should not have been relying on an invalid and unauthorised agreement (which is what a ROUTE(6) object is), does that matter? For the ROUTE(6) objects referencing RIPE address space and invalid ASNs, these objects had to be authorised by the address space holders. Why did they authorise creation of objects advertising false agreements? RIPE resource holders are required to enter correct data into the RIPE Database. The terms of the contracts they signed as resource holders give these objects no validity to remain in the RIPE Database. Answering these questions may answer the question about whether or not we should delete these ROUTE(6) objects. Ed, have any of these ROUTE(6) objects been created recently? Looking ahead, should we have a business rule in the RIPE Database to not allow creation of ROUTE(6) objects with an invalid (unallocated) origin ASN? cheers denis co-chair DB-WG On Wed, 30 Jun 2021 at 14:02, Cynthia Revström via db-wg <db-wg@ripe.net> wrote:
Hi Ed,
Thanks for the data, based on this I will stand by my opinion that there should be no action taken here currently. This opinion is also mainly based on the fact that it is not validated in the RIPE database. I am not sure if this is right or not, but I think it should probably not be cleaned up in RIPE-NONAUTH if it is not validated in RIPE.
But once again if someone has a better reason then I could change my mind. Also if/when we get to a point that these objects are a very significant part of the remaining objects in RIPE-NONAUTH then it might be worth discussing again.
I feel like in this case when there is no real personal data (afaik), we should value not breaking things we didn't think of way higher than cleaning up ~1600 route(6) objects. (Assuming the resource holders can contact the NCC to request to have them removed)
-Cynthia
On Wed, Jun 30, 2021 at 1:40 PM Edward Shryane <eshryane@ripe.net> wrote:
Hi Cynthia,
On 29 Jun 2021, at 15:00, Cynthia Revström <me@cynthia.re> wrote:
Hi Ed,
Thanks for implementing this :)
Thanks for your feedback.
I mainly wanted to give my initial take on the AS origin status part which is in short: I don't think we should clean up based on origin AS. This is as you do not need any technical authorization from the AS holder to create a route(6) object. Additionally, I don't think this is validated in RIPE AUTH, but I could be wrong on that part.
I might have a different opinion if it is a huge amount of objects that could be cleaned up or if it is such a tiny amount that maybe just contacting the maintainers manually would be enough. Summary: I don't think it is a good idea unless it is either a very large amount of objects, a very trivial task, or there is another good reason to do so.
-Cynthia
I found 1,577 route objects (out of 55,960) and 43 route6 objects (out of 1,522) in the RIPE-NONAUTH database which reference an unregistered AS number (i.e. "available" or "reserved" in any RIRs delegated stats).
Of these, there are 169 distinct unregistered AS numbers referenced by route(6) objects in RIPE-NONAUTH.
As we don't validate the origin AS number in the RIPE database (apart from excluding bogon space according to: http://www.team-cymru.com/bogon-reference.html), I also checked route(6) objects there.
I found 72 routes and 20 route6 objects in the RIPE database which reference an unregistered AS number (41 distinct AS numbers).
Regards Ed Shryane RIPE NCC
Hi Denis,
On 30 Jun 2021, at 22:48, denis walker <ripedenis@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. 194.165.87.0/24AS21389,20020304 83.216.160.0/19AS31419,20040630 213.228.244.0/24AS31453,20050104 86.110.128.0/19AS31419,20050719 83.136.64.0/21AS8871,20051114 83.216.160.0/20AS31419,20060428 83.216.176.0/20AS31419,20060428 86.110.128.0/20AS31419,20060428 86.110.144.0/20AS31419,20060428 194.99.204.0/22AS36895,20060504 83.216.160.0/21AS31419,20061018 83.216.168.0/21AS31419,20061018 83.216.176.0/21AS31419,20061018 83.216.184.0/21AS31419,20061018 91.102.168.0/21AS8295,20061117 91.102.168.0/24AS8295,20061117 91.102.169.0/24AS8295,20061117 91.102.170.0/24AS8295,20061117 91.102.171.0/24AS8295,20061117 91.102.172.0/24AS8295,20061117 91.102.173.0/24AS8295,20061117 91.102.174.0/24AS8295,20061117 91.102.175.0/24AS8295,20061117 193.33.110.0/23AS42796,20070417 193.201.204.0/24AS14880,20071123 193.201.205.0/24AS14880,20071123 86.110.128.0/21AS31419,20100909 86.110.136.0/21AS31419,20100909 86.110.144.0/21AS31419,20100909 86.110.152.0/21AS31419,20100909 91.220.83.0/24AS46414,20101028 5.1.112.0/21AS198738,20120426 5.1.112.0/24AS198738,20120516 5.1.113.0/24AS198738,20120516 81.52.165.0/24AS36879,20131001 81.52.166.0/24AS36879,20131002 81.52.167.0/24AS36879,20131002 81.52.168.0/24AS36879,20131002 81.52.169.0/24AS36879,20131002 185.48.220.0/22AS199724,20140305 194.201.253.0/24AS25568,20140408 5.160.196.0/24AS62280,20140510 5.160.197.0/24AS62280,20140510 5.160.240.0/24AS62280,20141102 5.160.241.0/24AS62280,20141102 77.246.74.0/24AS37631,20150529 185.106.44.0/24AS200968,20150629 158.255.59.0/24AS203655,20151127 185.148.138.0/23AS198738,20160912 82.98.78.0/24AS394935,20161026 185.164.160.0/22as14076,20161102 185.200.32.0/22AS33431,20170613 185.225.136.0/22AS33431,20171013 185.244.144.0/22AS204634,20180202 185.194.4.0/22AS205740,20180209 185.148.136.0/22AS198738,20190708 91.107.84.0/24AS202532,20190708 45.8.92.0/24AS46723,20190912 45.8.93.0/24AS46723,20190912 45.8.94.0/24AS46723,20190912 45.8.95.0/24AS46723,20190912 45.8.92.0/24AS397796,20190917 45.8.94.0/24AS397796,20190917 45.8.95.0/24AS397796,20190917 141.98.12.0/24AS208469,20200325 188.92.121.0/24AS40178,20200401 193.135.119.0/24AS46723,20200530 45.95.0.0/24AS46723,20200530 45.95.1.0/24AS46723,20200530 45.95.2.0/24AS46723,20200530 45.95.3.0/24AS46723,20200530 193.110.94.0/24AS16712,20210318 Here are the 20 route6 objects in the RIPE database with an unregistered origin: 2A00:9700:1::/48AS47497,20110225 2A00:E640::/32AS198738,20120426 2A01:9BA0::/32AS199724,20140305 2A0B:3E00::/32AS14076,20161102 2A0B:1040::/29AS31005,20170604 2A03:1960::/32AS201400,20170724 2A0B:4340:9::/64AS136559,20170830 2A0B:4340:10::/44AS136559,20171111 2A0D:2906::/32AS136559,20171130 2A09:F700::/29AS46723,20190306 2A03:B600::/29AS46723,20190314 2A0E:AA07:F030::/44AS132352,20190426 2A09:BE40:3620::/48AS208577,20190815 2A03:9C00:F::/48AS210323,20191217 2A0B:4340:A0:3EC::/64AS139734,20200318 2A0E:B107:680::/48AS140540,20200402 2A0D:1A40:FAF::/48AS138987,20200613 2A0E:B107:1E0::/44AS139641,20200623 2A07:7E40:1::/48AS34676,20200728 2A0A:7740::/48AS46076,20201030 Regards Ed
cheers denis co-chair DB-WG
Hi Ed Thanks for the data. This is quite bad. As recently as March this year someone created a ROUTE object referencing an unregistered ASN: 193.110.94.0/24AS16712,20210318 This is not 'accurate data' that resource holders are contracted to enter into the RIPE Database. It could simply be a typo rather than intentional false data. The obvious question is, should it be possible to create such an object today? cheers denis co-chair DB-WG On Thu, 1 Jul 2021 at 18:18, Edward Shryane <eshryane@ripe.net> wrote:
Hi Denis,
On 30 Jun 2021, at 22:48, denis walker <ripedenis@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.
194.165.87.0/24AS21389,20020304 83.216.160.0/19AS31419,20040630 213.228.244.0/24AS31453,20050104 86.110.128.0/19AS31419,20050719 83.136.64.0/21AS8871,20051114 83.216.160.0/20AS31419,20060428 83.216.176.0/20AS31419,20060428 86.110.128.0/20AS31419,20060428 86.110.144.0/20AS31419,20060428 194.99.204.0/22AS36895,20060504 83.216.160.0/21AS31419,20061018 83.216.168.0/21AS31419,20061018 83.216.176.0/21AS31419,20061018 83.216.184.0/21AS31419,20061018 91.102.168.0/21AS8295,20061117 91.102.168.0/24AS8295,20061117 91.102.169.0/24AS8295,20061117 91.102.170.0/24AS8295,20061117 91.102.171.0/24AS8295,20061117 91.102.172.0/24AS8295,20061117 91.102.173.0/24AS8295,20061117 91.102.174.0/24AS8295,20061117 91.102.175.0/24AS8295,20061117 193.33.110.0/23AS42796,20070417 193.201.204.0/24AS14880,20071123 193.201.205.0/24AS14880,20071123 86.110.128.0/21AS31419,20100909 86.110.136.0/21AS31419,20100909 86.110.144.0/21AS31419,20100909 86.110.152.0/21AS31419,20100909 91.220.83.0/24AS46414,20101028 5.1.112.0/21AS198738,20120426 5.1.112.0/24AS198738,20120516 5.1.113.0/24AS198738,20120516 81.52.165.0/24AS36879,20131001 81.52.166.0/24AS36879,20131002 81.52.167.0/24AS36879,20131002 81.52.168.0/24AS36879,20131002 81.52.169.0/24AS36879,20131002 185.48.220.0/22AS199724,20140305 194.201.253.0/24AS25568,20140408 5.160.196.0/24AS62280,20140510 5.160.197.0/24AS62280,20140510 5.160.240.0/24AS62280,20141102 5.160.241.0/24AS62280,20141102 77.246.74.0/24AS37631,20150529 185.106.44.0/24AS200968,20150629 158.255.59.0/24AS203655,20151127 185.148.138.0/23AS198738,20160912 82.98.78.0/24AS394935,20161026 185.164.160.0/22as14076,20161102 185.200.32.0/22AS33431,20170613 185.225.136.0/22AS33431,20171013 185.244.144.0/22AS204634,20180202 185.194.4.0/22AS205740,20180209 185.148.136.0/22AS198738,20190708 91.107.84.0/24AS202532,20190708 45.8.92.0/24AS46723,20190912 45.8.93.0/24AS46723,20190912 45.8.94.0/24AS46723,20190912 45.8.95.0/24AS46723,20190912 45.8.92.0/24AS397796,20190917 45.8.94.0/24AS397796,20190917 45.8.95.0/24AS397796,20190917 141.98.12.0/24AS208469,20200325 188.92.121.0/24AS40178,20200401 193.135.119.0/24AS46723,20200530 45.95.0.0/24AS46723,20200530 45.95.1.0/24AS46723,20200530 45.95.2.0/24AS46723,20200530 45.95.3.0/24AS46723,20200530 193.110.94.0/24AS16712,20210318
Here are the 20 route6 objects in the RIPE database with an unregistered origin:
2A00:9700:1::/48AS47497,20110225 2A00:E640::/32AS198738,20120426 2A01:9BA0::/32AS199724,20140305 2A0B:3E00::/32AS14076,20161102 2A0B:1040::/29AS31005,20170604 2A03:1960::/32AS201400,20170724 2A0B:4340:9::/64AS136559,20170830 2A0B:4340:10::/44AS136559,20171111 2A0D:2906::/32AS136559,20171130 2A09:F700::/29AS46723,20190306 2A03:B600::/29AS46723,20190314 2A0E:AA07:F030::/44AS132352,20190426 2A09:BE40:3620::/48AS208577,20190815 2A03:9C00:F::/48AS210323,20191217 2A0B:4340:A0:3EC::/64AS139734,20200318 2A0E:B107:680::/48AS140540,20200402 2A0D:1A40:FAF::/48AS138987,20200613 2A0E:B107:1E0::/44AS139641,20200623 2A07:7E40:1::/48AS34676,20200728 2A0A:7740::/48AS46076,20201030
Regards Ed
cheers denis co-chair DB-WG
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@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.
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@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@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.
From a records management perspective I am sympathetic to "get rid of
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. 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 <job@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@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.
George, Ed, everybody, This seems as good a moment as any to wave the POLA, transparency, and due-process banners. On 1 Jul 2021, at 23:46, George Michaelson via db-wg wrote:
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 wonder what criterion (or set of criteria) is available as the basis for such a sweep. As Edward Shryane via db-wg wrote on 1 Jul 2021, at 17:18:
We dropped the authentication requirement for the origin as part of NWI-5, which went into production on 4th September 2018.
As I read this (from Ed), data such as are involved in “this situation” are currently acceptable for insertion into the database, according to criteria concretized in the implementation of NWI-5. It seems to follow that anyone who has placed such data in the database may reasonably expect that they remain there, without interference, not only for as long as these acceptance criteria remain in effect, but also beyond that until action to remove or rectify prior data has been agreed by consensus in the WG, passed as a new NWI to the NCC, and implemented with due notice to the interested parties. Process and following it are tedious. Premature action is surprising, lacks transparency, and is unfair. I suggest keeping to the “yellow brick road”. Best regards, Niall — However far away I may place my hat, some of you will be convinced you can see its shadow.
Hi Niall On Fri, 2 Jul 2021 at 17:21, Niall O'Reilly via db-wg <db-wg@ripe.net> wrote:
George, Ed, everybody,
This seems as good a moment as any to wave the POLA, transparency, and due-process banners.
On 1 Jul 2021, at 23:46, George Michaelson via db-wg wrote:
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 wonder what criterion (or set of criteria) is available as the basis for such a sweep.
As Edward Shryane via db-wg wrote on 1 Jul 2021, at 17:18:
We dropped the authentication requirement for the origin as part of NWI-5, which went into production on 4th September 2018.
As I read this (from Ed), data such as are involved in “this situation” are currently acceptable for insertion into the database, according to criteria concretized in the implementation of NWI-5.
Not exactly. NWI-5 was about authorisation of correct data. It removed the requirement for mandatory authorisation by the ASN holder as well as the address space holder. It wasn't an invitation for resource holders to create ROUTE(6) objects referencing non existing ASNs or for ROUTE(6) objects to persist after the AUT-NUM object referenced in the origin is deleted.
It seems to follow that anyone who has placed such data in the database may reasonably expect that they remain there, without interference, not only for as long as these acceptance criteria remain in effect, but also beyond that until action to remove or rectify prior data has been agreed by consensus in the WG, passed as a new NWI to the NCC, and implemented with due notice to the interested parties.
Maybe the low hanging fruit here is to not allow a ROUTE(6) object to be created if it references an unregistered ASN at the time of creation. Although George did say: "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?" But prior to NWI-5 (in 2018) if ROUTE(6) objects were created for private ASNs they would have had to create an AUT-NUM object in the RIPE Database for the private ASN to authorise the route creation. That was only possible for non RIPE ASNs. So is routing with private ASNs in the RIPE Database a recent activity? I will bow to advice from routing experts on this. cheers denis co-chair DB-WG
Process and following it are tedious.
Premature action is surprising, lacks transparency, and is unfair.
I suggest keeping to the “yellow brick road”.
Best regards, Niall
— However far away I may place my hat, some of you will be convinced you can see its shadow.
On 2 Jul 2021, at 16:47, denis walker wrote:
Maybe the low hanging fruit here is to not allow a ROUTE(6) object to be created if it references an unregistered ASN at the time of creation.
Maybe. I think the first step is to decide what, in principle, distinguishes “rotten” from “sound” ROUTE(6) objects, and to establish consensus on this principle. Then, it should be easy to articulate a criterion (or set of criteria) which can be used to test each object in the category of interest for “soundness”, and so identify the objects which are candidates for action. Next, consensus on the action to be taken will be needed, taking due account of the suggestion by George that there may be “reasons for making route objects and ROA for private ASN routing”, of Job’s warning of the risk of unintended consequences, of Cynthia’s view that no action is currently warranted, and of Roland’s enthusiasm for a clean-up. At that stage, what will have been agreed can be wrapped up as an NWI and handed over to the NCC for analysis, action, and reporting. Finally,
I will bow to advice from routing experts on this.
So shall I. I hope this helps. Best regards, Niall
In message <4F1ED65A-D179-489F-8CC0-D9F797534147@ucd.ie>, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
I think the first step is to decide what, in principle, distinguishes “rotten” from “sound” ROUTE(6) objects, and to establish consensus on this principle.
I admit to being rather entirely stunned and flummoxed. Is there seriously any ambiguity or controversy here? Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs that are reserved, and that have been reserved, by various RFC(s), since time immemorial (e.g. 65535)? Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs that have -never- been assigned by any RIR to any party? Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs whose registrations have been revoked by the applicable RIR, e.g. due to either the non-payment of fees, or worse, due to outright fraud on the part of the relevant registrant? How would any of these usage scenarios do anything other than to damage the credibility and the reliability of the RIPE data base? How would any of these usage scenarios do anything other than to -reduce- the stability of the Internet? Could we please cut the crap and the speculative hand waving? Show me some -actual- example where keeping any of this garbage in the data base materially helps anyone. Regards, rfg
Hi Ronald, It is a matter of feasibility. In this context, at this layer of the technology stack it is up to the database clients to filter out information they do not consider of interest. The database is merely a conduit between an authorized internet number resource holder and the database clients. I'll share a practical example of 'client side' filtering. Back in 2016 I helped coordinate an industry-wide efforts to rid the public BGP Default-Free Zone of private ASNs. https://ripe72.ripe.net/archives/video/193/ https://ripe72.ripe.net/presentations/151-RIPE72_bogon_ASNs_JobSnijders.pdf I consider the campaign a success because nowadays private ASNs are by-and-large unusable in context of public BGP routing. The creation of easy to copy+paste config examples has further solidified the separation between 'public' and 'private': https://bgpfilterguide.nlnog.net/guides/bogon_asns/ Drawing analogies between IRR and RPKI ====================================== The expectation is that RPKI will assume most functionality of IRR databases over time. Thus, before proposing changes to any IRR system, we have to consider the rules of its cryptographic sibling, the RPKI, as that is the successor to IRR. In the RPKI authorization model the equivalent of the "origin:" attribute is defined as a positive integer [1] known as the 'ASId'. The issuer of the ROA decides what numeric value the ASId is set to. In many RPKI deployment scenarios it is *** technically impossible *** for the RIR to impose restrictions on the content of the ASId field, because the RIR is not involved in the issuance or publication of said objects. It is up to the relaying party (aka the 'database client') to discard objects which are not of interest because of local policy. Do I tell people they might have misconfigured an IRR route object or RPKI ROA when I see it? Yes Does IRRexplorer show warnings when private numbers are found in objects? Yes Should RIPE NCC point out private values in objects during Assisted Registry Checks? Yes Should BGP Default-Free Zone operators configure their routers to discard BGP UPDATE messages with private ASNs? Yes Should the database server software impose brittle restrictions on that field? No, not worth the headache. Kind regards, Job [1]: https://datatracker.ietf.org/doc/html/rfc6482#section-3
Hi Working Group, I'd like to clarify my position, Ronald lists three restrictions, the totality of those restrictions is what I consider brittle. On Tue, Jul 06, 2021 at 06:57:20PM -0700, Ronald F. Guilmette via db-wg wrote:
Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs that are reserved, and that have been reserved, by various RFC(s), since time immemorial (e.g. 65535)?
Preventing object creation where the origin AS is any of the following 0 # RFC 7607 23456 # RFC 4893 AS_TRANS 64496..64511 # RFC 5398 and documentation/example ASNs 64512..65534 # RFC 6996 Private ASNs 65535 # RFC 7300 Last 16 bit ASN 65536..65551 # RFC 5398 and documentation/example ASNs 65552..131071 # RFC IANA reserved ASNs 4200000000..4294967294 # RFC 6996 Private ASNs 4294967295 # RFC 7300 Last 32 bit ASN seems reasonable to me, I believe that in the Hosted RPKI environment similar restrictions apply. However, the following two restrictions are not optimal in my opinion.
Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs that have -never- been assigned by any RIR to any party?
Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs whose registrations have been revoked by the applicable RIR, e.g. due to either the non-payment of fees, or worse, due to outright fraud on the part of the relevant registrant?
For me this style of anthropomorphistic writing makes dialogue harder, for example the RIPE database lacks the ability to 'endorse' anything. Kind regards, Job
Good news everyone, most of the work was already done! :-) On Wed, Jul 07, 2021 at 01:08:18PM +0000, Job Snijders via db-wg wrote:
On Tue, Jul 06, 2021 at 06:57:20PM -0700, Ronald F. Guilmette via db-wg wrote:
Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs that are reserved, and that have been reserved, by various RFC(s), since time immemorial (e.g. 65535)?
Preventing object creation where the origin AS is any of the following
0 # RFC 7607 23456 # RFC 4893 AS_TRANS 64496..64511 # RFC 5398 and documentation/example ASNs 64512..65534 # RFC 6996 Private ASNs 65535 # RFC 7300 Last 16 bit ASN 65536..65551 # RFC 5398 and documentation/example ASNs 65552..131071 # RFC IANA reserved ASNs 4200000000..4294967294 # RFC 6996 Private ASNs 4294967295 # RFC 7300 Last 32 bit ASN
seems reasonable to me, I believe that in the Hosted RPKI environment similar restrictions apply.
The RIPE database already blocks creation of route/route6 objects for almost all private ASNs, see source code here: https://github.com/RIPE-NCC/whois/blob/9e40c79dfb3b00f63471126e17d9a70c76ea3... Which results in simple error message: http://chloe.sobornost.net/~job/cant_create_private.png The only ASN missing from the 'whois.reserved.as.numbers' list, compared to the list I provided is '23456'. I suspect that adding '23456' to the list indeed is not controversial. Kind regards, Job
Hi Job, I just replied to the previous thread regarding this so I have reposted it below (summary: +1/LGTM) I think that AS23456 should be excluded as I can't think of any good reason for having such a route object and seemingly no one else either as there are none currently. https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&inverse=origin&rflag=true&searchtext=AS23456&source=RIPE So assuming that I didn't mess up the query and that there are in fact none currently, I think it is completely reasonable to exclude AS23456 as while not listed as "reserved" it is reserved for a specific internal (unlike AS112) use case. -Cynthia On Wed, Jul 7, 2021 at 3:24 PM Job Snijders via db-wg <db-wg@ripe.net> wrote:
Good news everyone, most of the work was already done! :-)
On Wed, Jul 07, 2021 at 01:08:18PM +0000, Job Snijders via db-wg wrote:
On Tue, Jul 06, 2021 at 06:57:20PM -0700, Ronald F. Guilmette via db-wg wrote:
Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs that are reserved, and that have been reserved, by various RFC(s), since time immemorial (e.g. 65535)?
Preventing object creation where the origin AS is any of the following
0 # RFC 7607 23456 # RFC 4893 AS_TRANS 64496..64511 # RFC 5398 and documentation/example ASNs 64512..65534 # RFC 6996 Private ASNs 65535 # RFC 7300 Last 16 bit ASN 65536..65551 # RFC 5398 and documentation/example ASNs 65552..131071 # RFC IANA reserved ASNs 4200000000..4294967294 # RFC 6996 Private ASNs 4294967295 # RFC 7300 Last 32 bit ASN
seems reasonable to me, I believe that in the Hosted RPKI environment similar restrictions apply.
The RIPE database already blocks creation of route/route6 objects for almost all private ASNs, see source code here:
https://github.com/RIPE-NCC/whois/blob/9e40c79dfb3b00f63471126e17d9a70c76ea3...
Which results in simple error message: http://chloe.sobornost.net/~job/cant_create_private.png
The only ASN missing from the 'whois.reserved.as.numbers' list, compared to the list I provided is '23456'.
I suspect that adding '23456' to the list indeed is not controversial.
Kind regards,
Job
Cynthia Revström via db-wg wrote on 07/07/2021 15:44:
I think that AS23456 should be excluded as I can't think of any good reason for having such a route object and seemingly no one else either as there are none currently.
at one point years ago, before asn32s-capable software was widely available, it occasionally made sense to encode AS23456 in various objects. These days, there is no reason for it, and it would be better if AS23456 didn't appear in IRR objects. This brings up Niall's point about making sure that objects like this can't reappear if they're deleted. Nick
Hi Job,
On 7 Jul 2021, at 15:08, Job Snijders via db-wg <db-wg@ripe.net> wrote:
Hi Working Group,
I'd like to clarify my position, Ronald lists three restrictions, the totality of those restrictions is what I consider brittle.
On Tue, Jul 06, 2021 at 06:57:20PM -0700, Ronald F. Guilmette via db-wg wrote:
Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs that are reserved, and that have been reserved, by various RFC(s), since time immemorial (e.g. 65535)?
Preventing object creation where the origin AS is any of the following
0 # RFC 7607 23456 # RFC 4893 AS_TRANS 64496..64511 # RFC 5398 and documentation/example ASNs 64512..65534 # RFC 6996 Private ASNs 65535 # RFC 7300 Last 16 bit ASN 65536..65551 # RFC 5398 and documentation/example ASNs 65552..131071 # RFC IANA reserved ASNs 4200000000..4294967294 # RFC 6996 Private ASNs 4294967295 # RFC 7300 Last 32 bit ASN
seems reasonable to me, I believe that in the Hosted RPKI environment similar restrictions apply.
Currently it is not possible to create a route(6) in the RIPE database with a 'reserved' AS number according to: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml which includes 0,64496-131071,4200000000-4294967295 So 23456 is *not* excluded, but it can be if the DB-WG agrees. Regards Ed Shryane RIPE NCC
Hi Ed, I think that AS23456 should be excluded as I can't think of any good reason for having such a route object and seemingly no one else either as there are none currently. https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&inverse=origin&rflag=true&searchtext=AS23456&source=RIPE So assuming that I didn't mess up the query and that there are in fact none currently, I think it is completely reasonable to exclude AS23456 as while not listed as "reserved" it is reserved for a specific internal (unlike AS112) use case. -Cynthia On Wed, Jul 7, 2021 at 4:05 PM Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Job,
On 7 Jul 2021, at 15:08, Job Snijders via db-wg <db-wg@ripe.net> wrote:
Hi Working Group,
I'd like to clarify my position, Ronald lists three restrictions, the totality of those restrictions is what I consider brittle.
On Tue, Jul 06, 2021 at 06:57:20PM -0700, Ronald F. Guilmette via db-wg wrote:
Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs that are reserved, and that have been reserved, by various RFC(s), since time immemorial (e.g. 65535)?
Preventing object creation where the origin AS is any of the following
0 # RFC 7607 23456 # RFC 4893 AS_TRANS 64496..64511 # RFC 5398 and documentation/example ASNs 64512..65534 # RFC 6996 Private ASNs 65535 # RFC 7300 Last 16 bit ASN 65536..65551 # RFC 5398 and documentation/example ASNs 65552..131071 # RFC IANA reserved ASNs 4200000000..4294967294 # RFC 6996 Private ASNs 4294967295 # RFC 7300 Last 32 bit ASN
seems reasonable to me, I believe that in the Hosted RPKI environment similar restrictions apply.
Currently it is not possible to create a route(6) in the RIPE database with a 'reserved' AS number according to: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml
which includes 0,64496-131071,4200000000-4294967295
So 23456 is *not* excluded, but it can be if the DB-WG agrees.
Regards Ed Shryane RIPE NCC
Edward Shryane via db-wg wrote on 07/07/2021 15:05:
So 23456 is*not* excluded, but it can be if the DB-WG agrees.
just to be clearer: AS23456 should be included in the list of ASNs which cannot be used as the origin. Any objects which refer to it should be flagged for deletion. Nick
On Wed, Jul 07, 2021 at 10:29:42PM +0100, Nick Hilliard wrote:
Edward Shryane via db-wg wrote on 07/07/2021 15:05:
So 23456 is*not* excluded, but it can be if the DB-WG agrees.
just to be clearer: AS23456 should be included in the list of ASNs which cannot be used as the origin.
Yes.
Any objects which refer to it should be flagged for deletion.
Are you referring to RIPE or RIPE-NONAUTH? In 'RIPE-NONAUTH' no references appear to 23456. In 'RIPE' (the authoritative database) there are quite a few references to 23456. I would propose a "do not disturb existing objects" strategy for data source 'RIPE'. Because if there are no route/route6 objects with 23456 as 'origin:' (as Cynthia indicated), then the key 'members: AS23456' will be a NO-OP when doing reverse lookups through IRR AS-SETs to generate a prefix filterlist. Kind regards, Job
On 08/07/2021 00:29, Nick Hilliard via db-wg wrote:
Edward Shryane via db-wg wrote on 07/07/2021 15:05:
So 23456 is*not* excluded, but it can be if the DB-WG agrees.
just to be clearer: AS23456 should be included in the list of ASNs which cannot be used as the origin.
Any objects which refer to it should be flagged for deletion.
Nick
Why single out 23456 when there are many other ASNs such as those listed here: https://en.wikipedia.org/wiki/Autonomous_system_(Internet)#ASN_Table In the same way we would not allow 10.0.0.0 to appear as an inetnum in the DB, so too numerous private use and reserved ASNs should not appear in the DB. Regards, Hank
Hi Hank, As Ed mentioned earlier in the thread all of those except AS23456 are already blocked. -Cynthia On Thu, Jul 8, 2021, 08:14 Hank Nussbacher via db-wg <db-wg@ripe.net> wrote:
On 08/07/2021 00:29, Nick Hilliard via db-wg wrote:
Edward Shryane via db-wg wrote on 07/07/2021 15:05:
So 23456 is*not* excluded, but it can be if the DB-WG agrees.
just to be clearer: AS23456 should be included in the list of ASNs which cannot be used as the origin.
Any objects which refer to it should be flagged for deletion.
Nick
Why single out 23456 when there are many other ASNs such as those listed here: https://en.wikipedia.org/wiki/Autonomous_system_(Internet)#ASN_Table
In the same way we would not allow 10.0.0.0 to appear as an inetnum in the DB, so too numerous private use and reserved ASNs should not appear in the DB.
Regards, Hank
In message <YOWnQqD/X+EMPI5T@bench.sobornost.net>, Job Snijders <job@sobornost.net> wrote:
However, the following two restrictions are not optimal in my opinion.
Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs that have -never- been assigned by any RIR to any party?
Who is insisting that the RIPE data base should be effectively endorsing the *public* use of ASNs whose registrations have been revoked by the applicable RIR, e.g. due to either the non-payment of fees, or worse, due to outright fraud on the part of the relevant registrant?
For me this style of anthropomorphistic writing makes dialogue harder, for example the RIPE database lacks the ability to 'endorse' anything.
The presence of anything within the RIPE data base is effectively a public endorsement of that information. Does your bank hand out Monopoly{tm} money bills? No. Of course not. They have a reputation to protect. If the presence of a given route object within the RIPE data base is NOT an implicit endorsement of that route object by RIPE NCC and the RIPE community, then fine. In that case those un-endorsed "joke" route objects don't need to be in the RIPE data base. They can instead be published someplace else, like, for example, on Pastebin.com. I note that you say that disallowing route objects that refer to unassigned (but not reserved) ASNs would be "not optimal" byt you have deftly avoided responding to my eminently reasonable challenge: Show me. Show me even a single actual example where it does anything other than to dilute that value of the RIPE IRR to have it contain some *specific* route object which makes reference to some bogon ASN. In the absence of even a single concrete example where a "bogon" route object would be of any value to have in the RIPE IRR I stand by my prior assertion that arguments in favor of AS-bogon route objects are just a bunch of vapid hand waving, and that the very idea is merely a notion "full of sound and fury, signifying nothing." Regards, rfg
Edward Shryane via db-wg wrote on 29/06/2021 10:27:
If you have any feedback, please let us know.
yip - any route which overlaps any prefix block which was marked as reserved or invalid between 2018-09-04 and today, by any RIR, for more than the RIR's reclamation pool cool-down period, should also be considered as a candidate for deletion. There needs to be some care here, e.g. the recent Afrinic address block hijacking saga. It may be that the resulting route/route6 deletion candidate set might end up with a manual review process. Otherwise the autonuke process looks good. Nick
In message <4A061BA5-46D6-4D42-BED1-663C3D498207@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:
* The maintainer can ask to make an exception, not to delete a {bogon} route(6) object.
OK. I'll bite. Why?
* Otherwise, after a further 2 weeks, delete the route(6) objects.
Wait a minute. So for periods up to two full weeks, RIPE NCC will support and facilitate the use of bogon IP address space?? Somebody is going to need to explain to me the wisdom of that.
Note for now, the AS origin status is *not* considered. Please discuss further whether this should be included.
Maybe you missed it. I have raised this point multiple times here on this mailing list, i.e. the issue of eliminating those route objects that make refernece to bogon AS numbers from the data base, and each time there was an outpouring of unbridled enthusiasm. So what's the hold up? Eliminating the route objects that referred to bogon IP address space was a GOOD and a NECESSARY thing, but failing to also eliminate from the data base all of the (mostly ancient and abandoned) route objects that refer to bogon ASNs makes about as much sense as using a colander as a condom. Regards, rfg
Hi Ronald,
On 29 Jun 2021, at 22:56, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
In message <4A061BA5-46D6-4D42-BED1-663C3D498207@ripe.net>, Edward Shryane <eshryane@ripe.net> wrote:
* The maintainer can ask to make an exception, not to delete a {bogon} route(6) object.
OK. I'll bite. Why?
We don't know the purposes those route(6) objects are being used for. This is user data, and we can only delete objects according to the implementation plan agreed with the DB-WG. We need an option to exclude deleting route(6) objects, in case it could cause an operational issue by deleting them automatically. An alternative (if operational issues arise) is to disable the feature entirely, and this is also undesirable (i.e. we don't cleanup any objects).
* Otherwise, after a further 2 weeks, delete the route(6) objects.
Wait a minute. So for periods up to two full weeks, RIPE NCC will support and facilitate the use of bogon IP address space??
Somebody is going to need to explain to me the wisdom of that.
We will wait for two weeks after informing the object maintainer(s) to give them time to prepare, or in case they have a question, or raise a valid reason why we shouldn't delete the object. The 2018-06 NONAUTH cleanup has a similar clause to properly inform the parties involved (14 days in the text): https://www.ripe.net/participate/policies/proposals/2018-06
Note for now, the AS origin status is *not* considered. Please discuss further whether this should be included.
Maybe you missed it. I have raised this point multiple times here on this mailing list, i.e. the issue of eliminating those route objects that make refernece to bogon AS numbers from the data base, and each time there was an outpouring of unbridled enthusiasm. So what's the hold up?
Your suggestion is being discussed and I await consensus from the DB-WG before proceeding with it (the feedback was not unanimous). The current implementation for checking unregistered prefixes is already complete and can be extended to include AS numbers if the DB-WG agrees. Regards Ed Shryane RIPE NCC
Eliminating the route objects that referred to bogon IP address space was a GOOD and a NECESSARY thing, but failing to also eliminate from the data base all of the (mostly ancient and abandoned) route objects that refer to bogon ASNs makes about as much sense as using a colander as a condom.
Regards, rfg
Dear colleagues, It has now been one week since the cleanup job was enabled. Last night we emailed the maintainers of 890 route(6) objects, which will be eligible for deletion in two weeks time. Regards Ed Shryane RIPE NCC
On 29 Jun 2021, at 11:27, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
The implementation of the cleanup of RIPE NONAUTH route(6) objects using unregistered space is now complete, we plan to deploy to production *today*.
This means that the cleanup job will run for the first time tonight.
* Each night, all RIPE NONAUTH route(6) objects with an unregistered prefix ("available" or "reserved" in delegated stats) are selected. * If a prefix remains unregistered for 1 week, notify the maintainers of any related route(6) objects. * The maintainer can ask to make an exception, not to delete a route(6) object. * Otherwise, after a further 2 weeks, delete the route(6) objects.
See the solution definition for more details: https://www.ripe.net/ripe/mail/archives/db-wg/2021-March/006876.html
Note for now, the AS origin status is *not* considered. Please discuss further whether this should be included.
If you have any feedback, please let us know.
Regards Ed Shryane RIPE NCC
participants (9)
-
Cynthia Revström -
denis walker -
Edward Shryane -
George Michaelson -
Hank Nussbacher -
Job Snijders -
Niall O'Reilly -
Nick Hilliard -
Ronald F. Guilmette