Who Controls the ROA in an IPv4 Lease?

Summary

A Route Origin Authorization is a signed statement that a named autonomous system may originate specified prefixes. It is not a conveyance of ownership, a command to routers, a warranty that the route is benign, or proof that the named AS is still entitled under a private lease.
In most leases, the lessor remains the direct resource holder and therefore sits closest to the RPKI certification chain. The lessee runs the network and knows which origin ASes and more-specific routes are operationally necessary. The upstream carries or filters the route. The RIR operates a trust anchor or parent certification service. These are different powers.
Hosted and delegated RPKI alter custody and execution, not the underlying commercial bargain. Hosted service places key operations and publication with an RIR; delegated service lets the holder operate a CA and usually its private key. Neither arrangement, by itself, gives a lessee timely rights or protects it from a disputed deletion.
Every lease should attach an authorization schedule naming the exact prefixes, permitted origin ASes, maximum lengths, start and end windows, ordinary change deadline, emergency deadline, approvers, authentication channels and evidence to retain. A generic promise to provide a letter of authorization is not enough.
Contract time and RPKI time must be deliberately aligned. Hosted services may renew signed entities automatically, caches refresh on their own cadence, and a route can remain visible after the commercial term. Expiry at midnight is therefore neither instant technical revocation nor a safe reason to delete the only valid ROA before traffic has migrated.
Emergency access should be narrow and redundant. A lessee needs a way to add a pre-approved mitigation or replacement origin quickly, while the lessor needs limits that prevent open-ended delegation. Dual approval, bounded prefixes, short-lived emergency authority, independent logs and a post-incident review can meet both needs.
A commercial dispute should not be fought by surprising the global routing system. Except for an active security emergency, ROA deletion should follow notice, a short continuity window, independent escalation and a coordinated route withdrawal. The eventual revocation must be certain; the path to it should not turn customers into leverage.

The lease divides use from attestation

The awkward question in an IPv4 lease is not who owns the router. It is who can make the cryptographic statement on which other routers may rely.

The lessee may configure the origin AS, announce the prefix, serve customers, answer abuse reports and pay the transit bill. Yet if the prefix remains certified to the lessor, the lessee may be unable to create, alter or delete the ROA that describes its own live announcement. The lessor can be economically passive and technically decisive. A forgotten portal account or an unavailable signatory can turn a routine routing change into an outage risk.

That does not make leasing defective. It means a lease sits across two systems of authority. Contract law determines what one party promised another. RPKI determines whether a signed authorization can be validated through a chain rooted in the number-resource hierarchy. BGP determines what paths networks actually advertise and select. Transit contracts determine what an upstream will accept. None of those systems automatically reads the others.

RFC 9582 defines a ROA as a signed entity through which an address-block holder authorizes an AS to originate routes to one or more prefixes. Its security section is unusually useful for governance: RPKI provides authorization rather than identity authentication or non-repudiation. The entity proves that a valid certification path supported the statement when relying parties processed it. It does not publish the lease, price, customer, beneficial user, reason for the route or deadline in the commercial agreement.

This distinction defeats two common shortcuts. The first says that the party able to create the ROA must be the economic owner. That does not follow. The second says that the party named as origin in the ROA must control the address rights. That does not follow either. A holder may authorize a customer's AS, an upstream, a cloud network or a mitigation provider without transferring the resource. The signed entity is deliberately narrower than the surrounding relationship.

The right question is therefore not simply, "Who controls the ROA?" It is a set of questions: Who can ask for a change? Who decides that the request falls within the lease? Who operates the signing system? Who can stop an unsafe change? Who can act when the primary party is unreachable? Who bears the loss if a promised change is late? Who must remove authorization when the right to route ends?

A lease that answers only the first question leaves the rest to improvisation.

Four actors hold four different kinds of power

The lessor, lessee, upstream and RIR CA are often described as if they were points in a single chain of command. They are better understood as four actors with intersecting but non-identical power.

