Summary

  • If a restriction reaches beyond the listed resource, people may lose access to a website or work service that depends on the affected network. RIPE proposal 2026-02 acknowledges that continuity risk, but leaves the measures and their limits to later work.
  • RIPE proposal 2026-02 sets a 14-in-30-day trigger and says measures should avoid immediately disconnecting adjacent downstream networks, but leaves the restriction menu and auditable exit to later work. It remains under discussion.

For a hosting or access operator, a restriction attached to one resource can raise a practical question far beyond the registry record: will customers and downstream networks still be able to reach the services that depend on it? People may notice only that a website or work service no longer connects. RIPE’s draft acknowledges this continuity risk: it says measures should preserve assignments and avoid immediately disconnecting adjacent downstream networks. Yet the proposal leaves the restriction menu to a later document, so it does not yet show how that protection would work in practice.

The exit from a restriction is therefore part of the continuity question, not a technical footnote after detection.

The proposal is unusually specific about how a case could enter the process. The difficult question is what makes it leave.

Published on 13 October 2026 and assigned to the RIPE Security Working Group, “Contractual Accountability Framework for Infrastructure-Level Network Abuse” is in the Discussion Phase through 11 November. It would cover sustained malicious operations on RIPE NCC allocated or assigned resources, including command-and-control infrastructure, systemic malware distribution, phishing networks and automated spam-botnet infrastructure. It excludes residential and dynamic subscriber pools and distinguishes systemic infrastructure from an isolated compromised device. These are proposals, not current RIPE rules. (Proposal 2026-02; current proposals)

For a case to qualify, the draft requires more than a complaint or an address appearing once on a list. An affected network operator or National CERT would open a RIPE NCC Support ticket. It would carry automated telemetry from an approved infrastructure list and timestamp or cryptographic-signature evidence. The trigger is cumulative presence for 14 days within a rolling 30-day period in an allocated or assigned block. The Security Working Group would review threat classifications each year and maintain the approved-list registry through consensus, with objective telemetry, a public history and exclusions for residential or dynamic pools.

That architecture tries to turn an uncertain signal into a reproducible administrative threshold. But each conversion needs an accountable owner. Who can challenge whether a list’s telemetry is comparable across networks? How is a list’s clock reconciled when entries are added, removed and reinstated? What does “sustained” mean when observations are missing? The draft’s timestamps and historical archive help make a record possible; they do not by themselves settle how contradictory evidence is weighed.

The proposed notice stage is also carefully described. RIPE NCC would send a formal remediation notice, with tracked electronic delivery and read receipt, to the legal, administrative and billing contacts in the holder’s signed Standard Service Agreement. If multiple LIR accounts belonging to one member are implicated, each set of associated contacts would receive a copy. The holder then gets seven business days from confirmed delivery to comply: the identified prefixes must leave the approved lists, or the holder must take verified administrative action to isolate them.

The seven-day period is therefore not simply a countdown from first detection. Its start depends on delivery being confirmed to the designated contacts. For operators, that makes contact maintenance and internal escalation part of operational security. For RIPE NCC, the record must distinguish a failed delivery from a delivered notice that receives no response. A process that cannot show which clock ran, for whom, and on what evidence would be difficult to audit after a restriction is imposed.

Then comes the proposal’s least specified step: “proportionate intermediate administrative restrictions” keyed to the holder’s registry architecture. A public non-compliant abuse status would be added to the RIPE Database. The draft says the aim is to retain underlying assignments and avoid immediately disconnecting adjacent downstream networks. It does not, however, define the restriction menu in the proposal itself. Its rationale says effectiveness depends on strong, well-defined restrictions being agreed by the community and codified in a separate RIPE document.

That dependency changes how the rest of the sequence should be read. An evidence threshold does not tell an operator what function may be restricted, how scope follows the affected resources, or which neighbouring customers are insulated. “Proportionate” is a standard to apply; without a bounded set of measures and a rule for selecting among them, it is not yet a reproducible decision. Nor should the proposed intermediate measures be conflated with suspension, deregistration or termination under existing procedures. RIPE-732 is the published Standard Service Agreement, while RIPE-858 sets out LIR closure and resource deregistration; the proposal does not say it replaces either document. (RIPE-732; RIPE-858)

The exit is more concrete, at least on paper. RIPE NCC would lift the restrictions and public status within one working day after verifying compliance. The proposed test is binary: removal from the approved lists or, when RPKI is involved, deletion of the relevant ROA. Staff would not need to assess traffic to decide restoration. That can limit subjective judgment, but it also makes the list and registry record decisive at both ends of the process. A stale listing, disputed removal or mistaken ROA association could keep the administrative record and network state out of step.

There is a useful contrast with the existing abuse-contact rule. RIPE-705 requires an abuse-c attribute and at least annual validation of the mailbox, with follow-up when it is incorrect. It checks whether a contact channel works; it does not establish the new proposal’s threshold, restrictions or restoration mechanism. (RIPE-705)

Discussion should therefore test the whole case file, not only whether 14 days in 30 is a defensible line. A holder should be able to see the observations, the list version, the calculation, the delivery receipt, the cure evidence, the exact measure selected and the condition that ends it. The process needs a route to correct an erroneous input, a way to resolve conflicting records and a timestamped restoration receipt. Those controls would not decide whether the community should adopt the proposal. They would make the decision legible if it does.

Once a public database status can precede a restriction, the decision touches continuity for the holder and the adjacent networks the proposal says it wants to protect. The institutional choice is whether RIPE NCC should translate a community-defined signal into contract-linked administrative consequences, and how tightly those consequences must be bounded. A trigger can be precise while the remedy remains discretionary. Proposal 2026-02 has surfaced that asymmetry before adoption; the discussion period is the opportunity to close it with a reviewable restriction schedule and an equally testable exit. Process context: RIPE Policy Development Process (RIPE-781 and the official proposal-announcement archive.