RPKI Route-Origin Assurance Director

The mandate

The distributor found overlapping and stale route-origin authorisations while preparing to enforce validation across market-data edges. Providers treat invalid and unknown routes differently, several customer prefixes are originated through emergency arrangements, and a recent fail-open change produced inconsistent reachability among trading centres. The defined problem is to determine a deployable validation policy that improves origin assurance without creating ungoverned market fragmentation.

The named deliverable is an RPKI Route-Origin Assurance Opinion and Enforcement Runbook. It must include prefix and origin inventory, authorisation lifecycle, relying-party design, validation and exception policy, provider and customer dependencies, staged enforcement, external monitoring, failure and rollback tests, incident evidence, governance, and a reasoned decision for each market edge.

Three milestones cover ten weeks: by week two, accept the route and authorisation baseline; by week six, complete controlled tests for invalid, unknown, stale, unavailable and conflicting states across providers; and by week ten, submit the signed opinion, enforcement sequence, exception register and customer communication triggers. Each milestone invoice follows acceptance of its evidence.

The network officer and market resilience board will accept the work only when every advertised prefix has accountable authorisation ownership, test outcomes reproduce from archived route and validation data, relying-party failure has bounded behaviour, exceptions expire, customer reachability is measured externally, and operations can execute enforcement and rollback without consultant intervention during a timed exercise.

The client will provide prefix and ASN inventories, route histories, ROA records, relying-party configurations, provider policies, customer exceptions, network laboratories, external measurement access and cleared engineers. The consultant will not operate production routing, issue or revoke live ROAs, renegotiate connectivity, perform penetration testing or guarantee global propagation; third-party policy uncertainty remains recorded in the opinion.

Why this is external work

Internal route engineers own the current exceptions and face direct service pressure from customers whose authorisation hygiene varies. Providers can explain their individual policy but cannot independently judge cross-network market impact. A neutral routing-security specialist is needed to test failure and enforcement behaviour before assurance controls themselves become the cause of a trading-centre outage.

What you will own

• Reconcile advertised prefixes, origins, more-specifics, customer arrangements, ROA states, provider policy and named lifecycle ownership.
• Define treatment of valid, invalid, not-found, stale, conflicting and unverifiable states by market, service and emergency condition.
• Test relying-party refresh, cache corruption, repository loss, clock error, policy inconsistency and validation-state transition.
• Measure reachability and path change from external trading locations during staged filtering, exception and rollback scenarios.
• Specify controlled creation, review, expiry and revocation for route-origin exceptions and emergency origin changes.
• Align incident triggers across network control, customer assurance, compliance and providers using preserved route and validation evidence.
• Deliver the opinion, runbook, enforcement waves, measurement design and residual-risk statement at final acceptance.

Candidate qualifications

• Designed or assured RPKI route-origin validation in large carrier, exchange, cloud or financial connectivity networks.
• Managed ROA and prefix lifecycle across emergency origins, more-specifics, customer announcements and multiple providers.
• Tested relying-party and repository failure rather than assuming validation state remains continuously available and current.
• Measured external reachability consequences of staged filtering across networks that apply different invalid and unknown policies.
• Handled a routing-security incident where assurance, availability and customer obligation pulled toward different decisions.
• Produced an independent enforcement opinion and operational runbook accepted by network, risk and customer stakeholders.

Non-negotiables

• Can complete both Tokyo laboratories and all three customer-reachability reviews inside ten weeks.
• Will remain independent of transit, RPKI software, measurement and managed-network providers during the engagement.
• Brings production route-origin validation evidence; security policy or general BGP operations alone are insufficient.
• Accepts client-executed enforcement and rollback as conditions for final acceptance.

1. 49 words maximum. Describe an invalid route that could not simply be dropped because the authorisation failure was operationally legitimate.
2. 49 words maximum. Which relying-party fault would you inject before enforcing validation at a market-data edge?
3. 49 words maximum. How would you measure customer reachability when upstream networks apply different policies to unknown routes?