The lessor usually retains the registered relationship from which resource certification is derived. In a hosted RPKI service, an authorized user for the lessor's organization may create ROA configurations through the RIR's interface. In a delegated arrangement, the lessor may operate its own CA and hold the corresponding private key. The lessor's decisive capability is attestation: it can cause a statement about a prefix and origin AS to enter or leave the validated RPKI set.

The lessee has operational knowledge. It knows the intended origin, the upstream design, customer migration state, traffic-engineering more-specifics, mitigation arrangements and the date on which a new route must work. Its decisive capability is use: it or its providers can configure and originate BGP announcements. That capability can exist even when the route becomes RPKI Invalid, because RPKI does not switch BGP off. The practical consequence depends on which networks apply route-origin validation and how.

The upstream has acceptance and propagation power. It can require a letter of authorization, IRR object, matching ROA, contractual proof or some combination. It can build customer prefix filters from its own records, an IRR, RPKI validated payloads or manual review. It can refuse an otherwise valid route because the customer relationship is unverified, or carry a Not Found route under its policy. A valid ROA is relevant evidence, not a command to the upstream.

The RIR CA sits in the certification hierarchy. RFC 6480 describes an architecture aligned with number-resource allocation. RIR services issue or maintain the parent resource certificate, host signing for many holders, publish material and connect changes in certified resources to the hierarchy. The RIR is not a party to most leases and normally does not know their complete commercial terms. Its system can authenticate the holder's account and validate resource coverage without knowing whether a lessee's invoice is disputed.

These powers should not be collapsed. A lessor's ability to delete a ROA does not mean it should control the lessee's router. A lessee's ability to send an announcement does not mean it should have unrestricted signing power over the lessor's aggregate. An upstream's filter does not settle the lease. An RIR's certificate does not adjudicate beneficial use.

Good governance begins by admitting that no single actor sees the whole relationship.

A ROA authorizes an origin, not a route in all its dimensions

The narrowness of the ROA is a strength, but it becomes dangerous when contracts describe it too broadly.

A ROA identifies one origin AS and one or more prefixes. It may include a maximum length that permits certain more-specific announcements. If several ASes are authorized to originate the same prefix, separate ROAs are required. The entity does not state which upstream may carry the route, what AS path is acceptable, whether the origin has a current service agreement, which customer traffic belongs on the addresses or whether an announcement is geographically expected.

That is why "RPKI-compliant lease" can conceal more than it reveals. A lessor can create a technically valid ROA for the wrong business party's ASN. A lessee can keep announcing through the authorized origin after a service contract has ended. An authorized AS can accidentally leak or deliberately announce a more-specific permitted by an overbroad maximum length. A route can be RPKI Valid and still be operationally mistaken or abusive.

RFC 6483 warns that a ROA can affect other announcements covered by the same address space: routes from unlisted origins, or more-specifics beyond the permitted length, can become Invalid. It recommends accounting for all legitimately authorized origins and relevant more-specifics. RFC 7115 likewise treats origin validation as an operational input rather than a universal route-selection verdict.

For a lease, this means the schedule cannot merely say, "Lessor will create a ROA." It must state the exact prefix-origin pairs and explain the more-specific policy. If a /20 will be announced only as a /20 from the lessee's ASN, an unnecessarily permissive maximum length should not be granted as a convenience. If the lessee needs /24 announcements from two origins during migration, both origins and the temporary period should be explicit.

The upstream's role remains separate. The MANRS network-operator actions call for operators to ensure the correctness of their own and customer announcements, keep usable contacts and publish information that others can validate. A transit provider that checks only whether a ROA exists is not completing that task. It still needs to know that its customer is the party authorized to ask it to carry the route.

The lease should therefore promise several coordinated facts, not a magical status: commercial permission from the lessor, operational instruction from the lessee, origin authorization in RPKI, accurate routing information, and acceptance by the intended upstream.

Hosted RPKI concentrates execution at the holder's account

Hosted RPKI is attractive because it removes most of the cryptographic administration from the resource holder. That convenience also clarifies where lease dependence sits.

