Delegated RPKI Control: Beyond Hosted Models

Setting up delegated RPKI requires coordination with exactly five RIRs globally. You will learn how identity verification drives the entire process, why the choice of publication server dictates your operational overhead, and the precise steps to migrate from hosted services to a self-managed environment.

The fundamental workflow relies on two specific XML files: a child request generated by your local Krill instance and a parent response returned by the registry. While RIPE NCC, APNIC, and ARIN currently offer hosted publication services to spare operators from maintaining public rsync servers, true control demands understanding the underlying publisher request and repository response exchange. NIC.br also provides this repository capability for its members, yet many organizations remain dependent on third-party publication due to the complexity of running a highly available web server.

Moving beyond hosted solutions eliminates single points of failure but requires strict adherence to portal-specific constraints. For instance, APNIC users switching from hosted to delegated models must open a help desk ticket, as MyAPNIC lacks a direct migration path. Conversely, RIPE NCC members can provision multiple repositories to delegate resources across business units without forcing downstream partners to run their own infrastructure.

The Role of Delegated RPKI in Modern IP Resource Management

Hosted vs Delegated RPKI Publication Server Models

Hosted RPKI allows the registry to sign objects, while delegated RPKI forces operators to manage their own Certificate Authority keys. RIPE NCC, APNIC, and ARIN currently offer publication services among the five global Regional Internet Registries that remove the operational burden of maintaining public rsync servers. Operators using delegated models must exchange XML files to establish identity and resource entitlement before publishing route origin authorizations independently. NIC.br also provides similar repository capabilities for members within the Brazilian region, illustrating how National Internet Registries support local infrastructure needs. Choosing delegation grants full control over signing workflows but introduces the strict requirement to keep a highly available web server running at all times. This constraint creates tension between administrative autonomy and infrastructure reliability that network architects must resolve based on internal capacity. Organizations holding resources across multiple regions face complex portal management if they do not consolidate their publication strategy early. Registries often provide these servers, yet third parties can also host publication services since users are free to publish certificates and ROAs anywhere.

Executing Delegated RPKI via XML Publisher Request Exchange

Initializing delegated RPKI requires exchanging exactly two XML files between the operator and the registry trust anchor. Unlike hosted models where the RIR signs objects, this workflow demands the generation of a specific publisher request file by the child CA. The parent registry validates this input and returns a repository response containing the signed delegation certificate. This mechanism allows enterprises holding space across multiple regions to pool resources into a single management interface rather than navigating up to five distinct web portals. Large operators increasingly prefer this approach to centralize control while maintaining strict hierarchical validation.

RIPE NCC uniquely supports provisioning multiple repositories, enabling parent organizations to delegate subsets of address space to business units or customers. These sub-entities can run their own CAs and publish directly to the main repository without building independent infrastructure. However, switching from hosted to delegated modes often requires manual intervention via support tickets at APNIC and ARIN, as automated migration paths remain unavailable in member portals. Operators must weigh the benefit of centralized management against the initial administrative friction of re-configuring existing allocations.

RIPE NCC APNIC ARIN Hosted Service Availability Gap

RIPE NCC, APNIC, and ARIN currently provide direct RPKI publication services, creating a distinct operational divide for the remaining two global regions. Members in LACNIC and AfriNIC territories face a service availability gap where they must deploy independent rsync infrastructure or rely on third-party vendors to publish Route Origin Authorizations. This disparity forces operators in Latin America and Africa to manage high-availability web servers that their counterparts in Europe, Asia-Pacific, and North America can bypass through registry-hosted solutions. While NIC.br offers similar repository capabilities for Brazilian entities, the lack of a unified regional publication server increases the complexity of maintaining valid RPKI certificates across the Global South.

The strategic implication for global networks is clear: organizations holding resources in unsupported regions must budget for additional infrastructure to match the durability offered by hosted services elsewhere. Clients with multi-regional holdings may centralize management via delegated models while accounting for these regional publication constraints.

Inside the XML Exchange Protocol for Parent-Child Certificate Relationships

Defining the Child Request XML Structure for RIR Delegation

The child request file starts the two-file exchange linking an operator's Certificate Authority to a Regional Internet Registry. This XML document holds specific public key material and resource identifiers that the parent CA validates before issuing a signed delegation certificate. The initial payload establishes the cryptographic trust relationship between the network operator and the registry, distinct from the subsequent publisher request used for repository synchronization.

Management software such as Krill generates this file locally so private keys never leave the organizational perimeter. The parent-interactions protocol mandates local generation to maintain strict control over the signing hierarchy. Operators upload the created file to the member portal for RIR processing.

• o the parent Resource List Specifies IPv4 blocks or ASNs for delegation Metadata Defines

