Summary

  • RIPE proposal 2026-02 is open for discussion, not adopted policy. Its trigger is a sustained blocklist record; its first cure can be removal from the list or verified isolation.
  • Article 3.6 uses a different pair of restoration signals: blocklist removal or deletion of an “appropriate ROA” where RPKI is involved. The text does not define that connection.
  • A ROA says which autonomous system a resource holder has authorized to originate routes to listed prefixes. It is not, by itself, evidence that a phishing host, malware distribution service, spam system or other alleged operation has stopped.

Analysis

One process, three evidence questions

The RIPE community has begun discussing a new proposal on infrastructure-level network abuse. Its first version is dated 13 October 2026; the official status page shows a discussion period through 11 November. Nothing in the public record at this cutoff shows adoption, implementation or a case handled under the proposal. The document describes proposed duties; current RIPE policy and operations remain the reference point until a proposal completes its process.

The draft lists four forms of sustained infrastructure-level activity: dedicated DDoS command-and-control architecture, systemic malware hosting and distribution, phishing-site deployment networks or hosting farms, and systemic automated spam botnet infrastructure. It distinguishes these from isolated consumer-device compromise and expressly excludes residential or dynamic subscriber pools as designated by a holder or global routing registry.

That bounded scope is a real design feature. The proposal also tries to define a documentary path before restrictions begin: a ticket submitted to RIPE NCC by an affected network operator or National CERT; telemetry from an Approved Infrastructure Blocklist; timestamps or signatures; and a cumulative 14 days of observation within a rolling 30-day window. The Security Working Group would maintain the list registry, with objective automated telemetry, residential-network exclusions and a public historical archive as approval conditions.

The sequence then moves through three questions that should not be collapsed into one:

Stage Record or action named in the draft What it can establish What it does not establish by itself
Initiation 14 days in 30 on an approved infrastructure blocklist, with an authenticated notification That an identified address appeared in a particular list over the required window Whether the list correctly maps the address to the relevant holder, or what action stopped the activity
Initial cure The identified prefixes leave the list, or the holder takes verified administrative action to isolate them A list-state change or an isolation action tied to the cure period How isolation is verified, who verifies it, or why a list entry ended
Restoration The prefixes leave the list, or, where RPKI is involved, the “appropriate ROA” is deleted A list-state change or a route-origin authorization change Whether the alleged operation stopped, and why deletion of that ROA is the relevant remedy

This is not an argument that blocklists are useless or that an administrative process should never follow a sustained report. It is a question about whether the same case is being measured at each step. Article 3.1 is framed around list history. Article 3.4 recognizes either a list change or a verified act of isolation. Article 3.6 returns to the list or introduces a routing authorization record. The draft does not say whether its last branch proves isolation, remedies a route-origin allegation, or stands as a separate administrative shortcut.

The ROA answers a narrower question

RFC 9582 defines the purpose of a Route Origin Authorization: it lets a relying party verify that the holder of an address block authorized an autonomous system to originate routes to one or more prefixes. That is important infrastructure evidence. It identifies a particular authorization relationship. It does not describe what service ran on the address, what traffic it generated, whether a host was compromised, or whether an operator isolated the system after receiving a report.

There are situations in which RPKI could be relevant to an abuse allegation. A report might concern a route origin that the holder did not authorize, or a prefix whose routing authorization is part of the alleged mechanism. In that case, identifying the exact prefix, origin, ROA and notification could make deletion or replacement of an authorization a meaningful control action. But the proposal’s four listed threat classes are not all routing-origin allegations. A phishing hosting farm might be reachable through a valid route. The existence of a ROA does not tell the reader whether that ROA enabled the described behavior.

The draft leaves two key joins unstated. What makes a notification a case “where RPKI is involved”? And what makes a ROA the “appropriate” one to delete when a holder has multiple prefixes, origins or authorizations? These are not vocabulary details. They determine what an operator would be asked to change and what RIPE NCC would accept as the basis to lift a public status.