RIPE NCC's hosted CA guide says the hosted service signs, publishes and renews ROA objects from configurations managed by an authorized account. The user manages intended origin and prefix information; the service handles keys, entity renewal and publication. ARIN's hosted RPKI documentation similarly places the CA and signing with ARIN and says downstream organizations must have their upstream provider submit ROAs on their behalf where they cannot participate directly.

For a lessor, hosted service can reduce operational failure. There is no private CA repository for the lessee to monitor and no signing key to place in an employee laptop. For a lessee, however, the key question becomes account governance. Which individuals at the lessor can approve a request? Is there round-the-clock coverage? Can the lessee have a restricted role, or must every change be transcribed by the holder? What happens if the lessor's account is locked during an identity check, corporate change or dispute?

Portal access should not be shared casually. Giving a lessee the lessor's general credentials may expose unrelated prefixes, other customers and destructive actions. It also blurs attribution: the lessor cannot later tell whether its employee, contractor or customer made a change. Even if an interface supports multiple users, authorization should be scoped to the organization and tasks each person is allowed to perform.

The safer hosted model treats the lessee as an authenticated requester and the lessor as a bounded approver. Requests use a defined channel, identify the lease and prefixes, include the proposed origin and maximum length, and receive a transaction record. Routine changes have a service deadline. Emergency changes use a faster channel with separate authentication. Two people at the lessor should be able to act, and the lessee should have at least two approved requesters.

Automation can reduce delay, but it should enforce the authorization schedule rather than bypass it. A request for a listed prefix, listed ASN and permitted maximum length may be eligible for rapid approval. A request to authorize an unknown ASN or a broader more-specific range should stop for human review. The distinction is between automating a known promise and silently enlarging the promise.

Hosted service solves key operation. It does not solve commercial delegation unless the contract and account roles do.

Delegated RPKI moves the key, not the parent relationship

Delegated RPKI can give a resource holder more technical autonomy. It can also create a mistaken belief that the holder has escaped all upstream dependence.

RIPE NCC's comparison of hosted and delegated service says a delegated operator controls its resource certificate and corresponding private key and can choose where to publish. ARIN's deployment options state that a direct holder may operate its own CA, sign ROAs, and in the delegated model issue resource certificates for customers. APNIC also identifies self-hosted mode as delegated RPKI in its resource certification material.

That architecture can support a more direct division. A sophisticated lessor may run a parent CA and issue a subordinate resource certificate limited to the lessee's prefixes. The lessee can then sign entities within that bounded set without receiving power over the lessor's other resources. At the end of the lease, the lessor can revoke or allow the subordinate certificate to expire under the agreed sequence.

The apparent elegance carries operational duties. Someone must secure the private key, maintain the CA, publish current entities, manage manifests and revocation information, monitor availability, roll keys and preserve recovery access. The RIPE NCC policy on persistently non-functional delegated CAs illustrates the consequence of prolonged failure: after extended inability to discover and validate current material, the parent may revoke the delegated resource certificate. Delegation is control coupled to maintenance, not a one-time handover.

The parent relationship also remains. A delegated certificate exists within a hierarchy. If the certified resources change or the parent certificate is revoked, subordinate authority is affected. RFC 8211 examines adverse or mistaken actions by CAs and repository managers precisely because local possession of a key does not eliminate hierarchical and publication dependencies.

For many lessees, running a CA would be disproportionate. For large operators with frequent origin changes, multiple upstreams or strict continuity needs, bounded delegation may be worth the cost. The choice should depend on change frequency, outage tolerance, staff capability and the lessor's portfolio design, not on the prestige of holding a key.

Most importantly, delegated RPKI must not become an informal permanent grant. The subordinate resources, certificate term, renewal rule, revocation events, repository duties, emergency contacts and evidence of destruction or transfer at exit all belong in the lease. Moving the private key closer to the lessee reduces one delay while increasing the importance of disciplined termination.

The authorization schedule is the missing commercial instrument

The main agreement can state the economic bargain. A separate authorization schedule should state the routing-security bargain in terms an engineer and a lawyer can both test.

