Feedback-ID: :jgersch@invykta.com:invykta.com:flockmailId
From: Invykta <jgersch@invykta.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_ED2DC9DD-2C52-4712-BDED-F3EB100A7489"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Message-Id: <BC17529B-6B70-45C8-8DE0-098EC423B128@invykta.com>
Date: Tue, 22 Sep 2026 08:52:52 -0700
To: sidrops@ietf.org
Message-ID-Hash: W2QIPVKUHUG4OCFIPDVFGCRJ2HUHSOHX
Precedence: list
Subject: [Sidrops] New I-D: Route Origin Authorization via Protected Delegation of
 Internet Number Resources
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/sidrops/tDGhYecGaQ2i30NVal3ISlCMHLo>


--Apple-Mail=_ED2DC9DD-2C52-4712-BDED-F3EB100A7489
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi SIDROPS,

I've submitted a new individual Internet-Draft, "Route Origin =
Authorization via Protected Delegation of Internet Number Resources" =
(draft-gersch-sidrops-sovereign-roots-00):

   =20
=
https://www.ietf.org/archive/id/draft-gersch-sidrops-sovereign-roots-00.ht=
ml=20

https://datatracker.ietf.org/doc/draft-gersch-sidrops-sovereign-roots/


The central question posed is simple: after an Internet number resource =
has been delegated, should it be possible for the authorization system =
to express that the superior authority has actually relinquished =
authority over it?

RPKI provides cryptographic route-origin authorization, but its =
hierarchical authority model does not provide that property. A superior =
authority remains part of the authorization hierarchy after delegation. =
This draft explores a protected delegation boundary after which a =
superior authority no longer retains the technical capability to reclaim =
the delegated resource, suppress the holder's effective route-origin =
authorizations, or create competing allocation or route-origin authority =
within the protected range.

The proposal is not intended to replace RPKI. It uses a hierarchical =
resource registry with protected delegation boundaries enforced at =
state-transition time, derives conventional VRPs, and defines precedence =
rules for coexistence with RPKI. Routers continue to perform ordinary =
ROV and require no changes; the additional logic is confined to the =
authority and relying-party/aggregation side.

One consequence is that the mechanism can also provide route-origin =
authorization for resources that are not currently protected by RPKI, =
including legacy resources, but the proposal does not depend on such =
resources remaining outside RPKI.

I would particularly welcome feedback on:

* whether protected delegation is a useful authorization property in its =
own right;
* whether the proposed RPKI coexistence and protected-range precedence =
semantics are sound; and
* whether the trust, recovery, finality, and operational tradeoffs are =
stated clearly enough for experimentation.

This is an Experimental -00 intended to start technical discussion, not =
to propose a replacement for RPKI.

Thanks,

Joseph Gersch
Invykta LLC=20=

--Apple-Mail=_ED2DC9DD-2C52-4712-BDED-F3EB100A7489
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><div>Hi =
SIDROPS,</div><div><br></div><div>I've submitted a new individual =
Internet-Draft, "Route Origin Authorization via Protected Delegation of =
Internet Number Resources" =
(draft-gersch-sidrops-sovereign-roots-00):</div><div><br></div><div>&nbsp;=
 &nbsp;&nbsp;</div><a =
href=3D"https://www.ietf.org/archive/id/draft-gersch-sidrops-sovereign-roo=
ts-00.html">https://www.ietf.org/archive/id/draft-gersch-sidrops-sovereign=
-roots-00.html</a>&nbsp;<div><br><a =
href=3D"https://datatracker.ietf.org/doc/draft-gersch-sidrops-sovereign-ro=
ots/">https://datatracker.ietf.org/doc/draft-gersch-sidrops-sovereign-root=
s/</a></div><div><br><div></div><div><br></div><div>The central question =
posed is simple: after an Internet number resource has been delegated, =
should it be possible for the authorization system to express that the =
superior authority has actually relinquished authority over =
it?</div><div><br></div><div>RPKI provides cryptographic route-origin =
authorization, but its hierarchical authority model does not provide =
that property. A superior authority remains part of the authorization =
hierarchy after delegation. This draft explores a protected delegation =
boundary after which a superior authority no longer retains the =
technical capability to reclaim the delegated resource, suppress the =
holder's effective route-origin authorizations, or create competing =
allocation or route-origin authority within the protected =
range.</div><div><br></div><div>The proposal is not intended to replace =
RPKI. It uses a hierarchical resource registry with protected delegation =
boundaries enforced at state-transition time, derives conventional VRPs, =
and defines precedence rules for coexistence with RPKI. Routers continue =
to perform ordinary ROV and require no changes; the additional logic is =
confined to the authority and relying-party/aggregation =
side.</div><div><br></div><div>One consequence is that the mechanism can =
also provide route-origin authorization for resources that are not =
currently protected by RPKI, including legacy resources, but the =
proposal does not depend on such resources remaining outside =
RPKI.</div><div><br></div><div>I would particularly welcome feedback =
on:</div><div><br></div><div>* whether protected delegation is a useful =
authorization property in its own right;</div><div>* whether the =
proposed RPKI coexistence and protected-range precedence semantics are =
sound; and</div><div>* whether the trust, recovery, finality, and =
operational tradeoffs are stated clearly enough for =
experimentation.</div><div><br></div><div>This is an Experimental -00 =
intended to start technical discussion, not to propose a replacement for =
RPKI.</div><div><br></div><div>Thanks,</div><div><br></div><div>Joseph =
Gersch</div><div>Invykta LLC&nbsp;</div></div></body></html>=

--Apple-Mail=_ED2DC9DD-2C52-4712-BDED-F3EB100A7489--