Hosted RPKI risks: Stop manual crypto renewals today

The RIPE NCC hosts the Certificate Authority to sign Route Origin Authorizations via a web interface. This Hosted RPKI model strikes a specific balance: it trades programmatic flexibility for operational simplicity. Network operators secure BGP route origins without deploying local software, but they also surrender direct control over the signing lifecycle.

This workflow details creating a Hosted CA through the RIPE Dashboard using an LIR account. The system abstracts complex RFC 9582 objects into manageable configurations containing one Origin AS and prefix. It handles the signing and renewing automatically, preventing the expiration disasters that plague manual setups.

We will examine the Overview page sections, including Alert Configuration and Certified Resources. Note that Provider Independent holders must follow distinct access guides before managing their address space. This approach removes the burden of maintaining CA infrastructure while ensuring valid BGP announcements, provided you understand where the guardrails end.

The Role of Hosted RPKI in Securing BGP Route Origins

How Hosted RPKI Defines Route Origin Validation

A singular trust anchor per region anchors the Hosted RPKI Certification Authority architecture. Regional Internet Registries host resource certificates directly on their servers to establish legitimacy. The RIPE Network Coordination Center provides an intuitive web interface for authorizing legitimate BGP announcements. This workflow generates Route Origin Authorizations (ROAs) that define authorized route announcements for held prefixes. A ROA functions as a cryptographically signed statement linking an IP prefix to an Autonomous System Number. Relying Party software downloads these files to produce Validated ROA Payloads (VRPs) for router consumption. Network equipment evaluates each BGP announcement against known VRPs to determine validity. The resulting state becomes Valid, Invalid, or NotFound based on cryptographic coverage. The RIR assumes responsibility for upkeep and security within this Hosted model. Each of the Regional Internet Registries (RIRs) operates its own distinct repository and trust anchor. Global distribution of the Hosted RPKI infrastructure occurs across these specific regional entities rather than a single global server. Direct management of signing infrastructure remains with the registry.

Reducing BGP Hijacking Risks with Hosted RPKI

A Route Origin Authorization (ROA) serves as a cryptographically signed record specifying which Autonomous System may originate a specific IP prefix. Network operators use the intuitive web interface provided by the RIPE Network Coordination Center to generate these statements without managing server infrastructure. This process transforms raw address holdings into validated data that routers use to distinguish legitimate traffic from hijacked routes. Route Origin Validation (ROV) marks an announcement as Invalid when it lacks a matching ROA or originates from an unauthorized AS. Edge networks drop such traffic automatically. The primary output consists of cryptographically validatable statements binding an IP prefix to an ASN. Most origin-based hijacking attempts fail under this scrutiny. Operational simplicity comes at the cost of programmatic control compared to delegated architectures. Operators must manually update ROAs during infrastructure changes. Accidental outages occur if valid routes become Invalid due to outdated configurations. Properly configured ROAs keep only authorized paths reachable. Global routing table integrity depends on this precision.

Hosted vs Delegated CA: Operational Trade-offs

Ease-of-use, maintenance requirements, and flexibility define the Hosted RPKI model for network operators. The Delegated CA architecture demands full operator responsibility for server uptime and cryptographic key management. Regional Internet Registries own the infrastructure in the hosted configuration. Security patching execution falls to the registry. Technical overhead for the resource holder drops notably.

Operators choosing the delegated path gain maximum flexibility for custom automation. Deep expertise in cryptographic operations becomes mandatory. The hosted alternative restricts customization to features available within the member portal. Internal CA maintenance disappears from the operator workload. High ease-of-use via web portals characterizes the hosted model. Delegated models require deep expertise in cryptographic key management and server maintenance. Advanced integration scenarios requiring independent signing schedules remain unavailable in the hosted environment. Network planners weigh internal control value against RIR-managed service reliability. Selection of an implementation strategy hinges on these specific constraints.

Architecture of the Hosted Certification Authority and ROA Objects

RFC 9582 ROA Object vs Configuration State

Dashboard inputs differ fundamentally from the final cryptographically signed objects published to the global RPKI. Operators manage ROA configurations as discrete entries containing one Origin AS, one prefix, and an optional maximum length. This abstraction simplifies management but represents only a request rather than an enforceable policy. The Hosted CA system aggregates these individual configurations, signing and publishing them as composite RFC 9582 ROA objects that may contain multiple prefixes for a single autonomous system. These ROAs describe the BGP announcements done with the user's address space.

Infrastructure automates the translation of local settings into global trust anchors, ensuring continuous validity without operator intervention. Configuration remains mutable and local, whereas the hosted system handles signing, publishing, and renewing ROA objects based on this information. ROA objects can expire, yet the system renews them well ahead of time based on the configurations. Errors in the configuration stage propagate directly into the authoritative RPKI data used by relying parties worldwide. Separation ensures usability while maintaining the integrity of the global routing table.