The schedule starts with exact CIDRs. It then lists every permitted origin AS, the legal entity controlling that AS, the intended transit or hosting relationship and the allowed prefix length for each announcement. If multiple origins are temporary, the schedule gives them start and removal dates. If the lessee may use a mitigation provider, the provider's ASN can be pre-approved without being activated until an incident.

Next come the roles. Name the lessor's service owner and backup approver, the lessee's network lead and backup requester, and the contacts at each intended upstream. Use role addresses and authenticated channels, not only named employees. Employees leave; authorization should survive without leaving stale personal accounts behind.

The schedule then sets clocks. A normal request may require completion within one business day. A planned migration may require advance notice of five or ten business days. A severe outage may require acknowledgement in fifteen minutes and a bounded change in sixty minutes. The precise numbers depend on the service, but silence is not a service level.

The change record should include the request time, authenticated requester, affected prefix, old and new origin, maximum length, business reason, approval, publication observation and validation observation. This is not bureaucracy for its own sake. When a route becomes Invalid, the parties need to know whether the ROA was never changed, changed but not yet visible, changed incorrectly or made ineffective by another covering ROA.

Finally, state which requests the lessor may reject. A request outside the leased prefix, an ASN not controlled by an approved operator, a maximum length broader than the agreed routing design, or a change that would invalidate another customer's routes can require amendment rather than immediate execution. A rejection should be reasoned and time-stamped, not a vague invocation of security.

The schedule should be versioned with signatures or equivalent authenticated acceptance. The live ROA set should be compared with it at activation, after every approved change, at periodic review and before termination. The agreement then has a measurable answer to control: the lessor controls certification within a pre-agreed mandate; the lessee controls operational requests within the same mandate; neither may silently enlarge the other party's risk.

Contract time and RPKI time are different clocks

Leases use dates because dates are legible to courts and finance teams. Routing security operates through publication and retrieval, which rarely shares the same boundary.

A lease might begin at 00:00 UTC on Monday. The ROA may be created earlier so that relying-party caches can retrieve it before the first announcement. A hosted service may renew the signed entity automatically while its configuration remains active. If the lease ends, the commercial right can expire even though the last published authorization remains valid and visible. Conversely, deleting the configuration at 00:00 does not prove that every relying party has removed the corresponding validated payload at 00:01.

The contract therefore needs three moments rather than one. The authorization-ready time is when the intended route has a visible valid authorization and the upstream has confirmed its filters. The service-use time is when the lessee may announce and place customer traffic on the prefix. The authorization-end time is when the old origin must no longer be represented as permitted in RPKI after traffic has been withdrawn.

Those moments can overlap without contradiction. A ROA may be prepared before commercial use, provided the lessee is prohibited from announcing early. It may remain briefly during an orderly withdrawal, provided the lessee is prohibited from adding new customers and must reduce traffic. The residual authorization is controlled transition capacity, not an extension of the lease's economics.

This also explains why ROA expiration is a poor substitute for termination. A long certificate or entity lifetime can outlast the lease. A short lifetime can create avoidable renewal risk during the term. Hosted systems may renew well ahead of expiry, while delegated systems depend on local operation. The governing event should be an explicit end instruction, backed by observation, rather than hope that a timer coincides with the bargain.

The reverse mismatch matters too. If a lessor deletes the ROA before the lessee's replacement addresses or alternate origin are ready, networks that reject Invalid routes may stop carrying traffic. Customers bear the outage even if the lessor is contractually correct about the final date. If the lessor never deletes it, the former lessee retains a weaker but real opportunity to originate a route that some validators will regard as authorized.

Time alignment is therefore not leniency. It is the discipline of making authorization appear before dependence and disappear after dependence, with as little unsafe overlap as the service can tolerate.

Emergency change rights must be designed before the emergency

The most revealing test of ROA governance is not a planned migration. It is a Saturday outage when the approved origin cannot carry traffic and the only engineer who normally signs changes is asleep or unreachable.

