Dear colleagues,
One of the fastest ways to achieve a higher level of internet and ICT security may be through buying secure by design, but do governments and companies do so? This is what IS3C tries to establish. This is the background:
The Internet Governance Forum Dynamic Coalition on Internet Standards, Security and Safety will publish its report at the upcoming IGF in Kyoto. It's draft report aims to document existing policy requirements for public sector procurement contracts and supply chain management of digital technologies and asks whether security-related technical internet standards and ICT best practices are mentioned. It highlights emerging best practice and gaps in an effort to provide high-level guidance at the global level on how procurement plays a role in improving the security and safety of the global internet for all. We close with discussion and suggestions for future work. The document’s current status is open to feedback. We invite you to join this open consultation and share your views and to share links to policy documents, public or private on this topic not mentioned in the report. The deadline is Friday 25 August, 24.00 UTC.
You can access the draft report for comments here:
https://intgovforum.org/en/content/dynamic-coalition-on-internet-standards-…
Kind regards,
Wout de Natris
IS3C coordinator
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
De Natris Consult
Kamerlingh Onnesstraat 43 Tel: +31 648388813
2014 EK Haarlem Skype: wout.de.natris
denatrisconsult(a)hotmail.nl<mailto:denatrisconsult@hotmail.nl>
http://www.denatrisconsult.nl
Blog http://woutdenatris.wordpress.com
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
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
[image: Logo] <https://www.pingproxies.com/>
admin(a)pinglabs.co.uk - www.pinglabs.co.uk
International House, 12 Constance Street, London, United Kingdom, E16 2DQ
[image: LinkedIn icon]
<https://www.linkedin.com/in/timur-gok-6a7074159/> [image:
Twitter icon] <https://twitter.com/pingproxies>