Some registries lack automated upload paths for this XML structure, forcing manual ticket submission. AfriNIC keeps delegated RPKI in a test environment. LACNIC requires direct email coordination for configuration. Global entities managing space across multiple regions face operational friction due to this inconsistency. Optimizing this initial handshake ensures reliable Route Origin Authorization without relying on hosted signing services.

Configuring Delegated RPKI via RIR Member Portals

Administrators start delegated RPKI by logging into specific registry interfaces like my.ripe.net to upload child requests.

• APNIC members switching from hosted services must open a help desk ticket as MyAPNIC lacks a direct migration option.
• ARIN Online similarly requires a support ticket to transition from hosted to delegated RPKI configurations.
• LACNIC procedures remain undefined in their portal, necessitating contact via hostmaster @ lacnic. Net.
• RIPE NCC members must select non-hosted RPKI during initial setup or contact support to switch from hosted services.

The process relies on a strict two-file XML exchange protocol where the operator provides a request and the registry returns a signed response. This mechanism allows a single local CA to act as a child to multiple parents, centralizing management for global address space. Transitioning from hosted to delegated models often requires manual intervention via help desk tickets if the portal lacks a direct migration path. Operators holding resources in regions without active delegated support must maintain external publication servers, increasing operational overhead compared to peers using integrated registry services.

RIR vs NIR Service Availability for Hosted RPKI Publication

RIPE NCC, APNIC, and ARIN currently offer RPKI publication as a direct service, leaving LACNIC and AfriNIC members to manage independent infrastructure. This disparity forces operators in Latin America and Africa to maintain high-availability rsync servers that European and North American peers bypass via registry-hosted solutions. NIC.br provides similar repository capabilities for Brazilian entities, yet the lack of a unified regional publication server increases operational overhead for other national registries.

• Operators without hosted services must engineer redundant web servers solely to publish Route Origin Authorizations.
• Self-managed endpoints often compromise visibility during outages whereas hosted services guarantee consistent presence.
• Delegating publication functions allows engineers to focus on BGP security policy rather than storage availability.

Network durability depends on consistent visibility. Hosted services provide this reliability while self-managed endpoints risk compromise during outages.

Migrating from Hosted Services to a Self-Managed Krill Environment

Defining the Non-Hosted RPKI Mode Selection in RIPE NCC LIR Portal

Selecting the "non-hosted" option initiates delegated RPKI when a RIPE NCC member first accesses the configuration interface without existing settings. This specific mode selection acts as the mandatory prerequisite for operators intending to manage their own Certificate Authority using Krill rather than relying on registry-hosted signing. Organizations previously using the hosted service must locate the "Revoke hosted CA" link positioned at the bottom right of the dashboard to reset the state. Clicking this link triggers a dialog where all checkmarks require confirmation before the system displays the initial setup page. Here, selecting the "Delegated" radio button and accepting the Terms & Conditions finalizes the transition to a self-managed environment.

1. Access the RPKI dashboard within the LIR Portal.
2. Click "Revoke hosted CA" if migrating from a hosted setup.
3. Confirm all dialog checks and fill required fields.
4. Choose the "Delegated" radio button on the start page.

Network architects observe that failing to explicitly revoke an existing hosted CA prevents the portal from presenting the delegated options entirely. This procedural dependency ensures resource integrity but creates a hidden barrier for migration if the initial state is not correctly identified.

Executing the Hosted CA Revocation Workflow to Enable Delegated RPKI

RIPE NCC members click the red "Revoke hosted CA" link at the dashboard bottom-right to switch modes. This action initiates a mandatory workflow where operators check all dialog confirmations and populate required fields before proceeding. The system redirects to the Certificate Authority start page, demanding selection of the Delegated radio button and acceptance of Terms & Conditions. APNIC or ARIN users face portal limitations and must open help desk tickets, whereas RIPE NCC members execute this transition via self-service. Direct access accelerates the migration from centralized signing to independent key management without external dependency delays. Operators coordinate this switch carefully since the process involves resetting the CA state to allow for the creation of a new delegated authority. The following configuration illustrates the child request generation required immediately after completing the setup steps. Organizations managing assets across multiple regions note that LACNIC requires email correspondence while AfriNIC remains non-operational for delegated setups.

Navigating RIR-Specific Migration Barriers and Help Desk Dependencies

Procedural blocks appear immediately when self-service revocation links are absent from regional portals. RIPE NCC partners independently revoke a hosted CA, yet users of APNIC and ARIN encounter a hard constraint where no option exists within their each online interfaces to switch to delegated modes. This architectural gap forces reliance on manual help desk tickets, introducing unpredictable latency compared to the instant provisioning available in other regions. LACNIC presents a similar barrier; although the registry supports delegated RPKI, configuration remains impossible directly in the member portal. Operators must initiate contact via email to hostmaster channels to bypass these interface limitations. The situation is more severe for AfriNIC customers, where delegated capabilities exist only in a non-operational test environment. Migration timelines depend entirely on external support queue depths rather than internal engineering velocity. Organizations holding resources across multiple regions anticipate asymmetric rollout schedules, as some registries require human intervention for every configuration change.