An emergency may require a new transit provider, a DDoS mitigation ASN, a backup data center, a replacement origin after a router failure, or a temporary more-specific announcement. It may also involve compromised RPKI credentials or an accidental authorization that is making legitimate routes Invalid. The party observing the incident may be the lessee, upstream, lessor or an external network.

The lease should pre-authorize categories, not unlimited action. A list of standby ASNs can be verified at signing. A maximum emergency prefix length can be set. The lessee can be permitted to activate only the prefixes it leases and only for a short period. Any broader change requires an additional approver. This gives the operator speed without handing it a permanent blank cheque.

Authentication must survive the same incident. If ordinary requests depend on one email domain hosted behind the affected prefix, the channel may fail when it is needed. Use at least one out-of-band method and keep contacts at both organizations. The lessor should require a request code, named role, callback or cryptographic approval appropriate to the parties' risk. The point is to resist impersonation without turning identity checking into a multi-hour barrier.

The change itself should be reversible. Add the narrowly required origin; do not broaden unrelated ROAs. Set an expiry or review deadline for the emergency authorization. Confirm that the new route is observed and accepted before withdrawing the old path. After the incident, remove temporary authority and reconcile the live set with the schedule.

Liability should follow controllable delay. If the lessee failed to maintain approved contacts or demanded an unlisted ASN without evidence, it should carry that consequence. If the lessor missed an agreed emergency deadline despite a valid request, a fee credit alone may not reflect customer loss; the agreement may need an indemnity cap, termination right or right to move to bounded delegation. If the upstream rejected a route despite having received all required evidence, its service terms matter separately.

Emergency rights should be exercised rarely. Their value is that each party knows the path under pressure, not that the lessor becomes a 24-hour routing desk for routine changes.

Maximum length is a commercial risk decision

The most technical-looking field in a ROA can carry a large commercial consequence. maxLength determines how specific an announcement the authorized AS may originate while remaining consistent with that ROA.

An overly narrow authorization can make a legitimate traffic-engineering or mitigation route Invalid. An overly broad one can permit more-specific announcements that were never necessary for the lease. The decision affects failure containment, upstream practice and the range of routes that validators may accept as authorized.

The easy drafting error is to set the maximum to /24 for every leased IPv4 aggregate because /24 is commonly accepted across the global table. That may be operationally convenient, but it delegates more authority than a lessee that announces only an aggregate needs. If a /19 is always originated as a /19, a /24 maximum creates room for 32 separate more-specifics without explaining why. RFC 9582 says the field should be omitted when it equals the prefix length and defines how it bounds more-specific authorization.

The opposite error is to authorize only the aggregate when the lessee's documented design depends on more-specifics. An emergency scrubbing provider may announce /24s. A migration between two origins may divide an aggregate temporarily. If the contract ignores that design, the lessee will ask for a hurried change at the worst moment.

The authorization schedule should match the smallest set of expected routes, not the broadest technically possible set. Where several /24s are expected from different origins, explicit ROAs can make the division visible. Where a temporary wider maximum is justified, it should have an end date and a reason.

This is also a portfolio issue for lessors. One broad covering ROA can interact with more-specific leases beneath it. Before approving a change, the lessor must test whether another customer's valid route would become Invalid because of a covering authorization with a different origin or restrictive maximum. The lessor's inventory therefore needs to understand overlaps, not merely lease rows.

The commercial principle is least necessary authority. The lessee receives enough cryptographic permission to run the agreed network, including realistic resilience. The lessor does not retain an artificial veto over documented operations, but it also does not publish a permission wider than the bargain.

The upstream is an independent control, not a messenger

Transit providers are often treated as the final delivery point for a letter of authorization. In a mature lease, they should participate earlier.

Before activation, the intended upstream should confirm the exact prefixes and origin ASN it will accept, the evidence it requires, the minimum route size, the treatment of more-specifics, whether it builds filters from IRR or RPKI data, and how quickly those filters refresh. This confirmation belongs beside the ROA schedule because a technically correct authorization has little operational value if the upstream's customer filter still rejects the route.

