[anti-abuse-wg] Non-Efficacious Use of UCEPROTECT RBL data in RIPEstat

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 at pinglabs.co.uk <mailto:admin at 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