2026-02 New Policy Proposal (Contractual Accountability Framework for Infrastructure-Level Network Abuse)
Dear colleagues, A new RIPE Policy Proposal, 2026-02 "Contractual Accountability Framework for Infrastructure-Level Network Abuse" is now available for discussion. This proposal suggests a contractual mechanism to hold resource holders accountable for systematically failing to address infrastructure-level network abuse. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2026-02 As per the RIPE Policy Development Process (PDP), the purpose of the Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 We encourage you to review this proposal and send your comments to security-wg@ripe.net before 11 November 2026. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC
Angela Dall'Ara wrote on 13/10/2026 12:08:
This proposal suggests a contractual mechanism to hold resource holders accountable for systematically failing to address infrastructure-level network abuse.
From a brief reading, my take-away is that this proposal has a number of fundamental structural issues, not least an almost complete lack of clarity about what the policy is going to mean in practice, a suggestion that the RIPE NCC ought to execute a substantial change in strategic organisational direction from being a registry to using registry data to impose business consequences on RIPE NCC members, and not least, an unstated implication that by outsourcing some of the input process decision-making to third parties, that the RIPE NCC could somehow disclaim responsibility for operational outcomes of the policy. These are all disturbing problems, any one of which should be sufficient to justify rejecting the proposal in their own right. The Rationale section includes the following:
Operational Dependency: This policy will only be effective with strong, well-defined restrictions agreed by the community and codified into a separate RIPE document. The logic of those restrictions needs to be discussed in parallel with the policy to prevent administrative ambiguity or unworkable deployment workflows.
A good starting point would be to understand exactly what the author has in mind for "strong, well-defined restrictions". Can this proposal document be published first, so that the working group can at least have some idea what the author is asking the community agree to? Nick
Whoever it is probably has a strong allergy to not in my backyard^W “we are not the internet police” --srs ________________________________ From: Nick Hilliard <nick@foobar.org> Sent: Tuesday, 13 October 2026 19:07:46 To: Angela Dall'Ara <adallara@ripe.net> Cc: security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: 2026-02 New Policy Proposal (Contractual Accountability Framework for Infrastructure-Level Network Abuse) Angela Dall'Ara wrote on 13/10/2026 12:08:
This proposal suggests a contractual mechanism to hold resource holders accountable for systematically failing to address infrastructure-level network abuse.
From a brief reading, my take-away is that this proposal has a number of fundamental structural issues, not least an almost complete lack of clarity about what the policy is going to mean in practice, a suggestion that the RIPE NCC ought to execute a substantial change in strategic organisational direction from being a registry to using registry data to impose business consequences on RIPE NCC members, and not least, an unstated implication that by outsourcing some of the input process decision-making to third parties, that the RIPE NCC could somehow disclaim responsibility for operational outcomes of the policy. These are all disturbing problems, any one of which should be sufficient to justify rejecting the proposal in their own right. The Rationale section includes the following:
Operational Dependency: This policy will only be effective with strong, well-defined restrictions agreed by the community and codified into a separate RIPE document. The logic of those restrictions needs to be discussed in parallel with the policy to prevent administrative ambiguity or unworkable deployment workflows.
A good starting point would be to understand exactly what the author has in mind for "strong, well-defined restrictions". Can this proposal document be published first, so that the working group can at least have some idea what the author is asking the community agree to? 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/
Hi Nick, Angela, and Colleagues, Thank you for this prompt review, Nick, and for highlighting the exact structural mechanism that makes this framework effective. Nick suggests that enforcing contractual resource accountability represents a "disturbing" change in strategic direction for the RIPE NCC. What is genuinely disturbing is the operational reality playing out across our region this week. As the severe infrastructure attacks against Albert Heijn stores here in the Netherlands and major retail distribution networks in France demonstrate, infrastructure-level cybercrime has graduated from basic data theft to targeting the physical food supply chain. These operations rely entirely on the systematic exploitation of un-remediated, bulletproof hosting allocations. Pretending the RIPE registry must remain a passive, blind directory while its resources are weaponised to sabotage regional food supplies is a luxury the market can no longer afford. There was also the case dropped onto the Security WG list recently by Theo Plooij regarding 91.92.243.0/24 (Ticket 1112396). It exhibits the exact systemic loophole this policy aims to close: an active phishing block, blacklisted by Spamhaus, operating under an uncontracted offshore shell company via a Turkish LIR. Because the unmonitored abuse mailbox technically doesn't bounce emails, it is deemed 'valid' under ripe-705, leaving both the LIR and the RIPE NCC stating that they have no policy mandate to intervene. So nobody acts. Michele raises an excellent technical point regarding standard client-side email read-receipts being routinely blocked or disabled in 2026. This exact failure of standard email communication is precisely why Article 3.3 bypasses traditional unmonitored abuse mailboxes entirely. By mandating "electronic delivery with automated tracking" to the authoritative legal and billing contacts under the signed Standard Service Agreement (SSA), the policy directs the RIPE NCC to utilise contractually binding legal delivery mechanisms (such as secure portal-log timestamps or certified server-side delivery networks) where delivery verification is handled at the infrastructure layer, making it impossible for a non-compliant operator to claim ignorance. Your concern regarding the high-level operational nature of Article 3.5 is completely valid, and it is precisely why this framework utilises a split-document blueprint. To satisfy the Working Group Co-Chairs' explicit formatting directive to keep the primary policy text entirely unencumbered by technical software dependencies, the granular engineering pathways have been separated from the core template. This keeps the text of the policy elegant and future-proof. However, as explicitly noted in the Rationale section you quoted, a high-level policy mandate does not mean an undefined implementation. The logic of these restrictions must be discussed in parallel to ensure complete operational predictability. In direct response to your request to see exactly what is intended by "strong, well-defined restrictions," here is the full draft text of the parallel RIPE Network Abuse Policy Support Document. It details the explicit, community-governed parameters engineered to restrict operational registry agility safely across Hosted RPKI, Delegated RPKI, and non-RPKI configurations — additionally utilising Enforced De-aggregation and signed geofeed: ZZ metadata mapping parameters to isolate threats while aiming to protect adjacent innocent downstream assignments from collateral disruption. Per the published Rationale, I look forward to discussing these technical parameters alongside the main policy articles. ------------------------------ RIPE Network Abuse Policy Support Document ripe-nnn Publication date: nnnn 2026 State: Draft (Proposed Technical Baseline for Parallel Discussion) Authors Denis Walker 1. Governance, Authority, and Maintenance Framework 1.1 Operational Mandate and Scope This document serves as the authoritative operational technical logic for the execution of proportionate intermediate administrative restrictions authorised under "ripe-nnn Contractual Accountability Framework for Infrastructure-Level Network Abuse" (currently Policy Proposal 2026-02). The programmatic enforcement pathways detailed herein — including Hosted RPKI portal management suspensions, Delegated RPKI CA certificate adjustments utilising Enforced De-aggregation where necessary, and non-RPKI RIPE Database object overrides — constitute the community-approved parameters for the execution of these restrictions. 1.2 Working Group Consensus Control This operational technical logic document is a community-governed RIPE document maintained natively along with the registry of Approved Infrastructure Blocklists. Any future structural updates, technical pathway additions, algorithmic shifts, or modifications to the Approved Infrastructure Blocklists contained within this document shall be subject to the formal consensus rules of the Security Working Group. 1.3 Implementation Alignment The RIPE NCC shall schedule an update in a timely manner to its backend software and internal support interfaces to align with the revised document state once it is agreed by the community. 2. Registry Of Approved Infrastructure Blocklists (Active Restriction Triggers) To be included in this registry, a blocklist must rely on objective automated telemetry, maintain a publicly verifiable historical archive, and explicitly filter out or exclude residential/dynamic subscriber pools (e.g., utilising internal alignment with metrics parallel to the Spamhaus PBL framework). 1. Spamhaus DROP (Don't Route Or Peer) List 2. Spamhaus XBL (Exploit Block List) 3. [Placeholder for additional WG-approved telemetry feeds] 3. Logic for Applied Restrictions There are many permutations for an RPKI (or not) setup and RIPE Database object structures. For the policy to be effective, each of these permutations may need a separate enforced action flow. This results in a complex set of options. In practice, for any specific case, only one option is followed. The complexity should be handled within an automated system behind a simple user interface for the support staff. The appropriate option will be determined programmatically. The RIPE NCC support staff will not be required to work out the right permutation. Where an "abuse-status: NON-COMPLIANT" attribute is added in the RIPE Database, this will be to the resource holder's ORGANISATION object as well as the appropriate resource object. The "abuse-status:" attribute can only be removed by the RIPE NCC. 3.1 The identified operational restrictions options - a) Hosted RPKI: The RIPE NCC shall suspend portal management access for the resource holder’s RPKI dashboard, freezing their capability to alter, create, or renew cryptographic keys. Concurrently, an "abuse-status: NON-COMPLIANT" attribute shall be appended to the associated RIPE Database objects. The next actions depend on the ROA structures: - i. Individual ROAs: The resource holder must submit a manual request to the RIPE NCC Support ticket authorising the RIPE NCC to programmatically delete the specific Route Origin Authorization (ROA) object associated with the abusive prefix block. - ii. Aggregated ROA structure (not complying with BCP 185): If the abusive prefix is masked within an aggregated ROA structure, the resource holder can request a temporary 72-hour administrative window to access their RPKI management tools strictly to delete the aggregated ROA object and re-sign granular ROAs for their compliant prefixes. They must not create a ROA for the abusive prefix. Failure to achieve compliance by restructuring their ROAs within this window triggers immediate Aggregated-Block Quarantine. In this case the RIPE NCC will delete the aggregated ROA. The resource holder assumes all operational responsibility and legal liability for any subsequent routing disruptions that may be experienced by adjacent downstream networks encapsulated within an aggregated ROA due to their refusal to separate out a ROA object associated with the abusive prefix block. - b) Delegated RPKI (including "Publish in Parent" Hybrid Deployments): The RIPE NCC, acting as the authoritative Upstream Trust Anchor, shall execute restrictions based on the resource holder's RIPE Database object configuration: - i. Aggregated Infrastructure: If the abusive prefix is masked within an aggregated RIPE Database object (such as an AGGREGATED-BY-LIR object without an assignment-size:), the RIPE NCC shall issue an Administrative Enforced De-aggregation Mandate granting the resource holder 72 hours to comply by documenting the precise boundaries of the abusive prefix via a discrete child assignment object in the RIPE Database. Upon creation, the RIPE NCC shall immediately apply an "abuse-status: NON-COMPLIANT" attribute to that specific child object, issue a separate, narrow child certificate for that specific abusive block, and structurally revoke it, while reissuing a clean master parent certificate to the Delegated CA that safely insulates adjacent innocent downstream prefixes. - ii. Aggregated-Block Quarantine: If the Enforced De-aggregation Mandate is ignored after 72 hours, or if the resource holder does not utilise aggregate structures, the RIPE NCC shall structurally revoke or shrink the child certificate issued to that Delegated CA for the non-compliant block (which may be either the individual child assignment or the whole aggregation). Concurrently, an "abuse-status: NON-COMPLIANT" attribute shall be appended to the associated RIPE Database objects. The resource holder assumes all operational responsibility and legal liability for any subsequent routing disruptions that may be experienced by adjacent downstream networks encapsulated within any un-segmented, aggregated block due to their refusal to identify the actual assignment block boundaries. - c) No RPKI (Discrete RIPE Database Object): If RPKI services are not utilised, and a discrete assignment or allocation object matching or containing the offending abusive prefix exists in the RIPE Database, the RIPE NCC shall apply the "abuse-status: NON-COMPLIANT" attribute and modify or append the geofeed: attribute to the specific resource object to reference an authoritative file maintained and signed by the RIPE NCC, explicitly setting the geographic location country code to "ZZ". - d) No RPKI (Aggregated RIPE Database Object / Enforced De-aggregation): If RPKI services are not utilised, and the offending abusive prefix is masked within an aggregated RIPE Database object (such as an AGGREGATED-BY-LIR object without an assignment-size:), the RIPE NCC shall issue an Administrative Enforced De-aggregation Mandate granting the resource holder 72 hours to comply. - i. Surgical Compliance: The resource holder must create a discrete, individual child assignment object in the RIPE Database documenting the explicit boundaries of the offending prefix. Upon creation, the RIPE NCC shall immediately apply the "abuse-status: NON-COMPLIANT" attribute to the child object and modify or append the geofeed: attribute exclusively on that new child object, to reference an authoritative file maintained and signed by the RIPE NCC, explicitly setting the geographic location country code to "ZZ", likely protecting adjacent innocent downstream prefixes within the aggregated block. - ii. Aggregated Block Quarantine: If the resource holder ignores the De-aggregation Mandate after 72 hours, the RIPE NCC shall append the "abuse-status: NON-COMPLIANT" attribute and modify or append the geofeed: attribute directly to the parent aggregate object in the RIPE Database, to reference an authoritative file maintained and signed by the RIPE NCC, explicitly setting the geographic location country code to "ZZ". The resource holder assumes all operational responsibility and legal liability for any subsequent geographic access disruption that may be experienced by adjacent downstream networks encapsulated within that un-segmented, aggregated block due to their refusal to identify the actual assignment block boundaries. - e) Upstream Transit Escalation Protocol: If an administrative restriction executed under Options a, b, c, or d remains unresolved for 72 consecutive hours after application, the RIPE NCC Support team shall formally deliver an Authoritative Infrastructure Abuse Notice containing the audited compliance data trail directly to the security and operations teams of the non-compliant member's upstream transit providers as identified in global routing visibility datasets. 4. Document History - First Draft Proposed: 14 October 2026 - Consensus Declared: nnnn 2026 - Current Version Published: nnnn 2026 ------------------------------ Cheers, Denis Retired RIPE Database Senior Analyst & Engineer On Tue, 13 Oct 2026 at 15:37, Nick Hilliard <nick@foobar.org> wrote:
Angela Dall'Ara wrote on 13/10/2026 12:08:
This proposal suggests a contractual mechanism to hold resource holders accountable for systematically failing to address infrastructure-level network abuse.
From a brief reading, my take-away is that this proposal has a number of fundamental structural issues, not least an almost complete lack of clarity about what the policy is going to mean in practice, a suggestion that the RIPE NCC ought to execute a substantial change in strategic organisational direction from being a registry to using registry data to impose business consequences on RIPE NCC members, and not least, an unstated implication that by outsourcing some of the input process decision-making to third parties, that the RIPE NCC could somehow disclaim responsibility for operational outcomes of the policy. These are all disturbing problems, any one of which should be sufficient to justify rejecting the proposal in their own right.
The Rationale section includes the following:
Operational Dependency: This policy will only be effective with strong, well-defined restrictions agreed by the community and codified into a separate RIPE document. The logic of those restrictions needs to be discussed in parallel with the policy to prevent administrative ambiguity or unworkable deployment workflows.
A good starting point would be to understand exactly what the author has in mind for "strong, well-defined restrictions". Can this proposal document be published first, so that the working group can at least have some idea what the author is asking the community agree to?
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/
This proposal might be well intentioned, but as currently written is riddled with issues 1.4 Is it a listing in a blocklist or a report from a National CERT? Why would a CERT be contacting RIPE about issues with an AS number? It potentially is an escalation of non-response, but that’s not what the document says 1.5 I don’t think the WG is really qualified to do this. While members of the WG might have deep experience in many aspects of security I cannot see how the group would suddenly morph into being arbiters of this. Same with respect to 3.2 - I’d also see this as being open to gaming 2.1 define “systematically” 3.4 that assumes that blocklist operators will remove IP ranges in a timely fashion or following some kind of logical process. While some of the bigger ones might, some of the smaller ones might not 3.5 “explicitly” - what does that mean? Same with “proportionate” What exactly are these proposed restrictions? These are just my initial observations Regards Michele -- 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.
Also it’s 2026 I can’t remember the last time anyone sent a “read receipt” for an email. I’d also suspect that a lot of us have either disabled that functionality or block it. -- 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: Michele Neylon - Blacknight via Security-wg <security-wg@ripe.net> Date: Tuesday, 13 October 2026 at 16:18 To: Angela Dall'Ara <adallara@ripe.net>; security-wg@ripe.net <security-wg@ripe.net> Subject: [Security-wg] Re: 2026-02 New Policy Proposal (Contractual Accountability Framework for Infrastructure-Level Network Abuse) [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. This proposal might be well intentioned, but as currently written is riddled with issues 1.4 Is it a listing in a blocklist or a report from a National CERT? Why would a CERT be contacting RIPE about issues with an AS number? It potentially is an escalation of non-response, but that’s not what the document says 1.5 I don’t think the WG is really qualified to do this. While members of the WG might have deep experience in many aspects of security I cannot see how the group would suddenly morph into being arbiters of this. Same with respect to 3.2 - I’d also see this as being open to gaming 2.1 define “systematically” 3.4 that assumes that blocklist operators will remove IP ranges in a timely fashion or following some kind of logical process. While some of the bigger ones might, some of the smaller ones might not 3.5 “explicitly” - what does that mean? Same with “proportionate” What exactly are these proposed restrictions? These are just my initial observations Regards Michele -- 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.
Hi, On Tue, 13 Oct 2026 13:08:46 +0200, Angela Dall'Ara <adallara@ripe.net> wrote:
We encourage you to review this proposal and send your comments to security-wg@ripe.net before 11 November 2026.
I note that dictionary attacks, which were expressly included in August are not included in the exhaustive Article 1.1 list now. Was that intentional? In 1.2, grammatically, “It” has no clean antecedent. The preceding subject in 1.1 is "Network Abuse", so it appears to limit that definition. Suppose an infected residential PC is participating in a DDoS botnet. The botnet is certainly the sort of thing 1.1 appears intended to address. But its IP belongs to a residential/dynamic pool, which Article 1.3 explicitly excludes from the definition. So the policy seems to contemplate, for example, something like XBL minus PBL rather than XBL as is. Best Ale --
participants (6)
-
Alessandro Vesely -
Angela Dall'Ara -
denis walker -
Michele Neylon - Blacknight -
Nick Hilliard -
Suresh Ramasubramanian