Dear Timur, I understand your frustration with the issue of blocklisting and hope it can be resolved quickly. I'm pleased to inform you that we have implemented a replacement blocklist feature for our service in 2022. An update was sent to the mailing list in May of last year, and you can find it here: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2022-May/006351.html The current feature comprises a selection of 10 blocklists, none of which include UCE. Upon reading your message, I investigated and discovered that there was a reference to the old and deprecated data call in the API documentation. However, that has been corrected now. If you have any more questions or ideas about this feature, please don't hesitate to reach out. Wishing you the best, Christian Teuschel RIPE NCC On 03/08/2023 17:06, Ping Technology Labs LTD wrote:
Hello,
I am revisiting an issue last mentioned in a 2021 archive (I think): https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2021-March/006190.html <https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2021-March/006190.html>
The issue relates to the use of the UCEProtect RBL in RIPEstats blocklist. The previous discussion had several members voice objections to use of UCEProtect in RIPEstat on grounds of data accuracy and bad conduct/practice by UCE.
The issue ended with RIPE mentioning they will look to expand the list of RBLs they sample from and in doing so, we will likely improve overall accuracy of RIPEstate blocklist by minimising the importance of any single list which in itself may be inaccurate. This work was planned to start Q3 2021, however, to the best of my knowledge, it doesn't look like there has been any material change to the RIPEstat blocklist or API.
I am revisiting the issue as I would like to further voice my objection to using UCE with such high priority in RIPEstat due to the blocklist, particularly Level 3, not being efficacious in marking abusive resources.
UCE has three types of blacklists:
1. Level 1 - Specific IP addresses 2. Level 2 - Subnets 3. Level 3 - ASNs
Each resource type, i.e IP, Subnet, ASN accrues abusive points, or "impacts" as UCE labels them, which cascade up each level if the ASN does not resolve them.
The UCE Level 3 is levied against entire ASNs as a result of an ASN accuring impact points from IP addresses and subnets they operate. This sounds okay, however, the methodology UCE uses is deeply floored and allows single IP address resources to accrue multiple points which can therefore tarnish an entire subnet, or ASN if not dealt with, leading to every other end user on that ASN potentially being flagged for abuse.
This has come to my attention as we have connectivity with a carrier whose ASN is flagged with UCE L3 and as an end user of their network we have experienced negative side effects. Our carrier acts as a good example here so we will mention them specifically - AS42689 Glide Student & Residential Limited.
Glide serves over 350,000 customers in the UK and is one the country's largest carriers yet they are marked as an abusive L3 "Draconic" ASN by UCE and therefore shows on RIPEstats blocked list along with every single resource on the ASN.
I did some research into whether this is justified or not and was incredibly shocked to see that the entire ASN which serves 350,000+ customers has been given UCE L3 because of a *single abusive IP Address* (5.151.61.252) in the network which has had a high velocity of abusive.
Ofcourse, the carrier should have taken action on this single IP address and end user, however, in no case is it suitable to mark all other IP addresses (and end users) on their network as abusive just because of a single bad actor.
This Level 3 blacklist is not an efficacious indicator of abusive resources and instead is a better indicator of a somewhat lazy/or spotty approach to handling abuse from an operator perspective and is likely only present on UCE so they can charge a 449 CHF express delisting fee to ASNs that end up on this list.
From my understanding, the RIPEstat blocklist is meant to help indicate potentially abusive and harmful resources and whether RIPE likes it or not, their use of specific RBLs legitimizes them and adds a layer of perceived confidence in the data. Using the UCE L3 datasource for the RIPEstat tools isn't suitable and leads to more harm than good by implicating an entire network of end users to the abusive actions of a single non-related user of that network.
I'd like RIPE to revisit their use of UCE, particularly Level 3, and remove it from their tools. I imagine my thoughts are echoed by other members but if anybody else has any opposing thoughts I would be happy to hear them :)
Cheers,
Timur Gok Managing Director Logo <https://www.pingproxies.com/> admin@pinglabs.co.uk <mailto:admin@pinglabs.co.uk> - www.pinglabs.co.uk <http://www.pinglabs.co.uk/> International House, 12 Constance Street, London, United Kingdom, E16 2DQ LinkedIn icon <https://www.linkedin.com/in/timur-gok-6a7074159/> Twitter icon <https://twitter.com/pingproxies>
-- Christian Teuschel @christian_toysh RIPE NCC