Summary

  • RIPE proposal 2026-02 starts a response after 14 cumulative days on an approved infrastructure blocklist in a rolling 30-day window, gives a resource holder seven business days to act, then promises restoration within one working day of verified compliance.
  • Clause 3.4 accepts verified isolation of abusive prefixes. Clause 3.6 omits that route and instead names removal from the blocklist or deletion of the relevant ROA. Deleting a ROA changes origin-validation evidence; BGP withdrawal and prefix isolation are separate network actions.

A clock with three hands

RIPE NCC’s proposal 2026-02 has a satisfying calendar. An IP address must appear on an Approved Infrastructure Blocklist for a cumulative 14 days in any rolling 30-day window. An affected network operator or a National CERT must send an authenticated notification through a RIPE NCC Support ticket, with automated telemetry and timestamps or cryptographic signatures. RIPE NCC then sends a tracked notice to the resource holder’s legal, administrative and billing contacts. Seven business days follow. If compliance is verified, restrictions come off within one working day.

That sequence is easy to repeat and easy to put on a slide. The harder question is what counts as compliance when the holder wants the restrictions removed.

Two exits, one missing door

Article 3.4 gives a holder two ways to comply during the seven-day period: the identified prefixes leave the approved lists, or the holder takes verified administrative action to isolate them. Article 3.6 sets the restoration test. It says restrictions lift after the prefixes leave the lists, or, where RPKI is involved, the appropriate Route Origin Authorisation (ROA) has been deleted.

The isolation route has vanished. A holder could isolate a prefix at its network edge while a list entry remains visible in the required public archive. Article 3.4 calls that compliance. Article 3.6 does not name it as a way back. The one-day restoration clock therefore has no stated start for that repair.

The ROA route raises a different question. RFC 9582 defines a ROA as a signed object authorising an Autonomous System to originate routes for specified prefixes. RFC 6811 gives a route the state NotFound when no validated ROA payload covers its prefix. That status describes the validation record. BGP withdrawal and prefix isolation require separate network actions; router policy determines whether a validation state changes forwarding or route selection.

Clause 3.6 asks the operator to show one kind of evidence and lets RIPE NCC apply a binary check. The check can be quick. Its result can still differ from the actual repair Article 3.4 accepted.

The list is part of the enforcement machinery

The proposal assigns the Security Working Group a registry of approved blocklists. A list must use objective automated telemetry, exclude residential and dynamic subscriber pools, and keep a publicly verifiable history. Those are useful boundaries. They leave practical decisions for the discussion: how a list is admitted, how an error is challenged, which historical snapshot controls a 14-day count, and how overlapping entries are reconciled.

The proposal also leaves the intermediate restrictions to a separate RIPE document. Article 3.5 says they will depend on the holder’s registry architecture, restrict operational registry agility and place a public “non-compliant abuse status” in the RIPE Database while aiming to keep resource assignments intact. Its rationale says the restrictions still need to be agreed and specified well enough to avoid ambiguous or unworkable administration. That is a control surface, not a footnote.

The draft is open for discussion. The October RIPE NCC member update lists 11 November as the comment deadline; RIPE 93 schedules the proposal in the Security Working Group on 27 October. The next version can resolve the exit test before the clock is treated as ready to run.

Sources