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/>
ad...@pinglabs.co.uk <mailto:ad...@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
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