Setting Max Length for Specific Prefix Announcements

Operators set the optional max length field to authorize more specific prefixes without over-authorizing the entire address space. By default, the Hosted CA sets this value equal to the prefix length, restricting the Origin AS to exact matches only. Expanding this limit permits valid announcements of subnets, a configuration often required when delegating traffic to anti-DDoS providers or managing complex BGP topologies. The portal enables network operators to define these parameters while using hosted infrastructure to maintain server uptime.

Usage of the Maximum Length field as a method to prevent hijacking through the announcement of a more specific prefix is discouraged. When the field is not set, the AS is only authorised to advertise exactly the prefix specified. Any more specific announcement of the prefix will be considered unauthorised. This constraint requires precise alignment between ROA configurations and actual routing policy.

1. Navigate to the ROAs tab within the dashboard to manually edit existing entries.
2. Input the desired Maximum Length value greater than the prefix length.
3. Ensure the Origin AS matches the intended source for the prefix.

Using this field exclusively for known, active subnet requirements rather than future-proofing unused space is recommended. The global validation list ensures third parties can immediately verify these signed statements, making accuracy critical for global reachability.

Validating Resource Certificate Updates and History

The Overview page reflects the current state of resources, confirming the resource certificate status. The resource certificate is automatically updated when resources change, for example, if new resources are allocated or if resources are transferred into the organization. Infrastructure relies on a singular trust anchor where the RIR operates the CA, ensuring the public verification list remains current for any third-party checking signed prefixes.

Operators must distinguish between the local configuration state and the published ROA object to verify integrity effectively.

1. Confirm the History log displays the most recent events.
2. Verify that the BGP Announcements section shows the prefix covered by an active authorization.
3. Ensure the Hosted CA has renewed the underlying object well ahead of its expiration window.

Delegated models require manual key rollovers, while this hosted approach centralizes risk but demands trust in the provider's update latency. Monitoring the history log serves as the primary source of truth for audit compliance rather than relying solely on router feedback. The limitation is clear: while the system automates signing, the operator retains ultimate responsibility for verifying that the published state matches the intended policy.

Implementing Route Origin Authorization via the RIPE Dashboard

Defining Hosted and Delegated CA Roles in RIPE RPKI

Operators initiate ROA creation by selecting a trust anchor model within the RIPE NCC portal. The Hosted CA option keeps certificate management on RIPE infrastructure, removing the burden of server maintenance for LIRs. A Delegated CA requires the network owner to operate their own signing infrastructure using external software tools. If a user chooses to run a Delegated CA, they must consult the documentation of their CA software to ensure proper configuration and uptime. This architectural choice determines who holds the private key for the trust anchor. The Hosted model offers a fair balance of ease-of-use and reduced maintenance requirements compared to other implementation models. The primary output involves generating cryptographically validatable statements that define authorized route announcements for held prefixes. In the Hosted model, the RIR operates the Certificate Authority and hosts the resource certificates, whereas Delegated RPKI requires the resource holder to procure and manage their own CA infrastructure. Delegating the trust anchor to the RIR means the RIR assumes full responsibility for the upkeep, security, and availability of the signing infrastructure. Network engineers should log in using a RIPE NCC Account associated with one or more RIPE NCC members or PI resource holdings before attempting to configure these settings in the dashboard.

Configuring Daily and Weekly ROV Alert Notifications

Enable ROV alerting on the Overview page to receive scheduled digests regarding invalid or not found BGP announcements. Operators access the Alert Configuration section to define notification parameters for their address space. The system supports dispatching these reports on either a daily or weekly cadence to one or more assigned email addresses. This mechanism ensures network teams review validation failures without needing constant dashboard monitoring.

1. Navigate to the Alert Configuration panel within the active Hosted CA interface.
2. Input target email addresses and select the preferred frequency for digest delivery.
3. Choose to receive warnings specifically for invalid states or include not found conditions.
4. Review the Current Alerts tab to identify active incidents requiring immediate attention.
5. Select specific announcements to mute noise or re-enable notifications as operational needs shift.

Configuring these alerts allows operators to monitor the status of their ROA configurations effectively. A critical limitation of this approach is that alerts only trigger for prefixes covered by existing ROA configurations; unregistered space remains invisible to this specific monitoring loop. Silence does not equate to security if the underlying authorization data is absent. Network operators must distinguish between a quiet alert inbox and a fully protected origin. While periodic emails provide a manageable workflow for maintaining RPKI hygiene, they represent a scheduled summary rather than real-time streaming telemetry. However, for many mid-sized networks, this scheduled summary provides a manageable workflow for maintaining RPKI hygiene. The RIPE NCC infrastructure generates these alerts based on global validation data, removing the need for local collector maintenance. Operators can integrate these email digests into existing workflows to track resolution.

