Contractual Accountability Framework for Infrastructure-Level Network Abuse
- State:
- Discussion Phase: Open for discussion
- Publication date
- Draft document
- Draft
- Author
- Proposal Version
- 1.0 - 13 Oct 2026
- All Versions
-
- Working Group
- Security Working Group
- Mailing List
- Security Working Group
- Proposal type
-
- New
- Policy term
- Indefinite
Summary of Proposal
This proposal establishes a clear, contractual mechanism to hold resource holders accountable for systematically failing to address infrastructure-level network abuse. Existing policies mandate the existence of an abuse-c: contact, but fail to provide an enforcement path when a non-compliant operator routinely fails to act on authenticated abuse reporting data. This framework introduces a proportionate, measured administrative quarantine framework.
Policy Text
Article 1: Definitions
1.1 For the purposes of RIPE policy, "Network Abuse" is defined strictly as sustained, infrastructure-level malicious operations, specifically including:
- Dedicated Distributed Denial of Service (DDoS) command-and-control architectures
- Systemic malware hosting repositories and distribution networks
- Phishing site deployment networks and hosting farms
- Systemic automated spam botnet distribution infrastructure
1.2 It applies to resources distributed by the RIPE NCC where the underlying allocation or assignment is utilised to systematically facilitate these threat classifications, distinct from isolated consumer end user device compromises.
1.3 Residential/dynamic subscriber pools are explicitly excluded from this definition and are defined as IP address ranges designated by the resource holder or global routing registries as consumer access infrastructure (such as the Spamhaus PBL).
1.4 An "authenticated notification" is defined as a submission logged via a RIPE NCC Support ticket by an affected network operator or a National CERT, containing verifiable automated telemetry log data originating from an Approved Infrastructure Blocklist, accompanied by digital timestamps or cryptographic signatures confirming the sustained data trail.
1.5 The RIPE Security Working Group shall review the specific technical threat classifications in Article 1.1 annually to adapt to evolving Internet safety baselines. Any amendment to the definition of Network Abuse shall be subject to the RIPE Policy Development Process.
Article 2: Resource Integrity
2.1 Address space allocated and assigned by the RIPE NCC must not be systematically utilised to facilitate Network Abuse as defined in Article 1.
Article 3: Enforcement, Restrictions, and Remediation Pathways
3.1 Upon receipt of an authenticated notification demonstrating that an IP address within a RIPE NCC allocated or assigned block has engaged in Network Abuse, as defined in Article 1.1, for a cumulative total of 14 days within any rolling 30 day window, as documented on an Approved Infrastructure Blocklist, the RIPE NCC shall initiate an administrative delivery protocol.
3.2 The RIPE Security Working Group shall maintain the registry of Approved Infrastructure Blocklists. Any modification to this registry shall be subject to the formal consensus rules of the Security Working Group. To be approved, a blocklist must rely on objective automated telemetry, explicitly exclude residential/dynamic subscriber pools, and maintain a publicly verifiable historical archive.
3.3 The administrative delivery protocol requires that the RIPE NCC shall send a formal remediation notice by means of an electronic delivery with automated read-receipt tracking to the authoritative legal, administrative, and billing contacts the resource holder is contractually required to maintain under their signed RIPE NCC Standard Service Agreement (SSA). If the abuse involves multiple IP addresses distributed across multiple LIR accounts of the same member, copies of the remediation notice will be sent to all associated contacts.
3.4 A resource holder is granted a strict grace period of seven business days from the confirmed timestamp of electronic delivery to achieve compliance. Compliance is achieved when all identified abusive prefixes successfully drop off the Approved Infrastructure Blocklists, or when the resource holder takes verified administrative action to isolate the abusive prefixes.
3.5 If the seven business days expire and the resource holder has explicitly failed to achieve compliance, the RIPE NCC shall execute proportionate intermediate administrative restrictions based on the resource holder's registry architecture deployment. This would restrict the resource holder’s operational registry agility and publicly flag their “non-compliant abuse status” in the RIPE Database while aiming to keep underlying resource assignments intact and insulate adjacent downstream networks from immediate network disconnection.
3.6 The RIPE NCC shall lift all administrative restrictions, remove the “non-compliant abuse status” from the RIPE Database, within one working day of verifying that compliance has been achieved. Compliance for restoration is verified strictly by a binary check demonstrating that the identified abusive prefixes have successfully dropped off the Approved Infrastructure Blocklists, or where RPKI is involved, that the appropriate ROA has been deleted. No evaluation of network traffic by RIPE NCC staff is required for restoration. If a resource holder is subject to multiple authenticated notifications, compliance must be achieved for each notification before the restrictions are lifted.
Rationale:
a. Arguments Supporting the Proposal
- Abuse Definition and Structural Contract Symmetries: The policy includes a RIPE definition of network abuse, applicable strictly to commercial resource integrity contracts. It is not intended to be a legal definition within any local jurisdiction covered by the RIPE region. It utilises the official registry contacts that every member is contractually required to maintain, operating uniformly across all 70+ jurisdictions. By establishing that systemic network abuse constitutes an explicit violation of active RIPE policy, failure to remediate constitutes a boilerplate Material Breach under the signed RIPE NCC Standard Service Agreement (SSA).
- Dismantles the Scaling Trap: By anchoring the trigger to infrastructure-only blocklists that explicitly exclude residential pools, consumer IoT devices are automatically filtered out, protecting consumer privacy and dynamic access points.
- Zero Judicial Burden on RIPE NCC Staff: RIPE NCC staff execute a binary administrative audit: they verify the data presence via an approved list, relay an electronic notice, and apply a documented restriction if the grace period is ignored.
- Prevents Mass Disconnections: Because the restriction applies administrative measures rather than starting the resource revocation procedure, innocent downstream networks are likely protected from immediate BGP disconnection.
- Contractual Symmetries: The policy utilises the confidential legal contract details that every resource holder, whether a multinational corporation or an unincorporated sole trader, is already contractually required to maintain with the RIPE NCC. It applies uniformly to all 70+ jurisdictions in the RIPE region. This is the same contact that the RIPE NCC uses for billing issues.
b. Arguments Opposing the Proposal
- A possible concern is that this creates an administrative burden for the RIPE NCC. However, because the framework requires a cumulative 14 days of blocklist inclusion combined with a manual submission by an affected network or National CERT, the ticket volume is naturally restricted to high-level, systemic rogue operations.
- 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.