Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
Hello, I hope this is the right list to discuss. I'm seeing more and more providers auto-responding to abuse reports mailed to their "abuse-mailbox" address, stating that this mailbox will not be monitored and urging you to use some form on their website. And often enough, those forms are either only usable for very specific types of abuse or they are just tedious to use and sometimes I suddenly don't want to report spam or phishing anymore to that specific provider when I see a form with 20+ input fields. Besides that, it renders automatic reports useless, even those that are meant to be automatically processable (i.e., containing information as XARF). (Surely, automated reports are a very special topic, but as a provider we are grateful to receive prompt reports of abuse on our network.) This raises the questions: Is there – at least for the RIPE region – any sort of requirement to accept/process abuse reports by mail? While I'm sometimes a bit "pissed" about how bad reporting forms can be, I understand why providers might not want to maintain abuse mailboxes anymore (the amount of spam sent towards these addresses is hilariously large) and instead rely on forms with captchas to tackle this problem. So I'm wondering: Would there be a benefit for building some standardized HTTP API with an authentication system, that would allow providers to automatically send authenticated abuse reports to other providers? That could work in a similar way like DKIM does: The sending provider needs to publish a private key somewhere in the RIPE database, signs the report, and the receiving provider would be able to immediately verify that signature. And if you get a ton of false reports or even spam from a specific provider you can still filter these out based on the sender information in the signature. I would like to hear your opinion on this, or maybe there already *are* solutions I just don't know about yet (besides from manually reporting 20-30 phishing mails a day over 30 different forms). Thanks and greetings Max
Have you looked at Abusix? They have tools to manage abuse mailbox, parse various log types, and include a mechanism for building playbooks to automate handling. --h On Wed, Jul 29, 2026 at 11:14 AM Max Grobecker < max.grobecker@ml.grobecker.info> wrote:
Hello,
I hope this is the right list to discuss.
I'm seeing more and more providers auto-responding to abuse reports mailed to their "abuse-mailbox" address, stating that this mailbox will not be monitored and urging you to use some form on their website. And often enough, those forms are either only usable for very specific types of abuse or they are just tedious to use and sometimes I suddenly don't want to report spam or phishing anymore to that specific provider when I see a form with 20+ input fields. Besides that, it renders automatic reports useless, even those that are meant to be automatically processable (i.e., containing information as XARF). (Surely, automated reports are a very special topic, but as a provider we are grateful to receive prompt reports of abuse on our network.)
This raises the questions: Is there – at least for the RIPE region – any sort of requirement to accept/process abuse reports by mail?
While I'm sometimes a bit "pissed" about how bad reporting forms can be, I understand why providers might not want to maintain abuse mailboxes anymore (the amount of spam sent towards these addresses is hilariously large) and instead rely on forms with captchas to tackle this problem.
So I'm wondering: Would there be a benefit for building some standardized HTTP API with an authentication system, that would allow providers to automatically send authenticated abuse reports to other providers? That could work in a similar way like DKIM does: The sending provider needs to publish a private key somewhere in the RIPE database, signs the report, and the receiving provider would be able to immediately verify that signature. And if you get a ton of false reports or even spam from a specific provider you can still filter these out based on the sender information in the signature.
I would like to hear your opinion on this, or maybe there already *are* solutions I just don't know about yet (besides from manually reporting 20-30 phishing mails a day over 30 different forms).
Thanks and greetings
Max ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
I think Max's point was that others don't process mail reports, , which is true, because why would they. The problem, in my view is not, that they are overwhelmed by spam, because you can filter spam. And still let legitimate abuse complaints get through. But it's work. That's all why I think building another mechanism is not going to solve the issue. It's work to set it up, and even more work to process the complaints. And doing so helps others, respectively offloads the cost of abuse to others. Folks that already now don't bother won't bother in the future, unles not bothering is more expensive than bothering. But in the past we couldn't agree on making it more expensive to permit abuse than to tolerate it. So, I'm afraid we won't change a thing, but please prove me wrong. Serge On 29 July 2026 17:57:19 CEST, Heather Schiller <heather.skanks@gmail.com> wrote:
Have you looked at Abusix? They have tools to manage abuse mailbox, parse various log types, and include a mechanism for building playbooks to automate handling.
--h
On Wed, Jul 29, 2026 at 11:14 AM Max Grobecker < max.grobecker@ml.grobecker.info> wrote:
Hello,
I hope this is the right list to discuss.
I'm seeing more and more providers auto-responding to abuse reports mailed to their "abuse-mailbox" address, stating that this mailbox will not be monitored and urging you to use some form on their website. And often enough, those forms are either only usable for very specific types of abuse or they are just tedious to use and sometimes I suddenly don't want to report spam or phishing anymore to that specific provider when I see a form with 20+ input fields. Besides that, it renders automatic reports useless, even those that are meant to be automatically processable (i.e., containing information as XARF). (Surely, automated reports are a very special topic, but as a provider we are grateful to receive prompt reports of abuse on our network.)
This raises the questions: Is there – at least for the RIPE region – any sort of requirement to accept/process abuse reports by mail?
While I'm sometimes a bit "pissed" about how bad reporting forms can be, I understand why providers might not want to maintain abuse mailboxes anymore (the amount of spam sent towards these addresses is hilariously large) and instead rely on forms with captchas to tackle this problem.
So I'm wondering: Would there be a benefit for building some standardized HTTP API with an authentication system, that would allow providers to automatically send authenticated abuse reports to other providers? That could work in a similar way like DKIM does: The sending provider needs to publish a private key somewhere in the RIPE database, signs the report, and the receiving provider would be able to immediately verify that signature. And if you get a ton of false reports or even spam from a specific provider you can still filter these out based on the sender information in the signature.
I would like to hear your opinion on this, or maybe there already *are* solutions I just don't know about yet (besides from manually reporting 20-30 phishing mails a day over 30 different forms).
Thanks and greetings
Max ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
From a SOC/abuse perspective, I think we're solving the wrong problem. Attackers move in minutes. Most abuse handling still happens in hours or days. By the time a report is reviewed, the infrastructure has often already been rotated or abandoned. The issue isn't how reports are submitted-email, web forms, or a new API. The issue is whether there's an operational capability and willingness to act on them. A new protocol won't change that. If an organization doesn't process abuse reports today, I don't see why another transport mechanism would suddenly make them do so. It just gives them another inbox, queue, or API endpoint to ignore. The real challenge isn't improving report delivery-it's reducing response time and creating incentives to process abuse. Until then, we're optimizing the wrong part of the workflow. -Michael Från: Serge Droz via Security-wg <security-wg@ripe.net> Skickat: den 29 juli 2026 20:47 Till: security-wg@ripe.net Ämne: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms I think Max's point was that others don't process mail reports, , which is true, because why would they. The problem, in my view is not, that they are overwhelmed by spam, because you can filter spam. And still let legitimate abuse complaints get through. But it's work. That's all why I think building another mechanism is not going to solve the issue. It's work to set it up, and even more work to process the complaints. And doing so helps others, respectively offloads the cost of abuse to others. Folks that already now don't bother won't bother in the future, unles not bothering is more expensive than bothering. But in the past we couldn't agree on making it more expensive to permit abuse than to tolerate it. So, I'm afraid we won't change a thing, but please prove me wrong. Serge On 29 July 2026 17:57:19 CEST, Heather Schiller <heather.skanks@gmail.com<mailto:heather.skanks@gmail.com>> wrote: Have you looked at Abusix? They have tools to manage abuse mailbox, parse various log types, and include a mechanism for building playbooks to automate handling. --h On Wed, Jul 29, 2026 at 11:14 AM Max Grobecker <max.grobecker@ml.grobecker.info<mailto:max.grobecker@ml.grobecker.info>> wrote: Hello, I hope this is the right list to discuss. I'm seeing more and more providers auto-responding to abuse reports mailed to their "abuse-mailbox" address, stating that this mailbox will not be monitored and urging you to use some form on their website. And often enough, those forms are either only usable for very specific types of abuse or they are just tedious to use and sometimes I suddenly don't want to report spam or phishing anymore to that specific provider when I see a form with 20+ input fields. Besides that, it renders automatic reports useless, even those that are meant to be automatically processable (i.e., containing information as XARF). (Surely, automated reports are a very special topic, but as a provider we are grateful to receive prompt reports of abuse on our network.) This raises the questions: Is there – at least for the RIPE region – any sort of requirement to accept/process abuse reports by mail? While I'm sometimes a bit "pissed" about how bad reporting forms can be, I understand why providers might not want to maintain abuse mailboxes anymore (the amount of spam sent towards these addresses is hilariously large) and instead rely on forms with captchas to tackle this problem. So I'm wondering: Would there be a benefit for building some standardized HTTP API with an authentication system, that would allow providers to automatically send authenticated abuse reports to other providers? That could work in a similar way like DKIM does: The sending provider needs to publish a private key somewhere in the RIPE database, signs the report, and the receiving provider would be able to immediately verify that signature. And if you get a ton of false reports or even spam from a specific provider you can still filter these out based on the sender information in the signature. I would like to hear your opinion on this, or maybe there already *are* solutions I just don't know about yet (besides from manually reporting 20-30 phishing mails a day over 30 different forms). Thanks and greetings Max ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_security-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=GRIT-1oEfRlToTwuiJcUruGgk8mS696gMbfGmHvNvz4&m=sc4WpLGYnK33izpG8_UbTwFqfPPnVj6dBmll0KCMMMx4MrvjkRnTQSGC4jNweanw&s=wnOKjSw2Hka3J9pq0JKlrWAbTMAL6yhLSSGi9pLfhYs&e=> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=GRIT-1oEfRlToTwuiJcUruGgk8mS696gMbfGmHvNvz4&m=sc4WpLGYnK33izpG8_UbTwFqfPPnVj6dBmll0KCMMMx4MrvjkRnTQSGC4jNweanw&s=IanMQ8pIvD7qqPqeSpVuYxshUrDx2YrdQtSQ-PWpS-Q&e=>
Serge, Michael, and Working Group, The reason LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry closure. To avoid the historical jurisdiction arguments regarding the definition of "abuse" (used every time we try to address this issue), we can simply utilize the harmonized definitions established under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering DDoS, phishing, and malware distribution). Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious routing behaviors. I propose a simplified, two-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP): - Article 1: For the purposes of RIPE Address Policy, "Network Abuse" is defined by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks and systemic spam botnet distribution). - Article 2: RIPE address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1. By anchoring to an external regulatory baseline, we save the working group from endless definitional debates. If a member receives authenticated, systemic notifications of these technical harms and explicitly refuses to remediate them, they are in violation of RIPE Policy—with the ultimate sanction of triggering standard contractual registry closure procedures. Let's stop trying to fix the transport mechanism of the report and finally address the accountability of the resource holder. cheers denis ------------------------------ On Wed, 29 Jul 2026 at 21:02, Michael Duffy via Security-wg < security-wg@ripe.net> wrote:
From a SOC/abuse perspective, I think we're solving the wrong problem. Attackers move in minutes. Most abuse handling still happens in hours or days. By the time a report is reviewed, the infrastructure has often already been rotated or abandoned. The issue isn't how reports are submitted-email, web forms, or a new API. The issue is whether there's an operational capability and willingness to act on them. A new protocol won't change that. If an organization doesn't process abuse reports today, I don't see why another transport mechanism would suddenly make them do so. It just gives them another inbox, queue, or API endpoint to ignore. The real challenge isn't improving report delivery-it's reducing response time and creating incentives to process abuse. Until then, we're optimizing the wrong part of the workflow.
-Michael
*Från:* Serge Droz via Security-wg <security-wg@ripe.net> *Skickat:* den 29 juli 2026 20:47 *Till:* security-wg@ripe.net *Ämne:* [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
I think Max's point was that others don't process mail reports, , which is true, because why would they.
The problem, in my view is not, that they are overwhelmed by spam, because you can filter spam. And still let legitimate abuse complaints get through. But it's work. That's all why I think building another mechanism is not going to solve the issue. It's work to set it up, and even more work to process the complaints. And doing so helps others, respectively offloads the cost of abuse to others.
Folks that already now don't bother won't bother in the future, unles not bothering is more expensive than bothering.
But in the past we couldn't agree on making it more expensive to permit abuse than to tolerate it.
So, I'm afraid we won't change a thing, but please prove me wrong.
Serge
On 29 July 2026 17:57:19 CEST, Heather Schiller <heather.skanks@gmail.com> wrote:
Have you looked at Abusix? They have tools to manage abuse mailbox, parse various log types, and include a mechanism for building playbooks to automate handling.
--h
On Wed, Jul 29, 2026 at 11:14 AM Max Grobecker < max.grobecker@ml.grobecker.info> wrote:
Hello,
I hope this is the right list to discuss.
I'm seeing more and more providers auto-responding to abuse reports mailed to their "abuse-mailbox" address, stating that this mailbox will not be monitored and urging you to use some form on their website. And often enough, those forms are either only usable for very specific types of abuse or they are just tedious to use and sometimes I suddenly don't want to report spam or phishing anymore to that specific provider when I see a form with 20+ input fields. Besides that, it renders automatic reports useless, even those that are meant to be automatically processable (i.e., containing information as XARF). (Surely, automated reports are a very special topic, but as a provider we are grateful to receive prompt reports of abuse on our network.)
This raises the questions: Is there – at least for the RIPE region – any sort of requirement to accept/process abuse reports by mail?
While I'm sometimes a bit "pissed" about how bad reporting forms can be, I understand why providers might not want to maintain abuse mailboxes anymore (the amount of spam sent towards these addresses is hilariously large) and instead rely on forms with captchas to tackle this problem.
So I'm wondering: Would there be a benefit for building some standardized HTTP API with an authentication system, that would allow providers to automatically send authenticated abuse reports to other providers? That could work in a similar way like DKIM does: The sending provider needs to publish a private key somewhere in the RIPE database, signs the report, and the receiving provider would be able to immediately verify that signature. And if you get a ton of false reports or even spam from a specific provider you can still filter these out based on the sender information in the signature.
I would like to hear your opinion on this, or maybe there already *are* solutions I just don't know about yet (besides from manually reporting 20-30 phishing mails a day over 30 different forms).
Thanks and greetings
Max ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_security-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=GRIT-1oEfRlToTwuiJcUruGgk8mS696gMbfGmHvNvz4&m=sc4WpLGYnK33izpG8_UbTwFqfPPnVj6dBmll0KCMMMx4MrvjkRnTQSGC4jNweanw&s=wnOKjSw2Hka3J9pq0JKlrWAbTMAL6yhLSSGi9pLfhYs&e=> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=GRIT-1oEfRlToTwuiJcUruGgk8mS696gMbfGmHvNvz4&m=sc4WpLGYnK33izpG8_UbTwFqfPPnVj6dBmll0KCMMMx4MrvjkRnTQSGC4jNweanw&s=IanMQ8pIvD7qqPqeSpVuYxshUrDx2YrdQtSQ-PWpS-Q&e=>
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
I fear that any attempt to put in place a sensible policy will be scuttled as earlier attempts have been over the past decade or more. But yes this approach makes sense to me. From: denis walker <ripedenis@gmail.com> Date: Thursday, 30 July 2026 at 5:09 AM To: Michael Duffy <michael.duffy@excedo.se> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Serge, Michael, and Working Group, The reason LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry closure. To avoid the historical jurisdiction arguments regarding the definition of "abuse" (used every time we try to address this issue), we can simply utilize the harmonized definitions established under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering DDoS, phishing, and malware distribution). Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious routing behaviors. I propose a simplified, two-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP): * Article 1: For the purposes of RIPE Address Policy, "Network Abuse" is defined by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks and systemic spam botnet distribution). * Article 2: RIPE address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1. By anchoring to an external regulatory baseline, we save the working group from endless definitional debates. If a member receives authenticated, systemic notifications of these technical harms and explicitly refuses to remediate them, they are in violation of RIPE Policy—with the ultimate sanction of triggering standard contractual registry closure procedures. Let's stop trying to fix the transport mechanism of the report and finally address the accountability of the resource holder. cheers denis ________________________________ On Wed, 29 Jul 2026 at 21:02, Michael Duffy via Security-wg <security-wg@ripe.net<mailto:security-wg@ripe.net>> wrote: From a SOC/abuse perspective, I think we're solving the wrong problem. Attackers move in minutes. Most abuse handling still happens in hours or days. By the time a report is reviewed, the infrastructure has often already been rotated or abandoned. The issue isn't how reports are submitted-email, web forms, or a new API. The issue is whether there's an operational capability and willingness to act on them. A new protocol won't change that. If an organization doesn't process abuse reports today, I don't see why another transport mechanism would suddenly make them do so. It just gives them another inbox, queue, or API endpoint to ignore. The real challenge isn't improving report delivery-it's reducing response time and creating incentives to process abuse. Until then, we're optimizing the wrong part of the workflow. -Michael Från: Serge Droz via Security-wg <security-wg@ripe.net<mailto:security-wg@ripe.net>> Skickat: den 29 juli 2026 20:47 Till: security-wg@ripe.net<mailto:security-wg@ripe.net> Ämne: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms I think Max's point was that others don't process mail reports, , which is true, because why would they. The problem, in my view is not, that they are overwhelmed by spam, because you can filter spam. And still let legitimate abuse complaints get through. But it's work. That's all why I think building another mechanism is not going to solve the issue. It's work to set it up, and even more work to process the complaints. And doing so helps others, respectively offloads the cost of abuse to others. Folks that already now don't bother won't bother in the future, unles not bothering is more expensive than bothering. But in the past we couldn't agree on making it more expensive to permit abuse than to tolerate it. So, I'm afraid we won't change a thing, but please prove me wrong. Serge On 29 July 2026 17:57:19 CEST, Heather Schiller <heather.skanks@gmail.com<mailto:heather.skanks@gmail.com>> wrote: Have you looked at Abusix? They have tools to manage abuse mailbox, parse various log types, and include a mechanism for building playbooks to automate handling. --h On Wed, Jul 29, 2026 at 11:14 AM Max Grobecker <max.grobecker@ml.grobecker.info<mailto:max.grobecker@ml.grobecker.info>> wrote: Hello, I hope this is the right list to discuss. I'm seeing more and more providers auto-responding to abuse reports mailed to their "abuse-mailbox" address, stating that this mailbox will not be monitored and urging you to use some form on their website. And often enough, those forms are either only usable for very specific types of abuse or they are just tedious to use and sometimes I suddenly don't want to report spam or phishing anymore to that specific provider when I see a form with 20+ input fields. Besides that, it renders automatic reports useless, even those that are meant to be automatically processable (i.e., containing information as XARF). (Surely, automated reports are a very special topic, but as a provider we are grateful to receive prompt reports of abuse on our network.) This raises the questions: Is there – at least for the RIPE region – any sort of requirement to accept/process abuse reports by mail? While I'm sometimes a bit "pissed" about how bad reporting forms can be, I understand why providers might not want to maintain abuse mailboxes anymore (the amount of spam sent towards these addresses is hilariously large) and instead rely on forms with captchas to tackle this problem. So I'm wondering: Would there be a benefit for building some standardized HTTP API with an authentication system, that would allow providers to automatically send authenticated abuse reports to other providers? That could work in a similar way like DKIM does: The sending provider needs to publish a private key somewhere in the RIPE database, signs the report, and the receiving provider would be able to immediately verify that signature. And if you get a ton of false reports or even spam from a specific provider you can still filter these out based on the sender information in the signature. I would like to hear your opinion on this, or maybe there already *are* solutions I just don't know about yet (besides from manually reporting 20-30 phishing mails a day over 30 different forms). Thanks and greetings Max ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_security-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=GRIT-1oEfRlToTwuiJcUruGgk8mS696gMbfGmHvNvz4&m=sc4WpLGYnK33izpG8_UbTwFqfPPnVj6dBmll0KCMMMx4MrvjkRnTQSGC4jNweanw&s=wnOKjSw2Hka3J9pq0JKlrWAbTMAL6yhLSSGi9pLfhYs&e=> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=GRIT-1oEfRlToTwuiJcUruGgk8mS696gMbfGmHvNvz4&m=sc4WpLGYnK33izpG8_UbTwFqfPPnVj6dBmll0KCMMMx4MrvjkRnTQSGC4jNweanw&s=IanMQ8pIvD7qqPqeSpVuYxshUrDx2YrdQtSQ-PWpS-Q&e=> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
I agree with all of you, we need to penalise orgs that don't act, small ones, but also the hyper scalars, which admittedly have a scale problem. But externalising these costs is not ok. I'd fully support Denis' proposal, but aas Suresh says, we're really good here at not doing anything. Best Serge On 30/07/2026 02:59, Suresh Ramasubramanian wrote:
I fear that any attempt to put in place a sensible policy will be scuttled as earlier attempts have been over the past decade or more. But yes this approach makes sense to me.
*From: *denis walker <ripedenis@gmail.com> *Date: *Thursday, 30 July 2026 at 5:09 AM *To: *Michael Duffy <michael.duffy@excedo.se> *Cc: *security-wg@ripe.net <security-wg@ripe.net> *Subject: *[Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
Serge, Michael, and Working Group, The reason LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry closure. To avoid the historical jurisdiction arguments regarding the definition of "abuse" (used every time we try to address this issue), we can simply utilize the harmonized definitions established under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering DDoS, phishing, and malware distribution). Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious routing behaviors. I propose a simplified, two-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP):
* Article 1: For the purposes of RIPE Address Policy, "Network Abuse" is defined by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks and systemic spam botnet distribution). * Article 2: RIPE address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1.
By anchoring to an external regulatory baseline, we save the working group from endless definitional debates. If a member receives authenticated, systemic notifications of these technical harms and explicitly refuses to remediate them, they are in violation of RIPE Policy—with the ultimate sanction of triggering standard contractual registry closure procedures. Let's stop trying to fix the transport mechanism of the report and finally address the accountability of the resource holder.
cheers denis ------------------------------------------------------------------------
On Wed, 29 Jul 2026 at 21:02, Michael Duffy via Security-wg <security-wg@ripe.net> wrote:
From a SOC/abuse perspective, I think we're solving the wrong problem. Attackers move in minutes. Most abuse handling still happens in hours or days. By the time a report is reviewed, the infrastructure has often already been rotated or abandoned. The issue isn't how reports are submitted-email, web forms, or a new API. The issue is whether there's an operational capability and willingness to act on them. A new protocol won't change that. If an organization doesn't process abuse reports today, I don't see why another transport mechanism would suddenly make them do so. It just gives them another inbox, queue, or API endpoint to ignore. The real challenge isn't improving report delivery-it's reducing response time and creating incentives to process abuse. Until then, we're optimizing the wrong part of the workflow.
-Michael
*Från:* Serge Droz via Security-wg <security-wg@ripe.net> *Skickat:* den 29 juli 2026 20:47 *Till:* security-wg@ripe.net *Ämne:* [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
I think Max's point was that others don't process mail reports, , which is true, because why would they.
The problem, in my view is not, that they are overwhelmed by spam, because you can filter spam. And still let legitimate abuse complaints get through. But it's work. That's all why I think building another mechanism is not going to solve the issue. It's work to set it up, and even more work to process the complaints. And doing so helps others, respectively offloads the cost of abuse to others.
Folks that already now don't bother won't bother in the future, unles not bothering is more expensive than bothering.
But in the past we couldn't agree on making it more expensive to permit abuse than to tolerate it.
So, I'm afraid we won't change a thing, but please prove me wrong.
Serge
On 29 July 2026 17:57:19 CEST, Heather Schiller <heather.skanks@gmail.com> wrote:
Have you looked at Abusix? They have tools to manage abuse mailbox, parse various log types, and include a mechanism for building playbooks to automate handling.
--h
On Wed, Jul 29, 2026 at 11:14 AM Max Grobecker <max.grobecker@ml.grobecker.info> wrote:
Hello,
I hope this is the right list to discuss.
I'm seeing more and more providers auto-responding to abuse reports mailed to their "abuse-mailbox" address, stating that this mailbox will not be monitored and urging you to use some form on their website. And often enough, those forms are either only usable for very specific types of abuse or they are just tedious to use and sometimes I suddenly don't want to report spam or phishing anymore to that specific provider when I see a form with 20+ input fields. Besides that, it renders automatic reports useless, even those that are meant to be automatically processable (i.e., containing information as XARF). (Surely, automated reports are a very special topic, but as a provider we are grateful to receive prompt reports of abuse on our network.)
This raises the questions: Is there – at least for the RIPE region – any sort of requirement to accept/process abuse reports by mail?
While I'm sometimes a bit "pissed" about how bad reporting forms can be, I understand why providers might not want to maintain abuse mailboxes anymore (the amount of spam sent towards these addresses is hilariously large) and instead rely on forms with captchas to tackle this problem.
So I'm wondering: Would there be a benefit for building some standardized HTTP API with an authentication system, that would allow providers to automatically send authenticated abuse reports to other providers? That could work in a similar way like DKIM does: The sending provider needs to publish a private key somewhere in the RIPE database, signs the report, and the receiving provider would be able to immediately verify that signature. And if you get a ton of false reports or even spam from a specific provider you can still filter these out based on the sender information in the signature.
I would like to hear your opinion on this, or maybe there already *are* solutions I just don't know about yet (besides from manually reporting 20-30 phishing mails a day over 30 different forms).
Thanks and greetings
Max ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailman3_lists_security-2Dwg.ripe.net_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=GRIT-1oEfRlToTwuiJcUruGgk8mS696gMbfGmHvNvz4&m=sc4WpLGYnK33izpG8_UbTwFqfPPnVj6dBmll0KCMMMx4MrvjkRnTQSGC4jNweanw&s=wnOKjSw2Hka3J9pq0JKlrWAbTMAL6yhLSSGi9pLfhYs&e=> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership_mail_mailman-2D3-2Dmigration_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=GRIT-1oEfRlToTwuiJcUruGgk8mS696gMbfGmHvNvz4&m=sc4WpLGYnK33izpG8_UbTwFqfPPnVj6dBmll0KCMMMx4MrvjkRnTQSGC4jNweanw&s=IanMQ8pIvD7qqPqeSpVuYxshUrDx2YrdQtSQ-PWpS-Q&e=>
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit:https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at:https://www.ripe.net/membership/mail/mailman-3-migration/
On 30 Jul 2026, at 09:15, Serge Droz via Security-wg <security-wg@ripe.net> wrote:
I agree with all of you, we need to penalise orgs that don't act, small ones, but also the hyper scalars, which admittedly have a scale problem. But externalising these costs is not ok.
Especially the Hyper scalers, as they also make hyper money and have the expertise and money to fix those issues. They just do not have a reason to as nobody's KPI are hit with that and losing customers = losing money, even if those customers are not the best for the Internet. With setups like "APIs for LLMs to automatically setup domains/etc" that even becomes worse as their 'customers' can just rotate through new accounts. "we shut them down when we see, after we took the money from the stolen credit card"... too big to fail... As I just wrote to NANOG (before I noticed this thread, while I mentioned also about unmonitored abuse): https://lists.nanog.org/archives/list/nanog@lists.nanog.org/thread/XOZXIJCX6... We have for years (decades actually) had CIDR Reports send to NOG lists, but no action are being taken about known unallocated and reserved prefixes and ASNs and those that pass it on. And that is a very low hanging fruit. One can grab those delegated files and verify them against your own BGP tables and alert and reach out (not even asking to directly drop, though would not be bad :) ) -- misconfigs/accidents happen, we should try to minimize that. Even likely "national interest" ones like DoD prefixes/ASNs are in there, but also from so called big tech CDNs that are supposedly fighting the bad stuff on the Internet with DDoS protection (and apparently also host the booter/stresser services that cause that). At one point governments likely will want to regulate that like the banking industry (not that that helps in the current political climate). KYC (Know Your Customer) is a concept there, but for the Internet that is apparently completely lost as long is money to be made.... and we have the stats, and the logs and all the information, just cannot cannot find the contact for the other party to resolve it, and if one has a contact it often is a black hole with no action.
I'd fully support Denis' proposal, but aas Suresh says, we're really good here at not doing anything.
Same. I wish the world was a bit better with it all, but it is unlikely to change as long as money keeps flowing into pockets of the folks doing so. Regards, Jeroen
I don't agree that KYC is a solution applicable here - nothing prevents criminals from committing another crime called identity fraud.
Do note that criminals may NOT pay with a stolen card at all, if they are convinced that they have a long and comfortable stay at a particular provider who will be lax with abuse reports, but will understandably act quite fast against them if they pay with stolen cards. From: Jeroen Massar via Security-wg <security-wg@ripe.net> Date: Thursday, 30 July 2026 at 2:15 PM To: Serge Droz <serge.droz@first.org> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On 30 Jul 2026, at 09:15, Serge Droz via Security-wg <security-wg@ripe.net> wrote:
I agree with all of you, we need to penalise orgs that don't act, small ones, but also the hyper scalars, which admittedly have a scale problem. But externalising these costs is not ok.
Especially the Hyper scalers, as they also make hyper money and have the expertise and money to fix those issues. They just do not have a reason to as nobody's KPI are hit with that and losing customers = losing money, even if those customers are not the best for the Internet. With setups like "APIs for LLMs to automatically setup domains/etc" that even becomes worse as their 'customers' can just rotate through new accounts. "we shut them down when we see, after we took the money from the stolen credit card"... too big to fail... As I just wrote to NANOG (before I noticed this thread, while I mentioned also about unmonitored abuse): https://lists.nanog.org/archives/list/nanog@lists.nanog.org/thread/XOZXIJCX6... We have for years (decades actually) had CIDR Reports send to NOG lists, but no action are being taken about known unallocated and reserved prefixes and ASNs and those that pass it on. And that is a very low hanging fruit. One can grab those delegated files and verify them against your own BGP tables and alert and reach out (not even asking to directly drop, though would not be bad :) ) -- misconfigs/accidents happen, we should try to minimize that. Even likely "national interest" ones like DoD prefixes/ASNs are in there, but also from so called big tech CDNs that are supposedly fighting the bad stuff on the Internet with DDoS protection (and apparently also host the booter/stresser services that cause that). At one point governments likely will want to regulate that like the banking industry (not that that helps in the current political climate). KYC (Know Your Customer) is a concept there, but for the Internet that is apparently completely lost as long is money to be made.... and we have the stats, and the logs and all the information, just cannot cannot find the contact for the other party to resolve it, and if one has a contact it often is a black hole with no action.
I'd fully support Denis' proposal, but aas Suresh says, we're really good here at not doing anything.
Same. I wish the world was a bit better with it all, but it is unlikely to change as long as money keeps flowing into pockets of the folks doing so. Regards, Jeroen ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
We have been in this discussion several times. The fact that a stronger abuse-c policy reached consensus and has been implemented in APNIC and LACNIC (also in AFRINIC, but due to the situation there not yet implemented), disallowing forms and enforcing a proper abuse email validation, and that since they were implemented, spam and other abuses have been going down constantly in those regions, shall mean something. As I clearly suggested in my last versions of the proposal in RIPE (https://www.ripe.net/community/policies/proposals/2019-04/), it will be fine enforcing something like XARF for the reporting as it is also well supported in open source tools for automatic reporting. Allowing forms, that are different in each possible operator in the world is ridiculous, as it enforces each other operator to develop their own tools for each reporting. It is a clear way to be blind and allow criminals to stay in networks forever, so in other ways, allows cooperating with criminals without any responsibility. I guess we prefer regulators, sooner or later to impose their own rules, instead of the community to openly discuss what is best for the community itself. Regards, Jordi @jordipalet
El 30 jul 2026, a las 12:53, Suresh Ramasubramanian <ops.lists@gmail.com> escribió:
Do note that criminals may NOT pay with a stolen card at all, if they are convinced that they have a long and comfortable stay at a particular provider who will be lax with abuse reports, but will understandably act quite fast against them if they pay with stolen cards.
From: Jeroen Massar via Security-wg <security-wg@ripe.net> Date: Thursday, 30 July 2026 at 2:15 PM To: Serge Droz <serge.droz@first.org> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On 30 Jul 2026, at 09:15, Serge Droz via Security-wg <security-wg@ripe.net> wrote:
I agree with all of you, we need to penalise orgs that don't act, small ones, but also the hyper scalars, which admittedly have a scale problem. But externalising these costs is not ok.
Especially the Hyper scalers, as they also make hyper money and have the expertise and money to fix those issues. They just do not have a reason to as nobody's KPI are hit with that and losing customers = losing money, even if those customers are not the best for the Internet.
With setups like "APIs for LLMs to automatically setup domains/etc" that even becomes worse as their 'customers' can just rotate through new accounts. "we shut them down when we see, after we took the money from the stolen credit card"... too big to fail...
As I just wrote to NANOG (before I noticed this thread, while I mentioned also about unmonitored abuse): https://lists.nanog.org/archives/list/nanog@lists.nanog.org/thread/XOZXIJCX6...
We have for years (decades actually) had CIDR Reports send to NOG lists, but no action are being taken about known unallocated and reserved prefixes and ASNs and those that pass it on. And that is a very low hanging fruit.
One can grab those delegated files and verify them against your own BGP tables and alert and reach out (not even asking to directly drop, though would not be bad :) ) -- misconfigs/accidents happen, we should try to minimize that.
Even likely "national interest" ones like DoD prefixes/ASNs are in there, but also from so called big tech CDNs that are supposedly fighting the bad stuff on the Internet with DDoS protection (and apparently also host the booter/stresser services that cause that).
At one point governments likely will want to regulate that like the banking industry (not that that helps in the current political climate).
KYC (Know Your Customer) is a concept there, but for the Internet that is apparently completely lost as long is money to be made.... and we have the stats, and the logs and all the information, just cannot cannot find the contact for the other party to resolve it, and if one has a contact it often is a black hole with no action.
I'd fully support Denis' proposal, but aas Suresh says, we're really good here at not doing anything.
Same.
I wish the world was a bit better with it all, but it is unlikely to change as long as money keeps flowing into pockets of the folks doing so.
Regards, Jeroen
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Not all alleged abuse can or should be treated the same way and if you want companies to deal with it properly you need to facilitate them handling it using the appropriate tools. Email is often not the best tool for handling reports. -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072<tel:+353599183072> Direct Dial: +353 (0)59 9183090<tel:+353599183090> Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: jordi.palet--- via Security-wg <security-wg@ripe.net> Date: Thursday, 30 July 2026 at 12:06 To: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. We have been in this discussion several times. The fact that a stronger abuse-c policy reached consensus and has been implemented in APNIC and LACNIC (also in AFRINIC, but due to the situation there not yet implemented), disallowing forms and enforcing a proper abuse email validation, and that since they were implemented, spam and other abuses have been going down constantly in those regions, shall mean something. As I clearly suggested in my last versions of the proposal in RIPE (https://www.ripe.net/community/policies/proposals/2019-04/), it will be fine enforcing something like XARF for the reporting as it is also well supported in open source tools for automatic reporting. Allowing forms, that are different in each possible operator in the world is ridiculous, as it enforces each other operator to develop their own tools for each reporting. It is a clear way to be blind and allow criminals to stay in networks forever, so in other ways, allows cooperating with criminals without any responsibility. I guess we prefer regulators, sooner or later to impose their own rules, instead of the community to openly discuss what is best for the community itself. Regards, Jordi @jordipalet El 30 jul 2026, a las 12:53, Suresh Ramasubramanian <ops.lists@gmail.com> escribió: Do note that criminals may NOT pay with a stolen card at all, if they are convinced that they have a long and comfortable stay at a particular provider who will be lax with abuse reports, but will understandably act quite fast against them if they pay with stolen cards. From: Jeroen Massar via Security-wg <security-wg@ripe.net> Date: Thursday, 30 July 2026 at 2:15 PM To: Serge Droz <serge.droz@first.org> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On 30 Jul 2026, at 09:15, Serge Droz via Security-wg <security-wg@ripe.net> wrote:
I agree with all of you, we need to penalise orgs that don't act, small ones, but also the hyper scalars, which admittedly have a scale problem. But externalising these costs is not ok.
Especially the Hyper scalers, as they also make hyper money and have the expertise and money to fix those issues. They just do not have a reason to as nobody's KPI are hit with that and losing customers = losing money, even if those customers are not the best for the Internet. With setups like "APIs for LLMs to automatically setup domains/etc" that even becomes worse as their 'customers' can just rotate through new accounts. "we shut them down when we see, after we took the money from the stolen credit card"... too big to fail... As I just wrote to NANOG (before I noticed this thread, while I mentioned also about unmonitored abuse): https://lists.nanog.org/archives/list/nanog@lists.nanog.org/thread/XOZXIJCX6... We have for years (decades actually) had CIDR Reports send to NOG lists, but no action are being taken about known unallocated and reserved prefixes and ASNs and those that pass it on. And that is a very low hanging fruit. One can grab those delegated files and verify them against your own BGP tables and alert and reach out (not even asking to directly drop, though would not be bad :) ) -- misconfigs/accidents happen, we should try to minimize that. Even likely "national interest" ones like DoD prefixes/ASNs are in there, but also from so called big tech CDNs that are supposedly fighting the bad stuff on the Internet with DDoS protection (and apparently also host the booter/stresser services that cause that). At one point governments likely will want to regulate that like the banking industry (not that that helps in the current political climate). KYC (Know Your Customer) is a concept there, but for the Internet that is apparently completely lost as long is money to be made.... and we have the stats, and the logs and all the information, just cannot cannot find the contact for the other party to resolve it, and if one has a contact it often is a black hole with no action.
I'd fully support Denis' proposal, but aas Suresh says, we're really good here at not doing anything.
Same. I wish the world was a bit better with it all, but it is unlikely to change as long as money keeps flowing into pockets of the folks doing so. Regards, Jeroen ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
My point has never been “we must use email only”, but “let’s make sure that we all use the same protocol” and nobody needs to develop something for each possible operator where abuse is taking place. I think XARF can do it, other ways are feasible, but the point is to ensure that if you get a report and ignore it, you’re accountable for it.
El 30 jul 2026, a las 13:09, Michele Neylon - Blacknight <michele@blacknight.com> escribió:
Not all alleged abuse can or should be treated the same way and if you want companies to deal with it properly you need to facilitate them handling it using the appropriate tools. Email is often not the best tool for handling reports.
-- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 <tel:+353599183072> Direct Dial: +353 (0)59 9183090 <tel:+353599183090> Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: jordi.palet--- via Security-wg <security-wg@ripe.net> Date: Thursday, 30 July 2026 at 12:06 To: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.
We have been in this discussion several times.
The fact that a stronger abuse-c policy reached consensus and has been implemented in APNIC and LACNIC (also in AFRINIC, but due to the situation there not yet implemented), disallowing forms and enforcing a proper abuse email validation, and that since they were implemented, spam and other abuses have been going down constantly in those regions, shall mean something.
As I clearly suggested in my last versions of the proposal in RIPE (https://www.ripe.net/community/policies/proposals/2019-04/), it will be fine enforcing something like XARF for the reporting as it is also well supported in open source tools for automatic reporting. Allowing forms, that are different in each possible operator in the world is ridiculous, as it enforces each other operator to develop their own tools for each reporting. It is a clear way to be blind and allow criminals to stay in networks forever, so in other ways, allows cooperating with criminals without any responsibility. I guess we prefer regulators, sooner or later to impose their own rules, instead of the community to openly discuss what is best for the community itself.
Regards, Jordi
@jordipalet
El 30 jul 2026, a las 12:53, Suresh Ramasubramanian <ops.lists@gmail.com> escribió:
Do note that criminals may NOT pay with a stolen card at all, if they are convinced that they have a long and comfortable stay at a particular provider who will be lax with abuse reports, but will understandably act quite fast against them if they pay with stolen cards.
From: Jeroen Massar via Security-wg <security-wg@ripe.net> Date: Thursday, 30 July 2026 at 2:15 PM To: Serge Droz <serge.droz@first.org> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On 30 Jul 2026, at 09:15, Serge Droz via Security-wg <security-wg@ripe.net> wrote:
I agree with all of you, we need to penalise orgs that don't act, small ones, but also the hyper scalars, which admittedly have a scale problem. But externalising these costs is not ok.
Especially the Hyper scalers, as they also make hyper money and have the expertise and money to fix those issues. They just do not have a reason to as nobody's KPI are hit with that and losing customers = losing money, even if those customers are not the best for the Internet.
With setups like "APIs for LLMs to automatically setup domains/etc" that even becomes worse as their 'customers' can just rotate through new accounts. "we shut them down when we see, after we took the money from the stolen credit card"... too big to fail...
As I just wrote to NANOG (before I noticed this thread, while I mentioned also about unmonitored abuse): https://lists.nanog.org/archives/list/nanog@lists.nanog.org/thread/XOZXIJCX6...
We have for years (decades actually) had CIDR Reports send to NOG lists, but no action are being taken about known unallocated and reserved prefixes and ASNs and those that pass it on. And that is a very low hanging fruit.
One can grab those delegated files and verify them against your own BGP tables and alert and reach out (not even asking to directly drop, though would not be bad :) ) -- misconfigs/accidents happen, we should try to minimize that.
Even likely "national interest" ones like DoD prefixes/ASNs are in there, but also from so called big tech CDNs that are supposedly fighting the bad stuff on the Internet with DDoS protection (and apparently also host the booter/stresser services that cause that).
At one point governments likely will want to regulate that like the banking industry (not that that helps in the current political climate).
KYC (Know Your Customer) is a concept there, but for the Internet that is apparently completely lost as long is money to be made.... and we have the stats, and the logs and all the information, just cannot cannot find the contact for the other party to resolve it, and if one has a contact it often is a black hole with no action.
I'd fully support Denis' proposal, but aas Suresh says, we're really good here at not doing anything.
Same.
I wish the world was a bit better with it all, but it is unlikely to change as long as money keeps flowing into pockets of the folks doing so.
Regards, Jeroen
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
jordi.palet--- via Security-wg <security-wg@ripe.net> wrote: > My point has never been “we must use email only”, but “let’s make sure > that we all use the same protocol” and nobody needs to develop > something for each possible operator where abuse is taking place. I > think XARF can do it, other ways are feasible, but the point is to > ensure that if you get a report and ignore it, you’re accountable for > it. At the recent Vienna IETF meeting, I had a conversation about PCAPNG link types, and abuse reports, and the often need to pseudonymize packet traces. The immediate desire was to be able to have an encrypted (pcapng) block that provided the needed seeds/mappings to undo the pseudonomization once the report gets to a party that can actually act on the contents. Researchers who want data against which to test hypothesis, do training, or gather stats about trends don't need to decrypt. Still, there is a need to be sure that data can't be inferred by other means. There are many papers that point to how poor some shrouding attempts really are when combined with other sources. Being able to collect and comment on traces (not just L2/L3 ones, but also re-assembled, inside of TLS traces of abuse) would probably also help. I imagine a Jupyter-like work page that can be collaboratively amended, and maybe transformed into a playbook. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
denis walker wrote on 30/07/2026 00:38:
Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious routing behaviors.
"absolute authority"? Ok so. A reasonable and low-key start to this would be to formally declare "absolute authority" somewhere in the RIPE NCC Standard Service Agreement, and we can go from there. Nick
Hi Nick On Thu, 30 Jul 2026, 11:47 Nick Hilliard, <nick@foobar.org> wrote:
denis walker wrote on 30/07/2026 00:38:
Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious routing behaviors.
"absolute authority"? Ok so.
A reasonable and low-key start to this would be to formally declare "absolute authority" somewhere in the RIPE NCC Standard Service Agreement, and we can go from there.
You are assuming i meant the RIPE NCC has absolute authority. This is a self regulating industry where we make the rules based on consensus policy. Anyone can propose any change on any mailing list. If a hand full of people say yes, then the rules are changed and everyone must comply. So it's the RIPE community that has absolute authority over the rules. (For now...) Cheers Denis Nick
denis walker wrote on 30/07/2026 18:20:
You are assuming i meant the RIPE NCC has absolute authority. This is a self regulating industry where we make the rules based on consensus policy. Anyone can propose any change on any mailing list. If a hand full of people say yes, then the rules are changed and everyone must comply. So it's the RIPE community that has absolute authority over the rules. (For now...)
Denis, What you wrote was this:
Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious routing behaviors.
Just to avoid any misunderstanding, it's probably worth pointing out that limited authority to limit malicious routing behaviors would be the purview of national parliaments. Neither the RIPE Community nor the RIPE NCC have this authority. I'm unclear why the term "absolute authority" was introduced into the conversation because this is a concept that doesn't generally exist in non-totalitarian societies.
The reason LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry closure.
You might need to zoom out a bit on this one, but there are plenty of reasons that organisations don't process abuse reports. Also, it's something of an overclaim to say that only the RIPE Community can fix this, and only by creating a policy which mandates LIR closure for non-compliance. Nick
Hi Nick I think you are correct here. I read so many docs before writing this email I probably confused myself with some of the terminology. On Thu, 30 Jul 2026 at 23:56, Nick Hilliard <nick@foobar.org> wrote:
denis walker wrote on 30/07/2026 18:20:
You are assuming i meant the RIPE NCC has absolute authority. This is a self regulating industry where we make the rules based on consensus policy. Anyone can propose any change on any mailing list. If a hand full of people say yes, then the rules are changed and everyone must comply. So it's the RIPE community that has absolute authority over the rules. (For now...)
Denis,
What you wrote was this:
Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious routing behaviors.
I think this would be more accurate as: Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious abuse behaviors under the same contract.
Just to avoid any misunderstanding, it's probably worth pointing out that limited authority to limit malicious routing behaviors would be the purview of national parliaments. Neither the RIPE Community nor the RIPE NCC have this authority. I'm unclear why the term "absolute authority" was introduced into the conversation because this is a concept that doesn't generally exist in non-totalitarian societies.
The reason LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry closure.
You might need to zoom out a bit on this one, but there are plenty of reasons that organisations don't process abuse reports.
Ok 'One of the reasons...' and 'Where this reason applies, we can only fix this...'
Also, it's something of an overclaim to say that only the RIPE Community can fix this, and only by creating a policy which mandates LIR closure for non-compliance.
It is not only the RIPE Community that can fix this. The EU/EC can fix it with legislation. It would be preferable for this industry if this community can, finally, take some real action. The simple policy I proposed does not mandate anything about closure. But that is the ultimate sanction for any LIR that is in persistent violation of RIPE policies. cheers denis
Nick
denis walker wrote on 30/07/2026 23:32:
On Thu, 30 Jul 2026 at 23:56, Nick Hilliard <nick@foobar.org <mailto:nick@foobar.org>> wrote:
Denis,
What you wrote was this:
> Just as Address Policy limits sub-assignments under contract, we have > the absolute authority to limit malicious routing behaviors.
I think this would be more accurate as: Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious abuse behaviors under the same contract.
Denis, Before going any further, I think you would need to explain in some detail the legal basis for this claim. Nick
On Fri, 31 Jul 2026, 12:41 Nick Hilliard, <nick@foobar.org> wrote:
denis walker wrote on 30/07/2026 23:32:
On Thu, 30 Jul 2026 at 23:56, Nick Hilliard <nick@foobar.org> wrote:
Denis,
What you wrote was this:
Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious routing behaviors.
I think this would be more accurate as: Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious abuse behaviors under the same contract.
Denis,
Before going any further, I think you would need to explain in some detail the legal basis for this claim.
Why? It's a general background comment, not part of the policy proposal. Why are you so fixated on this? The rules of the game are set by policy. Policy is set by the RIPE community. It only takes a handful of people saying yes and the rules are changed. Then ALL resource holders, LIRs, End Users MUST obey the new rules. If you persistently break the rules you can be closed down and have resources taken away. To me, that sounds like a definition of absolute authority. But let's get to the core of your issue here. Do you have a problem with limiting malicious abusive behaviour on the Internet? Or are you just arguing over any point to slow the process down and ultimately prevent any policy from addressing this problem? EVERY time we have looked at this issue over the last couple of decades, 'someone' creates background noise, finds problems, develops arguments against and ultimately prevents any action from being taken. A couple of people even said it in this thread. This WG has a reputation for not taking action. This has to change. That's why I'm suggesting a very simple policy. Here's a list of bad things. You must not do these. Do you have a problem with this? Cheers Denis
Nick
Hi, On Fri, Jul 31, 2026 at 02:08:48PM +0200, denis walker wrote:
EVERY time we have looked at this issue over the last couple of decades, 'someone' creates background noise, finds problems, develops arguments against and ultimately prevents any action from being taken.
Maybe this is related to a basic rule of public policy-making - policy has to be *effective* and *adequate*. Neither of the things usually suggested ("you fail to reply to a single e-mail and all your resources are gone and your business will be bankrupt") fulfill either requirement.
A couple of people even said it in this thread. This WG has a reputation for not taking action. This has to change. That's why I'm suggesting a very simple policy. Here's a list of bad things. You must not do these. Do you have a problem with this?
Starting with a widely-agreed basis for what is considered "bad things" is much better than the previous proposals (equalling "you are not replying to your abuse mailbox" to "must be a bad person"). Stating "you must not do these" is also easy. Claiming authority to then do things that would likely drive a company out of business is where, I think, Nick does not agree with. Of course there are clear-cut cases, where LIRs are provably accomplice to abusers (and I'm all for kicking them out). But what about the middle ground? Where neglicence and/or stupidity leads to networks full of Joomla instances, being actively abused by *other* people - how do you define the threshold for "ok, we close down your business, goodbye"? Will that stand up before EU courts? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
denis walker wrote on 31/07/2026 13:08:
The rules of the game are set by policy. Policy is set by the RIPE community. It only takes a handful of people saying yes and the rules are changed. Then ALL resource holders, LIRs, End Users MUST obey the new rules. If you persistently break the rules you can be closed down and have resources taken away. To me, that sounds like a definition of absolute authority.
Denis, It certainly does sound like the definition of absolute authority. The question is to what degree does this mode of operation describe the legal and regulatory framework within which the RIPE NCC operates. I'd politely suggest: not even remotely. Nick
Never mind. A government person I know told me, back in the 2000s when much the same arguments were going on, that if a national government felt forced to step in to fix this situation, neither they nor the community would like the results. It will be interesting when it actually happens. --srs ________________________________ From: Nick Hilliard <nick@foobar.org> Sent: Friday, 31 July 2026 18:21:58 To: denis walker <ripedenis@gmail.com> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms denis walker wrote on 31/07/2026 13:08: The rules of the game are set by policy. Policy is set by the RIPE community. It only takes a handful of people saying yes and the rules are changed. Then ALL resource holders, LIRs, End Users MUST obey the new rules. If you persistently break the rules you can be closed down and have resources taken away. To me, that sounds like a definition of absolute authority. Denis, It certainly does sound like the definition of absolute authority. The question is to what degree does this mode of operation describe the legal and regulatory framework within which the RIPE NCC operates. I'd politely suggest: not even remotely. Nick
Suresh Ramasubramanian wrote on 31/07/2026 13:55:
Never mind. A government person I know told me, back in the 2000s when much the same arguments were going on, that if a national government felt forced to step in to fix this situation, neither they nor the community would like the results. It will be interesting when it actually happens.
I don't doubt they said that. And we can all agree that there are serious problems with online resource misuse and abuse; the issue is what do to about it, and who needs to be responsible for the "doing" bit of it. The issue we have in the RIPE security wg, and before that, abuse-wg and anti-spam-wg, is that the solutions being proposed involves changing the nature of the RIPE NCC from a registry into an quasi-judicial and enforcement body. Essentially the arguments are of the form which could waspily be described as "politicians' logic": https://youtu.be/trw1PbQt_Yo "Something must be done; this is something; therefore we must do this." In other words, registration of addresses is seen by some people as leverage with which to force compliance into a particular set of rules. If you don't comply with the rules of the registration organisation, your resources are withdrawn and the problem is dealt with that way. Well sorry but there is such a thing called reality which is applicable to the RIPE NCC and the RIPE Community, which as I understand it, falls roughly down the following lines: - lack of legal competence: the RIPE NCC doesn't have the authority to determine what is or isn't abuse or illegality because of its nature as a number resource registry - lack of jurisdiction: the RIPE NCC provides registration services in, what, seventy-something countries, and it has no basis to start acting as some supranational quasi-judicial body in any of these countries. - lack of authority: there are no laws which give the RIPE NCC any of these powers. - insufficiency of contract law: Contract law is not an adequate legal framework for handling any of this, and in particular contract law is governed by concepts like liability and proportionality. So if a RIR were to decide to mete out punitive measures like withdrawal of number resources on the basis of alleged downstream misuse of resources, it may open itself up to loss liability. Or let's say a LIR had a downstream customer whose network resources were being abused for sending spam, and the RIPE NCC chopped their services on that basis. What does the judge say? "Wait, you did what? You put the company out of business and caused serious business service loss to all their customers because they had a single incompetent customer two contracts down the line?" - generally not going to solve the problem: we've had fast flux abuse for 25 years. Number resource withdrawal is a slow process. - inappropriateness of the remedy for the problem at hand: the threat of withdrawal of numbering resources is inappropriate to deal with online abuse threats. In the situations where it might be possible to make some form of a case, the egregious nature of the infringing actions would be so severe that criminal law would probably be applicable anyway. No doubt there are other things missing from this list, and I'm sure an actual lawyer would be able to give you more - and better - reasons as to why threatening resource withdrawal is not an appropriate solution to the problem at hand. The point is that the RIPE NCC is not a hammer, and not everything is a nail. The problem of online abuse needs a bit better than what security-wg is proposing in this situation, and it may well be that any solution is outside, and possibly very far outside, the security-wg's remit to address. Nick
Nick Thanks I think you captured very well a lot of the concerns I had with what was being suggested. Michele Mr Michele Neylon Blacknight Hosting & Domains https://www.blacknight.com @mneylon Sent from mobile so typos and brevity are normal
On 31 Jul 2026, at 15:41, Nick Hilliard <nick@foobar.org> wrote:
[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.
Suresh Ramasubramanian wrote on 31/07/2026 13:55:
Never mind. A government person I know told me, back in the 2000s when much the same arguments were going on, that if a national government felt forced to step in to fix this situation, neither they nor the community would like the results. It will be interesting when it actually happens.
I don't doubt they said that. And we can all agree that there are serious problems with online resource misuse and abuse; the issue is what do to about it, and who needs to be responsible for the "doing" bit of it.
The issue we have in the RIPE security wg, and before that, abuse-wg and anti-spam-wg, is that the solutions being proposed involves changing the nature of the RIPE NCC from a registry into an quasi-judicial and enforcement body. Essentially the arguments are of the form which could waspily be described as "politicians' logic":
"Something must be done; this is something; therefore we must do this."
In other words, registration of addresses is seen by some people as leverage with which to force compliance into a particular set of rules. If you don't comply with the rules of the registration organisation, your resources are withdrawn and the problem is dealt with that way.
Well sorry but there is such a thing called reality which is applicable to the RIPE NCC and the RIPE Community, which as I understand it, falls roughly down the following lines:
- lack of legal competence: the RIPE NCC doesn't have the authority to determine what is or isn't abuse or illegality because of its nature as a number resource registry
- lack of jurisdiction: the RIPE NCC provides registration services in, what, seventy-something countries, and it has no basis to start acting as some supranational quasi-judicial body in any of these countries.
- lack of authority: there are no laws which give the RIPE NCC any of these powers.
- insufficiency of contract law: Contract law is not an adequate legal framework for handling any of this, and in particular contract law is governed by concepts like liability and proportionality. So if a RIR were to decide to mete out punitive measures like withdrawal of number resources on the basis of alleged downstream misuse of resources, it may open itself up to loss liability. Or let's say a LIR had a downstream customer whose network resources were being abused for sending spam, and the RIPE NCC chopped their services on that basis. What does the judge say? "Wait, you did what? You put the company out of business and caused serious business service loss to all their customers because they had a single incompetent customer two contracts down the line?"
- generally not going to solve the problem: we've had fast flux abuse for 25 years. Number resource withdrawal is a slow process.
- inappropriateness of the remedy for the problem at hand: the threat of withdrawal of numbering resources is inappropriate to deal with online abuse threats. In the situations where it might be possible to make some form of a case, the egregious nature of the infringing actions would be so severe that criminal law would probably be applicable anyway.
No doubt there are other things missing from this list, and I'm sure an actual lawyer would be able to give you more - and better - reasons as to why threatening resource withdrawal is not an appropriate solution to the problem at hand.
The point is that the RIPE NCC is not a hammer, and not everything is a nail. The problem of online abuse needs a bit better than what security-wg is proposing in this situation, and it may well be that any solution is outside, and possibly very far outside, the security-wg's remit to address.
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Oh well. It’d be interesting if the security / trust and safety etc teams of various providers started attending ripe and other rir conferences a lot more regularly. Might even end up modifying this comfortable status quo consensus. Short of that, not much here that’ll prevent déjà vu that has lasted since the 20+ years I’ve seen these various iterations of this wg. --srs ________________________________ From: Michele Neylon - Blacknight <michele@blacknight.com> Sent: Friday, 31 July 2026 19:42:59 To: Nick Hilliard <nick@foobar.org> Cc: Suresh Ramasubramanian <ops.lists@gmail.com>; denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net> Subject: Re: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Nick Thanks I think you captured very well a lot of the concerns I had with what was being suggested. Michele Mr Michele Neylon Blacknight Hosting & Domains https://www.blacknight.com @mneylon Sent from mobile so typos and brevity are normal
On 31 Jul 2026, at 15:41, Nick Hilliard <nick@foobar.org> wrote:
[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.
Suresh Ramasubramanian wrote on 31/07/2026 13:55:
Never mind. A government person I know told me, back in the 2000s when much the same arguments were going on, that if a national government felt forced to step in to fix this situation, neither they nor the community would like the results. It will be interesting when it actually happens.
I don't doubt they said that. And we can all agree that there are serious problems with online resource misuse and abuse; the issue is what do to about it, and who needs to be responsible for the "doing" bit of it.
The issue we have in the RIPE security wg, and before that, abuse-wg and anti-spam-wg, is that the solutions being proposed involves changing the nature of the RIPE NCC from a registry into an quasi-judicial and enforcement body. Essentially the arguments are of the form which could waspily be described as "politicians' logic":
"Something must be done; this is something; therefore we must do this."
In other words, registration of addresses is seen by some people as leverage with which to force compliance into a particular set of rules. If you don't comply with the rules of the registration organisation, your resources are withdrawn and the problem is dealt with that way.
Well sorry but there is such a thing called reality which is applicable to the RIPE NCC and the RIPE Community, which as I understand it, falls roughly down the following lines:
- lack of legal competence: the RIPE NCC doesn't have the authority to determine what is or isn't abuse or illegality because of its nature as a number resource registry
- lack of jurisdiction: the RIPE NCC provides registration services in, what, seventy-something countries, and it has no basis to start acting as some supranational quasi-judicial body in any of these countries.
- lack of authority: there are no laws which give the RIPE NCC any of these powers.
- insufficiency of contract law: Contract law is not an adequate legal framework for handling any of this, and in particular contract law is governed by concepts like liability and proportionality. So if a RIR were to decide to mete out punitive measures like withdrawal of number resources on the basis of alleged downstream misuse of resources, it may open itself up to loss liability. Or let's say a LIR had a downstream customer whose network resources were being abused for sending spam, and the RIPE NCC chopped their services on that basis. What does the judge say? "Wait, you did what? You put the company out of business and caused serious business service loss to all their customers because they had a single incompetent customer two contracts down the line?"
- generally not going to solve the problem: we've had fast flux abuse for 25 years. Number resource withdrawal is a slow process.
- inappropriateness of the remedy for the problem at hand: the threat of withdrawal of numbering resources is inappropriate to deal with online abuse threats. In the situations where it might be possible to make some form of a case, the egregious nature of the infringing actions would be so severe that criminal law would probably be applicable anyway.
No doubt there are other things missing from this list, and I'm sure an actual lawyer would be able to give you more - and better - reasons as to why threatening resource withdrawal is not an appropriate solution to the problem at hand.
The point is that the RIPE NCC is not a hammer, and not everything is a nail. The problem of online abuse needs a bit better than what security-wg is proposing in this situation, and it may well be that any solution is outside, and possibly very far outside, the security-wg's remit to address.
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Suresh I’d like to see changes for sure but the reductionist arguments being proposed by some people on this list aren’t helpful. Michele Mr Michele Neylon Blacknight Hosting & Domains https://www.blacknight.com @mneylon Sent from mobile so typos and brevity are normal On 31 Jul 2026, at 16:24, Suresh Ramasubramanian <ops.lists@gmail.com> wrote: [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. Oh well. It’d be interesting if the security / trust and safety etc teams of various providers started attending ripe and other rir conferences a lot more regularly. Might even end up modifying this comfortable status quo consensus. Short of that, not much here that’ll prevent déjà vu that has lasted since the 20+ years I’ve seen these various iterations of this wg. --srs ________________________________ From: Michele Neylon - Blacknight <michele@blacknight.com> Sent: Friday, 31 July 2026 19:42:59 To: Nick Hilliard <nick@foobar.org> Cc: Suresh Ramasubramanian <ops.lists@gmail.com>; denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net> Subject: Re: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Nick Thanks I think you captured very well a lot of the concerns I had with what was being suggested. Michele Mr Michele Neylon Blacknight Hosting & Domains https://www.blacknight.com @mneylon Sent from mobile so typos and brevity are normal
On 31 Jul 2026, at 15:41, Nick Hilliard <nick@foobar.org> wrote:
[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.
Suresh Ramasubramanian wrote on 31/07/2026 13:55:
Never mind. A government person I know told me, back in the 2000s when much the same arguments were going on, that if a national government felt forced to step in to fix this situation, neither they nor the community would like the results. It will be interesting when it actually happens.
I don't doubt they said that. And we can all agree that there are serious problems with online resource misuse and abuse; the issue is what do to about it, and who needs to be responsible for the "doing" bit of it.
The issue we have in the RIPE security wg, and before that, abuse-wg and anti-spam-wg, is that the solutions being proposed involves changing the nature of the RIPE NCC from a registry into an quasi-judicial and enforcement body. Essentially the arguments are of the form which could waspily be described as "politicians' logic":
"Something must be done; this is something; therefore we must do this."
In other words, registration of addresses is seen by some people as leverage with which to force compliance into a particular set of rules. If you don't comply with the rules of the registration organisation, your resources are withdrawn and the problem is dealt with that way.
Well sorry but there is such a thing called reality which is applicable to the RIPE NCC and the RIPE Community, which as I understand it, falls roughly down the following lines:
- lack of legal competence: the RIPE NCC doesn't have the authority to determine what is or isn't abuse or illegality because of its nature as a number resource registry
- lack of jurisdiction: the RIPE NCC provides registration services in, what, seventy-something countries, and it has no basis to start acting as some supranational quasi-judicial body in any of these countries.
- lack of authority: there are no laws which give the RIPE NCC any of these powers.
- insufficiency of contract law: Contract law is not an adequate legal framework for handling any of this, and in particular contract law is governed by concepts like liability and proportionality. So if a RIR were to decide to mete out punitive measures like withdrawal of number resources on the basis of alleged downstream misuse of resources, it may open itself up to loss liability. Or let's say a LIR had a downstream customer whose network resources were being abused for sending spam, and the RIPE NCC chopped their services on that basis. What does the judge say? "Wait, you did what? You put the company out of business and caused serious business service loss to all their customers because they had a single incompetent customer two contracts down the line?"
- generally not going to solve the problem: we've had fast flux abuse for 25 years. Number resource withdrawal is a slow process.
- inappropriateness of the remedy for the problem at hand: the threat of withdrawal of numbering resources is inappropriate to deal with online abuse threats. In the situations where it might be possible to make some form of a case, the egregious nature of the infringing actions would be so severe that criminal law would probably be applicable anyway.
No doubt there are other things missing from this list, and I'm sure an actual lawyer would be able to give you more - and better - reasons as to why threatening resource withdrawal is not an appropriate solution to the problem at hand.
The point is that the RIPE NCC is not a hammer, and not everything is a nail. The problem of online abuse needs a bit better than what security-wg is proposing in this situation, and it may well be that any solution is outside, and possibly very far outside, the security-wg's remit to address.
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
But he is right every time we start this, the same people fine a gazzilion reasons not to do anything. There is no perfect solution, and if we never try nothing is going to happen. The Status Qua is acceptable to the Nay Sayers, because they externalize the costs to victims. Best Serge On 31/07/2026 17:30, Michele Neylon - Blacknight via Security-wg wrote:
Suresh I’d like to see changes for sure but the reductionist arguments being proposed by some people on this list aren’t helpful. Michele
Mr Michele Neylon Blacknight Hosting & Domains https://www.blacknight.com @mneylon Sent from mobile so typos and brevity are normal
On 31 Jul 2026, at 16:24, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
*[EXTERNAL EMAIL]* Please use caution when opening attachments from unrecognised sources.
Oh well. It’d be interesting if the security / trust and safety etc teams of various providers started attending ripe and other rir conferences a lot more regularly. Might even end up modifying this comfortable status quo consensus.
Short of that, not much here that’ll prevent déjà vu that has lasted since the 20+ years I’ve seen these various iterations of this wg.
--srs ------------------------------------------------------------------------ *From:* Michele Neylon - Blacknight <michele@blacknight.com> *Sent:* Friday, 31 July 2026 19:42:59 *To:* Nick Hilliard <nick@foobar.org> *Cc:* Suresh Ramasubramanian <ops.lists@gmail.com>; denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net> *Subject:* Re: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Nick Thanks I think you captured very well a lot of the concerns I had with what was being suggested.
Michele
Mr Michele Neylon Blacknight Hosting & Domains https://www.blacknight.com @mneylon Sent from mobile so typos and brevity are normal
On 31 Jul 2026, at 15:41, Nick Hilliard <nick@foobar.org> wrote:
[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.
Suresh Ramasubramanian wrote on 31/07/2026 13:55:
Never mind. A government person I know told me, back in the 2000s when much the same arguments were going on, that if a national government felt forced to step in to fix this situation, neither they nor the community would like the results. It will be interesting when it actually happens.
I don't doubt they said that. And we can all agree that there are serious problems with online resource misuse and abuse; the issue is what do to about it, and who needs to be responsible for the "doing" bit of it.
The issue we have in the RIPE security wg, and before that, abuse-wg and anti-spam-wg, is that the solutions being proposed involves changing the nature of the RIPE NCC from a registry into an quasi-judicial and enforcement body. Essentially the arguments are of the form which could waspily be described as "politicians' logic":
"Something must be done; this is something; therefore we must do this."
In other words, registration of addresses is seen by some people as leverage with which to force compliance into a particular set of rules. If you don't comply with the rules of the registration organisation, your resources are withdrawn and the problem is dealt with that way.
Well sorry but there is such a thing called reality which is applicable to the RIPE NCC and the RIPE Community, which as I understand it, falls roughly down the following lines:
- lack of legal competence: the RIPE NCC doesn't have the authority to determine what is or isn't abuse or illegality because of its nature as a number resource registry
- lack of jurisdiction: the RIPE NCC provides registration services in, what, seventy-something countries, and it has no basis to start acting as some supranational quasi-judicial body in any of these countries.
- lack of authority: there are no laws which give the RIPE NCC any of these powers.
- insufficiency of contract law: Contract law is not an adequate legal framework for handling any of this, and in particular contract law is governed by concepts like liability and proportionality. So if a RIR were to decide to mete out punitive measures like withdrawal of number resources on the basis of alleged downstream misuse of resources, it may open itself up to loss liability. Or let's say a LIR had a downstream customer whose network resources were being abused for sending spam, and the RIPE NCC chopped their services on that basis. What does the judge say? "Wait, you did what? You put the company out of business and caused serious business service loss to all their customers because they had a single incompetent customer two contracts down the line?"
- generally not going to solve the problem: we've had fast flux abuse for 25 years. Number resource withdrawal is a slow process.
- inappropriateness of the remedy for the problem at hand: the threat of withdrawal of numbering resources is inappropriate to deal with online abuse threats. In the situations where it might be possible to make some form of a case, the egregious nature of the infringing actions would be so severe that criminal law would probably be applicable anyway.
No doubt there are other things missing from this list, and I'm sure an actual lawyer would be able to give you more - and better - reasons as to why threatening resource withdrawal is not an appropriate solution to the problem at hand.
The point is that the RIPE NCC is not a hammer, and not everything is a nail. The problem of online abuse needs a bit better than what security-wg is proposing in this situation, and it may well be that any solution is outside, and possibly very far outside, the security-wg's remit to address.
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit:https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at:https://www.ripe.net/membership/mail/mailman-3-migration/
Serge Droz via Security-wg wrote on 31/07/2026 16:36:
But he is right
every time we start this, the same people fine a gazzilion reasons not to do anything.
Serge, the various proposals which have been put forward over the years haven't failed because "the same people fine a gazzilion reasons not to do anything". They've failed because the proposals were unworkable, or would cause harm in other areas, or were not going to fix the problem at hand, or a combination of all three. Rather than venting at people, it would be more productive to deal with the issues that have been brought up, of which there's no shortage - and in all honesty many of them are really serious and fundamental structural problems. For example, how would the RIPE NCC deal with the sort of liability issues that would come up if they deregistered an organisation's address space because a downstream last-mile provider had customers whose TVs and IOT devices were persistently partaking in botnets and were being used to execute criminal damage against someone else? What legal basis would the RIPE NCC have for doing this in the Netherlands vs the UK vs Russia vs Saudi Arabia? What splash damage would happen? What would the RIPE NCC's obligations and policies be in terms of deciding whether some form of networking abuse was serious enough to merit deregistration? Would these be legally sound in all of the jurisdictions where the RIPE NCC operates. If they were brought to court, how would the RIPE NCC tell a judge that their behaviour would be justified within a particular legal system, and that it wasn't anti-competitive behaviour from a monopoly provider (i.e. criminal behaviour in many jurisdictions). How does the RIPE NCC handle legal differences? e.g. someone in one jurisdiction does something which is entirely legal in one, but a very serious crime in another? Think: blasphemy (capital punishment in several RIPE NCC service area countries, but absolutely acceptable in plenty of others), pornography (e.g.with age of consent differences in different jurisdictions), etc. How does the RIPE NCC handle resist scope creep? You've created a mechanism for enforcing policy, so how do you stop that from being used by people pushing for their own interests? How should the RIPE NCC react, for example, if someone's religious organisation were to start covertly pushing the edge on abuse to cover things that they would consider abuse, but which were specific to their religion? Or same for political? It's unhelpful to repeatedly dismiss those who disagree with you as nay-sayers or that the problem is that people won't get out of their "comfort zone". What's needed is to actually deal with the substance of the concerns that are brought up, i.e. create cogent, legally sound and workable proposals for dealing with these and the other problems which have been raised over the years. Nick
Hi Nick It's not venting. It's stating the facts: All you write are reasons why we should not change things. Alternatives could be 1. Check how the others do and copy it or 2. Instead of saying X is not workable, you could say It seems X is no workable, but we could try Y to solve this. But the second part never comes. Best Serge On 31/07/2026 19:17, Nick Hilliard wrote:
Serge Droz via Security-wg wrote on 31/07/2026 16:36:
But he is right
every time we start this, the same people fine a gazzilion reasons not to do anything.
Serge,
the various proposals which have been put forward over the years haven't failed because "the same people fine a gazzilion reasons not to do anything". They've failed because the proposals were unworkable, or would cause harm in other areas, or were not going to fix the problem at hand, or a combination of all three.
Rather than venting at people, it would be more productive to deal with the issues that have been brought up, of which there's no shortage - and in all honesty many of them are really serious and fundamental structural problems.
For example, how would the RIPE NCC deal with the sort of liability issues that would come up if they deregistered an organisation's address space because a downstream last-mile provider had customers whose TVs and IOT devices were persistently partaking in botnets and were being used to execute criminal damage against someone else? What legal basis would the RIPE NCC have for doing this in the Netherlands vs the UK vs Russia vs Saudi Arabia? What splash damage would happen? What would the RIPE NCC's obligations and policies be in terms of deciding whether some form of networking abuse was serious enough to merit deregistration? Would these be legally sound in all of the jurisdictions where the RIPE NCC operates. If they were brought to court, how would the RIPE NCC tell a judge that their behaviour would be justified within a particular legal system, and that it wasn't anti-competitive behaviour from a monopoly provider (i.e. criminal behaviour in many jurisdictions). How does the RIPE NCC handle legal differences? e.g. someone in one jurisdiction does something which is entirely legal in one, but a very serious crime in another? Think: blasphemy (capital punishment in several RIPE NCC service area countries, but absolutely acceptable in plenty of others), pornography (e.g.with age of consent differences in different jurisdictions), etc. How does the RIPE NCC handle resist scope creep? You've created a mechanism for enforcing policy, so how do you stop that from being used by people pushing for their own interests? How should the RIPE NCC react, for example, if someone's religious organisation were to start covertly pushing the edge on abuse to cover things that they would consider abuse, but which were specific to their religion? Or same for political?
It's unhelpful to repeatedly dismiss those who disagree with you as nay-sayers or that the problem is that people won't get out of their "comfort zone". What's needed is to actually deal with the substance of the concerns that are brought up, i.e. create cogent, legally sound and workable proposals for dealing with these and the other problems which have been raised over the years.
Nick
Serge, Serge Droz wrote on 31/07/2026 18:30:
It's not venting. It's stating the facts:
it's taking a swipe at people.
All you write are reasons why we should not change things. Alternatives could be
There are plenty of other proposals or groups of proposals that I've supported over the years, some controversial, some not so. This isn't because I don't want online abuse to be dealt with, or that I like objecting to RIPE policy proposals: it's because the proposals that are coming out of security-wg / abuse-wg have, in my opinion, really serious and fundamental problems with them which haven't been addressed by the proposal authors.
1. Check how the others do and copy it
or
2. Instead of saying X is not workable, you could say It seems X is no workable, but we could try Y to solve this. But the second part never comes.
It never comes from the policy proposer either, which is the actual problem here. Also, I don't have a workable alternative to the reality that the RIPE NCC doesn't have supranational judicial authority or that it's subject to the laws of the country where it legally resides. It's also correct to say that when someone comes up with a RIPE Community policy proposal, that it needs to be able to withstand reasonable criticism, and that if the proposer can't withstand that criticism, then the policy proposal should fail. The proposals aren't precious. I've had plenty of proposals shot down by other people. So what? Nick
On Fri, 31 Jul 2026, 19:58 Nick Hilliard, <nick@foobar.org> wrote:
Serge,
Serge Droz wrote on 31/07/2026 18:30:
It's not venting. It's stating the facts:
it's taking a swipe at people.
All you write are reasons why we should not change things. Alternatives could be
There are plenty of other proposals or groups of proposals that I've supported over the years, some controversial, some not so. This isn't because I don't want online abuse to be dealt with, or that I like objecting to RIPE policy proposals: it's because the proposals that are coming out of security-wg / abuse-wg have, in my opinion, really serious and fundamental problems with them which haven't been addressed by the proposal authors.
1. Check how the others do and copy it
or
2. Instead of saying X is not workable, you could say It seems X is no workable, but we could try Y to solve this. But the second part never comes.
It never comes from the policy proposer either, which is the actual problem here.
Don't speak for me Nick. A response is coming. I know your tactics well. They never change. You like to hit a proposer with a mass of legalistic speak. You swamp them with it in one dump hoping they will be overwhelmed. They won't be able to handle it and yet another proposal will bite the dust. Not this time...but it takes more than 5 minutes. Also, I don't have a workable alternative to the reality
that the RIPE NCC doesn't have supranational judicial authority or that it's subject to the laws of the country where it legally resides.
It's also correct to say that when someone comes up with a RIPE Community policy proposal, that it needs to be able to withstand reasonable criticism, and that if the proposer can't withstand that criticism, then the policy proposal should fail.
What you write is not reasonable criticism. What you are saying here is that if the proposer (person) can't handle your mass criticism, then the policy proposal (issue) should fail. I will take my time and then calmly address your comments. This issue is too important to fail again. Cheers Denis The proposals aren't
precious. I've had plenty of proposals shot down by other people. So what?
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
I know your tactics well. They never change. You like to hit a proposer with a mass of legalistic speak. You swamp them with it in one dump hoping they will be overwhelmed.
could we please refrain from ad homina? randy
So in essence nobody wants to accept responsibility to address this because x is illegal in one country but it could be legal somewhere else so that they think they’ll be exposed to litigation if they take any action at all? In all such cases (let us assume, as an extreme example, child abuse material, versus some country where the age of consent is absurdly low - there are countries where this age is pre teen ) the general rule has been to make it subject to the law of the host country, or in ripe ncc’s case, Dutch law. --srs ________________________________ From: Nick Hilliard <nick@foobar.org> Sent: Friday, 31 July 2026 23:28:47 To: Serge Droz <serge.droz@first.org> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Serge, Serge Droz wrote on 31/07/2026 18:30:
It's not venting. It's stating the facts:
it's taking a swipe at people.
All you write are reasons why we should not change things. Alternatives could be
There are plenty of other proposals or groups of proposals that I've supported over the years, some controversial, some not so. This isn't because I don't want online abuse to be dealt with, or that I like objecting to RIPE policy proposals: it's because the proposals that are coming out of security-wg / abuse-wg have, in my opinion, really serious and fundamental problems with them which haven't been addressed by the proposal authors.
1. Check how the others do and copy it
or
2. Instead of saying X is not workable, you could say It seems X is no workable, but we could try Y to solve this. But the second part never comes.
It never comes from the policy proposer either, which is the actual problem here. Also, I don't have a workable alternative to the reality that the RIPE NCC doesn't have supranational judicial authority or that it's subject to the laws of the country where it legally resides. It's also correct to say that when someone comes up with a RIPE Community policy proposal, that it needs to be able to withstand reasonable criticism, and that if the proposer can't withstand that criticism, then the policy proposal should fail. The proposals aren't precious. I've had plenty of proposals shot down by other people. So what? Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Suresh Ramasubramanian wrote on 01/08/2026 01:33:
So in essence nobody wants to accept responsibility to address this because x is illegal in one country but it could be legal somewhere else so that they think they’ll be exposed to litigation if they take any action at all?
Suresh, I didn't say that. What I said was that the suggestions being put forward would put the RIPE NCC in the position of being expected to make decisions which are well outside their area of competence and that these calls would be largely equivalent to legal judgements; also, that the proposed sanction (deregistration of number resources) is unsuited to the deal with the problem at hand. If you want to claim that the RIPE NCC would be immune to liability for this style of decision and outcome, I'd be interested to understand why. Nick
In all such cases (let us assume, as an extreme example, child abuse material, versus some country where the age of consent is absurdly low - there are countries where this age is pre teen ) the general rule has been to make it subject to the law of the host country, or in ripe ncc’s case, Dutch law.
--srs ------------------------------------------------------------------------ *From:* Nick Hilliard <nick@foobar.org> *Sent:* Friday, 31 July 2026 23:28:47 *To:* Serge Droz <serge.droz@first.org> *Cc:* security-wg@ripe.net <security-wg@ripe.net> *Subject:* [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Serge,
Serge Droz wrote on 31/07/2026 18:30:
It's not venting. It's stating the facts:
it's taking a swipe at people.
All you write are reasons why we should not change things. Alternatives could be
There are plenty of other proposals or groups of proposals that I've supported over the years, some controversial, some not so. This isn't because I don't want online abuse to be dealt with, or that I like objecting to RIPE policy proposals: it's because the proposals that are coming out of security-wg / abuse-wg have, in my opinion, really serious and fundamental problems with them which haven't been addressed by the proposal authors.
1. Check how the others do and copy it
or
2. Instead of saying X is not workable, you could say It seems X is no workable, but we could try Y to solve this. But the second part never comes.
It never comes from the policy proposer either, which is the actual problem here. Also, I don't have a workable alternative to the reality that the RIPE NCC doesn't have supranational judicial authority or that it's subject to the laws of the country where it legally resides.
It's also correct to say that when someone comes up with a RIPE Community policy proposal, that it needs to be able to withstand reasonable criticism, and that if the proposer can't withstand that criticism, then the policy proposal should fail. The proposals aren't precious. I've had plenty of proposals shot down by other people. So what?
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space. So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc. --srs ________________________________ From: Nick Hilliard <nick@foobar.org> Sent: Saturday, 01 August 2026 15:04:54 To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Serge Droz <serge.droz@first.org>; security-wg@ripe.net <security-wg@ripe.net> Subject: Re: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Suresh Ramasubramanian wrote on 01/08/2026 01:33:
So in essence nobody wants to accept responsibility to address this because x is illegal in one country but it could be legal somewhere else so that they think they’ll be exposed to litigation if they take any action at all?
Suresh, I didn't say that. What I said was that the suggestions being put forward would put the RIPE NCC in the position of being expected to make decisions which are well outside their area of competence and that these calls would be largely equivalent to legal judgements; also, that the proposed sanction (deregistration of number resources) is unsuited to the deal with the problem at hand. If you want to claim that the RIPE NCC would be immune to liability for this style of decision and outcome, I'd be interested to understand why. Nick
In all such cases (let us assume, as an extreme example, child abuse material, versus some country where the age of consent is absurdly low - there are countries where this age is pre teen ) the general rule has been to make it subject to the law of the host country, or in ripe ncc’s case, Dutch law.
--srs ------------------------------------------------------------------------ *From:* Nick Hilliard <nick@foobar.org> *Sent:* Friday, 31 July 2026 23:28:47 *To:* Serge Droz <serge.droz@first.org> *Cc:* security-wg@ripe.net <security-wg@ripe.net> *Subject:* [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Serge,
Serge Droz wrote on 31/07/2026 18:30:
It's not venting. It's stating the facts:
it's taking a swipe at people.
All you write are reasons why we should not change things. Alternatives could be
There are plenty of other proposals or groups of proposals that I've supported over the years, some controversial, some not so. This isn't because I don't want online abuse to be dealt with, or that I like objecting to RIPE policy proposals: it's because the proposals that are coming out of security-wg / abuse-wg have, in my opinion, really serious and fundamental problems with them which haven't been addressed by the proposal authors.
1. Check how the others do and copy it
or
2. Instead of saying X is not workable, you could say It seems X is no workable, but we could try Y to solve this. But the second part never comes.
It never comes from the policy proposer either, which is the actual problem here. Also, I don't have a workable alternative to the reality that the RIPE NCC doesn't have supranational judicial authority or that it's subject to the laws of the country where it legally resides.
It's also correct to say that when someone comes up with a RIPE Community policy proposal, that it needs to be able to withstand reasonable criticism, and that if the proposer can't withstand that criticism, then the policy proposal should fail. The proposals aren't precious. I've had plenty of proposals shot down by other people. So what?
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
On 1 Aug 2026, at 16:31, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space.
So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc.
This and other courses with a security focus are already available: https://academy.ripe.net/mod/page/view.php?id=965 RIPE NCC Academy: Fundamentals - Webinar - Anti-Abuse | RIPE NCC Academy academy.ripe.net Regards, Leo
There has been no shortage of capacity building for decades now. Perhaps the question is who takes the horse to water and makes it drink --srs ________________________________ From: Leo Vegoda <leo@vegoda.org> Sent: Saturday, 01 August 2026 22:10:19 To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Nick Hilliard <nick@foobar.org>; Serge Droz <serge.droz@first.org>; security-wg@ripe.net <security-wg@ripe.net> Subject: Re: [Security-wg] Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms On 1 Aug 2026, at 16:31, Suresh Ramasubramanian <ops.lists@gmail.com> wrote: That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space. So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc. This and other courses with a security focus are already available: <https://academy.ripe.net/mod/page/view.php?id=965> [course-material-library.jpg] RIPE NCC Academy: Fundamentals - Webinar - Anti-Abuse | RIPE NCC Academy<https://academy.ripe.net/mod/page/view.php?id=965> academy.ripe.net<https://academy.ripe.net/mod/page/view.php?id=965> Regards, Leo
Suresh Ramasubramanian wrote on 01/08/2026 16:31:
That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space.
So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc.
Suresh, the RIPE NCC has a fiduciary duty to registration of IP space. How those number resources are used is an issue for the courts and the law. Your comparison with the bank manager is inapplicable for a lot of reasons, the main ones being that a bank is not a registration authority and - unlike money - an IP address isn't at risk of disappearing into thin air when the holder walks out the front door. If you want to claim that the bank manager is still on the hook to do some due diligence to ensure that it's not obviously being used for illegal activity, there's no problem pulling out another somewhat inapplicable comparison and say that road / motorway operators don't seem to be bound by any sort of due diligence for use of their resources, and knowingly allow their roads to be used for all sorts of crimes, many heinous. There are plenty of situations in society where abuse of a resource or a registration can cause harm and where we don't require any sort of due diligence: cutlery vendors don't check their customer out if someone walks in to buy a carving knife; the IEEE isn't on the hook if their MAC addresses are used in NICs which are used for network abuse, and so forth. The point is not that that you can't invoke comparisons of dubious comparative value with other organisations or societal structures, it's that the RIPE NCC is in something of a unique position, being a registration organisation for a large number of countries for numbers which are used for international communications. We don't have a direct analogue anywhere else. Nick
They certainly can disappear into thin air due to a variety of reasons. Given the dollar amount that v4 netblocks seem to change hands at these days.. --srs ________________________________ From: Nick Hilliard <nick@foobar.org> Sent: Sunday, 02 August 2026 15:56:01 To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Serge Droz <serge.droz@first.org>; security-wg@ripe.net <security-wg@ripe.net> Subject: Re: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Suresh Ramasubramanian wrote on 01/08/2026 16:31:
That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space.
So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc.
Suresh, the RIPE NCC has a fiduciary duty to registration of IP space. How those number resources are used is an issue for the courts and the law. Your comparison with the bank manager is inapplicable for a lot of reasons, the main ones being that a bank is not a registration authority and - unlike money - an IP address isn't at risk of disappearing into thin air when the holder walks out the front door. If you want to claim that the bank manager is still on the hook to do some due diligence to ensure that it's not obviously being used for illegal activity, there's no problem pulling out another somewhat inapplicable comparison and say that road / motorway operators don't seem to be bound by any sort of due diligence for use of their resources, and knowingly allow their roads to be used for all sorts of crimes, many heinous. There are plenty of situations in society where abuse of a resource or a registration can cause harm and where we don't require any sort of due diligence: cutlery vendors don't check their customer out if someone walks in to buy a carving knife; the IEEE isn't on the hook if their MAC addresses are used in NICs which are used for network abuse, and so forth. The point is not that that you can't invoke comparisons of dubious comparative value with other organisations or societal structures, it's that the RIPE NCC is in something of a unique position, being a registration organisation for a large number of countries for numbers which are used for international communications. We don't have a direct analogue anywhere else. Nick
In the day and age of cloud services there are hundreds of examples of services provided to different jurisdictions. Usually the law of your legal residence applies. Furthermore, APnic and Lacnic do such things, and they cover multiple jurisdictions,a fact you seem to ignore. At least let us know what makes them different from us,in away that cannot be changed. And your cutlery vendor analogy doesn't cut it: Once the knife is sold, the vendor doesn't control it anymore. That is different from ip addresses. Best Serge On 2 August 2026 10:26:01 UTC, Nick Hilliard <nick@foobar.org> wrote:
Suresh Ramasubramanian wrote on 01/08/2026 16:31:
That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space.
So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc.
Suresh,
the RIPE NCC has a fiduciary duty to registration of IP space. How those number resources are used is an issue for the courts and the law.
Your comparison with the bank manager is inapplicable for a lot of reasons, the main ones being that a bank is not a registration authority and - unlike money - an IP address isn't at risk of disappearing into thin air when the holder walks out the front door.
If you want to claim that the bank manager is still on the hook to do some due diligence to ensure that it's not obviously being used for illegal activity, there's no problem pulling out another somewhat inapplicable comparison and say that road / motorway operators don't seem to be bound by any sort of due diligence for use of their resources, and knowingly allow their roads to be used for all sorts of crimes, many heinous. There are plenty of situations in society where abuse of a resource or a registration can cause harm and where we don't require any sort of due diligence: cutlery vendors don't check their customer out if someone walks in to buy a carving knife; the IEEE isn't on the hook if their MAC addresses are used in NICs which are used for network abuse, and so forth.
The point is not that that you can't invoke comparisons of dubious comparative value with other organisations or societal structures, it's that the RIPE NCC is in something of a unique position, being a registration organisation for a large number of countries for numbers which are used for international communications. We don't have a direct analogue anywhere else.
Nick
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams https://first.org
Arguing this for the n’th time in decades is fruitless. I would just suggest that organisations send people from their trust and safety teams across to ripe meetings besides the usual ripe regulars and/or ensure that the ripe regulars coordinate with their trust and safety teams before key votes. Consensus tends to depend on just who is working to achieve it, I have found. The naysayers can continue to naysay, that is a situation we just have to grow to accept and ignore. --srs ________________________________ From: Serge Droz via Security-wg <security-wg@ripe.net> Sent: Sunday, 02 August 2026 17:42:05 To: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms In the day and age of cloud services there are hundreds of examples of services provided to different jurisdictions. Usually the law of your legal residence applies. Furthermore, APnic and Lacnic do such things, and they cover multiple jurisdictions,a fact you seem to ignore. At least let us know what makes them different from us,in away that cannot be changed. And your cutlery vendor analogy doesn't cut it: Once the knife is sold, the vendor doesn't control it anymore. That is different from ip addresses. Best Serge On 2 August 2026 10:26:01 UTC, Nick Hilliard <nick@foobar.org> wrote: Suresh Ramasubramanian wrote on 01/08/2026 16:31: That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space. So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc. Suresh, the RIPE NCC has a fiduciary duty to registration of IP space. How those number resources are used is an issue for the courts and the law. Your comparison with the bank manager is inapplicable for a lot of reasons, the main ones being that a bank is not a registration authority and - unlike money - an IP address isn't at risk of disappearing into thin air when the holder walks out the front door. If you want to claim that the bank manager is still on the hook to do some due diligence to ensure that it's not obviously being used for illegal activity, there's no problem pulling out another somewhat inapplicable comparison and say that road / motorway operators don't seem to be bound by any sort of due diligence for use of their resources, and knowingly allow their roads to be used for all sorts of crimes, many heinous. There are plenty of situations in society where abuse of a resource or a registration can cause harm and where we don't require any sort of due diligence: cutlery vendors don't check their customer out if someone walks in to buy a carving knife; the IEEE isn't on the hook if their MAC addresses are used in NICs which are used for network abuse, and so forth. The point is not that that you can't invoke comparisons of dubious comparative value with other organisations or societal structures, it's that the RIPE NCC is in something of a unique position, being a registration organisation for a large number of countries for numbers which are used for international communications. We don't have a direct analogue anywhere else. Nick -- Dr. Serge Droz Director, Forum of Incident Response and Security Teams https://first.org
Serge, Serge Droz via Security-wg wrote on 02/08/2026 13:12:
In the day and age of cloud services there are hundreds of examples of services provided to different jurisdictions. Usually the law of your legal residence applies.
yep, that's largely where the abuse management needs to happen.
Furthermore, APnic and Lacnic do such things, and they cover multiple jurisdictions,a fact you seem to ignore.
This argument is looking perilously close to suggesting that the RIPE NCC should throw the outcome of its own PDP into the bin and follow the other RIRs willy-nilly.
And your cutlery vendor analogy doesn't cut it: Once the knife is sold, the vendor doesn't control it anymore. That is different from ip addresses.
Yep, this is why I flagged it as an inapplicable comparison, in a similar way to the bank manager comparison: once the asset goes out the door, you lose control. But you've brought up the nub of the issue here: you're viewing continued number registration as a lever which can be used to exert control over the resource holder in a way that ticks some boxes for you. There are a lot of reasons why this approach doesn't make good policy. Nick
We can frame this as we like. And we don't need to solve this 100%, if we get 80% it's still better than nothing. And we don't have to fall back to law. We have to make sure we don't violate existing law. But we can demand working abuse addresses, and exert some pain if that's not provided. This is not unusual, it is how most of the internet works. Serge On 2 August 2026 13:03:16 UTC, Nick Hilliard <nick@foobar.org> wrote:
Serge,
Serge Droz via Security-wg wrote on 02/08/2026 13:12:
In the day and age of cloud services there are hundreds of examples of services provided to different jurisdictions. Usually the law of your legal residence applies.
yep, that's largely where the abuse management needs to happen.
Furthermore, APnic and Lacnic do such things, and they cover multiple jurisdictions,a fact you seem to ignore.
This argument is looking perilously close to suggesting that the RIPE NCC should throw the outcome of its own PDP into the bin and follow the other RIRs willy-nilly.
And your cutlery vendor analogy doesn't cut it: Once the knife is sold, the vendor doesn't control it anymore. That is different from ip addresses.
Yep, this is why I flagged it as an inapplicable comparison, in a similar way to the bank manager comparison: once the asset goes out the door, you lose control.
But you've brought up the nub of the issue here: you're viewing continued number registration as a lever which can be used to exert control over the resource holder in a way that ticks some boxes for you. There are a lot of reasons why this approach doesn't make good policy.
Nick
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams https://first.org
On Sun, 2 Aug 2026 at 14:12, Serge Droz via Security-wg < security-wg@ripe.net> wrote:
In the day and age of cloud services there are hundreds of examples of services provided to different jurisdictions. Usually the law of your legal residence applies.
That is not true. If your cloud service has it's data centres in the USA then US law applies to your data, regardless of your residence. cheers denis
Furthermore, APnic and Lacnic do such things, and they cover multiple jurisdictions,a fact you seem to ignore. At least let us know what makes them different from us,in away that cannot be changed.
And your cutlery vendor analogy doesn't cut it: Once the knife is sold, the vendor doesn't control it anymore. That is different from ip addresses.
Best Serge
On 2 August 2026 10:26:01 UTC, Nick Hilliard <nick@foobar.org> wrote:
Suresh Ramasubramanian wrote on 01/08/2026 16:31:
That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space.
So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc.
Suresh,
the RIPE NCC has a fiduciary duty to registration of IP space. How those number resources are used is an issue for the courts and the law.
Your comparison with the bank manager is inapplicable for a lot of reasons, the main ones being that a bank is not a registration authority and - unlike money - an IP address isn't at risk of disappearing into thin air when the holder walks out the front door.
If you want to claim that the bank manager is still on the hook to do some due diligence to ensure that it's not obviously being used for illegal activity, there's no problem pulling out another somewhat inapplicable comparison and say that road / motorway operators don't seem to be bound by any sort of due diligence for use of their resources, and knowingly allow their roads to be used for all sorts of crimes, many heinous. There are plenty of situations in society where abuse of a resource or a registration can cause harm and where we don't require any sort of due diligence: cutlery vendors don't check their customer out if someone walks in to buy a carving knife; the IEEE isn't on the hook if their MAC addresses are used in NICs which are used for network abuse, and so forth.
The point is not that that you can't invoke comparisons of dubious comparative value with other organisations or societal structures, it's that the RIPE NCC is in something of a unique position, being a registration organisation for a large number of countries for numbers which are used for international communications. We don't have a direct analogue anywhere else.
Nick
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams https://first.org
To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Now consider where 1. The user has residency in a country and the country’s law applies 2. The cloud provider themselves may have a local office in that country - even if the actual service is ring fenced from other country jurisdiction, the local subsidiary is a locally incorporated company etc The correct answer is that “it is complex” --srs ________________________________ From: denis walker <ripedenis@gmail.com> Sent: Sunday, 02 August 2026 20:01:51 To: Serge Droz <serge.droz@first.org> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms On Sun, 2 Aug 2026 at 14:12, Serge Droz via Security-wg <security-wg@ripe.net<mailto:security-wg@ripe.net>> wrote: In the day and age of cloud services there are hundreds of examples of services provided to different jurisdictions. Usually the law of your legal residence applies. That is not true. If your cloud service has it's data centres in the USA then US law applies to your data, regardless of your residence. cheers denis Furthermore, APnic and Lacnic do such things, and they cover multiple jurisdictions,a fact you seem to ignore. At least let us know what makes them different from us,in away that cannot be changed. And your cutlery vendor analogy doesn't cut it: Once the knife is sold, the vendor doesn't control it anymore. That is different from ip addresses. Best Serge On 2 August 2026 10:26:01 UTC, Nick Hilliard <nick@foobar.org<mailto:nick@foobar.org>> wrote: Suresh Ramasubramanian wrote on 01/08/2026 16:31: That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space. So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc. Suresh, the RIPE NCC has a fiduciary duty to registration of IP space. How those number resources are used is an issue for the courts and the law. Your comparison with the bank manager is inapplicable for a lot of reasons, the main ones being that a bank is not a registration authority and - unlike money - an IP address isn't at risk of disappearing into thin air when the holder walks out the front door. If you want to claim that the bank manager is still on the hook to do some due diligence to ensure that it's not obviously being used for illegal activity, there's no problem pulling out another somewhat inapplicable comparison and say that road / motorway operators don't seem to be bound by any sort of due diligence for use of their resources, and knowingly allow their roads to be used for all sorts of crimes, many heinous. There are plenty of situations in society where abuse of a resource or a registration can cause harm and where we don't require any sort of due diligence: cutlery vendors don't check their customer out if someone walks in to buy a carving knife; the IEEE isn't on the hook if their MAC addresses are used in NICs which are used for network abuse, and so forth. The point is not that that you can't invoke comparisons of dubious comparative value with other organisations or societal structures, it's that the RIPE NCC is in something of a unique position, being a registration organisation for a large number of countries for numbers which are used for international communications. We don't have a direct analogue anywhere else. Nick -- Dr. Serge Droz Director, Forum of Incident Response and Security Teams https://first.org ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Yes, if the cloud operator has an office somewhere else, it becomes complicated. But RIPE doesn't it's 100% pure dutch. So Dutch la applies. I think in this case the jurisdiction stuff is simple. In addition to that. I don't think we should go down a route where we need to think too much about this. We should look at the no brainers, otherwise we never make progress. We can solve the more complicated cases later. Sorry if I created the confusion. Best Serge On 02/08/2026 16:42, Suresh Ramasubramanian wrote:
Now consider where
1. The user has residency in a country and the country’s law applies 2. The cloud provider themselves may have a local office in that country - even if the actual service is ring fenced from other country jurisdiction, the local subsidiary is a locally incorporated company etc
The correct answer is that “it is complex”
--srs ------------------------------------------------------------------------ *From:* denis walker <ripedenis@gmail.com> *Sent:* Sunday, 02 August 2026 20:01:51 *To:* Serge Droz <serge.droz@first.org> *Cc:* security-wg@ripe.net <security-wg@ripe.net> *Subject:* [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On Sun, 2 Aug 2026 at 14:12, Serge Droz via Security-wg <security- wg@ripe.net <mailto:security-wg@ripe.net>> wrote:
In the day and age of cloud services there are hundreds of examples of services provided to different jurisdictions. Usually the law of your legal residence applies.
That is not true. If your cloud service has it's data centres in the USA then US law applies to your data, regardless of your residence.
cheers denis
Furthermore, APnic and Lacnic do such things, and they cover multiple jurisdictions,a fact you seem to ignore. At least let us know what makes them different from us,in away that cannot be changed.
And your cutlery vendor analogy doesn't cut it: Once the knife is sold, the vendor doesn't control it anymore. That is different from ip addresses.
Best Serge
On 2 August 2026 10:26:01 UTC, Nick Hilliard <nick@foobar.org <mailto:nick@foobar.org>> wrote:
Suresh Ramasubramanian wrote on 01/08/2026 16:31:
That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space.
So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc.
Suresh,
the RIPE NCC has a fiduciary duty to registration of IP space. How those number resources are used is an issue for the courts and the law.
Your comparison with the bank manager is inapplicable for a lot of reasons, the main ones being that a bank is not a registration authority and - unlike money - an IP address isn't at risk of disappearing into thin air when the holder walks out the front door.
If you want to claim that the bank manager is still on the hook to do some due diligence to ensure that it's not obviously being used for illegal activity, there's no problem pulling out another somewhat inapplicable comparison and say that road / motorway operators don't seem to be bound by any sort of due diligence for use of their resources, and knowingly allow their roads to be used for all sorts of crimes, many heinous. There are plenty of situations in society where abuse of a resource or a registration can cause harm and where we don't require any sort of due diligence: cutlery vendors don't check their customer out if someone walks in to buy a carving knife; the IEEE isn't on the hook if their MAC addresses are used in NICs which are used for network abuse, and so forth.
The point is not that that you can't invoke comparisons of dubious comparative value with other organisations or societal structures, it's that the RIPE NCC is in something of a unique position, being a registration organisation for a large number of countries for numbers which are used for international communications. We don't have a direct analogue anywhere else.
Nick
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams https://first.org <https://first.org> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ security-wg.ripe.net/ <https://mailman.ripe.net/mailman3/lists/ security-wg.ripe.net/> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3- migration/ <https://www.ripe.net/membership/mail/mailman-3-migration/>
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams (FIRST) serge.droz@first.org | https://www.first.org
That is not true. If your cloud service has it's data centres in the USA then US law applies to your data, regardless of your residence.
it's wider than that. if the cloud provider is a subsidiary, or otherwise under the control of, a US company, the US claims authority over the data. see the cloud act. randy
That's what I meant. It's the juristiocn of the operator, not the customers. On 02/08/2026 16:31, denis walker wrote:
On Sun, 2 Aug 2026 at 14:12, Serge Droz via Security-wg <security- wg@ripe.net <mailto:security-wg@ripe.net>> wrote:
In the day and age of cloud services there are hundreds of examples of services provided to different jurisdictions. Usually the law of your legal residence applies.
That is not true. If your cloud service has it's data centres in the USA then US law applies to your data, regardless of your residence.
cheers denis
Furthermore, APnic and Lacnic do such things, and they cover multiple jurisdictions,a fact you seem to ignore. At least let us know what makes them different from us,in away that cannot be changed.
And your cutlery vendor analogy doesn't cut it: Once the knife is sold, the vendor doesn't control it anymore. That is different from ip addresses.
Best Serge
On 2 August 2026 10:26:01 UTC, Nick Hilliard <nick@foobar.org <mailto:nick@foobar.org>> wrote:
Suresh Ramasubramanian wrote on 01/08/2026 16:31:
That suggests that some capacity building is in order. They have what is effectively a fiduciary duty to IP space.
So they can no more not develop competence in this than a bank manager can disclaim all competence in assessing whether a loan that they disburse is going to be repaid or not, used for illegal activity or not etc.
Suresh,
the RIPE NCC has a fiduciary duty to registration of IP space. How those number resources are used is an issue for the courts and the law.
Your comparison with the bank manager is inapplicable for a lot of reasons, the main ones being that a bank is not a registration authority and - unlike money - an IP address isn't at risk of disappearing into thin air when the holder walks out the front door.
If you want to claim that the bank manager is still on the hook to do some due diligence to ensure that it's not obviously being used for illegal activity, there's no problem pulling out another somewhat inapplicable comparison and say that road / motorway operators don't seem to be bound by any sort of due diligence for use of their resources, and knowingly allow their roads to be used for all sorts of crimes, many heinous. There are plenty of situations in society where abuse of a resource or a registration can cause harm and where we don't require any sort of due diligence: cutlery vendors don't check their customer out if someone walks in to buy a carving knife; the IEEE isn't on the hook if their MAC addresses are used in NICs which are used for network abuse, and so forth.
The point is not that that you can't invoke comparisons of dubious comparative value with other organisations or societal structures, it's that the RIPE NCC is in something of a unique position, being a registration organisation for a large number of countries for numbers which are used for international communications. We don't have a direct analogue anywhere else.
Nick
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams https://first.org <https://first.org> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ security-wg.ripe.net/ <https://mailman.ripe.net/mailman3/lists/ security-wg.ripe.net/> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3- migration/ <https://www.ripe.net/membership/mail/mailman-3-migration/>
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams (FIRST) serge.droz@first.org | https://www.first.org
Hi, On Sun, Aug 02, 2026 at 07:11:59PM +0200, Serge Droz via Security-wg wrote:
That's what I meant. It's the juristiocn of the operator, not the customers.
If you provide services to EU customers, jurisdiction of the customers applies as well. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
At which point law firms in two countries become very happy indeed. The point is that it doesn’t invalidate the fact that regardless of third country jurisdiction, dutch law also applies. From: Gert Doering <gert@space.net> Date: Monday, 3 August 2026 at 2:01 AM To: Serge Droz <serge.droz@first.org> Cc: denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Hi, On Sun, Aug 02, 2026 at 07:11:59PM +0200, Serge Droz via Security-wg wrote:
That's what I meant. It's the juristiocn of the operator, not the customers.
If you provide services to EU customers, jurisdiction of the customers applies as well. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Nick,
On 7/31/2026, at 16:41, Nick Hilliard <nick@foobar.org> wrote:
The issue we have in the RIPE security wg, and before that, abuse-wg and anti-spam-wg, is that the solutions being proposed involves changing the nature of the RIPE NCC from a registry into an quasi-judicial and enforcement body. Essentially the arguments are of the form which could waspily be described as "politicians' logic":
Technically, we crossed this line when we introduced not just the company names, but also their registration numbers into the RIPE Database. NWI-21. -- Sergey
Hi, On Sat, Aug 01, 2026 at 01:45:15AM +0300, Sergey Myasoedov via Security-wg wrote:
On 7/31/2026, at 16:41, Nick Hilliard <nick@foobar.org> wrote:
The issue we have in the RIPE security wg, and before that, abuse-wg and anti-spam-wg, is that the solutions being proposed involves changing the nature of the RIPE NCC from a registry into an quasi-judicial and enforcement body. Essentially the arguments are of the form which could waspily be described as "politicians' logic":
Technically, we crossed this line when we introduced not just the company names, but also their registration numbers into the RIPE Database. NWI-21.
This very much sounds like a thing a registry would do, like, register numbers and document who has them, in an unambiguous way? So which line exactly was crossed by publishing more unambiguous holder info, for legal entities? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Here is what lac ich does: <https://www.lacnic.net/5733/2/lacnic/how-to-validate-your-abuse-contact-to-unblock-access-to-milacnic> It's more than keeping an elaborate list of numbers, and neither they or the world has ended. So, this could be an easy start Then Morecambe added, e.g no action against specific abuse types. (I very much favour a well defined list, even if it will miss edge casses). I think if the argument is, ripe should never do more than run a db, fighting abuse will have to happen elsewhere. I see ripe as a community that endures it stays nice. So start with some simple things: Verify folks reply. Expand to action in specific casses. If we agree on this we can start to work out the mechanics. Best Serge On 1 August 2026 15:45:38 UTC, Gert Doering <gert@space.net> wrote:
Hi,
On Sat, Aug 01, 2026 at 01:45:15AM +0300, Sergey Myasoedov via Security-wg wrote:
On 7/31/2026, at 16:41, Nick Hilliard <nick@foobar.org> wrote:
The issue we have in the RIPE security wg, and before that, abuse-wg and anti-spam-wg, is that the solutions being proposed involves changing the nature of the RIPE NCC from a registry into an quasi-judicial and enforcement body. Essentially the arguments are of the form which could waspily be described as "politicians' logic":
Technically, we crossed this line when we introduced not just the company names, but also their registration numbers into the RIPE Database. NWI-21.
This very much sounds like a thing a registry would do, like, register numbers and document who has them, in an unambiguous way? So which line exactly was crossed by publishing more unambiguous holder info, for legal entities?
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams https://first.org
On 01/08/2026 19:32, Serge Droz via Security-wg wrote:
Here is what lac ich does: <https://www.lacnic.net/5733/2/lacnic/how-to- validate-your-abuse-contact-to-unblock-access-to-milacnic <https:// www.lacnic.net/5733/2/lacnic/how-to-validate-your-abuse-contact-to- unblock-access-to-milacnic>>
It's more than keeping an elaborate list of numbers, and neither they or the world has ended.
+1 - simple, easy solution and already deployed at a RIR. -Hank
It is implemented also in APNIC, and in the way in AFRINIC. As explained a couple of days ago, the point is not to judge (from the RIR perspective), if it is an abuse or not, just to ensure that you accept abuse reporting by email from any source, not forms, and you react to that. If that fails, you can escalate to the RIR, because that is a policy violation. Now, if we want to improve it, as I suggested in my last version of the RIPE proposal, we can enforce XARF or whatever. Regards, Jordi @jordipalet
El 2 ago 2026, a las 7:09, Hank Nussbacher <hank@interall.co.il> escribió:
On 01/08/2026 19:32, Serge Droz via Security-wg wrote:
Here is what lac ich does: <https://www.lacnic.net/5733/2/lacnic/how-to- validate-your-abuse-contact-to-unblock-access-to-milacnic <https:// www.lacnic.net/5733/2/lacnic/how-to-validate-your-abuse-contact-to- unblock-access-to-milacnic>> It's more than keeping an elaborate list of numbers, and neither they or the world has ended.
+1 - simple, easy solution and already deployed at a RIR.
-Hank ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On Sat, 1 Aug 2026 at 18:32, Serge Droz via Security-wg < security-wg@ripe.net> wrote:
Here is what lac ich does: < https://www.lacnic.net/5733/2/lacnic/how-to-validate-your-abuse-contact-to-u...
Unfortunately this doesn't change anything at all. What do you do with the LIR that just does nothing with abuse reports? The ONLY penalty we have right now is closure. If you are not willing to do that then the LIR is untouchable. The NCC has no IPv4 to give out. The LIR may have enough IPv6 to last them years. If not they can buy it on the open market. If the NCC refuses to administer the transfer that doesn't mean it won't happen. It is just not registered. Or they can lease more space and sub assign it to their customers. You can lock their objects in the RIPE Database. Then they just don't update them. As long as the LIR keeps paying it's fees to the NCC there is nothing you can do to them. As things stand there is no accountability, no penalty. It's either full closure or untouchable. We need a rethink and a reset. This is what I am working on.... cheers denis
It's more than keeping an elaborate list of numbers, and neither they or the world has ended.
So, this could be an easy start
Then Morecambe added, e.g no action against specific abuse types. (I very much favour a well defined list, even if it will miss edge casses).
I think if the argument is, ripe should never do more than run a db, fighting abuse will have to happen elsewhere.
I see ripe as a community that endures it stays nice.
So start with some simple things:
Verify folks reply. Expand to action in specific casses.
If we agree on this we can start to work out the mechanics.
Best Serge
On 1 August 2026 15:45:38 UTC, Gert Doering <gert@space.net> wrote:
Hi,
On Sat, Aug 01, 2026 at 01:45:15AM +0300, Sergey Myasoedov via Security-wg wrote:
On 7/31/2026, at 16:41, Nick Hilliard <nick@foobar.org> wrote:
The issue we have in the RIPE security wg, and before that, abuse-wg and anti-spam-wg, is that the solutions being proposed involves changing the nature of the RIPE NCC from a registry into an quasi-judicial and enforcement body. Essentially the arguments are of the form which could waspily be described as "politicians' logic":
Technically, we crossed this line when we introduced not just the company names, but also their registration numbers into the RIPE Database. NWI-21.
This very much sounds like a thing a registry would do, like, register numbers and document who has them, in an unambiguous way? So which line exactly was crossed by publishing more unambiguous holder info, for legal entities?
Gert Doering -- NetMaster
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams https://first.org
To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
On 2 Aug 2026, at 16:51, denis walker <ripedenis@gmail.com> wrote: [..] As things stand there is no accountability, no penalty. It's either full closure or untouchable. We need a rethink and a reset. This is what I am working on....
Reverse DNS is needed to spam properly. IRR / RPKI / ASPA is needed to route (though RPKI/ASPA becomes 'unknown' which is the majority of prefixes today) So yes, if a RIR does not delegate then a prefix becomes a lot less useable. Thus marking a LIR as 'under investigation' or similar and then at non-response closing it can be a means to stop the abuse. But, it becomes really tricky if an LIR is saying one thing and a pile of others are saying another (they did abuse etc) And I do not think RIRs have the resources (unless membership fees go insane) to resolve that. Even if a RIR gives out an 'advise' that the resources are 'tainted' or 'likely abuse' a legal proceeding can cause a whole lot of problems for the RIR. Same for blacklists of course, as the folks from the original MAPS and nowadays Spamhaus and similar setups can attest to, the legal issues are the biggest problem there. (and for some on the wrong side, people claim that the *good* people from Spamhaus do not respond to the delisting requests etc... ) Regards, Jeroen
On Sun, 2 Aug 2026, 22:28 Jeroen Massar, <jeroen@massar.ch> wrote:
On 2 Aug 2026, at 16:51, denis walker <ripedenis@gmail.com> wrote: [..] As things stand there is no accountability, no penalty. It's either full closure or untouchable. We need a rethink and a reset. This is what I am working on....
Reverse DNS is needed to spam properly. IRR / RPKI / ASPA is needed to route (though RPKI/ASPA becomes 'unknown' which is the majority of prefixes today)
So yes, if a RIR does not delegate then a prefix becomes a lot less useable.
Can this be done using a commercial routing registry like RADb?
Thus marking a LIR as 'under investigation' or similar and then at non-response closing it can be a means to stop the abuse.
But we are back to the closure option. As I said, closure or untouchable. If the registry has thousands of legitimate business customers is the RIPE NCC going to close it?
But, it becomes really tricky if an LIR is saying one thing and a pile of others are saying another (they did abuse etc)
And I do not think RIRs have the resources (unless membership fees go insane) to resolve that.
Even if a RIR gives out an 'advise' that the resources are 'tainted' or 'likely abuse' a legal proceeding can cause a whole lot of problems for the RIR.
By the time that advise goes out on a particular set of numbers, they probably aren't connected with the abuser any more. Cheers Denis
Same for blacklists of course, as the folks from the original MAPS and nowadays Spamhaus and similar setups can attest to, the legal issues are the biggest problem there. (and for some on the wrong side, people claim that the *good* people from Spamhaus do not respond to the delisting requests etc... )
Regards, Jeroen
As for the closure option, look at one of the first such, and most prominent such, cases in the ICANN world - Estdomains. Set up as a criminal front. Very high number of criminal domains. It went through ICANN’s entire process and they deregistered it. The few legitimate domains that happened to be on it were transferred to another registrar (Directi) so that service to those would not be disrupted. —srs From: denis walker <ripedenis@gmail.com> Date: Monday, 3 August 2026 at 2:29 AM To: Jeroen Massar <jeroen@massar.ch> Cc: Serge Droz <serge.droz@first.org>; security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms On Sun, 2 Aug 2026, 22:28 Jeroen Massar, <jeroen@massar.ch<mailto:jeroen@massar.ch>> wrote:
On 2 Aug 2026, at 16:51, denis walker <ripedenis@gmail.com<mailto:ripedenis@gmail.com>> wrote: [..] As things stand there is no accountability, no penalty. It's either full closure or untouchable. We need a rethink and a reset. This is what I am working on....
Reverse DNS is needed to spam properly. IRR / RPKI / ASPA is needed to route (though RPKI/ASPA becomes 'unknown' which is the majority of prefixes today) So yes, if a RIR does not delegate then a prefix becomes a lot less useable. Can this be done using a commercial routing registry like RADb? Thus marking a LIR as 'under investigation' or similar and then at non-response closing it can be a means to stop the abuse. But we are back to the closure option. As I said, closure or untouchable. If the registry has thousands of legitimate business customers is the RIPE NCC going to close it? But, it becomes really tricky if an LIR is saying one thing and a pile of others are saying another (they did abuse etc) And I do not think RIRs have the resources (unless membership fees go insane) to resolve that. Even if a RIR gives out an 'advise' that the resources are 'tainted' or 'likely abuse' a legal proceeding can cause a whole lot of problems for the RIR. By the time that advise goes out on a particular set of numbers, they probably aren't connected with the abuser any more. Cheers Denis Same for blacklists of course, as the folks from the original MAPS and nowadays Spamhaus and similar setups can attest to, the legal issues are the biggest problem there. (and for some on the wrong side, people claim that the *good* people from Spamhaus do not respond to the delisting requests etc... ) Regards, Jeroen
So here is what I propose. I'm not a lawyer, so maybe this needs to be phrased differently. But the idea is a: Make sure poeple read their abuse e-mails b: Possibly, take further acction if they read it bud don't act. a: Abuse mailbox tests: The RIPE NCC cunducts bi-annual communications checks to the abuse handles. It is expected that these are replied to within [X hours/days/...] If no replies is received this will be escalated through other contacts. If no reply is received on may as well assume the org no longer exists and take appropriate action. LACNIC blocks access. b: Complaints about missing action RIPE NCC solicitations feedback about failure to take action. This feedback should only be admissible for specific abuses, I would start small (spam, maybe residential proxies, but that's already hard). If there are n (1, 2, ...) complains the RIPE NCC will send a warning to the violating organisation. Here we have to talk about sanctions and time lines. If push comes to shove I suggest arbitration under Dutch jurisdiction. This is assuming: Most people that don't react will react if there is just a slight incentive to do so. This is the experience I had from abuse fighting here in Switzerland. There is much to be discussed, and that's the discussion I'd like to see. 1. Can we make these ideas clerere? Timelines? Should we start with a and later follow up with b. I specifically ask for constructive ideas. If they tunr out not to be feasible, we have tried. Best Serge On 03/08/2026 02:47, Suresh Ramasubramanian wrote:
As for the closure option, look at one of the first such, and most prominent such, cases in the ICANN world - Estdomains.
Set up as a criminal front. Very high number of criminal domains. It went through ICANN’s entire process and they deregistered it. The few legitimate domains that happened to be on it were transferred to another registrar (Directi) so that service to those would not be disrupted.
—srs
*From: *denis walker <ripedenis@gmail.com> *Date: *Monday, 3 August 2026 at 2:29 AM *To: *Jeroen Massar <jeroen@massar.ch> *Cc: *Serge Droz <serge.droz@first.org>; security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> *Subject: *[Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On Sun, 2 Aug 2026, 22:28 Jeroen Massar, <jeroen@massar.ch> wrote:
> On 2 Aug 2026, at 16:51, denis walker <ripedenis@gmail.com> wrote: > [..] > As things stand there is no accountability, no penalty. It's either full closure or untouchable. We need a rethink and a reset. This is what I am working on....
Reverse DNS is needed to spam properly. IRR / RPKI / ASPA is needed to route (though RPKI/ASPA becomes 'unknown' which is the majority of prefixes today)
So yes, if a RIR does not delegate then a prefix becomes a lot less useable.
Can this be done using a commercial routing registry like RADb?
Thus marking a LIR as 'under investigation' or similar and then at non-response closing it can be a means to stop the abuse.
But we are back to the closure option. As I said, closure or untouchable. If the registry has thousands of legitimate business customers is the RIPE NCC going to close it?
But, it becomes really tricky if an LIR is saying one thing and a pile of others are saying another (they did abuse etc)
And I do not think RIRs have the resources (unless membership fees go insane) to resolve that.
Even if a RIR gives out an 'advise' that the resources are 'tainted' or 'likely abuse' a legal proceeding can cause a whole lot of problems for the RIR.
By the time that advise goes out on a particular set of numbers, they probably aren't connected with the abuser any more.
Cheers Denis
Same for blacklists of course, as the folks from the original MAPS and nowadays Spamhaus and similar setups can attest to, the legal issues are the biggest problem there. (and for some on the wrong side, people claim that the *good* people from Spamhaus do not respond to the delisting requests etc... )
Regards, Jeroen
On 3 Aug 2026, at 13:33, Serge Droz <serge.droz@first.org> wrote: [..] b: Complaints about missing action RIPE NCC solicitations feedback about failure to take action. This feedback should only be admissible for specific abuses, I would start small (spam, maybe residential proxies, but that's already hard). If there are n (1, 2, ...) complains the RIPE NCC will send a warning to the violating organisation.
TLDR: - Abuse mailbox response is meaningless if the customer gets recycled to another host - Blacklists make the ASN / address space useless as not more abuse can happen - ISPs that care will try to get themselves off blacklists - What is the problem to solve with 'reports'? - IMHO abuse-mailbox should be volunantary for those that want to take action, everybody else should be able to publish a 'do-not-care-won't-handle' as then folks know what the network is about. A response means very very little. Please note that there are a variety of 'enablers' that will happily answer all your abuse reports. Some will acknowledge the report back to the report and directly forward the full email to the one who is using the IP addresses in question. Some will "shutdown" that "customer". The 'customer' will then create a new account, re-setup resources on a different IP and continue doing what it did before. Then the bigger fun: setup a whole bunch of companies, all entered in the trade register, paper work legit, all separate entities, heck, have random people act as CEO. One of these entities are then used for the LIR, one for one or more transit AS, some for datacenters/rack colocation and some others become customers of these other entities. Voila: keep rotating a few of these elements. The reports are handled, customers are shutdown (they can even show the config changes, the billing etc) But all the reporting will not do anything as it will take time, effort (mostly on the side of the reporters and the RIRs) and then possibly some legal challenges in the mix to make it all even nastier. And then the other fun: - Spam sources, can be because of compromised hosts, and given Wordpress that is easy; next to thousands of others of software with issues (and throw LLM analysis in the mix and ... fun) - Residential Proxies tend to be enabled not by the customer, but by a gadget they buy and plug into their networks. And that is just two parts of the equation. Hence the big question is more: - what is the exact type of problem you want to solve, and how much time do you have. Noting: I have a long time given up on abuse reporting a long time ago (unless I know the entity will act). Hence shutting down, and trying KYC style helps a wee bit. But as noted, easy to setup new companies as RIPE NCC is well aware of with the many international/out-of-RIR-area customers they get with often rather shady setups. But due to the rules they accept them anyway. I've seen hundreds of megabit flow for weeks, many millions of requests just coming in and going; reporting them does often not matter, as even if the provider shuts them down, the 'customer' will pop up in a new place. Provider takes money, service for a bit, shutdown, repeat.... For some ISPs it is even 'good' to have that kind of traffic, as then they might rebalance their network to be more equal in inbound/outbound traffic flow which means they can get cheaper/better transit.... Hence why many resort simply to blacklists, or even some cases whitelists. Blacklists act quicker and causes a ASN / Prefix to end up blocked. Does not matter if they rotate their 'customers' the resource becomes useless: and that costs them money. Of course the fun with "cloud" and "hyperscalers" is that they have so many swaths of address space that they become unblockable, especially when the address space gets shared by many other inhabitants. One sees that also with gmail/outlook/SES where much of the spam comes from: many customers, thus 1% spam is suddenly a lot. Regards, Jeroen
If a space is in an email oriented blocklist like say Spamhaus, it just gets used for some other kind of abuse .. DDoS C2, account farming, host illegal content and so on. Or if spam, then spam through some messaging or social media platform rather than through email. From: Jeroen Massar <jeroen@massar.ch> Date: Monday, 3 August 2026 at 5:21 PM To: Serge Droz <serge.droz@first.org> Cc: Suresh Ramasubramanian <ops.lists@gmail.com>; denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> Subject: Re: [Security-wg] Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On 3 Aug 2026, at 13:33, Serge Droz <serge.droz@first.org> wrote: [..] b: Complaints about missing action RIPE NCC solicitations feedback about failure to take action. This feedback should only be admissible for specific abuses, I would start small (spam, maybe residential proxies, but that's already hard). If there are n (1, 2, ...) complains the RIPE NCC will send a warning to the violating organisation.
TLDR: - Abuse mailbox response is meaningless if the customer gets recycled to another host - Blacklists make the ASN / address space useless as not more abuse can happen - ISPs that care will try to get themselves off blacklists - What is the problem to solve with 'reports'? - IMHO abuse-mailbox should be volunantary for those that want to take action, everybody else should be able to publish a 'do-not-care-won't-handle' as then folks know what the network is about. A response means very very little. Please note that there are a variety of 'enablers' that will happily answer all your abuse reports. Some will acknowledge the report back to the report and directly forward the full email to the one who is using the IP addresses in question. Some will "shutdown" that "customer". The 'customer' will then create a new account, re-setup resources on a different IP and continue doing what it did before. Then the bigger fun: setup a whole bunch of companies, all entered in the trade register, paper work legit, all separate entities, heck, have random people act as CEO. One of these entities are then used for the LIR, one for one or more transit AS, some for datacenters/rack colocation and some others become customers of these other entities. Voila: keep rotating a few of these elements. The reports are handled, customers are shutdown (they can even show the config changes, the billing etc) But all the reporting will not do anything as it will take time, effort (mostly on the side of the reporters and the RIRs) and then possibly some legal challenges in the mix to make it all even nastier. And then the other fun: - Spam sources, can be because of compromised hosts, and given Wordpress that is easy; next to thousands of others of software with issues (and throw LLM analysis in the mix and ... fun) - Residential Proxies tend to be enabled not by the customer, but by a gadget they buy and plug into their networks. And that is just two parts of the equation. Hence the big question is more: - what is the exact type of problem you want to solve, and how much time do you have. Noting: I have a long time given up on abuse reporting a long time ago (unless I know the entity will act). Hence shutting down, and trying KYC style helps a wee bit. But as noted, easy to setup new companies as RIPE NCC is well aware of with the many international/out-of-RIR-area customers they get with often rather shady setups. But due to the rules they accept them anyway. I've seen hundreds of megabit flow for weeks, many millions of requests just coming in and going; reporting them does often not matter, as even if the provider shuts them down, the 'customer' will pop up in a new place. Provider takes money, service for a bit, shutdown, repeat.... For some ISPs it is even 'good' to have that kind of traffic, as then they might rebalance their network to be more equal in inbound/outbound traffic flow which means they can get cheaper/better transit.... Hence why many resort simply to blacklists, or even some cases whitelists. Blacklists act quicker and causes a ASN / Prefix to end up blocked. Does not matter if they rotate their 'customers' the resource becomes useless: and that costs them money. Of course the fun with "cloud" and "hyperscalers" is that they have so many swaths of address space that they become unblockable, especially when the address space gets shared by many other inhabitants. One sees that also with gmail/outlook/SES where much of the spam comes from: many customers, thus 1% spam is suddenly a lot. Regards, Jeroen
On 3 Aug 2026, at 13:54, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
If a space is in an email oriented blocklist like say Spamhaus, it just gets used for some other kind of abuse .. DDoS C2, account farming, host illegal content and so on. Or if spam, then spam through some messaging or social media platform rather than through email.
Yep, that is why Spamhaus DROP exists: https://www.spamhaus.org/blocklists/do-not-route-or-peer/ (btw, as per the text there, do migrate to the JSON editions!) Which is a very rough hammer. As updates to entries are infrequent, one really has to be a bad seed to be listed there. I can recommend fetching the JSONs, making a delta with the previous version one has, and then adding a approve/deny option to your NOC interface of choice so that a live person reviews "who is that entity, why are they considered so bad" and then approves new listings. Though running blind by trusting Spamhaus is fine too of course ;) Maybe one thing in this field is to have, like adblockers, more such lists that are trusted, be that from the various NOGs or other groups. Spamhaus are great at what they do, but alternatives (that do have the legal protections needed for these kind of lists) would be a good thing. And in such a situation, merge those lists, rate&rank yourself how evil one considers those entities and... drop. Do note any other such good entities for consideration if one knows any solid ones. Regards, Jeroen
Rather than hand IP space out to bad actors like candy with minimal to no verification and then have no alternative but to null route it locally, use DROP or whatever, it’d be so much better if the allocation was not made at all by the “not the internet police”. Right now a common argument is “IPv4 is done with, IPv6 has so much space, even if bad actors corner large chunks of it, there’s still unlimited space left”. We will probably, with 20/20 hindsight, realize that this argument will go the way of that apocryphal Bill Gates quote about 640k should be enough for anybody. —srs From: Jeroen Massar <jeroen@massar.ch> Date: Monday, 3 August 2026 at 6:33 PM To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Serge Droz <serge.droz@first.org>; denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> Subject: Re: [Security-wg] Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On 3 Aug 2026, at 13:54, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
If a space is in an email oriented blocklist like say Spamhaus, it just gets used for some other kind of abuse .. DDoS C2, account farming, host illegal content and so on. Or if spam, then spam through some messaging or social media platform rather than through email.
Yep, that is why Spamhaus DROP exists: https://www.spamhaus.org/blocklists/do-not-route-or-peer/ (btw, as per the text there, do migrate to the JSON editions!) Which is a very rough hammer. As updates to entries are infrequent, one really has to be a bad seed to be listed there. I can recommend fetching the JSONs, making a delta with the previous version one has, and then adding a approve/deny option to your NOC interface of choice so that a live person reviews "who is that entity, why are they considered so bad" and then approves new listings. Though running blind by trusting Spamhaus is fine too of course ;) Maybe one thing in this field is to have, like adblockers, more such lists that are trusted, be that from the various NOGs or other groups. Spamhaus are great at what they do, but alternatives (that do have the legal protections needed for these kind of lists) would be a good thing. And in such a situation, merge those lists, rate&rank yourself how evil one considers those entities and... drop. Do note any other such good entities for consideration if one knows any solid ones. Regards, Jeroen
On 3 Aug 2026, at 15:10, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
Rather than hand IP space out to bad actors like candy with minimal to no verification and then have no alternative but to null route it locally, use DROP or whatever, it’d be so much better if the allocation was not made at all by the “not the internet police”.
Full agree, that would definitely be a great goal, if that could be achieved. But checking many LIR details with fun addresses in Panama or the Seychelles and other such constructs but claiming to then operate elsewhere, and being uncontactable.... well, apparently answering to the RIR but the bad stuff keeps on flowing... let alone WHOIS entry details being pertinently false... And then, with the current situation around the world, there are countries where it might be hard to actually do a legit business setup, if one wanted to start out. Thus yes, maybe "LIR scoring" might be an approach that is needed. But abuse reports go to /dev/zero with most large corporations/hyperscalers/clouds for whom spam is a <1% of their traffic thing and where DDoS does not get noticed as it is only a tiny bit of their total volume. As such, abuse reports is not likely to scale in making such a rating happen. And as noted, setting up a new LIR with a new company is very easy depending on the locality that it happens, and often completely anonymous and more importantly, not verifable by a RIR (and noting RIR, not just RIPE NCC, as it is a global issue and RIPE NCC gets LIR requests from "companies" in the countries above for instance...). The concept of RIR though was to make it easier to verify per region, as they should have proper contacts with authorities and to And no, NIR does not work either, as we can see with Indonesia where their RPKI systems are effectively offline and who as a NIR are effectively unreachable too. And letting APNIC cut off a whole country is also something, when in that case the ISPs are only harmed by non-service). Or heck, AFRINIC with their problems... The question is then of course 'who gets to claim a LIR/ISP/country/etc' is bad. Especially as that is regarding international laws, and international situations. The Internet is supposed to be open and welcoming to new players (who already lose out with IPv4 availability). More rules/verifications will restrict bad folks getting new footing, but if properly funded (and as long as they make money they will be) will find a way. New smaller entrants who want to do something 'good' (definition depends on which side one is on... are the almost not-existing Sith gone because others wiped them out?)
Right now a common argument is “IPv4 is done with, IPv6 has so much space, even if bad actors corner large chunks of it, there’s still unlimited space left”.
We will probably, with 20/20 hindsight, realize that this argument will go the way of that apocryphal Bill Gates quote about 640k should be enough for anybody.
2000::/3 will then be considered 'rotten'. Somebody will use one of the other /3s to start allocating from. That was also the argument for "we can give everybody a /32" which is now turning into "you get a /29 and you get a /29" ..... But there are indeed quite a few of those to burn through, the block lists just might get very very long. Fortunately we are routing 128-bits space in /48 chunks with 32-bits numbers thus there is kinda a limit. Regards, Jeroen (and noting all this to Suresh of all who has been on the battlefield of all this for longer than most have had internet access in the first place....)
On 3 Aug 2026, at 14:10, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
Rather than hand IP space out to bad actors like candy with minimal to no verification
You imply that it is possible tell ahead of time whether a new company is well intentioned or not. In my view, trying to turn the RIPE NCC into some kind of fortune teller with an associated address registry is unlikely to end well. Regards, Leo
Banks, corporations, corner grocery stores, the guy walking down a street who gets approached for a loan from someone who claims his wallet was stolen and he needs a few euros for a meal and petrol to get home .. everyone is a fortune teller of sorts, and some of them invest quite a lot in fraud / trust and safety teams, AIML and so on. Why should RIPE NCC be any different? --srs ________________________________ From: Leo Vegoda <leo@vegoda.org> Sent: Monday, 03 August 2026 20:31:38 To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Jeroen Massar <jeroen@massar.ch>; Serge Droz <serge.droz@first.org>; denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> Subject: Re: [Security-wg] Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms On 3 Aug 2026, at 14:10, Suresh Ramasubramanian <ops.lists@gmail.com> wrote: Rather than hand IP space out to bad actors like candy with minimal to no verification You imply that it is possible tell ahead of time whether a new company is well intentioned or not. In my view, trying to turn the RIPE NCC into some kind of fortune teller with an associated address registry is unlikely to end well. Regards, Leo
RIPE NCC does a lot of due diligence on new members. You’re making it sound like they don’t. -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072<tel:+353599183072> Direct Dial: +353 (0)59 9183090<tel:+353599183090> Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: Suresh Ramasubramanian <ops.lists@gmail.com> Date: Monday, 3 August 2026 at 17:24 To: Leo Vegoda <leo@vegoda.org> Cc: Jeroen Massar <jeroen@massar.ch>; Serge Droz <serge.droz@first.org>; denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. Banks, corporations, corner grocery stores, the guy walking down a street who gets approached for a loan from someone who claims his wallet was stolen and he needs a few euros for a meal and petrol to get home .. everyone is a fortune teller of sorts, and some of them invest quite a lot in fraud / trust and safety teams, AIML and so on. Why should RIPE NCC be any different? --sr
Suresh, On 3 Aug 2026, at 16:24, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
Banks, corporations, corner grocery stores, the guy walking down a street who gets approached for a loan from someone who claims his wallet was stolen and he needs a few euros for a meal and petrol to get home .. everyone is a fortune teller of sorts, and some of them invest quite a lot in fraud / trust and safety teams, AIML and so on.
Why should RIPE NCC be any different?
The key difference is that the RIPE NCC is a natural monopoly. They are similar to a utility provider. They have a published due diligence process with steps before and after getting resources. They have training courses for those that want them. What they can’t do is pretend that they are the police or a court. Regards, Leo
Of course there is, but of course there is also a certain level of misuse. It may well be argued that the due diligence process needs work, including from people whose speciality is fraud mitigation, if there is a reluctance to vet beyond a limit. --srs ________________________________ From: Leo Vegoda <leo@vegoda.org> Sent: Monday, 03 August 2026 21:57:03 To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Jeroen Massar <jeroen@massar.ch>; Serge Droz <serge.droz@first.org>; denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> Subject: Re: [Security-wg] Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Suresh, On 3 Aug 2026, at 16:24, Suresh Ramasubramanian <ops.lists@gmail.com> wrote: Banks, corporations, corner grocery stores, the guy walking down a street who gets approached for a loan from someone who claims his wallet was stolen and he needs a few euros for a meal and petrol to get home .. everyone is a fortune teller of sorts, and some of them invest quite a lot in fraud / trust and safety teams, AIML and so on. Why should RIPE NCC be any different? The key difference is that the RIPE NCC is a natural monopoly. They are similar to a utility provider. They have a published due diligence process with steps before and after getting resources. They have training courses for those that want them. What they can’t do is pretend that they are the police or a court. Regards, Leo
Hi, On Mon, Aug 03, 2026 at 01:10:25PM +0000, Suresh Ramasubramanian wrote:
Right now a common argument is ???IPv4 is done with, IPv6 has so much space, even if bad actors corner large chunks of it, there???s still unlimited space left???.
We will probably, with 20/20 hindsight, realize that this argument will go the way of that apocryphal Bill Gates quote about 640k should be enough for anybody.
We can do math. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
You can do math at current and/or projected usage levels. I doubt future usage levels are going to be as easily estimated. --srs ________________________________ From: Gert Doering <gert@space.net> Sent: Monday, August 3, 2026 9:02 PM To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Jeroen Massar <jeroen@massar.ch>; Serge Droz <serge.droz@first.org>; denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> Subject: Re: [Security-wg] Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Hi, On Mon, Aug 03, 2026 at 01:10:25PM +0000, Suresh Ramasubramanian wrote:
Right now a common argument is ???IPv4 is done with, IPv6 has so much space, even if bad actors corner large chunks of it, there???s still unlimited space left???.
We will probably, with 20/20 hindsight, realize that this argument will go the way of that apocryphal Bill Gates quote about 640k should be enough for anybody.
We can do math. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On Mon, Aug 03, 2026 at 04:34:15PM +0000, Suresh Ramasubramanian wrote:
You can do math at current and/or projected usage levels. I doubt future usage levels are going to be as easily estimated.
Sure. But still there is no evidence of any sort to back your claim that IPv6 will run out because we give chunks of it to bad actors. (When discussing the APWG proposal "shall we give every LIR a /28", I did a bit of math on the "would it create a noticeable shortage, even if the number of LIRs grow by x100", and the answer still is "no") Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 3 Aug 2026, at 17:34, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
You can do math at current and/or projected usage levels. I doubt future usage levels are going to be as easily estimated. \
If each RIR got a new /12 every year it would take a century to fill up the current /3. And there are other /3s. Allocating that much address space would require a lot of extra people even with some excellent automation. Regards, Leo
I rather suspect we will have this conversation again in another oh .. five or six years and let’s then see. --srs ________________________________ From: Leo Vegoda <leo@vegoda.org> Sent: Monday, 03 August 2026 22:11:44 To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: Gert Doering <gert@space.net>; Jeroen Massar <jeroen@massar.ch>; Serge Droz <serge.droz@first.org>; denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net> Subject: Re: [Security-wg] Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms On 3 Aug 2026, at 17:34, Suresh Ramasubramanian <ops.lists@gmail.com> wrote: You can do math at current and/or projected usage levels. I doubt future usage levels are going to be as easily estimated. \ If each RIR got a new /12 every year it would take a century to fill up the current /3. And there are other /3s. Allocating that much address space would require a lot of extra people even with some excellent automation. Regards, Leo
Hi, On Mon, Aug 03, 2026 at 04:55:12PM +0000, Suresh Ramasubramanian wrote:
I rather suspect we will have this conversation again in another oh .. five or six years and let?s then see.
Leo's math is hard to argue with. It's maths for people that do not grok "big numbers" but can understand "100 years"... (and we're using way *less* than "a /12 per RIR per year" right now). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Yes but the conditions at which you calculated IP allocation are set to change if AI comes into the picture for provisioning instances, and IoT catches on more than it already has, to name just a couple of use cases. And who knows if there’s going to be internet in space to the extent that space aliens will be at some future netops or governance conference? Yes you have done the math and yes v6 exhaustion looks impossible at this time, but that is what people thought about V4 to the extent that classful allocations were a thing, “MIT has more IPs than China” was a persistent sort of meme long after it became invalid and so on. On 03/08/26, 10:47 PM, "Gert Doering" <gert@space.net> wrote: Hi, On Mon, Aug 03, 2026 at 04:55:12PM +0000, Suresh Ramasubramanian wrote:
I rather suspect we will have this conversation again in another oh .. five or six years and let?s then see.
Leo's math is hard to argue with. It's maths for people that do not grok "big numbers" but can understand "100 years"... (and we're using way *less* than "a /12 per RIR per year" right now). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On Tue, Aug 04, 2026 at 01:27:36AM +0000, Suresh Ramasubramanian wrote:
Yes but the conditions at which you calculated IP allocation are set to change if AI comes into the picture for provisioning instances, and IoT catches on more than it already has, to name just a couple of use cases.
400 zillion IoT devices in a single /64 will still be "just a single /64", and will not affect allocation rate in any way, given that every household can have a /56 today, or /48. But that is totally irrelevant - you keep claiming that the way the NCC is "allocationg space to spammers" would exhaust the IPv6 space, and we tell you "no, here, math". Then you bring up something totally different - unrelated to abuse, spammers, etc. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Right now that is the case. How are we to know whether a use case develops somewhere down the road that requires individual allocations rather than netted through someone’s home network? Nobody in the ARPANET days could have predicted the scale to which things would reach even within their lifetimes. We should avoid repeating the same mistakes. That “math is on our side” is a somewhat dangerous assumption. Never mind. Like I said we’ll all be better off discussing this with the benefit of full 20/20 hindsight. Meanwhile it is detracting from the main thrust of this discussion, that allocating these ranges to bad actors is something RIPE NCC should be actively working to prevent. Doing precisely this, handing out /15s at a time that ended up in Spamhaus type blocklists, was a major contributor to the early exhaustion of IPv4, as it is. —srs On 04/08/26, 11:06 AM, "Gert Doering" <gert@space.net> wrote: Hi, On Tue, Aug 04, 2026 at 01:27:36AM +0000, Suresh Ramasubramanian wrote:
Yes but the conditions at which you calculated IP allocation are set to change if AI comes into the picture for provisioning instances, and IoT catches on more than it already has, to name just a couple of use cases.
400 zillion IoT devices in a single /64 will still be "just a single /64", and will not affect allocation rate in any way, given that every household can have a /56 today, or /48. But that is totally irrelevant - you keep claiming that the way the NCC is "allocationg space to spammers" would exhaust the IPv6 space, and we tell you "no, here, math". Then you bring up something totally different - unrelated to abuse, spammers, etc. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
As someone new to the list I can naturally take the village idiot role, without the burden of considering the outcomes of past discussions :-) On 3. Aug 2026, at 14.33, Serge Droz via Security-wg <security-wg@ripe.net <mailto:security-wg@ripe.net>> wrote:
So here is what I propose. I'm not a lawyer, so maybe this needs to be phrased differently. But the idea is
a: Make sure poeple read their abuse e-mails
b: Possibly, take further acction if they read it bud don't act.
a: Abuse mailbox tests:
The RIPE NCC cunducts bi-annual communications checks to the abuse handles. It is expected that these are replied to within [X hours/days/...]
If no replies is received this will be escalated through other contacts.
If no reply is received on may as well assume the org no longer exists and take appropriate action. LACNIC blocks access.
b: Complaints about missing action
It very much sounds like the b) part of this proposal is where the objections come from, so would it be helpful to just focus on the a) part? One parallel I’d like to draw is RPKI, where the RIRs have put in place infrastructure to detect unauthorized route advertisements, but don’t really mandate specific action operators should take with them. Rather it’s just information the operators’ own policies can consider. To me this reads like a) can be implemented essentially the same way. Checks are added to enforce the already existing requirement of a valid abuse contact; results of those checks are published in the database. This creates compliance pressure without any specific threats of further action. Not processing abuse emails results in a signal that third parties are free to interpret in a way that might be harmful towards the reputation and thus value of the number resources that refer to that specific abuse-c. And I think crucially, this does not require a RIPE policy to argue what the signal means (like some sort of LIR score would), it’s just there for anyone to interpret as they wish. Of course, the counterargument is the one Jeroen just made, that just responding to emails is not worth much. Sure. But a setup like this would at least help folks keep their abuse-c working, and I’m sure there are tons of cases where they’re inoperable not because of malice, but because nobody thought to make sure they worked. Marko
On 3 Aug 2026, at 15:42, Marko Karppinen via Security-wg <security-wg@ripe.net> wrote:
As someone new to the list I can naturally take the village idiot role, without the burden of considering the outcomes of past discussions :-)
IMHO the ship of abuse reporting simply has completely sailed. Some years ago one could still report and action would be taken, now that will happen if you know the people directly and otherwise even with an intro it often just gets ignored (many people are also to busy with too many fires though). And as the subject of this thread is: - Abuse mailboxes are increasingly no longer monitored - are being replaced by (bad) forms I think we just need to accept that One way would be a 'good netizen' marking by giving LIRs with a 'functional abuse/report handling and. Noting that it is not only about abuse, sometimes there is a MTU issue, or packet lo, that one would love to see fixed and that will help both parties. Or simply peering. Contacts are hard, especially if they go against business interests. [..]
Of course, the counterargument is the one Jeroen just made, that just responding to emails is not worth much. Sure. But a setup like this would at least help folks keep their abuse-c working, and I’m sure there are tons of cases where they’re inoperable not because of malice, but because nobody thought to make sure they worked.
Lots of abuse mailboxes work fine, there might even be people checking that mail is arriving from something 'important' (eg a RIR) and respond to that. But most of it is /dev/null, especially if ones "business" is facilitating the things that are complained about. There are many examples that can be found simply on: https://krebsonsecurity.com <https://krebsonsecurity.com/> the latter not being really monitored either.... Fortunately as Brian's articles shows, some operations are annoying enough for large companies to go after them with their vast legal respresentation, many are not though, and many get recycled under different names. Regards, Jeroen
On the flip side of things - and speaking in absolutely general terms rather than specific facts or figures from any particular provider 1. An abuse mailbox of long standing will receive enough direct spam that 99.99% of its traffic is spam rather than complaints 2. Provider feedback loops from report spam clicks account for the lions share of actual spam complaints; in a machine parseable format and at scale. 3. A lot of the complaints that do come in are either misdirected, incomplete or both (and that is not counting the cranks aggrieved about alien mind control rays and/or secret government experiments that somehow involve an internet connection) Given all these, the usual best practice that seems to be evolving is to prefer a web form but also accept and process emailed abuse reports on a best effort basis. Though more than one provider probably stops short at just the web form --srs ________________________________ From: Jeroen Massar via Security-wg <security-wg@ripe.net> Sent: Monday, 03 August 2026 19:26:55 To: Marko Karppinen <marko@karppinen.fi> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On 3 Aug 2026, at 15:42, Marko Karppinen via Security-wg <security-wg@ripe.net> wrote:
As someone new to the list I can naturally take the village idiot role, without the burden of considering the outcomes of past discussions :-)
IMHO the ship of abuse reporting simply has completely sailed. Some years ago one could still report and action would be taken, now that will happen if you know the people directly and otherwise even with an intro it often just gets ignored (many people are also to busy with too many fires though). And as the subject of this thread is: - Abuse mailboxes are increasingly no longer monitored - are being replaced by (bad) forms I think we just need to accept that One way would be a 'good netizen' marking by giving LIRs with a 'functional abuse/report handling and. Noting that it is not only about abuse, sometimes there is a MTU issue, or packet lo, that one would love to see fixed and that will help both parties. Or simply peering. Contacts are hard, especially if they go against business interests. [..]
Of course, the counterargument is the one Jeroen just made, that just responding to emails is not worth much. Sure. But a setup like this would at least help folks keep their abuse-c working, and I’m sure there are tons of cases where they’re inoperable not because of malice, but because nobody thought to make sure they worked.
Lots of abuse mailboxes work fine, there might even be people checking that mail is arriving from something 'important' (eg a RIR) and respond to that. But most of it is /dev/null, especially if ones "business" is facilitating the things that are complained about. There are many examples that can be found simply on: https://krebsonsecurity.com <https://krebsonsecurity.com/> the latter not being really monitored either.... Fortunately as Brian's articles shows, some operations are annoying enough for large companies to go after them with their vast legal respresentation, many are not though, and many get recycled under different names. Regards, Jeroen ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
On 03/08/2026 16:56, Jeroen Massar via Security-wg wrote:
IMHO the ship of abuse reporting simply has completely sailed. Some years ago one could still report and action would be taken, now that will happen if you know the people directly and otherwise even with an intro it often just gets ignored (many people are also to busy with too many fires though).
And as the subject of this thread is: - Abuse mailboxes are increasingly no longer monitored - are being replaced by (bad) forms
I think we just need to accept that All that is missing now is an xkcd cartoon.
-Hank
On 4 Aug 2026, at 06:22, Hank Nussbacher <hank@interall.co.il> wrote:
On 03/08/2026 16:56, Jeroen Massar via Security-wg wrote:
IMHO the ship of abuse reporting simply has completely sailed. Some years ago one could still report and action would be taken, now that will happen if you know the people directly and otherwise even with an intro it often just gets ignored (many people are also to busy with too many fires though). And as the subject of this thread is: - Abuse mailboxes are increasingly no longer monitored - are being replaced by (bad) forms I think we just need to accept that All that is missing now is an xkcd cartoon.
:) -- briefly checked, no existing one there... yet. Thus maybe better would be a little write-up with some new ideas and self-counter points to exclude those already :) TLDR: - ISPs need to work together to resolve this - RIRs could verify LIR details better (but hard problem with the state of the world) # A) Bad-actors getting new resources Bad-actors can easily create a 'company' anywhere around the world, even outside of the RIRs service area, with valid paperwork and apply to become a LIR and request resources (be that ASN, IPv4 or IPv6) and use those. Their claim is "we are a company in Panama, we'll use the prefix in Netherlands", and they might even have hardware in a colocation to back that up. RIR cannot check if the person behind the anonymous corporation is the same or a fake person, as identities can be stolen, officials bribed etc. Thus for them finding out if the same actors are behind it, a bad actor will find a way. # B) Reporting Abuse only works when the LIR/ISP wants to really be a good netizen While telling a RIR "this LIR does not handle abuse" is an option, the RIR currently has no mandate to do much with it. And even then, lets say there is a mandate to close, the bad actor will go to A # C) Whitelists / Trusted ISPs Instead of blacklists and marking all the bad networks, one could make a list of GOOD networks, as that scoring does not change too often. Networks (ASN / LIR level) one knows that do report to abuse handling and are good netizens (and yes, bad apples can slip in over time, companies get bought out, thus one need to account for that). The ideal version would be multiple separate entities keeping a "good ASN / LIR" list. An ISP can then consume those lists and go 'two out of three trust that ASN" and now at least know that abuse reports get handled. New entrants, would need to find a way to get on it. The legal complications that might be associated with such a list for "you did not put me in the whitelist" are fun, at least the model of multiple and scoring based on that would help with redundancy. In the end though, as history has shown, either there will be one working list, list will be commercialized, or run by the same people in the backend ;) Anything not on the whitelist is something one can then ratelimit in pps or requests/sec etc. Will it give something worthwhile.... a split in the Internet if implemented (and we are going there already with hyperscalers being the center and the ones that decides things), not sure it can even work out. Trust networks tend to only work in smaller scales where people still now eachother, the Internet is rather large. We have one semi-known 'good list' btw: MANRS... https://manrs.org <https://manrs.org/> but how many ISPs actively properly implement it? At least for routing that covers it, does not cover abuse (spam/ddos/etc). # D) Misconfigurations happen and persist Bad-actors and misconfigurations can ask for transit from an ISP, who happily announces it: https://www.cidr-report.org/#Bogons We know that these prefixes are not supposed to be there (unallocated space, thus no RIR involvement) but as long as transits pass them on without consequence... does it matter? And that discounts option C: there will be good ISPs having misconfigs and not acting to remove clearly obviously fully backed unallocated blocks. Go through the above list, and the IPv6 one, and check the prefixes. You will find transit ASNs that you know and love, and who do not do their due diligence, but would end up on any 'good'' list. AS421005xxx being in that list is a good example of this. ISPs that do not want to see these can implement unallocated checks (but long list and resource heavy to verify that it is okay to route that prefix). It would be so much better done at the edge of networks who accept these prefixes. Or they can at least verify with RPKI ROV or ASPA checks that those are permitted prefixes. both need ISPs to change something to make their Internet better. And not everything on the Internet has a ROA let alone ASPA. And one needs BGPsec at one point too to make it a full solution. So above a few ideas, but also their counter arguments. As long as there is no accountability for an ISP to pass on unallocated space/ASN as the simplest example little will change with the offenders of spam, ddos etc, as there are easier low hanging fruits that are not addressed either. And yes, effectively, that would require an internet police to resolve, and with international law, that will not easily happen, till some large enough government just puts their foot down... Those unallocated spaces are inexcusable, but now go find an ARF format where that complaint fits in while every ISP worth their salt has seen the CIDR Report for many many years already. Regards, Jeroen
I think we are dealing with two different problems here: 1. Orgs that just are opportunistic, i.e. they ignore abuse complaints because it's cheaper and there is no penalty for ignoring complaints. These you can catch by the LACNIC approach I mailed earlier The second case is orgs whose business case rests on abuse, likely intentionally. There the LACNIC approach might have an impact, in that it increases costs for the orgs, but probably not much. I assume that the second case would require some different action. I don't think we should mix them up too much. Best Serge On 04/08/2026 09:47, Jeroen Massar via Security-wg wrote:
On 4 Aug 2026, at 06:22, Hank Nussbacher <hank@interall.co.il> wrote:
On 03/08/2026 16:56, Jeroen Massar via Security-wg wrote:
IMHO the ship of abuse reporting simply has completely sailed. Some years ago one could still report and action would be taken, now that will happen if you know the people directly and otherwise even with an intro it often just gets ignored (many people are also to busy with too many fires though). And as the subject of this thread is: - Abuse mailboxes are increasingly no longer monitored - are being replaced by (bad) forms I think we just need to accept that All that is missing now is an xkcd cartoon.
:) -- briefly checked, no existing one there... yet.
Thus maybe better would be a little write-up with some new ideas and self-counter points to exclude those already :)
TLDR: - ISPs need to work together to resolve this - RIRs could verify LIR details better (but hard problem with the state of the world)
# A) Bad-actors getting new resources
Bad-actors can easily create a 'company' anywhere around the world, even outside of the RIRs service area, with valid paperwork and apply to become a LIR and request resources (be that ASN, IPv4 or IPv6) and use those. Their claim is "we are a company in Panama, we'll use the prefix in Netherlands", and they might even have hardware in a colocation to back that up.
RIR cannot check if the person behind the anonymous corporation is the same or a fake person, as identities can be stolen, officials bribed etc. Thus for them finding out if the same actors are behind it, a bad actor will find a way.
# B) Reporting Abuse only works when the LIR/ISP wants to really be a good netizen
While telling a RIR "this LIR does not handle abuse" is an option, the RIR currently has no mandate to do much with it. And even then, lets say there is a mandate to close, the bad actor will go to A
# C) Whitelists / Trusted ISPs
Instead of blacklists and marking all the bad networks, one could make a list of GOOD networks, as that scoring does not change too often.
Networks (ASN / LIR level) one knows that do report to abuse handling and are good netizens (and yes, bad apples can slip in over time, companies get bought out, thus one need to account for that).
The ideal version would be multiple separate entities keeping a "good ASN / LIR" list. An ISP can then consume those lists and go 'two out of three trust that ASN" and now at least know that abuse reports get handled. New entrants, would need to find a way to get on it.
The legal complications that might be associated with such a list for "you did not put me in the whitelist" are fun, at least the model of multiple and scoring based on that would help with redundancy.
In the end though, as history has shown, either there will be one working list, list will be commercialized, or run by the same people in the backend ;)
Anything not on the whitelist is something one can then ratelimit in pps or requests/sec etc.
Will it give something worthwhile.... a split in the Internet if implemented (and we are going there already with hyperscalers being the center and the ones that decides things), not sure it can even work out. Trust networks tend to only work in smaller scales where people still now eachother, the Internet is rather large.
We have one semi-known 'good list' btw: MANRS... https://manrs.org <https://manrs.org/> but how many ISPs actively properly implement it? At least for routing that covers it, does not cover abuse (spam/ddos/etc).
# D) Misconfigurations happen and persist
Bad-actors and misconfigurations can ask for transit from an ISP, who happily announces it: https://www.cidr-report.org/#Bogons
We know that these prefixes are not supposed to be there (unallocated space, thus no RIR involvement) but as long as transits pass them on without consequence... does it matter?
And that discounts option C: there will be good ISPs having misconfigs and not acting to remove clearly obviously fully backed unallocated blocks. Go through the above list, and the IPv6 one, and check the prefixes. You will find transit ASNs that you know and love, and who do not do their due diligence, but would end up on any 'good'' list. AS421005xxx being in that list is a good example of this.
ISPs that do not want to see these can implement unallocated checks (but long list and resource heavy to verify that it is okay to route that prefix). It would be so much better done at the edge of networks who accept these prefixes.
Or they can at least verify with RPKI ROV or ASPA checks that those are permitted prefixes. both need ISPs to change something to make their Internet better. And not everything on the Internet has a ROA let alone ASPA. And one needs BGPsec at one point too to make it a full solution.
So above a few ideas, but also their counter arguments. As long as there is no accountability for an ISP to pass on unallocated space/ASN as the simplest example little will change with the offenders of spam, ddos etc, as there are easier low hanging fruits that are not addressed either.
And yes, effectively, that would require an internet police to resolve, and with international law, that will not easily happen, till some large enough government just puts their foot down...
Those unallocated spaces are inexcusable, but now go find an ARF format where that complaint fits in while every ISP worth their salt has seen the CIDR Report for many many years already.
Regards, Jeroen
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams (FIRST) serge.droz@first.org | https://www.first.org
On 03/08/2026 14:33, Serge Droz via Security-wg wrote: This thread has supplied amusement for the summer. Two opposing camps that have been battling it out since time immemorial and probably will still be battling it out 20 years from now. -Hank
So here is what I propose. I'm not a lawyer, so maybe this needs to be phrased differently. But the idea is
a: Make sure poeple read their abuse e-mails
b: Possibly, take further acction if they read it bud don't act.
a: Abuse mailbox tests:
The RIPE NCC cunducts bi-annual communications checks to the abuse handles. It is expected that these are replied to within [X hours/days/...]
If no replies is received this will be escalated through other contacts.
If no reply is received on may as well assume the org no longer exists and take appropriate action. LACNIC blocks access.
b: Complaints about missing action
RIPE NCC solicitations feedback about failure to take action. This feedback should only be admissible for specific abuses, I would start small (spam, maybe residential proxies, but that's already hard).
If there are n (1, 2, ...) complains the RIPE NCC will send a warning to the violating organisation.
Here we have to talk about sanctions and time lines. If push comes to shove I suggest arbitration under Dutch jurisdiction.
This is assuming:
Most people that don't react will react if there is just a slight incentive to do so. This is the experience I had from abuse fighting here in Switzerland.
There is much to be discussed, and that's the discussion I'd like to see. 1. Can we make these ideas clerere?
Timelines?
Should we start with a and later follow up with b.
I specifically ask for constructive ideas. If they tunr out not to be feasible, we have tried.
Best Serge
On 03/08/2026 02:47, Suresh Ramasubramanian wrote:
As for the closure option, look at one of the first such, and most prominent such, cases in the ICANN world - Estdomains.
Set up as a criminal front. Very high number of criminal domains. It went through ICANN’s entire process and they deregistered it. The few legitimate domains that happened to be on it were transferred to another registrar (Directi) so that service to those would not be disrupted.
—srs
*From: *denis walker <ripedenis@gmail.com> *Date: *Monday, 3 August 2026 at 2:29 AM *To: *Jeroen Massar <jeroen@massar.ch> *Cc: *Serge Droz <serge.droz@first.org>; security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> *Subject: *[Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On Sun, 2 Aug 2026, 22:28 Jeroen Massar, <jeroen@massar.ch> wrote:
> On 2 Aug 2026, at 16:51, denis walker <ripedenis@gmail.com> wrote: > [..] > As things stand there is no accountability, no penalty. It's either full closure or untouchable. We need a rethink and a reset. This is what I am working on....
Reverse DNS is needed to spam properly. IRR / RPKI / ASPA is needed to route (though RPKI/ASPA becomes 'unknown' which is the majority of prefixes today)
So yes, if a RIR does not delegate then a prefix becomes a lot less useable.
Can this be done using a commercial routing registry like RADb?
Thus marking a LIR as 'under investigation' or similar and then at non-response closing it can be a means to stop the abuse.
But we are back to the closure option. As I said, closure or untouchable. If the registry has thousands of legitimate business customers is the RIPE NCC going to close it?
But, it becomes really tricky if an LIR is saying one thing and a pile of others are saying another (they did abuse etc)
And I do not think RIRs have the resources (unless membership fees go insane) to resolve that.
Even if a RIR gives out an 'advise' that the resources are 'tainted' or 'likely abuse' a legal proceeding can cause a whole lot of problems for the RIR.
By the time that advise goes out on a particular set of numbers, they probably aren't connected with the abuser any more.
Cheers Denis
Same for blacklists of course, as the folks from the original MAPS and nowadays Spamhaus and similar setups can attest to, the legal issues are the biggest problem there. (and for some on the wrong side, people claim that the *good* people from Spamhaus do not respond to the delisting requests etc... )
Regards, Jeroen
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Which is why, as I said, organizations are encouraged to bring their trust and safety / security teams in to attend meetings of this wg and other RIPE meetings. This is a somewhat comfortable state of affairs that needs to be disrupted. From: Hank Nussbacher <hank@interall.co.il> Date: Tuesday, 4 August 2026 at 9:48 AM To: Serge Droz <serge.droz@first.org>; Suresh Ramasubramanian <ops.lists@gmail.com>; denis walker <ripedenis@gmail.com>; Jeroen Massar <jeroen@massar.ch> Cc: security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms On 03/08/2026 14:33, Serge Droz via Security-wg wrote: This thread has supplied amusement for the summer. Two opposing camps that have been battling it out since time immemorial and probably will still be battling it out 20 years from now. -Hank
So here is what I propose. I'm not a lawyer, so maybe this needs to be phrased differently. But the idea is
a: Make sure poeple read their abuse e-mails
b: Possibly, take further acction if they read it bud don't act.
a: Abuse mailbox tests:
The RIPE NCC cunducts bi-annual communications checks to the abuse handles. It is expected that these are replied to within [X hours/days/...]
If no replies is received this will be escalated through other contacts.
If no reply is received on may as well assume the org no longer exists and take appropriate action. LACNIC blocks access.
b: Complaints about missing action
RIPE NCC solicitations feedback about failure to take action. This feedback should only be admissible for specific abuses, I would start small (spam, maybe residential proxies, but that's already hard).
If there are n (1, 2, ...) complains the RIPE NCC will send a warning to the violating organisation.
Here we have to talk about sanctions and time lines. If push comes to shove I suggest arbitration under Dutch jurisdiction.
This is assuming:
Most people that don't react will react if there is just a slight incentive to do so. This is the experience I had from abuse fighting here in Switzerland.
There is much to be discussed, and that's the discussion I'd like to see. 1. Can we make these ideas clerere?
Timelines?
Should we start with a and later follow up with b.
I specifically ask for constructive ideas. If they tunr out not to be feasible, we have tried.
Best Serge
On 03/08/2026 02:47, Suresh Ramasubramanian wrote:
As for the closure option, look at one of the first such, and most prominent such, cases in the ICANN world - Estdomains.
Set up as a criminal front. Very high number of criminal domains. It went through ICANN’s entire process and they deregistered it. The few legitimate domains that happened to be on it were transferred to another registrar (Directi) so that service to those would not be disrupted.
—srs
*From: *denis walker <ripedenis@gmail.com> *Date: *Monday, 3 August 2026 at 2:29 AM *To: *Jeroen Massar <jeroen@massar.ch> *Cc: *Serge Droz <serge.droz@first.org>; security-wg@ripe.net <security-wg@ripe.net>; Gert Doering <gert@space.net> *Subject: *[Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
On Sun, 2 Aug 2026, 22:28 Jeroen Massar, <jeroen@massar.ch> wrote:
> On 2 Aug 2026, at 16:51, denis walker <ripedenis@gmail.com> wrote: > [..] > As things stand there is no accountability, no penalty. It's either full closure or untouchable. We need a rethink and a reset. This is what I am working on....
Reverse DNS is needed to spam properly. IRR / RPKI / ASPA is needed to route (though RPKI/ASPA becomes 'unknown' which is the majority of prefixes today)
So yes, if a RIR does not delegate then a prefix becomes a lot less useable.
Can this be done using a commercial routing registry like RADb?
Thus marking a LIR as 'under investigation' or similar and then at non-response closing it can be a means to stop the abuse.
But we are back to the closure option. As I said, closure or untouchable. If the registry has thousands of legitimate business customers is the RIPE NCC going to close it?
But, it becomes really tricky if an LIR is saying one thing and a pile of others are saying another (they did abuse etc)
And I do not think RIRs have the resources (unless membership fees go insane) to resolve that.
Even if a RIR gives out an 'advise' that the resources are 'tainted' or 'likely abuse' a legal proceeding can cause a whole lot of problems for the RIR.
By the time that advise goes out on a particular set of numbers, they probably aren't connected with the abuser any more.
Cheers Denis
Same for blacklists of course, as the folks from the original MAPS and nowadays Spamhaus and similar setups can attest to, the legal issues are the biggest problem there. (and for some on the wrong side, people claim that the *good* people from Spamhaus do not respond to the delisting requests etc... )
Regards, Jeroen
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Serge Droz via Security-wg wrote on 03/08/2026 12:33:
RIPE NCC solicitations feedback about failure to take action. This feedback should only be admissible for specific abuses, I would start small (spam, maybe residential proxies, but that's already hard).
Serge, The countries in the RIPE NCC service region have a population of over a billion people. How does this suggestion scale in terms of resourcing, and who pays for it? Nick
I've heard that argument before Who would pay for reducing fossil fuels, it affects so many people? Who would pay for introducing IPv6, as IPv4 just works, it's so many devices. Nick: I'd appreciate if you could contribute more than just reasons for why something doesn't work. Or is, what you are saying, that LACNIC and APNIC just don't get it. I will now stop answering to your objections, since this is not constructive. Serge On 04/08/2026 14:08, Nick Hilliard wrote:
Serge Droz via Security-wg wrote on 03/08/2026 12:33:
RIPE NCC solicitations feedback about failure to take action. This feedback should only be admissible for specific abuses, I would start small (spam, maybe residential proxies, but that's already hard).
Serge,
The countries in the RIPE NCC service region have a population of over a billion people. How does this suggestion scale in terms of resourcing, and who pays for it?
Nick
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams (FIRST) serge.droz@first.org | https://www.first.org
Serge Droz via Security-wg wrote on 04/08/2026 13:30:
Nick: I'd appreciate if you could contribute more than just reasons for why something doesn't work. Or is, what you are saying, that LACNIC and APNIC just don't get it. I will now stop answering to your objections, since this is not constructive.
Serge, I replied to a suggestion that you made, and if I understand it correctly, what LACNIC and APNIC are doing is substantially different to what you were suggesting in your email. Possibly this is one of the problems with this (recurrent) conversation - different people are talking across each other about different potential solutions to different problems in the same email thread. Specifically what you suggested in your last email is fairly fine-grained. Spam and residential proxies are a huge problem and a noticeable percentage of subscriber accounts host compromised equipment - TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your proposal is effectively for individual subscriber-level stuff to be handled by or escalated in some way another to the RIPE NCC, there's a huge scaling problem right there. The RIPE NCC doesn't have the scope or scale to become a clearinghouse for abuse complaints at that level of granularity. At the point that an organisation was so substantially involved with online abuse that complete resource withdrawal could be considered justified by some measure, then I'd be thinking that that would be already well within the jurisdiction of civil authorities to handle. Also, the RIPE NCC isn't set up to make judgement calls about this sort of thing. If you're talking about general abuse management, then the suggestion of deregistration of resources is a pretty severe sanction. Put simply, it's the sort of thing that could kill a business, and given the RIPE NCC's position as a regional monopoly of registration services, they would need to be pretty careful about applying this sort of sanction to their members. Threatening to do something which would kill a business is the sort of thing that's going to be legally unworkable unless it falls into either breach of boilerplate contract terms (e.g. failure of members to pay bills, bankruptcy, etc, i.e. stuff which is routine and well-established in law) or stuff which was immediately identifiable as critical to the continuity of the RIPE NCC's core mandate, which is to ensure the correct registration of resources, e.g. continued failure of ARC audits. These things are already in the standard service agreement. Overall, the remedies being proposed are too slow and too coarse-grained to deal with how resources are abused in real life, and too severe to deal with anything other than systematically intentional abuse, in which case it's by definition a legal problem for someone else to handle anyway. You're right to ask for constructive ideas, but I genuinely don't see any which involve the RIPE NCC that aren't fraught with serious and in many cases, existential problems. Maybe the way to deal with this would be to put a formal proposal together, as something that can be discussed? Right now, there's nothing concrete to discuss. Nick
Nick Hilliard <nick@foobar.org> wrote: > Possibly this is one of the problems with this (recurrent) conversation > - different people are talking across each other about different > potential solutions to different problems in the same email thread. Agreed. > Specifically what you suggested in your last email is fairly > fine-grained. Spam and residential proxies are a huge problem and a > noticeable percentage of subscriber accounts host compromised equipment > - TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your > proposal is effectively for individual subscriber-level stuff to be > handled by or escalated in some way another to the RIPE NCC, there's a > huge scaling problem right there. The RIPE NCC doesn't have the scope > or scale to become a clearinghouse for abuse complaints at that level > of granularity. A question is: who is that wants to report such things, and to whom? (It's a real question) I think that at least a few ISPs actually operate fake subscriber systems as canaries, and I'm sure it's annoying to them to get reports about them :-) I'm told that there was/is some system where I could dial another NOC using a SIP phone, and their phone number was their ASN. I think that kind of between operator reporting is way way different than random emails from random people. I can see why abuse@ does not get the attention it deserves, as beyond the literal spam problem, are the endless useless/incomplete reports. > If you're talking about general abuse management, then the suggestion > of deregistration of resources is a pretty severe sanction. Agreed. Still: the ol' Usenet penalty was useful. RIPE should limit itself to dealing with unresponsive registrants, and it's the unresponsiveness that is the concern. With many levels of escalation. (At some point: if they are universally unresponsive, they won't pay their bill) > Overall, the remedies being proposed are too slow and too > coarse-grained to deal with how resources are abused in real life, and > too severe to deal with anything other than systematically intentional > abuse, in which case it's by definition a legal problem for someone > else to handle anyway. Agreed. What I would like to see is more cross-training between CERTs at various levels and RIPE, including some process that educates operators to elevate their abilities. I didn't know about XARF before this thread, and I do now, and I wish that it was more used, although I don't understand how that org operates. {I used to get periodic emails from Canada's CSIS/CVE about how my Cisco routers were insecure based upon some very confused scan of BGP ports. They never actually told me what IP they had looked at, and... I had no Cisco equipment. They stopped a few years ago. I wish they hadn't stopped, but rather gotten more clue. They also didn't use abuse@ } -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours **
Providers that are incompetent at abuse management can be handled in one way or the other. The question before the house is the other kind of provider that acquires IP space solely for abusive purposes or, to pick a recent example, for abusive purposes as well as sanctions avoidance. The activity hosted on such providers tends to eventually get the provider raided by law enforcement and shut down. It’d be very interesting if part of such an investigation spilled into just why such groups or individuals, were given number resources. --srs ________________________________ From: Michael Richardson <mcr+ietf@sandelman.ca> Sent: Tuesday, 04 August 2026 20:43:40 To: Nick Hilliard <nick@foobar.org>; security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Nick Hilliard <nick@foobar.org> wrote: > Possibly this is one of the problems with this (recurrent) conversation > - different people are talking across each other about different > potential solutions to different problems in the same email thread. Agreed. > Specifically what you suggested in your last email is fairly > fine-grained. Spam and residential proxies are a huge problem and a > noticeable percentage of subscriber accounts host compromised equipment > - TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your > proposal is effectively for individual subscriber-level stuff to be > handled by or escalated in some way another to the RIPE NCC, there's a > huge scaling problem right there. The RIPE NCC doesn't have the scope > or scale to become a clearinghouse for abuse complaints at that level > of granularity. A question is: who is that wants to report such things, and to whom? (It's a real question) I think that at least a few ISPs actually operate fake subscriber systems as canaries, and I'm sure it's annoying to them to get reports about them :-) I'm told that there was/is some system where I could dial another NOC using a SIP phone, and their phone number was their ASN. I think that kind of between operator reporting is way way different than random emails from random people. I can see why abuse@ does not get the attention it deserves, as beyond the literal spam problem, are the endless useless/incomplete reports. > If you're talking about general abuse management, then the suggestion > of deregistration of resources is a pretty severe sanction. Agreed. Still: the ol' Usenet penalty was useful. RIPE should limit itself to dealing with unresponsive registrants, and it's the unresponsiveness that is the concern. With many levels of escalation. (At some point: if they are universally unresponsive, they won't pay their bill) > Overall, the remedies being proposed are too slow and too > coarse-grained to deal with how resources are abused in real life, and > too severe to deal with anything other than systematically intentional > abuse, in which case it's by definition a legal problem for someone > else to handle anyway. Agreed. What I would like to see is more cross-training between CERTs at various levels and RIPE, including some process that educates operators to elevate their abilities. I didn't know about XARF before this thread, and I do now, and I wish that it was more used, although I don't understand how that org operates. {I used to get periodic emails from Canada's CSIS/CVE about how my Cisco routers were insecure based upon some very confused scan of BGP ports. They never actually told me what IP they had looked at, and... I had no Cisco equipment. They stopped a few years ago. I wish they hadn't stopped, but rather gotten more clue. They also didn't use abuse@ } -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours **
Colleagues One of the reasons LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry suspension or closure. To bypass historical jurisdiction arguments regarding the definition of "abuse," we can utilize the harmonized definitions established under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering DDoS, phishing, and malware distribution) as a baseline. Just as Address Policy limits sub-assignments under contract, we have the same right to prevent abusive behaviors, using the same contractual terms. Nick's latest email correctly highlights the core existential and scaling traps that have stalled this conversation for a decade. If a policy targets individual subscriber-level botnets, it creates an unworkable scaling failure. If a policy forces the RIPE NCC to act as a judge or deploy the 'nuclear option' of total resource withdrawal, it invites massive legal liability. However, we can completely bypass these traps by separating low-level consumer incidents from systemic infrastructure abuse, and by shifting the sanction from resource closure to administrative quarantine. I propose a simplified, three-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP): ---------------------------------- Article 1: 1.1 For the purposes of RIPE Address Policy, "Network Abuse" is defined, as a base line, by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks, and systemic spam botnet distribution). 1.2 The following activities are also included: - dictionary attacks Article 2: RIPE allocated and assigned address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1. Article 3: When the RIPE NCC receives an authenticated notification of systemic abuse involving RIPE allocated and assigned IP addresses, the registry responsible for those addresses will be given 14 working days notice to shut down the abuser or have their registry operation suspended. ---------------------------------- To address the valid operational and legal questions raised over the weekend regarding implementation, "internet policing," and protecting innocent downstream networks, the operational compliance workflow would function across three objective, administrative steps: 1. Objective Identification (The Scaling Filter) To eliminate the 'grandma's compromised router' scaling problem, the policy trigger must rely exclusively on infrastructure-only, architecture-level blocklists that explicitly exclude residential and dynamic subscriber IP space (such as the Spamhaus DROP list). An IP from a RIPE address allocation or assignment must appear on such a list for a continuous period of 14 consecutive days. This removes human bias and ensures only persistent, intentional, infrastructure-level abuse triggers the process. 2. Administrative Accountability (The Registry Mail Relay) Because the LIR is ignoring standard automated abuse-c: emails, an affected network operator or a National CERT uploads the 14-day continuous blocklist evidence to a dedicated RIPE NCC Compliance Portal. The RIPE NCC does not act as a judge or evaluate the traffic. To strictly protect member data privacy, the official contract address of the LIR remains confidential. The RIPE NCC simply acts as an administrative postal carrier. They look up the LIR’s private legal contact details on file and forward a formal remediation notice via Registered Mail to the physical legal address they are already contractually required to maintain under their signed RIPE NCC Standard Service Agreement. This applies uniformly to all LIRs across the entire RIPE region, regardless of country, organizational structure or legal jurisdiction. The RIPE NCC already uses this exact contract address to send out formal legal warnings for non-payment of fees or failure to pass administrative audits (ARCs). They are simply utilizing an existing, well-established legal pipe. 3. Non-Lethal Sanction (The RPKI CA Freeze) The LIR is given a strict 14 business days from the confirmed date of physical or electronic delivery to self-correct. If they quietly terminate the abuser’s account, the traffic stops, the IP automatically drops off the blocklist, the RIPE ticket closes, and no penalty is applied. If the 14 days pass, the IP remains blacklisted, and the LIR has explicitly refused to respond to the paper trail sent by the RIR registry, the RIPE NCC executes a boilerplate administrative sanction: they freeze the LIR's RPKI CA management and append an administrative status update to the continuous NRTM serial stream by updating the LIR's ORGANISATION and ALLOCATION or ASSIGNMENT objects with a 'NON-COMPLIANCE' tag. Operational Timeline and Liability Realities: Nick is entirely correct that threatening to kill a business over a few abusers is legally unworkable. That is why this proposal does not withdraw resources or trigger a sudden, automated network shutdown that instantly drops thousands of innocent downstream customers offline. The RIPE NCC is completely insulated from legal liability. Initially, all downstream traffic continues to flow normally. What we are doing is cryptographically freezing the LIR's routing boundaries. They cannot shift transits or alter routes to evade security tracking, and their daily automated BGP filter rebuilds will signal their non-compliance to the market. Furthermore, if an LIR ignores over four weeks of automated warnings and an explicit, paper-trailed legal notice from the RIR registry, concealing that operational risk from its own downstream clients, the liability for any subsequent routing disruption or upstream transit disconnection rests squarely on the non-compliant LIR—not the RIPE NCC. We completely bypass unmonitored email accounts. The RIPE NCC handles the administrative notice delivery and holds the authoritative, legally binding proof of receipt. Nick asked for a concrete proposal to discuss rather than generalities. This 3-step framework uses existing data and mechanisms, protects data privacy, requires zero judicial filtering by RIPE NCC staff, avoids legal liability by the RIPE NCC for any consequences and protects innocent networks while finally holding non-responsive resource holders contractually accountable. Let's work together to end this 20 year impasse... cheers denis On Tue, 4 Aug 2026 at 16:27, Nick Hilliard <nick@foobar.org> wrote:
Serge Droz via Security-wg wrote on 04/08/2026 13:30:
Nick: I'd appreciate if you could contribute more than just reasons for why something doesn't work. Or is, what you are saying, that LACNIC and APNIC just don't get it. I will now stop answering to your objections, since this is not constructive.
Serge,
I replied to a suggestion that you made, and if I understand it correctly, what LACNIC and APNIC are doing is substantially different to what you were suggesting in your email.
Possibly this is one of the problems with this (recurrent) conversation - different people are talking across each other about different potential solutions to different problems in the same email thread.
Specifically what you suggested in your last email is fairly fine-grained. Spam and residential proxies are a huge problem and a noticeable percentage of subscriber accounts host compromised equipment - TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your proposal is effectively for individual subscriber-level stuff to be handled by or escalated in some way another to the RIPE NCC, there's a huge scaling problem right there. The RIPE NCC doesn't have the scope or scale to become a clearinghouse for abuse complaints at that level of granularity.
At the point that an organisation was so substantially involved with online abuse that complete resource withdrawal could be considered justified by some measure, then I'd be thinking that that would be already well within the jurisdiction of civil authorities to handle. Also, the RIPE NCC isn't set up to make judgement calls about this sort of thing.
If you're talking about general abuse management, then the suggestion of deregistration of resources is a pretty severe sanction. Put simply, it's the sort of thing that could kill a business, and given the RIPE NCC's position as a regional monopoly of registration services, they would need to be pretty careful about applying this sort of sanction to their members. Threatening to do something which would kill a business is the sort of thing that's going to be legally unworkable unless it falls into either breach of boilerplate contract terms (e.g. failure of members to pay bills, bankruptcy, etc, i.e. stuff which is routine and well-established in law) or stuff which was immediately identifiable as critical to the continuity of the RIPE NCC's core mandate, which is to ensure the correct registration of resources, e.g. continued failure of ARC audits. These things are already in the standard service agreement.
Overall, the remedies being proposed are too slow and too coarse-grained to deal with how resources are abused in real life, and too severe to deal with anything other than systematically intentional abuse, in which case it's by definition a legal problem for someone else to handle anyway.
You're right to ask for constructive ideas, but I genuinely don't see any which involve the RIPE NCC that aren't fraught with serious and in many cases, existential problems. Maybe the way to deal with this would be to put a formal proposal together, as something that can be discussed? Right now, there's nothing concrete to discuss.
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
There is this notice and takedown framework the Dutch put in place. https://www.i3d.net/legal/dutch-notice-and-takedown-procedure/ There is always a way when there is a will - particularly with legislation as enabling as this one reads, besides generally robust safe harbor protections Now, developing that will is the next step. From: denis walker <ripedenis@gmail.com> Date: Tuesday, 4 August 2026 at 11:18 PM To: Nick Hilliard <nick@foobar.org> Cc: Serge Droz <serge.droz@first.org>; security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Colleagues One of the reasons LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry suspension or closure. To bypass historical jurisdiction arguments regarding the definition of "abuse," we can utilize the harmonized definitions established under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering DDoS, phishing, and malware distribution) as a baseline. Just as Address Policy limits sub-assignments under contract, we have the same right to prevent abusive behaviors, using the same contractual terms. Nick's latest email correctly highlights the core existential and scaling traps that have stalled this conversation for a decade. If a policy targets individual subscriber-level botnets, it creates an unworkable scaling failure. If a policy forces the RIPE NCC to act as a judge or deploy the 'nuclear option' of total resource withdrawal, it invites massive legal liability. However, we can completely bypass these traps by separating low-level consumer incidents from systemic infrastructure abuse, and by shifting the sanction from resource closure to administrative quarantine. I propose a simplified, three-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP): ---------------------------------- Article 1: 1.1 For the purposes of RIPE Address Policy, "Network Abuse" is defined, as a base line, by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks, and systemic spam botnet distribution). 1.2 The following activities are also included: - dictionary attacks Article 2: RIPE allocated and assigned address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1. Article 3: When the RIPE NCC receives an authenticated notification of systemic abuse involving RIPE allocated and assigned IP addresses, the registry responsible for those addresses will be given 14 working days notice to shut down the abuser or have their registry operation suspended. ---------------------------------- To address the valid operational and legal questions raised over the weekend regarding implementation, "internet policing," and protecting innocent downstream networks, the operational compliance workflow would function across three objective, administrative steps: 1. Objective Identification (The Scaling Filter) To eliminate the 'grandma's compromised router' scaling problem, the policy trigger must rely exclusively on infrastructure-only, architecture-level blocklists that explicitly exclude residential and dynamic subscriber IP space (such as the Spamhaus DROP list). An IP from a RIPE address allocation or assignment must appear on such a list for a continuous period of 14 consecutive days. This removes human bias and ensures only persistent, intentional, infrastructure-level abuse triggers the process. 2. Administrative Accountability (The Registry Mail Relay) Because the LIR is ignoring standard automated abuse-c: emails, an affected network operator or a National CERT uploads the 14-day continuous blocklist evidence to a dedicated RIPE NCC Compliance Portal. The RIPE NCC does not act as a judge or evaluate the traffic. To strictly protect member data privacy, the official contract address of the LIR remains confidential. The RIPE NCC simply acts as an administrative postal carrier. They look up the LIR’s private legal contact details on file and forward a formal remediation notice via Registered Mail to the physical legal address they are already contractually required to maintain under their signed RIPE NCC Standard Service Agreement. This applies uniformly to all LIRs across the entire RIPE region, regardless of country, organizational structure or legal jurisdiction. The RIPE NCC already uses this exact contract address to send out formal legal warnings for non-payment of fees or failure to pass administrative audits (ARCs). They are simply utilizing an existing, well-established legal pipe. 3. Non-Lethal Sanction (The RPKI CA Freeze) The LIR is given a strict 14 business days from the confirmed date of physical or electronic delivery to self-correct. If they quietly terminate the abuser’s account, the traffic stops, the IP automatically drops off the blocklist, the RIPE ticket closes, and no penalty is applied. If the 14 days pass, the IP remains blacklisted, and the LIR has explicitly refused to respond to the paper trail sent by the RIR registry, the RIPE NCC executes a boilerplate administrative sanction: they freeze the LIR's RPKI CA management and append an administrative status update to the continuous NRTM serial stream by updating the LIR's ORGANISATION and ALLOCATION or ASSIGNMENT objects with a 'NON-COMPLIANCE' tag. Operational Timeline and Liability Realities: Nick is entirely correct that threatening to kill a business over a few abusers is legally unworkable. That is why this proposal does not withdraw resources or trigger a sudden, automated network shutdown that instantly drops thousands of innocent downstream customers offline. The RIPE NCC is completely insulated from legal liability. Initially, all downstream traffic continues to flow normally. What we are doing is cryptographically freezing the LIR's routing boundaries. They cannot shift transits or alter routes to evade security tracking, and their daily automated BGP filter rebuilds will signal their non-compliance to the market. Furthermore, if an LIR ignores over four weeks of automated warnings and an explicit, paper-trailed legal notice from the RIR registry, concealing that operational risk from its own downstream clients, the liability for any subsequent routing disruption or upstream transit disconnection rests squarely on the non-compliant LIR—not the RIPE NCC. We completely bypass unmonitored email accounts. The RIPE NCC handles the administrative notice delivery and holds the authoritative, legally binding proof of receipt. Nick asked for a concrete proposal to discuss rather than generalities. This 3-step framework uses existing data and mechanisms, protects data privacy, requires zero judicial filtering by RIPE NCC staff, avoids legal liability by the RIPE NCC for any consequences and protects innocent networks while finally holding non-responsive resource holders contractually accountable. Let's work together to end this 20 year impasse... cheers denis On Tue, 4 Aug 2026 at 16:27, Nick Hilliard <nick@foobar.org<mailto:nick@foobar.org>> wrote: Serge Droz via Security-wg wrote on 04/08/2026 13:30:
Nick: I'd appreciate if you could contribute more than just reasons for why something doesn't work. Or is, what you are saying, that LACNIC and APNIC just don't get it. I will now stop answering to your objections, since this is not constructive.
Serge, I replied to a suggestion that you made, and if I understand it correctly, what LACNIC and APNIC are doing is substantially different to what you were suggesting in your email. Possibly this is one of the problems with this (recurrent) conversation - different people are talking across each other about different potential solutions to different problems in the same email thread. Specifically what you suggested in your last email is fairly fine-grained. Spam and residential proxies are a huge problem and a noticeable percentage of subscriber accounts host compromised equipment - TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your proposal is effectively for individual subscriber-level stuff to be handled by or escalated in some way another to the RIPE NCC, there's a huge scaling problem right there. The RIPE NCC doesn't have the scope or scale to become a clearinghouse for abuse complaints at that level of granularity. At the point that an organisation was so substantially involved with online abuse that complete resource withdrawal could be considered justified by some measure, then I'd be thinking that that would be already well within the jurisdiction of civil authorities to handle. Also, the RIPE NCC isn't set up to make judgement calls about this sort of thing. If you're talking about general abuse management, then the suggestion of deregistration of resources is a pretty severe sanction. Put simply, it's the sort of thing that could kill a business, and given the RIPE NCC's position as a regional monopoly of registration services, they would need to be pretty careful about applying this sort of sanction to their members. Threatening to do something which would kill a business is the sort of thing that's going to be legally unworkable unless it falls into either breach of boilerplate contract terms (e.g. failure of members to pay bills, bankruptcy, etc, i.e. stuff which is routine and well-established in law) or stuff which was immediately identifiable as critical to the continuity of the RIPE NCC's core mandate, which is to ensure the correct registration of resources, e.g. continued failure of ARC audits. These things are already in the standard service agreement. Overall, the remedies being proposed are too slow and too coarse-grained to deal with how resources are abused in real life, and too severe to deal with anything other than systematically intentional abuse, in which case it's by definition a legal problem for someone else to handle anyway. You're right to ask for constructive ideas, but I genuinely don't see any which involve the RIPE NCC that aren't fraught with serious and in many cases, existential problems. Maybe the way to deal with this would be to put a formal proposal together, as something that can be discussed? Right now, there's nothing concrete to discuss. Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
South African Internet Service Providers (ISPA) operates a take-down notice process on behalf of its members. https://ispa.org.za/consumer-support/take-down-notices/how-to-lodge-a-take-d... Regards. Le mar. 4 août 2026 à 12:56, Suresh Ramasubramanian <ops.lists@gmail.com> a écrit :
There is this notice and takedown framework the Dutch put in place.
https://www.i3d.net/legal/dutch-notice-and-takedown-procedure/
There is always a way when there is a will - particularly with legislation as enabling as this one reads, besides generally robust safe harbor protections
Now, developing that will is the next step.
*From: *denis walker <ripedenis@gmail.com> *Date: *Tuesday, 4 August 2026 at 11:18 PM *To: *Nick Hilliard <nick@foobar.org> *Cc: *Serge Droz <serge.droz@first.org>; security-wg@ripe.net < security-wg@ripe.net> *Subject: *[Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
Colleagues
One of the reasons LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry suspension or closure.
To bypass historical jurisdiction arguments regarding the definition of "abuse," we can utilize the harmonized definitions established under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering DDoS, phishing, and malware distribution) as a baseline. Just as Address Policy limits sub-assignments under contract, we have the same right to prevent abusive behaviors, using the same contractual terms.
Nick's latest email correctly highlights the core existential and scaling traps that have stalled this conversation for a decade. If a policy targets individual subscriber-level botnets, it creates an unworkable scaling failure. If a policy forces the RIPE NCC to act as a judge or deploy the 'nuclear option' of total resource withdrawal, it invites massive legal liability.
However, we can completely bypass these traps by separating low-level consumer incidents from systemic infrastructure abuse, and by shifting the sanction from resource closure to administrative quarantine.
I propose a simplified, three-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP):
---------------------------------- Article 1: 1.1 For the purposes of RIPE Address Policy, "Network Abuse" is defined, as a base line, by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks, and systemic spam botnet distribution).
1.2 The following activities are also included: - dictionary attacks
Article 2: RIPE allocated and assigned address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1.
Article 3: When the RIPE NCC receives an authenticated notification of systemic abuse involving RIPE allocated and assigned IP addresses, the registry responsible for those addresses will be given 14 working days notice to shut down the abuser or have their registry operation suspended. ----------------------------------
To address the valid operational and legal questions raised over the weekend regarding implementation, "internet policing," and protecting innocent downstream networks, the operational compliance workflow would function across three objective, administrative steps:
1. Objective Identification (The Scaling Filter) To eliminate the 'grandma's compromised router' scaling problem, the policy trigger must rely exclusively on infrastructure-only, architecture-level blocklists that explicitly exclude residential and dynamic subscriber IP space (such as the Spamhaus DROP list). An IP from a RIPE address allocation or assignment must appear on such a list for a continuous period of 14 consecutive days. This removes human bias and ensures only persistent, intentional, infrastructure-level abuse triggers the process.
2. Administrative Accountability (The Registry Mail Relay) Because the LIR is ignoring standard automated abuse-c: emails, an affected network operator or a National CERT uploads the 14-day continuous blocklist evidence to a dedicated RIPE NCC Compliance Portal.
The RIPE NCC does not act as a judge or evaluate the traffic. To strictly protect member data privacy, the official contract address of the LIR remains confidential. The RIPE NCC simply acts as an administrative postal carrier. They look up the LIR’s private legal contact details on file and forward a formal remediation notice via Registered Mail to the physical legal address they are already contractually required to maintain under their signed RIPE NCC Standard Service Agreement. This applies uniformly to all LIRs across the entire RIPE region, regardless of country, organizational structure or legal jurisdiction.
The RIPE NCC already uses this exact contract address to send out formal legal warnings for non-payment of fees or failure to pass administrative audits (ARCs). They are simply utilizing an existing, well-established legal pipe.
3. Non-Lethal Sanction (The RPKI CA Freeze) The LIR is given a strict 14 business days from the confirmed date of physical or electronic delivery to self-correct. If they quietly terminate the abuser’s account, the traffic stops, the IP automatically drops off the blocklist, the RIPE ticket closes, and no penalty is applied.
If the 14 days pass, the IP remains blacklisted, and the LIR has explicitly refused to respond to the paper trail sent by the RIR registry, the RIPE NCC executes a boilerplate administrative sanction: they freeze the LIR's RPKI CA management and append an administrative status update to the continuous NRTM serial stream by updating the LIR's ORGANISATION and ALLOCATION or ASSIGNMENT objects with a 'NON-COMPLIANCE' tag.
Operational Timeline and Liability Realities: Nick is entirely correct that threatening to kill a business over a few abusers is legally unworkable. That is why this proposal does not withdraw resources or trigger a sudden, automated network shutdown that instantly drops thousands of innocent downstream customers offline. The RIPE NCC is completely insulated from legal liability.
Initially, all downstream traffic continues to flow normally. What we are doing is cryptographically freezing the LIR's routing boundaries. They cannot shift transits or alter routes to evade security tracking, and their daily automated BGP filter rebuilds will signal their non-compliance to the market.
Furthermore, if an LIR ignores over four weeks of automated warnings and an explicit, paper-trailed legal notice from the RIR registry, concealing that operational risk from its own downstream clients, the liability for any subsequent routing disruption or upstream transit disconnection rests squarely on the non-compliant LIR—not the RIPE NCC. We completely bypass unmonitored email accounts. The RIPE NCC handles the administrative notice delivery and holds the authoritative, legally binding proof of receipt.
Nick asked for a concrete proposal to discuss rather than generalities. This 3-step framework uses existing data and mechanisms, protects data privacy, requires zero judicial filtering by RIPE NCC staff, avoids legal liability by the RIPE NCC for any consequences and protects innocent networks while finally holding non-responsive resource holders contractually accountable.
Let's work together to end this 20 year impasse...
cheers denis
On Tue, 4 Aug 2026 at 16:27, Nick Hilliard <nick@foobar.org> wrote:
Serge Droz via Security-wg wrote on 04/08/2026 13:30:
Nick: I'd appreciate if you could contribute more than just reasons for why something doesn't work. Or is, what you are saying, that LACNIC and APNIC just don't get it. I will now stop answering to your objections, since this is not constructive.
Serge,
I replied to a suggestion that you made, and if I understand it correctly, what LACNIC and APNIC are doing is substantially different to what you were suggesting in your email.
Possibly this is one of the problems with this (recurrent) conversation - different people are talking across each other about different potential solutions to different problems in the same email thread.
Specifically what you suggested in your last email is fairly fine-grained. Spam and residential proxies are a huge problem and a noticeable percentage of subscriber accounts host compromised equipment - TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your proposal is effectively for individual subscriber-level stuff to be handled by or escalated in some way another to the RIPE NCC, there's a huge scaling problem right there. The RIPE NCC doesn't have the scope or scale to become a clearinghouse for abuse complaints at that level of granularity.
At the point that an organisation was so substantially involved with online abuse that complete resource withdrawal could be considered justified by some measure, then I'd be thinking that that would be already well within the jurisdiction of civil authorities to handle. Also, the RIPE NCC isn't set up to make judgement calls about this sort of thing.
If you're talking about general abuse management, then the suggestion of deregistration of resources is a pretty severe sanction. Put simply, it's the sort of thing that could kill a business, and given the RIPE NCC's position as a regional monopoly of registration services, they would need to be pretty careful about applying this sort of sanction to their members. Threatening to do something which would kill a business is the sort of thing that's going to be legally unworkable unless it falls into either breach of boilerplate contract terms (e.g. failure of members to pay bills, bankruptcy, etc, i.e. stuff which is routine and well-established in law) or stuff which was immediately identifiable as critical to the continuity of the RIPE NCC's core mandate, which is to ensure the correct registration of resources, e.g. continued failure of ARC audits. These things are already in the standard service agreement.
Overall, the remedies being proposed are too slow and too coarse-grained to deal with how resources are abused in real life, and too severe to deal with anything other than systematically intentional abuse, in which case it's by definition a legal problem for someone else to handle anyway.
You're right to ask for constructive ideas, but I genuinely don't see any which involve the RIPE NCC that aren't fraught with serious and in many cases, existential problems. Maybe the way to deal with this would be to put a formal proposal together, as something that can be discussed? Right now, there's nothing concrete to discuss.
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi Dennis I like this, thanks a lot. I think it would make sense to create a better understanding of systematic abuse, because otherwise there will be endless arguments about this. I also think it makes sense to have a clear list of abuse types we deal with, maybe with a clause to update this every year or so. Otherwise, the EU/ENISA will determine this. I kind of like starting small, and then expand. But if people are fine with this, no problem for me. There probably needs a feedback mechanism to the org that filed the complaint. I still think we need, separate to this an abuse-c test. Back in the day, when we started blocking (removing NS delegations) for malicious CH-Domains, one provider didn't have a working abuse contact, so we blocked. Once they learned about the issue they fixed this. This is my point: If you have a big club like you prose, there will be a motivation to get your house in order before you escalate. As I said, lazy/negligent operators are not the same as criminal ones. The former we can probably motivate to become better. Best Serge On 04/08/2026 19:48, denis walker wrote:
Colleagues
One of the reasons LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry suspension or closure.
To bypass historical jurisdiction arguments regarding the definition of "abuse," we can utilize the harmonized definitions established under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering DDoS, phishing, and malware distribution) as a baseline. Just as Address Policy limits sub-assignments under contract, we have the same right to prevent abusive behaviors, using the same contractual terms.
Nick's latest email correctly highlights the core existential and scaling traps that have stalled this conversation for a decade. If a policy targets individual subscriber-level botnets, it creates an unworkable scaling failure. If a policy forces the RIPE NCC to act as a judge or deploy the 'nuclear option' of total resource withdrawal, it invites massive legal liability.
However, we can completely bypass these traps by separating low-level consumer incidents from systemic infrastructure abuse, and by shifting the sanction from resource closure to administrative quarantine.
I propose a simplified, three-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP):
---------------------------------- Article 1: 1.1 For the purposes of RIPE Address Policy, "Network Abuse" is defined, as a base line, by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks, and systemic spam botnet distribution).
1.2 The following activities are also included: - dictionary attacks
Article 2: RIPE allocated and assigned address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1.
Article 3: When the RIPE NCC receives an authenticated notification of systemic abuse involving RIPE allocated and assigned IP addresses, the registry responsible for those addresses will be given 14 working days notice to shut down the abuser or have their registry operation suspended. ----------------------------------
To address the valid operational and legal questions raised over the weekend regarding implementation, "internet policing," and protecting innocent downstream networks, the operational compliance workflow would function across three objective, administrative steps:
1. Objective Identification (The Scaling Filter) To eliminate the 'grandma's compromised router' scaling problem, the policy trigger must rely exclusively on infrastructure-only, architecture-level blocklists that explicitly exclude residential and dynamic subscriber IP space (such as the Spamhaus DROP list). An IP from a RIPE address allocation or assignment must appear on such a list for a continuous period of 14 consecutive days. This removes human bias and ensures only persistent, intentional, infrastructure-level abuse triggers the process.
2. Administrative Accountability (The Registry Mail Relay) Because the LIR is ignoring standard automated abuse-c: emails, an affected network operator or a National CERT uploads the 14-day continuous blocklist evidence to a dedicated RIPE NCC Compliance Portal.
The RIPE NCC does not act as a judge or evaluate the traffic. To strictly protect member data privacy, the official contract address of the LIR remains confidential. The RIPE NCC simply acts as an administrative postal carrier. They look up the LIR’s private legal contact details on file and forward a formal remediation notice via Registered Mail to the physical legal address they are already contractually required to maintain under their signed RIPE NCC Standard Service Agreement. This applies uniformly to all LIRs across the entire RIPE region, regardless of country, organizational structure or legal jurisdiction.
The RIPE NCC already uses this exact contract address to send out formal legal warnings for non-payment of fees or failure to pass administrative audits (ARCs). They are simply utilizing an existing, well-established legal pipe.
3. Non-Lethal Sanction (The RPKI CA Freeze) The LIR is given a strict 14 business days from the confirmed date of physical or electronic delivery to self-correct. If they quietly terminate the abuser’s account, the traffic stops, the IP automatically drops off the blocklist, the RIPE ticket closes, and no penalty is applied.
If the 14 days pass, the IP remains blacklisted, and the LIR has explicitly refused to respond to the paper trail sent by the RIR registry, the RIPE NCC executes a boilerplate administrative sanction: they freeze the LIR's RPKI CA management and append an administrative status update to the continuous NRTM serial stream by updating the LIR's ORGANISATION and ALLOCATION or ASSIGNMENT objects with a 'NON-COMPLIANCE' tag.
Operational Timeline and Liability Realities: Nick is entirely correct that threatening to kill a business over a few abusers is legally unworkable. That is why this proposal does not withdraw resources or trigger a sudden, automated network shutdown that instantly drops thousands of innocent downstream customers offline. The RIPE NCC is completely insulated from legal liability.
Initially, all downstream traffic continues to flow normally. What we are doing is cryptographically freezing the LIR's routing boundaries. They cannot shift transits or alter routes to evade security tracking, and their daily automated BGP filter rebuilds will signal their non-compliance to the market.
Furthermore, if an LIR ignores over four weeks of automated warnings and an explicit, paper-trailed legal notice from the RIR registry, concealing that operational risk from its own downstream clients, the liability for any subsequent routing disruption or upstream transit disconnection rests squarely on the non-compliant LIR—not the RIPE NCC. We completely bypass unmonitored email accounts. The RIPE NCC handles the administrative notice delivery and holds the authoritative, legally binding proof of receipt.
Nick asked for a concrete proposal to discuss rather than generalities. This 3-step framework uses existing data and mechanisms, protects data privacy, requires zero judicial filtering by RIPE NCC staff, avoids legal liability by the RIPE NCC for any consequences and protects innocent networks while finally holding non-responsive resource holders contractually accountable.
Let's work together to end this 20 year impasse...
cheers denis
On Tue, 4 Aug 2026 at 16:27, Nick Hilliard <nick@foobar.org> wrote:
Serge Droz via Security-wg wrote on 04/08/2026 13:30: > Nick: I'd appreciate if you could contribute more than just reasons for > why something doesn't work. Or is, what you are saying, that LACNIC and > APNIC just don't get it. I will now stop answering to your objections, > since this is not constructive.
Serge,
I replied to a suggestion that you made, and if I understand it correctly, what LACNIC and APNIC are doing is substantially different to what you were suggesting in your email.
Possibly this is one of the problems with this (recurrent) conversation - different people are talking across each other about different potential solutions to different problems in the same email thread.
Specifically what you suggested in your last email is fairly fine-grained. Spam and residential proxies are a huge problem and a noticeable percentage of subscriber accounts host compromised equipment - TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your proposal is effectively for individual subscriber-level stuff to be handled by or escalated in some way another to the RIPE NCC, there's a huge scaling problem right there. The RIPE NCC doesn't have the scope or scale to become a clearinghouse for abuse complaints at that level of granularity.
At the point that an organisation was so substantially involved with online abuse that complete resource withdrawal could be considered justified by some measure, then I'd be thinking that that would be already well within the jurisdiction of civil authorities to handle. Also, the RIPE NCC isn't set up to make judgement calls about this sort of thing.
If you're talking about general abuse management, then the suggestion of deregistration of resources is a pretty severe sanction. Put simply, it's the sort of thing that could kill a business, and given the RIPE NCC's position as a regional monopoly of registration services, they would need to be pretty careful about applying this sort of sanction to their members. Threatening to do something which would kill a business is the sort of thing that's going to be legally unworkable unless it falls into either breach of boilerplate contract terms (e.g. failure of members to pay bills, bankruptcy, etc, i.e. stuff which is routine and well-established in law) or stuff which was immediately identifiable as critical to the continuity of the RIPE NCC's core mandate, which is to ensure the correct registration of resources, e.g. continued failure of ARC audits. These things are already in the standard service agreement.
Overall, the remedies being proposed are too slow and too coarse-grained to deal with how resources are abused in real life, and too severe to deal with anything other than systematically intentional abuse, in which case it's by definition a legal problem for someone else to handle anyway.
You're right to ask for constructive ideas, but I genuinely don't see any which involve the RIPE NCC that aren't fraught with serious and in many cases, existential problems. Maybe the way to deal with this would be to put a formal proposal together, as something that can be discussed? Right now, there's nothing concrete to discuss.
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit:https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at:https://www.ripe.net/membership/mail/mailman-3-migration/
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams (FIRST) serge.droz@first.org |https://www.first.org
Serge and Working Group, Thank you for the constructive feedback, Serge. The core philosophy here is that a credible administrative escalation pathway is the only mechanism that motivates negligent operators to get their house in order before a sanction is applied. To address your points regarding clarity and to prevent endless text arguments, we can easily formalise these parameters into the draft text: 1. Defining "Systemic" Objectively: To eliminate any judgment calls by RIPE NCC staff, "systemic abuse" should be defined by a strict, binary technical threshold. For example: *An LIR is in systemic violation if a single assigned prefix remains on an approved infrastructure blocklist (such as the Spamhaus DROP list) for 14 consecutive days, or if multiple distinct prefixes within their allocation are listed concurrently.* 2. The Annual List Review: I agree with starting small. Article 1 can baseline commonly recognised threats (DDoS, phishing, malware, dictionary attacks) and include an administrative clause stating that the appropriate WG will review and update this list annually to respond to evolving threat landscapes. 3. The Feedback Mechanism: Because the workflow routes through a RIPE NCC Compliance Portal, the ticket lifecycle provides a transparent, automated feedback loop. The reporting network or CERT will receive standard system status updates (e.g., *Evidence Logged*, *Notice Relayed*, *Remediated/Closed*, *Sanction Applied or **Sanction Lifted*). 4. The abuse-c Bridge: If RIPE NCC’s routine automated validation detects a dead or bouncing abuse-c mailbox, it can automatically trigger the Step 2 Registered Mail sequence. This provides a direct, non-cryptographic pathway to wake up negligent operators before any routing freeze occurs. I suggest to the Working Group Chairs that I formally present this now as a policy proposal with the PDP. I am ready to work with you, Serge, and the chairs and anyone else who is serious about reducing these threats posed by the Internet. Submitting this formalised text to the RIPE Policy Development Process (PDP), we can move this to a structured community review. cheers denis On Wed, 5 Aug 2026 at 19:14, Serge Droz via Security-wg < security-wg@ripe.net> wrote:
Hi Dennis
I like this, thanks a lot. I think it would make sense to create a better understanding of systematic abuse, because otherwise there will be endless arguments about this.
I also think it makes sense to have a clear list of abuse types we deal with, maybe with a clause to update this every year or so. Otherwise, the EU/ENISA will determine this. I kind of like starting small, and then expand. But if people are fine with this, no problem for me.
There probably needs a feedback mechanism to the org that filed the complaint.
I still think we need, separate to this an abuse-c test. Back in the day, when we started blocking (removing NS delegations) for malicious CH-Domains, one provider didn't have a working abuse contact, so we blocked. Once they learned about the issue they fixed this. This is my point: If you have a big club like you prose, there will be a motivation to get your house in order before you escalate. As I said, lazy/negligent operators are not the same as criminal ones. The former we can probably motivate to become better.
Best Serge
On 04/08/2026 19:48, denis walker wrote:
Colleagues
One of the reasons LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry suspension or closure.
To bypass historical jurisdiction arguments regarding the definition of "abuse," we can utilize the harmonized definitions established under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering DDoS, phishing, and malware distribution) as a baseline. Just as Address Policy limits sub-assignments under contract, we have the same right to prevent abusive behaviors, using the same contractual terms.
Nick's latest email correctly highlights the core existential and scaling traps that have stalled this conversation for a decade. If a policy targets individual subscriber-level botnets, it creates an unworkable scaling failure. If a policy forces the RIPE NCC to act as a judge or deploy the 'nuclear option' of total resource withdrawal, it invites massive legal liability.
However, we can completely bypass these traps by separating low-level consumer incidents from systemic infrastructure abuse, and by shifting the sanction from resource closure to administrative quarantine.
I propose a simplified, three-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP):
---------------------------------- Article 1: 1.1 For the purposes of RIPE Address Policy, "Network Abuse" is defined, as a base line, by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks, and systemic spam botnet distribution).
1.2 The following activities are also included: - dictionary attacks
Article 2: RIPE allocated and assigned address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1.
Article 3: When the RIPE NCC receives an authenticated notification of systemic abuse involving RIPE allocated and assigned IP addresses, the registry responsible for those addresses will be given 14 working days notice to shut down the abuser or have their registry operation suspended. ----------------------------------
To address the valid operational and legal questions raised over the weekend regarding implementation, "internet policing," and protecting innocent downstream networks, the operational compliance workflow would function across three objective, administrative steps:
1. Objective Identification (The Scaling Filter) To eliminate the 'grandma's compromised router' scaling problem, the policy trigger must rely exclusively on infrastructure-only, architecture-level blocklists that explicitly exclude residential and dynamic subscriber IP space (such as the Spamhaus DROP list). An IP from a RIPE address allocation or assignment must appear on such a list for a continuous period of 14 consecutive days. This removes human bias and ensures only persistent, intentional, infrastructure-level abuse triggers the process.
2. Administrative Accountability (The Registry Mail Relay) Because the LIR is ignoring standard automated abuse-c: emails, an affected network operator or a National CERT uploads the 14-day continuous blocklist evidence to a dedicated RIPE NCC Compliance Portal.
The RIPE NCC does not act as a judge or evaluate the traffic. To strictly protect member data privacy, the official contract address of the LIR remains confidential. The RIPE NCC simply acts as an administrative postal carrier. They look up the LIR’s private legal contact details on file and forward a formal remediation notice via Registered Mail to the physical legal address they are already contractually required to maintain under their signed RIPE NCC Standard Service Agreement. This applies uniformly to all LIRs across the entire RIPE region, regardless of country, organizational structure or legal jurisdiction.
The RIPE NCC already uses this exact contract address to send out formal legal warnings for non-payment of fees or failure to pass administrative audits (ARCs). They are simply utilizing an existing, well-established legal pipe.
3. Non-Lethal Sanction (The RPKI CA Freeze) The LIR is given a strict 14 business days from the confirmed date of physical or electronic delivery to self-correct. If they quietly terminate the abuser’s account, the traffic stops, the IP automatically drops off the blocklist, the RIPE ticket closes, and no penalty is applied.
If the 14 days pass, the IP remains blacklisted, and the LIR has explicitly refused to respond to the paper trail sent by the RIR registry, the RIPE NCC executes a boilerplate administrative sanction: they freeze the LIR's RPKI CA management and append an administrative status update to the continuous NRTM serial stream by updating the LIR's ORGANISATION and ALLOCATION or ASSIGNMENT objects with a 'NON-COMPLIANCE' tag.
Operational Timeline and Liability Realities: Nick is entirely correct that threatening to kill a business over a few abusers is legally unworkable. That is why this proposal does not withdraw resources or trigger a sudden, automated network shutdown that instantly drops thousands of innocent downstream customers offline. The RIPE NCC is completely insulated from legal liability.
Initially, all downstream traffic continues to flow normally. What we are doing is cryptographically freezing the LIR's routing boundaries. They cannot shift transits or alter routes to evade security tracking, and their daily automated BGP filter rebuilds will signal their non-compliance to the market.
Furthermore, if an LIR ignores over four weeks of automated warnings and an explicit, paper-trailed legal notice from the RIR registry, concealing that operational risk from its own downstream clients, the liability for any subsequent routing disruption or upstream transit disconnection rests squarely on the non-compliant LIR—not the RIPE NCC. We completely bypass unmonitored email accounts. The RIPE NCC handles the administrative notice delivery and holds the authoritative, legally binding proof of receipt.
Nick asked for a concrete proposal to discuss rather than generalities. This 3-step framework uses existing data and mechanisms, protects data privacy, requires zero judicial filtering by RIPE NCC staff, avoids legal liability by the RIPE NCC for any consequences and protects innocent networks while finally holding non-responsive resource holders contractually accountable.
Let's work together to end this 20 year impasse...
cheers denis
On Tue, 4 Aug 2026 at 16:27, Nick Hilliard <nick@foobar.org> wrote:
Serge Droz via Security-wg wrote on 04/08/2026 13:30:
Nick: I'd appreciate if you could contribute more than just reasons for why something doesn't work. Or is, what you are saying, that LACNIC and APNIC just don't get it. I will now stop answering to your objections, since this is not constructive.
Serge,
I replied to a suggestion that you made, and if I understand it correctly, what LACNIC and APNIC are doing is substantially different to what you were suggesting in your email.
Possibly this is one of the problems with this (recurrent) conversation - different people are talking across each other about different potential solutions to different problems in the same email thread.
Specifically what you suggested in your last email is fairly fine-grained. Spam and residential proxies are a huge problem and a noticeable percentage of subscriber accounts host compromised equipment - TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your proposal is effectively for individual subscriber-level stuff to be handled by or escalated in some way another to the RIPE NCC, there's a huge scaling problem right there. The RIPE NCC doesn't have the scope or scale to become a clearinghouse for abuse complaints at that level of granularity.
At the point that an organisation was so substantially involved with online abuse that complete resource withdrawal could be considered justified by some measure, then I'd be thinking that that would be already well within the jurisdiction of civil authorities to handle. Also, the RIPE NCC isn't set up to make judgement calls about this sort of thing.
If you're talking about general abuse management, then the suggestion of deregistration of resources is a pretty severe sanction. Put simply, it's the sort of thing that could kill a business, and given the RIPE NCC's position as a regional monopoly of registration services, they would need to be pretty careful about applying this sort of sanction to their members. Threatening to do something which would kill a business is the sort of thing that's going to be legally unworkable unless it falls into either breach of boilerplate contract terms (e.g. failure of members to pay bills, bankruptcy, etc, i.e. stuff which is routine and well-established in law) or stuff which was immediately identifiable as critical to the continuity of the RIPE NCC's core mandate, which is to ensure the correct registration of resources, e.g. continued failure of ARC audits. These things are already in the standard service agreement.
Overall, the remedies being proposed are too slow and too coarse-grained to deal with how resources are abused in real life, and too severe to deal with anything other than systematically intentional abuse, in which case it's by definition a legal problem for someone else to handle anyway.
You're right to ask for constructive ideas, but I genuinely don't see any which involve the RIPE NCC that aren't fraught with serious and in many cases, existential problems. Maybe the way to deal with this would be to put a formal proposal together, as something that can be discussed? Right now, there's nothing concrete to discuss.
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams (FIRST)serge.droz@first.org | https://www.first.org
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Denis, Everyone, As always the Co-Chairs are available to help with such matters, as are the NCC. If you would like to pull your proposal into the PDP template and send it to security-wg-chairs@ripe.net we can go from there. Thank you, Brian Co-Chair, RIPE Security WG Brian Nisbet (he/him) Head of Service Operations Asiera (formerly HEAnet), Ireland's National Research and Education Network North Dock One, 93-94 North Wall Quay, Dublin 1, D01 V8Y6 +35316609040 brian.nisbet@asiera.ie www.heanet.ie<http://www.heanet.ie> www.asiera.ie<https://www.asiera.ie/> Registered in Ireland, No. 275301. CRA No. 20036270 ________________________________ From: denis walker <ripedenis@gmail.com> Sent: Thursday 6 August 2026 16:24 To: Serge Droz <serge.droz@first.org> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms CAUTION[External]: This email originated from outside of the organisation. Do not click on links or open the attachments unless you recognise the sender and know the content is safe. Serge and Working Group, Thank you for the constructive feedback, Serge. The core philosophy here is that a credible administrative escalation pathway is the only mechanism that motivates negligent operators to get their house in order before a sanction is applied. To address your points regarding clarity and to prevent endless text arguments, we can easily formalise these parameters into the draft text: 1. Defining "Systemic" Objectively: To eliminate any judgment calls by RIPE NCC staff, "systemic abuse" should be defined by a strict, binary technical threshold. For example: An LIR is in systemic violation if a single assigned prefix remains on an approved infrastructure blocklist (such as the Spamhaus DROP list) for 14 consecutive days, or if multiple distinct prefixes within their allocation are listed concurrently. 2. The Annual List Review: I agree with starting small. Article 1 can baseline commonly recognised threats (DDoS, phishing, malware, dictionary attacks) and include an administrative clause stating that the appropriate WG will review and update this list annually to respond to evolving threat landscapes. 3. The Feedback Mechanism: Because the workflow routes through a RIPE NCC Compliance Portal, the ticket lifecycle provides a transparent, automated feedback loop. The reporting network or CERT will receive standard system status updates (e.g., Evidence Logged, Notice Relayed, Remediated/Closed, Sanction Applied or Sanction Lifted). 4. The abuse-c Bridge: If RIPE NCC’s routine automated validation detects a dead or bouncing abuse-c mailbox, it can automatically trigger the Step 2 Registered Mail sequence. This provides a direct, non-cryptographic pathway to wake up negligent operators before any routing freeze occurs. I suggest to the Working Group Chairs that I formally present this now as a policy proposal with the PDP. I am ready to work with you, Serge, and the chairs and anyone else who is serious about reducing these threats posed by the Internet. Submitting this formalised text to the RIPE Policy Development Process (PDP), we can move this to a structured community review. cheers denis On Wed, 5 Aug 2026 at 19:14, Serge Droz via Security-wg <security-wg@ripe.net<mailto:security-wg@ripe.net>> wrote: Hi Dennis I like this, thanks a lot. I think it would make sense to create a better understanding of systematic abuse, because otherwise there will be endless arguments about this. I also think it makes sense to have a clear list of abuse types we deal with, maybe with a clause to update this every year or so. Otherwise, the EU/ENISA will determine this. I kind of like starting small, and then expand. But if people are fine with this, no problem for me. There probably needs a feedback mechanism to the org that filed the complaint. I still think we need, separate to this an abuse-c test. Back in the day, when we started blocking (removing NS delegations) for malicious CH-Domains, one provider didn't have a working abuse contact, so we blocked. Once they learned about the issue they fixed this. This is my point: If you have a big club like you prose, there will be a motivation to get your house in order before you escalate. As I said, lazy/negligent operators are not the same as criminal ones. The former we can probably motivate to become better. Best Serge On 04/08/2026 19:48, denis walker wrote: Colleagues One of the reasons LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry suspension or closure. To bypass historical jurisdiction arguments regarding the definition of "abuse," we can utilize the harmonized definitions established under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering DDoS, phishing, and malware distribution) as a baseline. Just as Address Policy limits sub-assignments under contract, we have the same right to prevent abusive behaviors, using the same contractual terms. Nick's latest email correctly highlights the core existential and scaling traps that have stalled this conversation for a decade. If a policy targets individual subscriber-level botnets, it creates an unworkable scaling failure. If a policy forces the RIPE NCC to act as a judge or deploy the 'nuclear option' of total resource withdrawal, it invites massive legal liability. However, we can completely bypass these traps by separating low-level consumer incidents from systemic infrastructure abuse, and by shifting the sanction from resource closure to administrative quarantine. I propose a simplified, three-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP): ---------------------------------- Article 1: 1.1 For the purposes of RIPE Address Policy, "Network Abuse" is defined, as a base line, by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks, and systemic spam botnet distribution). 1.2 The following activities are also included: - dictionary attacks Article 2: RIPE allocated and assigned address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1. Article 3: When the RIPE NCC receives an authenticated notification of systemic abuse involving RIPE allocated and assigned IP addresses, the registry responsible for those addresses will be given 14 working days notice to shut down the abuser or have their registry operation suspended. ---------------------------------- To address the valid operational and legal questions raised over the weekend regarding implementation, "internet policing," and protecting innocent downstream networks, the operational compliance workflow would function across three objective, administrative steps: 1. Objective Identification (The Scaling Filter) To eliminate the 'grandma's compromised router' scaling problem, the policy trigger must rely exclusively on infrastructure-only, architecture-level blocklists that explicitly exclude residential and dynamic subscriber IP space (such as the Spamhaus DROP list). An IP from a RIPE address allocation or assignment must appear on such a list for a continuous period of 14 consecutive days. This removes human bias and ensures only persistent, intentional, infrastructure-level abuse triggers the process. 2. Administrative Accountability (The Registry Mail Relay) Because the LIR is ignoring standard automated abuse-c: emails, an affected network operator or a National CERT uploads the 14-day continuous blocklist evidence to a dedicated RIPE NCC Compliance Portal. The RIPE NCC does not act as a judge or evaluate the traffic. To strictly protect member data privacy, the official contract address of the LIR remains confidential. The RIPE NCC simply acts as an administrative postal carrier. They look up the LIR’s private legal contact details on file and forward a formal remediation notice via Registered Mail to the physical legal address they are already contractually required to maintain under their signed RIPE NCC Standard Service Agreement. This applies uniformly to all LIRs across the entire RIPE region, regardless of country, organizational structure or legal jurisdiction. The RIPE NCC already uses this exact contract address to send out formal legal warnings for non-payment of fees or failure to pass administrative audits (ARCs). They are simply utilizing an existing, well-established legal pipe. 3. Non-Lethal Sanction (The RPKI CA Freeze) The LIR is given a strict 14 business days from the confirmed date of physical or electronic delivery to self-correct. If they quietly terminate the abuser’s account, the traffic stops, the IP automatically drops off the blocklist, the RIPE ticket closes, and no penalty is applied. If the 14 days pass, the IP remains blacklisted, and the LIR has explicitly refused to respond to the paper trail sent by the RIR registry, the RIPE NCC executes a boilerplate administrative sanction: they freeze the LIR's RPKI CA management and append an administrative status update to the continuous NRTM serial stream by updating the LIR's ORGANISATION and ALLOCATION or ASSIGNMENT objects with a 'NON-COMPLIANCE' tag. Operational Timeline and Liability Realities: Nick is entirely correct that threatening to kill a business over a few abusers is legally unworkable. That is why this proposal does not withdraw resources or trigger a sudden, automated network shutdown that instantly drops thousands of innocent downstream customers offline. The RIPE NCC is completely insulated from legal liability. Initially, all downstream traffic continues to flow normally. What we are doing is cryptographically freezing the LIR's routing boundaries. They cannot shift transits or alter routes to evade security tracking, and their daily automated BGP filter rebuilds will signal their non-compliance to the market. Furthermore, if an LIR ignores over four weeks of automated warnings and an explicit, paper-trailed legal notice from the RIR registry, concealing that operational risk from its own downstream clients, the liability for any subsequent routing disruption or upstream transit disconnection rests squarely on the non-compliant LIR—not the RIPE NCC. We completely bypass unmonitored email accounts. The RIPE NCC handles the administrative notice delivery and holds the authoritative, legally binding proof of receipt. Nick asked for a concrete proposal to discuss rather than generalities. This 3-step framework uses existing data and mechanisms, protects data privacy, requires zero judicial filtering by RIPE NCC staff, avoids legal liability by the RIPE NCC for any consequences and protects innocent networks while finally holding non-responsive resource holders contractually accountable. Let's work together to end this 20 year impasse... cheers denis On Tue, 4 Aug 2026 at 16:27, Nick Hilliard <nick@foobar.org<mailto:nick@foobar.org>> wrote: Serge Droz via Security-wg wrote on 04/08/2026 13:30:
Nick: I'd appreciate if you could contribute more than just reasons for why something doesn't work. Or is, what you are saying, that LACNIC and APNIC just don't get it. I will now stop answering to your objections, since this is not constructive.
Serge, I replied to a suggestion that you made, and if I understand it correctly, what LACNIC and APNIC are doing is substantially different to what you were suggesting in your email. Possibly this is one of the problems with this (recurrent) conversation - different people are talking across each other about different potential solutions to different problems in the same email thread. Specifically what you suggested in your last email is fairly fine-grained. Spam and residential proxies are a huge problem and a noticeable percentage of subscriber accounts host compromised equipment - TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your proposal is effectively for individual subscriber-level stuff to be handled by or escalated in some way another to the RIPE NCC, there's a huge scaling problem right there. The RIPE NCC doesn't have the scope or scale to become a clearinghouse for abuse complaints at that level of granularity. At the point that an organisation was so substantially involved with online abuse that complete resource withdrawal could be considered justified by some measure, then I'd be thinking that that would be already well within the jurisdiction of civil authorities to handle. Also, the RIPE NCC isn't set up to make judgement calls about this sort of thing. If you're talking about general abuse management, then the suggestion of deregistration of resources is a pretty severe sanction. Put simply, it's the sort of thing that could kill a business, and given the RIPE NCC's position as a regional monopoly of registration services, they would need to be pretty careful about applying this sort of sanction to their members. Threatening to do something which would kill a business is the sort of thing that's going to be legally unworkable unless it falls into either breach of boilerplate contract terms (e.g. failure of members to pay bills, bankruptcy, etc, i.e. stuff which is routine and well-established in law) or stuff which was immediately identifiable as critical to the continuity of the RIPE NCC's core mandate, which is to ensure the correct registration of resources, e.g. continued failure of ARC audits. These things are already in the standard service agreement. Overall, the remedies being proposed are too slow and too coarse-grained to deal with how resources are abused in real life, and too severe to deal with anything other than systematically intentional abuse, in which case it's by definition a legal problem for someone else to handle anyway. You're right to ask for constructive ideas, but I genuinely don't see any which involve the RIPE NCC that aren't fraught with serious and in many cases, existential problems. Maybe the way to deal with this would be to put a formal proposal together, as something that can be discussed? Right now, there's nothing concrete to discuss. Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ -- Dr. Serge Droz Director, Forum of Incident Response and Security Teams (FIRST) serge.droz@first.org<mailto:serge.droz@first.org> | https://www.first.org ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Hi Denis/All are we going to follow up on this? I think we should. The chairs have offered to support us to put this into the proper format, and maybe we can actually move forward. Best Serge On 06/08/2026 17:24, denis walker wrote:
Serge and Working Group, Thank you for the constructive feedback, Serge. The core philosophy here is that a credible administrative escalation pathway is the only mechanism that motivates negligent operators to get their house in order before a sanction is applied. To address your points regarding clarity and to prevent endless text arguments, we can easily formalise these parameters into the draft text:
1. Defining "Systemic" Objectively: To eliminate any judgment calls by RIPE NCC staff, "systemic abuse" should be defined by a strict, binary technical threshold. For example: /An LIR is in systemic violation if a single assigned prefix remains on an approved infrastructure blocklist (such as the Spamhaus DROP list) for 14 consecutive days, or if multiple distinct prefixes within their allocation are listed concurrently./ 2. The Annual List Review: I agree with starting small. Article 1 can baseline commonly recognised threats (DDoS, phishing, malware, dictionary attacks) and include an administrative clause stating that the appropriate WG will review and update this list annually to respond to evolving threat landscapes. 3. The Feedback Mechanism: Because the workflow routes through a RIPE NCC Compliance Portal, the ticket lifecycle provides a transparent, automated feedback loop. The reporting network or CERT will receive standard system status updates (e.g., /Evidence Logged/, /Notice Relayed/, /Remediated/Closed/, /Sanction Applied or //Sanction Lifted/). 4. The |abuse-c| Bridge: If RIPE NCC’s routine automated validation detects a dead or bouncing |abuse-c| mailbox, it can automatically trigger the Step 2 Registered Mail sequence. This provides a direct, non-cryptographic pathway to wake up negligent operators before any routing freeze occurs.
I suggest to the Working Group Chairs that I formally present this now as a policy proposal with the PDP. I am ready to work with you, Serge, and the chairs and anyone else who is serious about reducing these threats posed by the Internet. Submitting this formalised text to the RIPE Policy Development Process (PDP), we can move this to a structured community review.
cheers denis
On Wed, 5 Aug 2026 at 19:14, Serge Droz via Security-wg <security- wg@ripe.net <mailto:security-wg@ripe.net>> wrote:
__
Hi Dennis
I like this, thanks a lot. I think it would make sense to create a better understanding of systematic abuse, because otherwise there will be endless arguments about this.
I also think it makes sense to have a clear list of abuse types we deal with, maybe with a clause to update this every year or so. Otherwise, the EU/ENISA will determine this. I kind of like starting small, and then expand. But if people are fine with this, no problem for me.
There probably needs a feedback mechanism to the org that filed the complaint.
I still think we need, separate to this an abuse-c test. Back in the day, when we started blocking (removing NS delegations) for malicious CH-Domains, one provider didn't have a working abuse contact, so we blocked. Once they learned about the issue they fixed this. This is my point: If you have a big club like you prose, there will be a motivation to get your house in order before you escalate. As I said, lazy/negligent operators are not the same as criminal ones. The former we can probably motivate to become better.
Best Serge
On 04/08/2026 19:48, denis walker wrote:
Colleagues
One of the reasons LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry suspension or closure.
To bypass historical jurisdiction arguments regarding the definition of "abuse," we can utilize the harmonized definitions established under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics (covering DDoS, phishing, and malware distribution) as a baseline. Just as Address Policy limits sub-assignments under contract, we have the same right to prevent abusive behaviors, using the same contractual terms.
Nick's latest email correctly highlights the core existential and scaling traps that have stalled this conversation for a decade. If a policy targets individual subscriber-level botnets, it creates an unworkable scaling failure. If a policy forces the RIPE NCC to act as a judge or deploy the 'nuclear option' of total resource withdrawal, it invites massive legal liability.
However, we can completely bypass these traps by separating low- level consumer incidents from systemic infrastructure abuse, and by shifting the sanction from resource closure to administrative quarantine.
I propose a simplified, three-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP):
---------------------------------- Article 1: 1.1 For the purposes of RIPE Address Policy, "Network Abuse" is defined, as a base line, by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks, and systemic spam botnet distribution).
1.2 The following activities are also included: - dictionary attacks
Article 2: RIPE allocated and assigned address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1.
Article 3: When the RIPE NCC receives an authenticated notification of systemic abuse involving RIPE allocated and assigned IP addresses, the registry responsible for those addresses will be given 14 working days notice to shut down the abuser or have their registry operation suspended. ----------------------------------
To address the valid operational and legal questions raised over the weekend regarding implementation, "internet policing," and protecting innocent downstream networks, the operational compliance workflow would function across three objective, administrative steps:
1. Objective Identification (The Scaling Filter) To eliminate the 'grandma's compromised router' scaling problem, the policy trigger must rely exclusively on infrastructure-only, architecture-level blocklists that explicitly exclude residential and dynamic subscriber IP space (such as the Spamhaus DROP list). An IP from a RIPE address allocation or assignment must appear on such a list for a continuous period of 14 consecutive days. This removes human bias and ensures only persistent, intentional, infrastructure-level abuse triggers the process.
2. Administrative Accountability (The Registry Mail Relay) Because the LIR is ignoring standard automated abuse-c: emails, an affected network operator or a National CERT uploads the 14-day continuous blocklist evidence to a dedicated RIPE NCC Compliance Portal.
The RIPE NCC does not act as a judge or evaluate the traffic. To strictly protect member data privacy, the official contract address of the LIR remains confidential. The RIPE NCC simply acts as an administrative postal carrier. They look up the LIR’s private legal contact details on file and forward a formal remediation notice via Registered Mail to the physical legal address they are already contractually required to maintain under their signed RIPE NCC Standard Service Agreement. This applies uniformly to all LIRs across the entire RIPE region, regardless of country, organizational structure or legal jurisdiction.
The RIPE NCC already uses this exact contract address to send out formal legal warnings for non-payment of fees or failure to pass administrative audits (ARCs). They are simply utilizing an existing, well-established legal pipe.
3. Non-Lethal Sanction (The RPKI CA Freeze) The LIR is given a strict 14 business days from the confirmed date of physical or electronic delivery to self-correct. If they quietly terminate the abuser’s account, the traffic stops, the IP automatically drops off the blocklist, the RIPE ticket closes, and no penalty is applied.
If the 14 days pass, the IP remains blacklisted, and the LIR has explicitly refused to respond to the paper trail sent by the RIR registry, the RIPE NCC executes a boilerplate administrative sanction: they freeze the LIR's RPKI CA management and append an administrative status update to the continuous NRTM serial stream by updating the LIR's ORGANISATION and ALLOCATION or ASSIGNMENT objects with a 'NON-COMPLIANCE' tag.
Operational Timeline and Liability Realities: Nick is entirely correct that threatening to kill a business over a few abusers is legally unworkable. That is why this proposal does not withdraw resources or trigger a sudden, automated network shutdown that instantly drops thousands of innocent downstream customers offline. The RIPE NCC is completely insulated from legal liability.
Initially, all downstream traffic continues to flow normally. What we are doing is cryptographically freezing the LIR's routing boundaries. They cannot shift transits or alter routes to evade security tracking, and their daily automated BGP filter rebuilds will signal their non-compliance to the market.
Furthermore, if an LIR ignores over four weeks of automated warnings and an explicit, paper-trailed legal notice from the RIR registry, concealing that operational risk from its own downstream clients, the liability for any subsequent routing disruption or upstream transit disconnection rests squarely on the non-compliant LIR—not the RIPE NCC. We completely bypass unmonitored email accounts. The RIPE NCC handles the administrative notice delivery and holds the authoritative, legally binding proof of receipt.
Nick asked for a concrete proposal to discuss rather than generalities. This 3-step framework uses existing data and mechanisms, protects data privacy, requires zero judicial filtering by RIPE NCC staff, avoids legal liability by the RIPE NCC for any consequences and protects innocent networks while finally holding non-responsive resource holders contractually accountable.
Let's work together to end this 20 year impasse...
cheers denis
On Tue, 4 Aug 2026 at 16:27, Nick Hilliard <nick@foobar.org <mailto:nick@foobar.org>> wrote:
Serge Droz via Security-wg wrote on 04/08/2026 13:30: > Nick: I'd appreciate if you could contribute more than just reasons for > why something doesn't work. Or is, what you are saying, that LACNIC and > APNIC just don't get it. I will now stop answering to your objections, > since this is not constructive.
Serge,
I replied to a suggestion that you made, and if I understand it correctly, what LACNIC and APNIC are doing is substantially different to what you were suggesting in your email.
Possibly this is one of the problems with this (recurrent) conversation - different people are talking across each other about different potential solutions to different problems in the same email thread.
Specifically what you suggested in your last email is fairly fine-grained. Spam and residential proxies are a huge problem and a noticeable percentage of subscriber accounts host compromised equipment - TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your proposal is effectively for individual subscriber-level stuff to be handled by or escalated in some way another to the RIPE NCC, there's a huge scaling problem right there. The RIPE NCC doesn't have the scope or scale to become a clearinghouse for abuse complaints at that level of granularity.
At the point that an organisation was so substantially involved with online abuse that complete resource withdrawal could be considered justified by some measure, then I'd be thinking that that would be already well within the jurisdiction of civil authorities to handle. Also, the RIPE NCC isn't set up to make judgement calls about this sort of thing.
If you're talking about general abuse management, then the suggestion of deregistration of resources is a pretty severe sanction. Put simply, it's the sort of thing that could kill a business, and given the RIPE NCC's position as a regional monopoly of registration services, they would need to be pretty careful about applying this sort of sanction to their members. Threatening to do something which would kill a business is the sort of thing that's going to be legally unworkable unless it falls into either breach of boilerplate contract terms (e.g. failure of members to pay bills, bankruptcy, etc, i.e. stuff which is routine and well-established in law) or stuff which was immediately identifiable as critical to the continuity of the RIPE NCC's core mandate, which is to ensure the correct registration of resources, e.g. continued failure of ARC audits. These things are already in the standard service agreement.
Overall, the remedies being proposed are too slow and too coarse-grained to deal with how resources are abused in real life, and too severe to deal with anything other than systematically intentional abuse, in which case it's by definition a legal problem for someone else to handle anyway.
You're right to ask for constructive ideas, but I genuinely don't see any which involve the RIPE NCC that aren't fraught with serious and in many cases, existential problems. Maybe the way to deal with this would be to put a formal proposal together, as something that can be discussed? Right now, there's nothing concrete to discuss.
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/ mailman3/lists/security-wg.ripe.net/ <https:// mailman.ripe.net/mailman3/lists/security-wg.ripe.net/> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/ mailman-3-migration/ <https://www.ripe.net/membership/mail/ mailman-3-migration/>
----- To unsubscribe from this mailing list or change your subscription options, please visit:https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ <https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at:https://www.ripe.net/membership/mail/mailman-3-migration/ <https://www.ripe.net/membership/mail/mailman-3-migration/>
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams (FIRST) serge.droz@first.org <mailto:serge.droz@first.org> |https://www.first.org <https://www.first.org>
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ security-wg.ripe.net/ <https://mailman.ripe.net/mailman3/lists/ security-wg.ripe.net/> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3- migration/ <https://www.ripe.net/membership/mail/mailman-3-migration/>
-- Dr. Serge Droz Director, Forum of Incident Response and Security Teams (FIRST) serge.droz@first.org | https://www.first.org
Hi Serge, colleagues On Mon, 17 Aug 2026 at 21:15, Serge Droz via Security-wg < security-wg@ripe.net> wrote:
Hi Denis/All
are we going to follow up on this? I think we should. The chairs have offered to support us to put this into the proper format, and maybe we can actually move forward.
Best Serge
Yes, absolutely. The text has been modified using the feedback from the list discussion — including explicit BCP 185 routing practices, the strict infrastructure-only triggers, and a dedicated, independent administrative quarantine framework. A first draft of a policy proposal template was submitted to the Working Group chairs recently. Some of the chair team have been out of their office over these last couple of weeks. When they are able to review it, then it will move forward. Once the text is passed to the RIPE NCC Policy Development Office (PDO), they will formally assign a Proposal Number and launch the official Discussion Phase. I look forward to opening the formalized draft up for full community discussion the moment the PDO issues the tracking number. Cheers Denis
Gert,
On 8/1/2026, at 18:45, Gert Doering <gert@space.net> wrote:
On 7/31/2026, at 16:41, Nick Hilliard <nick@foobar.org> wrote: The issue we have in the RIPE security wg, and before that, abuse-wg and anti-spam-wg, is that the solutions being proposed involves changing the nature of the RIPE NCC from a registry into an quasi-judicial and enforcement body. Essentially the arguments are of the form which could waspily be described as "politicians' logic":
Technically, we crossed this line when we introduced not just the company names, but also their registration numbers into the RIPE Database. NWI-21.
This very much sounds like a thing a registry would do, like, register numbers and document who has them, in an unambiguous way? So which line exactly was crossed by publishing more unambiguous holder info, for legal entities?
Not all of the data collected by the registry should be published. Publishing an "official" identifier is a significant step to future steps towards technical and/or political restrictions based on the registry data. -- Best, Sergey
Hi, On Sun, Aug 02, 2026 at 11:31:27PM +0300, Sergey Myasoedov via Security-wg wrote:
Technically, we crossed this line when we introduced not just the company names, but also their registration numbers into the RIPE Database. NWI-21.
This very much sounds like a thing a registry would do, like, register numbers and document who has them, in an unambiguous way? So which line exactly was crossed by publishing more unambiguous holder info, for legal entities?
Not all of the data collected by the registry should be published. Publishing an "official" identifier is a significant step to future steps towards technical and/or political restrictions based on the registry data.
The RIPE NCC does not publish "all the data collected", far from it. It does, and should, publish who is the receiver of a set of numbers received from the RIPE NCC. In commercial relationships, requiring the legal registry number of your contract partner is the most normal thing to do (at least over here). I fail to make the conclusion how this will pave the way to future "restrictions based on the data". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert,
On 8/2/2026, at 23:35, Gert Doering <gert@space.net> wrote:
Technically, we crossed this line when we introduced not just the company names, but also their registration numbers into the RIPE Database. NWI-21. This very much sounds like a thing a registry would do, like, register numbers and document who has them, in an unambiguous way? So which line exactly was crossed by publishing more unambiguous holder info, for legal entities? Not all of the data collected by the registry should be published. Publishing an "official" identifier is a significant step to future steps towards technical and/or political restrictions based on the registry data. ... I fail to make the conclusion how this will pave the way to future "restrictions based on the data".
When the data is public and could be cross-verified, the approach "we can't introduce automatic restrictions because we can't identify the holder/related persons" is not longer valid, while the approach "as we could identify the holder/related persons, it's fair and logical to use this data against those who don't behave" could arise. The phonebook could contain the subscriber's full address, but in most cases, this information is excessive. -- Best, Sergey
On 31 Jul 2026, at 13:08, denis walker <ripedenis@gmail.com> wrote: […]
The rules of the game are set by policy. Policy is set by the RIPE community. It only takes a handful of people saying yes and the rules are changed. Then ALL resource holders, LIRs, End Users MUST obey the new rules. If you persistently break the rules you can be closed down and have resources taken away. To me, that sounds like a definition of absolute authority.
But let's get to the core of your issue here. Do you have a problem with limiting malicious abusive behaviour on the Internet? Or are you just arguing over any point to slow the process down and ultimately prevent any policy from addressing this problem?
EVERY time we have looked at this issue over the last couple of decades, 'someone' creates background noise, finds problems, develops arguments against and ultimately prevents any action from being taken. A couple of people even said it in this thread. This WG has a reputation for not taking action. This has to change. That's why I'm suggesting a very simple policy. Here's a list of bad things. You must not do these. Do you have a problem with this?
Who would investigate claims? Who would judge? The RIPE NCC has a good structure for handing things out when conditions are met. But taking them away is much more challenging and expensive. Even if a policy proposal along these lines was accepted, implementation would probably require higher fees, which might be a challenge. Regards, Leo
Nobody needs to investigate, this is not how it has been done in other 3 RIRs (one pending of implementation). This has been explained thousands of times in previous proposals. 1) You must have a standard way to send the report to the resource holder, not using a form. Up to now this has been done in other RIRs by email. 2) If the resource holder don’t take an action, or the reporting standard way doesn’t work, you can escalate to the RIR, so they look for lack of compliance because a) the reporting is not working, b) is ignored, c) alternative non-standard reporting is enforced. 3) Lack of compliance, if not resolved, can enact a reclamation procedure. If the RIR believes (for example), a DDOS or spam are legal, then the problems is out of the hands of the RIR, and is up to each jurisdiction if the reporter can take legal actions, or filter them or even blame them publicly so others also filter them, or whatever. Regards, Jordi @jordipalet
El 31 jul 2026, a las 17:45, Leo Vegoda <leo@vegoda.org> escribió:
On 31 Jul 2026, at 13:08, denis walker <ripedenis@gmail.com> wrote:
[…]
The rules of the game are set by policy. Policy is set by the RIPE community. It only takes a handful of people saying yes and the rules are changed. Then ALL resource holders, LIRs, End Users MUST obey the new rules. If you persistently break the rules you can be closed down and have resources taken away. To me, that sounds like a definition of absolute authority.
But let's get to the core of your issue here. Do you have a problem with limiting malicious abusive behaviour on the Internet? Or are you just arguing over any point to slow the process down and ultimately prevent any policy from addressing this problem?
EVERY time we have looked at this issue over the last couple of decades, 'someone' creates background noise, finds problems, develops arguments against and ultimately prevents any action from being taken. A couple of people even said it in this thread. This WG has a reputation for not taking action. This has to change. That's why I'm suggesting a very simple policy. Here's a list of bad things. You must not do these. Do you have a problem with this?
Who would investigate claims? Who would judge?
The RIPE NCC has a good structure for handing things out when conditions are met. But taking them away is much more challenging and expensive.
Even if a policy proposal along these lines was accepted, implementation would probably require higher fees, which might be a challenge.
Regards,
Leo ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On 31 Jul 2026, at 16:58, jordi.palet--- via Security-wg <security-wg@ripe.net> wrote:
Nobody needs to investigate, this is not how it has been done in other 3 RIRs (one pending of implementation).
But that’s not what Denis suggested. I was responding to his words and not to what has been done elsewhere. Regards, Leo
Ok, understood. Reading in disorder … In any case, I don’t think is possible to setup an investigation point in the RIR, because different jurisdictions can have different opinions of what is abuse and what is not. Unless we previously define abuse at the RIR as part of the policy itself. The only chance that can reach consensus is to be very “soft” in the abuse definition, which I don’t think it will be useful. Much better to avoid entering into that. Defining a standard way to report (such as already being accepted XARF). The discussion only is if we can just use email for sending the XARF (like it is being done at the moment) or we want to make it more complex and then it means slow to adopt ...
El 31 jul 2026, a las 18:04, Leo Vegoda <leo@vegoda.org> escribió:
On 31 Jul 2026, at 16:58, jordi.palet--- via Security-wg <security-wg@ripe.net> wrote:
Nobody needs to investigate, this is not how it has been done in other 3 RIRs (one pending of implementation).
But that’s not what Denis suggested. I was responding to his words and not to what has been done elsewhere.
Regards,
Leo
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
jordi.palet--- via Security-wg <security-wg@ripe.net> wrote: > 1) You must have a standard way to send the report to the resource > holder, not using a form. Up to now this has been done in other RIRs by > email. > 2) If the resource holder don’t take an action, or the > reporting standard way doesn’t work, you can escalate to the RIR, so > they look for lack of compliance because So, in this case the (meta-)report is that reporting isn't working.
3) Lack of compliance, if not resolved, can enact a reclamation procedure.
And in the case of a meta-report, would you agree that the RIR is competent to judge if they can reach a reporting system? (That doesn't have to cause resources to be reclaimed. It could just result in an entry in a table, by which others might judge reputation) -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours **
El 1 ago 2026, a las 16:05, Michael Richardson <mcr+ietf@sandelman.ca> escribió:
jordi.palet--- via Security-wg <security-wg@ripe.net> wrote:
1) You must have a standard way to send the report to the resource holder, not using a form. Up to now this has been done in other RIRs by email. 2) If the resource holder don’t take an action, or the reporting standard way doesn’t work, you can escalate to the RIR, so they look for lack of compliance because
So, in this case the (meta-)report is that reporting isn't working.
3) Lack of compliance, if not resolved, can enact a reclamation procedure.
And in the case of a meta-report, would you agree that the RIR is competent to judge if they can reach a reporting system?
(That doesn't have to cause resources to be reclaimed. It could just result in an entry in a table, by which others might judge reputation)
That depends, on the lack of compliance actions. For example in LACNIC, you have several opportunities to correct the situation, and then in case you’re not reachable, the resources are published for 3 months as “in recovery”, only then if you still haven’t been contacted and resolved the situation, will be recovered.
-- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours **
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
might rephrase to “not only, but every community needs to fix this in their remit of operations” Add that if icann sanctions can shut down a registrar, why should an LIR not be subject to a similar penalty? —— Also, it's something of an overclaim to say that only the RIPE Community can fix this, and only by creating a policy which mandates LIR closure for non-compliance. Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Suresh Ramasubramanian wrote on 31/07/2026 02:52:
Add that if icann sanctions can shut down a registrar, why should an LIR not be subject to a similar penalty?
Suresh, Have you read the Termination of Agreement clauses in the ICANN Registrar Accreditation Agreement, Section 5.3?
https://www.icann.org/en/contracted-parties/accredited-registrars/registrar-...
Specifically, under what conditions can the registrar agreement be terminated by ICANN? Nick
There are narrowly defined and stringent conditions yes but i must confess I fail to see your point here. --srs ________________________________ From: Nick Hilliard <nick@foobar.org> Sent: Friday, 31 July 2026 16:00:20 To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: denis walker <ripedenis@gmail.com>; security-wg@ripe.net <security-wg@ripe.net> Subject: Re: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms Suresh Ramasubramanian wrote on 31/07/2026 02:52:
Add that if icann sanctions can shut down a registrar, why should an LIR not be subject to a similar penalty?
Suresh, Have you read the Termination of Agreement clauses in the ICANN Registrar Accreditation Agreement, Section 5.3?
https://www.icann.org/en/contracted-parties/accredited-registrars/registrar-...
Specifically, under what conditions can the registrar agreement be terminated by ICANN? Nick
Suresh Ramasubramanian wrote on 31/07/2026 11:36:
There are narrowly defined and stringent conditions yes but i must confess I fail to see your point here.
my point is that they're largely boilerplate contract termination terms. There's nothing in there to say that e.g. if an internet domain is used for spamming or illegal hosting, and the registrar fails to pull it, that the registrar agreement would be terminated. Nick
Denis I like that idea. Especially since there are many groups right now pushing at least within the EU for clear legislation to mandate Service Providers to be better. The DSA (Digital Services Act) was a start, although it was weak on Service Providers, and only content focused, but I know there are discussions going on right now to fix the holes. And yes I agree again, lets not talk transport. Transport is fixed with things like xarf.org ( http://xarf.org/ ) and the worldwide policies about abuse-contacts. This is an accountability problem. On all levels, not only the Hyperscaler level. Thanks, Tobias On Thu, Jul 30, 2026 at 1:39 AM, denis walker < ripedenis@gmail.com > wrote:
Serge, Michael, and Working Group, The reason LIRs do not process abuse reports is because RIPE policy currently makes it entirely free to ignore them. We can only fix this by creating a clear, contractual incentive where permitting systemic abuse carries the risk of registry closure. To avoid the historical jurisdiction arguments regarding the definition of "abuse" (used every time we try to address this issue), we can simply utilize the harmonized definitions established under the EU Directive on Cybercrime ( 2013/40 /EU) and ENISA metrics (covering DDoS, phishing, and malware distribution). Just as Address Policy limits sub-assignments under contract, we have the absolute authority to limit malicious routing behaviors. I propose a simplified, two-article baseline framework for an Anti-Abuse Policy under the Policy Development Process (PDP):
* Article 1: For the purposes of RIPE Address Policy, "Network Abuse" is defined by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks and systemic spam botnet distribution). * Article 2: RIPE address space must not be systematically utilized to facilitate Network Abuse as defined in Article 1.
By anchoring to an external regulatory baseline, we save the working group from endless definitional debates. If a member receives authenticated, systemic notifications of these technical harms and explicitly refuses to remediate them, they are in violation of RIPE Policy—with the ultimate sanction of triggering standard contractual registry closure procedures. Let's stop trying to fix the transport mechanism of the report and finally address the accountability of the resource holder.
cheers denis
On Wed, 29 Jul 2026 at 21:02, Michael Duffy via Security-wg < security-wg@ ripe. net ( security-wg@ripe.net ) > wrote:
From a SOC/abuse perspective, I think we're solving the wrong problem. Attackers move in minutes. Most abuse handling still happens in hours or days. By the time a report is reviewed, the infrastructure has often already been rotated or abandoned. The issue isn't how reports are submitted-email, web forms, or a new API. The issue is whether there's an operational capability and willingness to act on them. A new protocol won't change that. If an organization doesn't process abuse reports today , I don't see why another transport mechanism would suddenly make them do so. It just gives them another inbox, queue, or API endpoint to ignore. The real challenge isn't improving report delivery-it's reducing response time and creating incentives to process abuse. Until then, we're optimizing the wrong part of the workflow.
-Michael
*Från:* Serge Droz via Security-wg < security-wg@ ripe. net ( security-wg@ripe.net ) > *Skickat:* den 29 juli 2026 20:47 *Till:* security-wg@ ripe. net ( security-wg@ripe.net ) *Ämne:* [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored and are being replaced by (bad) forms
I think Max's point was that others don't process mail reports, , which is true, because why would they.
The problem, in my view is not, that they are overwhelmed by spam, because you can filter spam. And still let legitimate abuse complaints get through. But it's work. That's all why I think building another mechanism is not going to solve the issue. It's work to set it up, and even more work to process the complaints. And doing so helps others, respectively offloads the cost of abuse to others.
Folks that already now don't bother won't bother in the future, unles not bothering is more expensive than bothering.
But in the past we couldn't agree on making it more expensive to permit abuse than to tolerate it.
So, I'm afraid we won't change a thing, but please prove me wrong.
Serge
On 29 July 2026 17:57:19 CEST, Heather Schiller < heather. skanks@ gmail. com ( heather.skanks@gmail.com ) > wrote:
Have you looked at Abusix? They have tools to manage abuse mailbox, parse various log types, and include a mechanism for building playbooks to automate handling.
--h
On Wed, Jul 29, 2026 at 11:14 AM Max Grobecker < max. grobecker@ ml. grobecker. info ( max.grobecker@ml.grobecker.info ) > wrote:
Hello,
I hope this is the right list to discuss.
I'm seeing more and more providers auto-responding to abuse reports mailed to their "abuse-mailbox" address, stating that this mailbox will not be monitored and urging you to use some form on their website. And often enough, those forms are either only usable for very specific types of abuse or they are just tedious to use and sometimes I suddenly don't want to report spam or phishing anymore to that specific provider when I see a form with 20+ input fields. Besides that, it renders automatic reports useless, even those that are meant to be automatically processable (i.e., containing information as XARF). (Surely, automated reports are a very special topic, but as a provider we are grateful to receive prompt reports of abuse on our network.)
This raises the questions: Is there – at least for the RIPE region – any sort of requirement to accept/process abuse reports by mail?
While I'm sometimes a bit "pissed" about how bad reporting forms can be, I understand why providers might not want to maintain abuse mailboxes anymore (the amount of spam sent towards these addresses is hilariously large) and instead rely on forms with captchas to tackle this problem.
So I'm wondering: Would there be a benefit for building some standardized HTTP API with an authentication system, that would allow providers to automatically send authenticated abuse reports to other providers? That could work in a similar way like DKIM does: The sending provider needs to publish a private key somewhere in the RIPE database, signs the report, and the receiving provider would be able to immediately verify that signature. And if you get a ton of false reports or even spam from a specific provider you can still filter these out based on the sender information in the signature.
I would like to hear your opinion on this, or maybe there already *are* solutions I just don't know about yet (besides from manually reporting 20-30 phishing mails a day over 30 different forms).
Thanks and greetings
Max ----- To unsubscribe from this mailing list or change your subscription options, please visit: https:/ / mailman. ripe. net/ mailman3/ lists/ security-wg. ripe. net/ ( https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ripe.net_mailma... ) As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https:/ / www. ripe. net/ membership/ mail/ mailman-3-migration/ ( https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ripe.net_membership... )
----- To unsubscribe from this mailing list or change your subscription options, please visit: https:/ / mailman. ripe. net/ mailman3/ lists/ security-wg. ripe. net/ ( https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ ) As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https:/ / www. ripe. net/ membership/ mail/ mailman-3-migration/ ( https://www.ripe.net/membership/mail/mailman-3-migration/ )
----- To unsubscribe from this mailing list or change your subscription options, please visit: https:/ / mailman. ripe. net/ mailman3/ lists/ security-wg. ripe. net/ ( https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/ ) As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https:/ / www. ripe. net/ membership/ mail/ mailman-3-migration/ ( https://www.ripe.net/membership/mail/mailman-3-migration/ )
On Thu 30/Jul/2026 01:38:48 +0200 denis walker wrote:
# Article 1: For the purposes of RIPE Address Policy, "Network Abuse" is defined by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks and systemic spam botnet distribution).
Hm... most automatic abuse reports I send are about dictionary attacks. They don't seem to be included in the four categories you mention. Yet, they are very common and presumably indicate an 0wned host, so I think it's useful to report them. Isn't it? Best Ale --
Hi Alessandro On Thu, 30 Jul 2026, 13:57 Alessandro Vesely, <vesely@tana.it> wrote:
On Thu 30/Jul/2026 01:38:48 +0200 denis walker wrote:
# Article 1: For the purposes of RIPE Address Policy, "Network Abuse" is defined by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks and systemic spam botnet distribution).
Hm... most automatic abuse reports I send are about dictionary attacks. They don't seem to be included in the four categories you mention. Yet, they are very common and presumably indicate an 0wned host, so I think it's useful to report them. Isn't it?
So maybe: Article 1 1.1 For the purposes of RIPE Address Policy, "Network Abuse" is defined, as a base line, by the technical threat classifications maintained under the European Union Cybercrime framework (specifically DDoS, malware hosting, phishing networks and systemic spam botnet distribution). 1.2 The following items are also included: - dictionary attacks This could be updated over time. Or to avoid updating the policy every time a new threat emerges it could refer to a list maintained by the RIPE NCC on behalf of the community. Cheers Denis
Best Ale --
{Having not yet read the thread} It seems like a use for: 1) signed emails: if only we could agree on openpgp vs pkix/SMIME, and we could anchor it back to RIRs, like RPKI, but not the same anchor. 2) Structured Email replies that point to forms/issue trackers in a way that would accomodate incremental automation. This only works for providers reporting to other providers, and your proposal: Max Grobecker <max.grobecker@ml.grobecker.info> wrote: > So I'm wondering: Would there be a benefit for building some > standardized HTTP API with an authentication system, that would allow > providers to automatically send authenticated abuse reports to other > providers? That could work in a similar way like DKIM does: The > sending provider needs to publish a private key somewhere in the RIPE > database, signs the report, and the receiving provider would be able to > immediately verify that signature. And if you get a ton of false > reports or even spam from a specific provider you can still filter > these out based on the sender information in the signature. is essentially going to have to be restricted to provider to provider reports. abuse@ is intended to receive complaints from end-users, but it would be also nice if such a system could allow providers to aggregate reports from their customers. > I would like to hear your opinion on this, or maybe there already *are* > solutions I just don't know about yet (besides from manually reporting > 20-30 phishing mails a day over 30 different forms). There is a stunted ecosystem around ROLIE, DOTS (IETF), MILE (IETF), STIX, MISP-project. CVE/Mitre has never been great, but now we have to replace it, and there is the GVIP-project.org. There is a certain software focus among some, but it ought to be also be about operational concerns. I tried to engage about this at RIPE79 about IoT reporting: https://www.sandelman.ca/SSW/talks/ripe-iot-unquarantine2019/RIPE79-IoT-Unqu... (slide 11 onwards) The CERTs were not even close to ready seven years ago. I doubt it's better now, as this is totally a tragedy of the commons. A team of ~12 people (including marketing, communications!) with long-term funding could make a serious impact via creation and promotion of tools and methods. That ought to be CERTs, but somehow it never is. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
participants (22)
-
Alessandro Vesely -
Brian Nisbet -
denis walker -
Gert Doering -
Hank Nussbacher -
Heather Schiller -
Jean-Robert Hountomey -
Jeroen Massar -
jordi.palet＠consulintel.es -
Leo Vegoda -
lists＠at.encryp.ch -
Marko Karppinen -
Max Grobecker -
Michael Duffy -
Michael Richardson -
Michele Neylon - Blacknight -
Nick Hilliard -
Randy Bush -
Serge Droz -
Sergey Myasoedov -
Suresh Ramasubramanian -
Tobias Knecht