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).

Spamhaus DROP (Don't Route Or Peer) List
Spamhaus XBL (Exploit Block List)
[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