1. Identify current registry portal capabilities before planning migration windows.
2. Prepare ticket templates for APNIC and ARIN to reduce back-and-forth delays.
3. Verify LACNIC hostmaster contact details prior to initiation.
4. Monitor AfriNIC test environment status updates regularly.
5. Document regional variance in deployment playbooks.

1. Prepare detailed support tickets for APNIC, ARIN, and LACNIC transitions.
2. Monitor AfriNIC announcements for operational status updates on test environments.

Global operators cannot standardize their RPKI deployment playbooks across all regions simultaneously due to the lack of uniform automation.

Operational Constraints and Portal Limitations Across Global Registries

Operational Gaps in RIR Member Portal RPKI Configuration

Current ARIN Online and MyAPNIC interfaces prevent direct self-service migration from hosted to delegated RPKI. Operators seeking this switch find no button to revoke the hosted Certificate Authority or alter publication modes. This functional void mandates manual help desk tickets, introducing unpredictable latency that contrasts sharply with instant provisioning found elsewhere. LACNIC presents a comparable barrier; although the registry supports delegated RPKI, the member portal lacks configuration capabilities.

• ARIN: No online option to switch modes; requires ticket submission.
• APNIC: Interface lacks revocation tools for existing hosted users.
• LACNIC: Delegated setup requires email intervention via hostmaster.

Procedural bottlenecks create dependency on registry support staff availability instead of automated XML exchange protocols. RIPE NCC constituents execute transitions via a self-service "Revoke hosted CA" link, while peers in other regions face administrative friction delaying route origin authorization updates. Operational tempo suffers measurably: network teams cannot rapidly respond to routing incidents by rotating keys if the registry portal locks them into a hosted state. Instant mode toggling remains necessary for modern BGP security postures.

Executing Manual RPKI Mode Switches via Help Desk Tickets

Absent self-service revocation links, operators must submit the requests to registry support teams for transitioning from hosted to delegated modes. This manual dependency creates a visible gap between delegated RPKI readiness and actual deployment capability across substantial regions. Networks holding resources in ARIN regions encounter an online interface lacking any button to switch modes, forcing complete reliance on ticketing systems. The situation mirrors constraints at APNIC, where the choice to run an independent CA requires direct help desk intervention rather than automated portal controls. LACNIC members face a similar procedural hurdle; while the registry supports delegation, configuration remains impossible within the member portal until new procedures are finalized. Users must initiate contact via the hostmaster email channel to begin the process.

• ARIN: Requires help desk ticket; no online switch available.
• APNIC: Manual ticket mandatory for mode conversion.
• LACNIC: Email initiation required while portal features develop.
• RIPE NCC: Instant self-service transition available via portal.

Measurable latency defines this trade-off; RIPE NCC affiliates execute transitions instantly while others endure indefinite waiting periods dependent on support queue depth. Operational friction delays adoption of independent signing authorities, leaving networks exposed to limitations of centralized repository availability. Automating this switch represents a significant bottleneck for large-scale IP management strategies relying on rapid reconfiguration.

high-availability Dependencies in RIR Hosted Publication Services

RIRs highly recommend hosted services because they relieve operators of the burden to run a highly available repository, yet this convenience creates a strategic dependency trap. ARIN and APNIC promote these managed solutions to guarantee uptime, yet their portals currently lack native functionality for users to switch back to delegated modes independently. This architectural constraint forces networks seeking autonomy to bypass standard self-service workflows entirely. Operators must open the help desk tickets to request mode changes, introducing manual latency into critical infrastructure updates.

• ARIN: No online option exists to switch from hosted to delegated; ticket required.
• APNIC: Interface lacks revocation tools for hosted CAs; manual intervention necessary.
• LACNIC: Delegated configuration is unavailable in the member portal; email initiation needed.
• RIPE NCC: Full self-service control over hosted and delegated states.

Human-mediated transitions contradict automation goals of modern route origin validation. RIPE NCC participants self-serve via a "Revoke hosted CA" link, whereas users in other regions face indefinite wait times dependent on support queue depth. This disparity means that during a security incident requiring immediate key rollover, some networks remain locked behind administrative bottlenecks. InterLIR advises clients to evaluate these migration barriers before committing to hosted publication models. Avoiding repository maintenance carries the cost of potential loss of control over your certificate authority lifecycle. Strategic planning must account for these procedural frictions to ensure uninterrupted IP resource management.

References

• What Is a Regional Internet Registry? A Comprehensive Guide