The upstream should authenticate its customer independently. A valid ROA can show that a certification chain authorizes the origin ASN for a prefix. It does not prove that the person opening a transit ticket controls that ASN or that the lessor approved the commercial account. A letter of authorization can connect the parties, but letters are easy to forward and difficult to revoke globally. Account records, verified contacts and direct confirmation from the lessor make the evidence stronger.

During the lease, the upstream should not accept an origin change solely because a new ROA appeared. The change may be accidental, malicious or intended for a different provider. Nor should it ignore a new Invalid state. It should contact the lessee and lessor through known channels, compare the route with the agreed prefix list and determine whether the route or authorization is wrong.

At termination, the upstream has a decisive role in making revocation real. The lessor can remove a ROA, but the former lessee may still send the BGP announcement. The upstream can remove customer prefix permission and reject the route at the direct boundary. That local action is often faster and more certain than waiting for every network to apply updated validation data.

This division is healthy. RPKI provides globally verifiable origin authorization. The upstream enforces the customer relationship nearest to the source. The lease connects the two. None should be asked to carry the entire burden.

An upstream that supports leased prefixes can publish its evidence requirements and emergency contact route. Predictability makes safe leasing easier. Secret, inconsistent review pushes operators toward last-minute tickets and informal exceptions, which weakens both security and accountability.

Disputes need isolation from customer traffic

The hardest clause is what happens when the lessor and lessee disagree about money, breach, abuse or renewal while the prefix still carries live services.

The lessor may fear that a continuity period rewards non-payment or permits harm. The lessee may fear that the lessor will use ROA deletion as a remote kill switch. Both concerns are legitimate. The answer cannot be permanent authorization, but it should not be an unannounced cryptographic ambush either.

Start by distinguishing events. Scheduled expiry and ordinary non-renewal should follow the full exit plan. A disputed invoice should trigger notice and a short cure period unless the agreement clearly makes payment immediate and critical. Credible evidence of active abuse may justify tighter controls, but removing a ROA does not necessarily stop the abusive route; the direct upstream and lessee's equipment remain more immediate points of intervention. A compromised signing key requires security action even if the commercial relationship is sound.

During a bona fide dispute, freeze discretionary expansion. The lessee should not add customers, request new origins or widen maximum lengths. The lessor should preserve the last known safe authorizations for the bounded continuity period. Both parties should notify the upstream that no change is valid without dual confirmation, except a documented emergency needed to protect traffic.

An independent escalation contact can determine whether a request fits the existing schedule without deciding the whole lawsuit. The question is narrow: does the requested action preserve an already authorized service, or does it enlarge rights? That limited determination can keep routing stable while commercial claims proceed elsewhere.

The agreement should also define a hard stop. Continuity cannot become indefinite occupation. At the end of the cure or migration period, the lessee must withdraw routes, the upstream must remove filters, and the lessor must remove the ROA. Failure by either side produces specified evidence and remedies. If customer safety requires a court order or emergency relief, the parties know which acts must be restrained.

Logs matter most here. A party alleging wrongful deletion should be able to show the agreed authorization, request, acknowledgement, change time and validation impact. A lessor alleging continued use should be able to show route observations after the withdrawal deadline. Dispute isolation works only when facts can be reconstructed without trusting one side's inbox.

The governing norm is simple: do not make unrelated Internet users the enforcement mechanism for a private debt, and do not use their dependence to make a lease perpetual.

Revocation is necessary, but deletion is not a complete remedy

A lease must end with the former lessee unable to rely on the lessor's authorization. That requires revocation or removal at the appropriate layer. It also requires more than revocation.

When the authorization-end time arrives, the lessor should remove or modify the relevant ROA configuration. In delegated arrangements, it may revoke the bounded subordinate certificate after confirming that no continuing authorization is required. The parties should observe the resulting validated payloads from more than one independent vantage point. A portal success message is evidence of a submitted act, not proof that the public state has converged.