Deleting a ROA changes an authorization record. It may affect how networks that use route-origin validation assess an announcement, depending on surrounding authorization data and local routing policy. The sources do not establish one uniform routing result. More importantly, none of those possible outcomes proves that the service behavior alleged in a blocklist stopped. A route may be less authorized while the host or service remains active; or a holder may remove a ROA for a reason unrelated to the report. The draft needs a case-specific relationship rather than treating the existence of an RPKI object as an explanation for misconduct.

The contact policy is not the proposed enforcement path

RIPE-705 addresses the contact layer. It requires an abuse contact attribute for relevant resource records, points to an abuse mailbox, makes that mailbox available for reports and calls for annual validation and follow-up under existing policy and procedures. RIPE NCC’s abuse-c explainer describes the purpose as helping reports reach the appropriate resource holder.

That is different from the new proposal’s intended mechanism. A contact record helps route a report; it does not decide whether the report is correct, whether an operator has isolated a prefix, or which registry restrictions should follow. Proposal 2026-02 would add a separate administrative chain: notice to legal, administrative and billing contacts, a seven-business-day grace period from confirmed electronic delivery, then intermediate restrictions and a public non-compliant-abuse status if the holder has not met the stated condition.

The draft says those restrictions are meant to preserve resource assignments and avoid immediate network disconnection. It also says the details of strong, well-defined restrictions depend on a separate RIPE document. That dependency deserves attention alongside the ROA clause. A public flag can influence how other parties interpret a holder’s record even when the assignment remains intact. If its evidence and correction path are not clear, the status may travel further than the list entry that triggered it.

The proposal’s own rationale characterizes persistent failure as a contractual breach. That is the proposer’s rationale, not an adjudicated legal conclusion. The formal RIPE process remains open and consensus-based; the proposal has not passed discussion. The immediate question is what facts the draft would require before each status change.

Give every status its own receipt

A workable design could preserve the staged approach while requiring an evidence receipt for every notification. It need not publish sensitive telemetry. It should record enough for the holder, RIPE NCC and any reviewer to reconstruct the decision:

  • the notification identifier, submitting class and affected resource;
  • the exact prefix and list entry, list version, observation dates and archive reference;
  • the basis for mapping that prefix to the account or holder that received notice;
  • the specific containment action, owner and verification method, if isolation is claimed;
  • whether RPKI is relevant to the alleged mechanism, and the exact ROA and authorization relationship at issue;
  • the reason a list removal or ROA change satisfies the condition;
  • delivery, cure, restriction, correction and restoration timestamps.

That would keep four records separate: observed conduct, route-origin authorization, containment and the registry’s administrative status. If an allegation concerns route origination, a ROA change may be part of the remedy, alongside evidence that the route or service condition changed. If the allegation concerns a hosting service or command-and-control system, an unrelated ROA deletion should not stand in for evidence of isolation. The proposal could limit its ROA branch to cases where a notification identifies a specific route-origin issue and the change addresses it.

The reverse relationship matters too. A prefix disappearing from a blocklist is a measurable list state, but the draft should explain whether disappearance follows removal of the operation, correction of the list, a changed criterion or the end of an observation window. Those paths have different meanings for the holder. The public archive requirement helps reconstruct past list states; it does not explain why a particular entry ended.

RIPE-781 describes four phases and a consensus process, with RIPE NCC providing administrative support including analysis of possible effects and implementation work. During discussion, the community can ask not only how many days a list must report an address, but what evidence connects that address to a holder, an alleged operation to an authorization object, and a cure to removal of a public flag.

Proposal 2026-02 is at the start of that conversation. Its strongest safeguard is the attempt to define the infrastructure abuse in scope and protect residential and dynamic pools. Its unresolved evidentiary issue is narrower: the text starts with one kind of record, permits an operational isolation action during cure, then introduces a different record at restoration. Until the draft explains the link, deleting a ROA can show that route authorization changed. It cannot, on its own, close an abuse case.

Sources