Summary

  • A September individual Internet-Draft proposes a separate protected resource registry, but leaves each relying party free to choose whether to suppress existing RPKI-derived route authorizations.
  • Its own warning is concrete: applying that filter before protected authorizations become final and confirmed could turn routes from RPKI-valid evidence into NotFound for the electing consumer. That is a proposed failure mode, not a reported outage.

The interesting switch is not a key. It is a filter. A resource holder may control a delegated private key and still face a parent certificate authority able to revoke the child. Joseph Gersch’s new individual draft tries to change that superior power in a separate protected IPv4/IPv6 registry. Yet a router is not expected to abandon ordinary origin validation. The proposed bridge sits at a relying party or aggregator, where somebody decides which authorization set the router will see.

The document was submitted on 18 September and introduced to the SIDROPS list four days later. It is an individual Internet-Draft, not an adopted IETF standard or an operational registry service. Its protected state would become irreversible only after finality, holder confirmation and expiry of any provisional interval. A holder-selected recovery policy must be recorded first. Imported RIR or RPKI records would initially be assertions, not confirmed protected rights; exported origin authorizations must come from confirmed, final state.

These constraints matter because a recently visible transaction is not yet an instruction to displace existing route evidence.

RFC 8416 already permits local RPKI exceptions through SLURM filters and additions. The draft draws an important distinction between adding a new protected-registry VRP and loading a filter that removes an incumbent RPKI VRP. Section 10.6 says a mistaken filter can deny legitimate incumbent authority, and that the consumer’s decision to load it is optional local policy. Section 10.5 adds a less obvious edge case: a filter naming only the protected prefix may miss a less-specific ROA whose maximum-length permission reaches into it.

Partial suppression needs more precise replacement data or a richer mechanism, not a convenient prefix-only assumption.

The transition has a one-way-looking trap. If the consumer removes incumbent VRPs before the protected holder has final, confirmed origin authorizations, a route can be NotFound in that consumer’s view even though an incumbent RPKI ROA remains valid. NotFound is not Invalid, and forwarding depends on the operator’s routing policy; the draft does not document a real outage. A consumer taking only exported VRPs also trusts the exporter, because this proposal does not put the holder’s signature on that export. The advertised shift in control therefore depends on both registry state and the consumer’s source-selection decision.

The author describes a proof of concept on a permissioned chain, while listing independent implementations, production finality profiles and Internet-scale measurement as unfinished. In the mailing-list exchange, one participant questioned whether the approach belongs in SIDROPS; the author deferred to the chairs. Neither message is a working-group verdict. The news is a choice that can be made locally before any wider consensus exists: which incumbent authorizations, if any, may this new source cause a relying party to discard?

Sources