Pre-Flight Checklist for RIPE NCC Account and Resource Access

Validate RIPE NCC Access credentials against held resources before attempting ROA creation.

1. Confirm the account links to a LIR, or follow the specific guide if holding Provider Independent or Legacy blocks without membership.
2. Locate the drop-down menu on the top right to switch contexts if the profile manages multiple organizations.
3. Select the correct entity to ensure cryptographically validatable statements apply to the intended address space.

Operators should note that if a RIPE NCC Access account is associated with more than one member or PI holding organisation, they can switch between them using the drop-down menu. The Hosted CA interface displays resources based on the currently selected organization context. This separation prevents accidental misattribution of route origins across different corporate entities. Proper context selection is necessary for ensuring that ROA configurations apply to the correct address space.

Operational Impact of ROV States on BGP Announcement Validity

ROV States: Valid, Invalid, and NotFound Explained

Router software assigns a Valid state only when a Route Origin Authorization (ROA) cryptographically authorizes the announcing Autonomous System (AS) for that specific prefix. The Hosted CA infrastructure ensures these signed objects remain current without manual renewal interventions by operators. An Invalid status indicates the announcement is covered by a known VRP but conflicts with the authorized origin or exceeds the permitted maximum length. This specific failure mode requires immediate correction of the ROA configuration to restore legitimate traffic flow. A NotFound result occurs when no covering VRP exists in the local validator cache, leaving the route subject to local policy rather than cryptographic rejection.

Relying parties fetch data from RIR repositories to perform these checks against every incoming BGP update. The absence of a ROA does not imply illegitimacy, yet it leaves the prefix vulnerable to hijacking attempts that a Valid signature would prevent. Operators observe distinct behaviors for each state across the network edge.

1. Valid routes pass filtering policies automatically.
2. Invalid routes face high probability of discard by strict peers.
3. NotFound routes rely entirely on legacy ranking mechanisms.
4. Invalid signals often trigger alerts in monitoring systems.
5. NotFound states offer no cryptographic assurance of origin.

Diagnosing Invalid Routes via ROA Mismatch

An Invalid route status arises when a BGP announcement matches a known prefix but fails authorization checks against the signed ROA data. This failure typically occurs because the announced Autonomous System number differs from the origin authorized in the cryptographically validatable statements managed by the registry. Operators must verify that the Origin AS in their configuration exactly matches the advertising router, as even a single digit discrepancy triggers rejection. Unlike NotFound states where traffic may still pass depending on local policy, Invalid routes are frequently dropped by downstream networks implementing strict filtering.

The primary resolution path involves accessing the Hosted CA dashboard to inspect active configurations. Users should select the specific prefix causing the alert and modify the ROA configuration to include the correct originating AS. It is critical to distinguish between the signed object parameters and the abstraction layer; the system manages renewal automatically, but the operator defines the allowed origin. Misconfigurations often stem from assuming the maximum length field permits any sub-prefix announcement without explicit authorization for that specific range. Correcting the entry propagates quickly to global validators, restoring the Valid state required for uninterrupted traffic delivery. Precise alignment of ASN and prefix length prevents recurrence of the drop.

Operational Risks of Revoking Hosted Certification Authorities

Revoking a Hosted CA triggers immediate deletion of the authority and all associated ROA configurations, causing covered prefixes to lose validation status. This destructive action prevents make-before-break migrations because operators cannot activate a new certificate before removing the existing one. The system architecture currently mandates revoking the current CA prior to reactivation, creating a unavoidable window where no valid signatures exist for the address space. During this gap, downstream networks performing Route Origin Validation will mark announcements as Invalid or NotFound, potentially dropping traffic entirely.

Unlike delegated models offering flexibility in key management, the hosted approach ties configuration history strictly to the specific CA instance. Once revoked, the complete audit trail and BGP authorization history disappear permanently from the dashboard. Network operators must recognize that resolving an Invalid route by revoking the CA often creates a wider outage than the original misconfiguration. InterLIR advises exhausting all manual ROA correction options within the existing authority before considering revocation. The total loss of configuration data complicates forensic analysis and restores no immediate benefit to prefix availability. Careful planning avoids unnecessary service interruption during key rotation events.

References

• Inter-RIR Transfers — RIPE Network Coordination Centre: ... For
• Fee Schedule - American Registry for Internet Numbers: The
• Vote for progressive fees at May 2026 RIPE General