At the same time, the lessee must withdraw the BGP route and its upstreams must remove customer permission. IRR route objects that still name the old origin should be deleted or updated. Reverse DNS and public contacts should no longer point to a former operator where that would misdirect operational or abuse reports. These systems have different refresh times and maintainers, so a single timestamp cannot prove complete exit.

Deletion can also have collateral effects. A ROA may cover several prefixes, and a delegated certificate may contain resources beyond one lease if the lessor designed it badly. The operator must identify the exact entity or authorization to change. "Revoke the customer's RPKI" is not a safe instruction unless the certification boundary matches the customer boundary.

The residual risk runs both ways. If the ROA remains, the former lessee retains a validation advantage should it continue announcing. If the ROA disappears while a stale route remains, the route may become Invalid and be rejected unevenly, creating partial reachability rather than universal silence. If no covering ROA remains, the route may become Not Found and continue to propagate under many policies. RPKI state is therefore not a reliable substitute for withdrawing at the source.

A completion record should state: route withdrawn by the old origin; upstream filter removed; old ROA absent or replaced; no unintended covering authorization remains; delegated certificate closed where applicable; IRR records reconciled; and monitoring continued through a defined observation period. Exceptions should be named rather than rounded into "done."

Revocation protects the lessor and the next user. Coordinated withdrawal protects current customers. A responsible exit does both.

The RIR should authenticate certification authority, not decide the lease

RIRs occupy a sensitive position because hosted service can make them the place where a contested change is executed. That does not mean they should become tribunals for every IPv4 lease.

The RIR has a legitimate interest in authenticating the organization entitled to use its certification service, protecting accounts, maintaining the hierarchy and responding to proven credential compromise. It may need to alter certified resources after a transfer, return or registration change. RIPE NCC's hosted documentation notes that resource certificates update as resources move and published ROAs are adjusted when resources are removed. Those are consequences of the certification hierarchy.

A private lease dispute is different. The RIR usually lacks the contract, payment history, customer migration facts and governing-law evidence needed to decide which party is in breach. If it accepts unsupported instructions from a lessee, it may displace the holder's authority. If it treats every holder instruction as conclusive despite a court order or proven account compromise, it may amplify harm. The answer is a narrow role with clear process.

The RIR can preserve logs, authenticate account actors, publish service status, provide documented emergency channels for security incidents and comply with valid legal orders. It can make account roles granular enough that a holder need not share broad credentials. It can explain the technical effects of hosted and delegated choices. It should be cautious about converting ambiguous leasing policy into discretionary control over live routes.

This restraint is consistent with the limited meaning of the ROA. The certification service verifies authority within the number-resource hierarchy. It does not certify every private reason for exercising that authority. The commercial obligation remains enforceable between the parties and, where necessary, through courts or agreed dispute mechanisms.

The registry layer can still improve leasing without recognizing a new property category. It can support scoped users, machine-readable change history, notifications to multiple contacts, delayed destructive actions where safe, and exportable evidence of current and prior configurations. These tools reduce dependence on one account holder while leaving the legal bargain outside the CA.

The policy goal should be predictable execution, not moral approval of each lease. A secure system can distinguish the person technically entitled to sign from the person contractually entitled to request without pretending those are always the same person.

Control has an economic price

ROA control is often bundled into the lease price as if it were a free clerical task. It is a separate continuity service.

A lessor that promises rapid changes must maintain trained staff, protected credentials, monitoring, backup approvers and incident coverage. A delegated model requires CA operation and publication reliability. A lessee that needs frequent origin changes imposes more cost and creates more opportunity for error than a lessee with one stable ASN. Pricing should make those differences visible.

The alternative is false economy. A low-cost lease with a five-day response to an emergency ROA change may be unusable for a network with strict availability commitments. A lessee may then share credentials informally, ask an upstream for exceptions or maintain an overbroad authorization to avoid future delay. Each shortcut converts an unpriced service requirement into security risk.

The wider economics of network identity sharpen the point. Lu Heng's note on network identity and customer continuity argues that an address can become embedded in customer whitelists, partner rules, APIs and compliance systems. Once that happens, a failed ROA change is not just a routing inconvenience. It can interrupt a business identity that external parties already trust.

