Border Gateway Protocol routes can change in seconds, while a mistaken or malicious origin announcement can send traffic toward the wrong network. Resource Public Key Infrastructure (RPKI) helps operators verify whether an autonomous system is authorized to originate a prefix. A scheduled web cron job can turn that verification into a dependable control without requiring another always-on monitoring service.
What RPKI route origin validation checks
A Route Origin Authorization (ROA) binds an IP prefix to an authorized origin ASN and a maximum prefix length. Route Origin Validation compares a BGP announcement with current validated ROA data and classifies it as valid, invalid, or not found. Valid means the origin and prefix length are authorized. Invalid means a ROA exists but the announcement conflicts with it. Not found means no covering ROA is available.
These states are not interchangeable. An invalid announcement is a high-priority routing-security signal. Not found indicates missing protection, not necessarily an active incident. Your monitor should preserve the exact classification and supporting evidence rather than collapsing every non-valid result into a generic failure.
Build a focused monitoring endpoint
Create an authenticated endpoint such as /internal/checks/rpki. The web cron scheduler calls this endpoint, and the application queries one or more trusted RPKI validation sources. Keep the endpoint read-only and restrict its input to an approved inventory of prefixes and expected origin ASNs.
GET /internal/checks/rpki?asset=edge-eu
Authorization: Bearer Return a compact JSON response containing the prefix, observed origin, expected origin, validity state, matching VRPs, source timestamp, serial or dataset version, query latency, and monitor run ID. Never echo reusable credentials or internal routing configuration.
Maintain an explicit route inventory
Store each monitored prefix with its expected origin ASN, allowed more-specifics, service owner, region, and escalation contact. Include provider-announced space only when you have a clear contractual expectation for its origin. An undocumented baseline creates noisy alerts and can hide a real route leak.
| Field | Purpose |
|---|---|
| Prefix | The exact IPv4 or IPv6 network under observation |
| Expected origin | The ASN permitted by deployment policy |
| Maximum length | The longest authorized more-specific route |
| Owner | The team responsible for remediation |
| Change window | Approved period for routing transitions |
Validate through independent sources
Query at least two sources when practical: a local validator or routing platform and an external validation API. Independent results help distinguish a genuine RPKI state change from stale caches or a single service outage. Compare dataset timestamps and reject responses that are older than your freshness threshold.
Use strict network timeouts, bounded response sizes, and schema validation. The patterns in scheduled API health checks and API schema drift monitoring apply directly to validation services.
Compare observed announcements with policy
RPKI validity alone does not prove that a route is expected. A valid announcement may still come from an authorized but unintended origin during a configuration error. Compare the observed BGP origin and prefix length against both validated ROAs and your internal inventory.
- Alert critically when an observed production route becomes RPKI invalid.
- Warn when a protected prefix changes from valid to not found.
- Warn when the origin changes, even if both origins are currently authorized.
- Record new more-specifics and verify that their prefix lengths are allowed.
- Track disappeared announcements separately from validation state.
Schedule checks for useful detection time
Run critical prefixes every five to fifteen minutes and lower-risk inventory every thirty minutes. Add jitter so many assets do not query the same validator simultaneously. Each run should be idempotent and protected against overlap. For resilient execution, follow the backoff and idempotency guidance and the file-locking pattern.
Retry only transient transport failures. Do not automatically retry an invalid result until it disappears from the incident stream; repeated queries cannot repair a bad ROA or route announcement.
Design alerts around transitions
Notify on a state transition, not on every poll. Use prefix, origin ASN, and validation state as the deduplication key. A critical alert should include the current announcement, expected origin, covering VRPs, validator timestamps, first-seen time, and links to the owner runbook.
| Condition | Severity | Response |
|---|---|---|
| Valid to invalid | Critical | Page network operations and verify route/ROA changes |
| Origin changed | High | Confirm provider and deployment intent |
| Valid to not found | Medium | Check ROA expiry, publication, and repository health |
| Validator data stale | Medium | Fail over to another source and investigate freshness |
| Single API unavailable | Low until sustained | Retry with backoff and preserve last verified state |
Handle planned routing changes
During migrations, register the new origin and ROA before advertising the route. Add a time-bounded maintenance record to the monitor, but do not suppress evidence. The system should label an expected transition while still recording every state and source response. Remove temporary authorization promptly after the change.
Store evidence for audits
Persist the normalized result, raw response digest, matching VRPs, observed origin, timestamps, and inventory version. Retention makes it possible to reconstruct whether the alert came from routing policy, ROA publication, or stale validation data. Accurate clocks matter, so pair this workflow with server clock-drift monitoring.
Secure and test the endpoint
Protect the check with a dedicated short-lived credential, allowlisted assets, request-rate limits, and safe outbound destinations. Apply the controls described in securing web cron endpoints. Unit-test valid, invalid ASN, invalid prefix length, not found, stale dataset, malformed response, and conflicting-source cases.
In staging, simulate route inventory changes without touching production BGP. Verify that alerts fire once, remain deduplicated, and resolve only after two or more fresh sources agree on recovery.
Implementation checklist
- Inventory every critical IPv4 and IPv6 prefix and expected origin.
- Query fresh validated data from independent sources.
- Preserve valid, invalid, and not-found as distinct states.
- Compare observed routing with both ROAs and internal policy.
- Alert on transitions with complete evidence and ownership.
- Use short timeouts, jitter, bounded retries, and overlap protection.
- Test planned changes, stale data, conflicts, and recovery paths.
RPKI monitoring does not replace routing observability, but it adds a precise authorization signal. A small scheduled job can catch invalid origin announcements quickly, expose gaps in ROA coverage, and give responders the evidence needed to protect traffic before an incident spreads.