His discussion of managed IPv4 leasing and registry risk makes a related market point: obtaining addresses is only the visible transaction; continued operability depends on how registry, routing and lifecycle risks are carried. A neutral analysis need not accept every institutional conclusion in that argument to recognize the operational fact. The party selling continuity should describe and price the acts that continuity requires.

This can produce service tiers. A basic lease may permit one stable origin and business-hours changes. A resilient lease may include two origins, pre-approved mitigation, round-the-clock response and periodic reconciliation. A lessee with its own capable CA may choose bounded delegation and accept more duties. Transparent tiers are better than pretending every lease includes instant, unlimited RPKI administration.

Control should also affect remedies. If the lessor charges for emergency coverage and fails to provide it, the consequence should be meaningful. If the lessee chooses a slower tier and later demands instant action, the lessor should not be treated as having promised what it did not sell.

The market becomes safer when the cryptographic dependency is named as part of the product rather than hidden in "support."

A practical allocation of rights

There is no universal arrangement, but a defensible default can be stated clearly.

The lessor retains ultimate control of the resource certification relationship and may refuse changes outside the leased scope. It must maintain at least two authorized operators, protect credentials, create the initial ROAs before activation, meet defined normal and emergency change times, give notice before destructive action except in a genuine security emergency, and remove authorization after verified exit.

The lessee controls its network design within the schedule. It must identify and prove control of each origin ASN, give accurate route plans, maintain two authenticated requesters, notify the lessor before planned changes, avoid announcements outside the authorization, monitor RPKI state, withdraw promptly at termination and retain evidence of upstream closure.

The upstream independently verifies the customer-prefix relationship, prepares filters before activation, monitors discrepancies, supports a direct emergency contact, refuses unscheduled origin changes pending confirmation and removes permission at exit. It does not rely on a ROA as the sole proof of customer authority.

The RIR or parent CA authenticates the resource holder, operates or supports the chosen certification model, protects the parent hierarchy, provides reliable publication and change records, and handles proven credential or legal events within a transparent remit. It does not infer the private lease from BGP or decide ordinary invoices.

For high-change or high-dependence leases, a bounded subordinate CA can move execution closer to the lessee. For low-change leases, hosted service with strict response commitments may be safer. For very short terms, the cost of RPKI and upstream transition may justify longer notice or a different address design. The choice should follow operational dependence, not ideology.

Every model needs the same guardrails: exact scope, least authority, redundant contacts, measured response, visible state, safe overlap, hard termination and independent evidence. Remove one, and control migrates to whoever happens to possess the credential when something goes wrong.

The test is whether authority follows responsibility

An IPv4 lease is sustainable when the party responsible for service can obtain necessary authorization, while the party responsible for the resource can prevent unauthorized expansion and guarantee eventual revocation.

That balance is not achieved by assigning the ROA to one actor in a sentence. It is achieved by connecting commercial permission to operational events. The lessor's certificate authority must not become an unpriced veto over routine network changes. The lessee's need for speed must not become permanent signing authority over an aggregate. The upstream must not outsource customer verification to a cryptographic entity. The RIR must not be pushed into deciding a contract it cannot see.

The technology already exposes the relevant distinctions. A ROA names a prefix, origin and optional maximum length. Hosted service centralizes signing operations. Delegated service moves key control and maintenance. Relying parties retrieve and validate published material. Routers apply local policy. The governance task is to make the lease just as precise.

The safest lease creates authorization before traffic depends on it, keeps the authorization aligned with documented routes, permits narrow emergency adaptation, isolates disputes from customers, and withdraws both the route and its cryptographic permission at the end. It records who did each act and when.

The final answer to "Who controls the ROA?" is therefore intentionally plural. The lessor controls the certified authority. The lessee controls the operational requirement. The upstream controls direct acceptance. The RIR controls a parent or hosted service within its remit. The contract controls how those powers meet.

If the contract is silent, the credential holder controls the crisis. If the contract is precise, no actor controls more than the responsibility it has agreed to bear.