Openfactory

Learn before you apply

FreeTransit Learning Centre

Learn how RPKI authorises route origins, how ROA maxLength works and how networks perform route origin validation.

RPKI, ROAs and route origin validation

The Resource Public Key Infrastructure allows a resource holder to publish a cryptographically verifiable statement about which ASN may originate an IP prefix. That statement is a Route Origin Authorisation, or ROA.

RPKI origin validation helps with accidental or malicious origin changes. It does not validate the full AS path and does not replace ordinary BGP import and export policy.

The two sides of RPKI

Resource holder: publish ROAs

For every prefix you intend to announce, publish a ROA with:

  • the authorised origin ASN;
  • the authorised prefix;
  • a maxLength that permits only the announcement lengths you actually intend to use.

Network operator: validate received routes

An RPKI validator downloads and verifies RPKI data. Routers receive validated prefix-origin data through the RPKI-to-Router protocol and classify BGP routes according to origin validity.

The familiar operational states are:

  • Valid: a matching ROA authorises the origin ASN and prefix length.
  • Invalid: a covering ROA exists, but the origin ASN or prefix length is not authorised.
  • Not Found: no covering ROA provides an authorisation decision.

A production policy commonly rejects Invalid routes after a monitored rollout. Not Found is not the same as Invalid.

Understand maxLength

maxLength is permission to announce more-specific routes. It is not a recommended default.

Examples:

  • A ROA for 2001:db8:1000::/48, origin AS64512, maxLength /48 permits only that /48.
  • A ROA for 2001:db8:2000::/44, origin AS64512, maxLength /48 permits the /44 and any more-specific from /45 through /48.
  • If you announce only the aggregate /44, setting maxLength /48 grants more authority than necessary.
  • If you intentionally announce selected /48 more-specifics, the ROA must permit them or separate exact ROAs must exist.

Use the most restrictive ROA design that matches your real routing plan. Do not mechanically select /24 for IPv4 or /48 for IPv6 without understanding what it authorises.

Official learning resources

The RIPE webinar collection includes introductions to RPKI, deploying RPKI, IRR and BGP filtering.

Open-source RPKI software

Routinator

Routinator is an open-source RPKI relying-party validator. It validates RPKI data and can make validated payloads available to routers.

Useful documentation:

Krill

Krill is an open-source RPKI Certificate Authority and publication server. Most FreeTransit applicants can use the RIPE NCC hosted CA, but Krill is useful for learning delegated RPKI and more advanced deployments.

Safe deployment sequence

  1. Inventory every prefix and origin ASN you operate.
  2. Compare intended announcements with current BGP visibility.
  3. Create narrowly scoped ROAs matching the intended routing plan.
  4. Verify the published state through an independent tool.
  5. Monitor for Invalid announcements before changing router policy.
  6. Deploy at least two independent validator instances for a production network where possible.
  7. Connect routers to validators according to the router vendor's failure and cache guidance.
  8. Observe validation state without rejecting routes first.
  9. Correct legitimate Invalids.
  10. Enable rejection of Invalid routes through a controlled change.
  11. Monitor validator freshness, router sessions and rejected-route counts.
  12. Review ROAs whenever prefixes, origins or traffic-engineering announcements change.

Monitoring and verification

  • RIPEstat — inspect ASN, prefix, routing and RPKI information.
  • BGPlay — visualise routing changes over time.
  • RIPE RIS Live — real-time BGP message stream for advanced monitoring.
  • BGPalerter — monitor visibility, unexpected origins and RPKI conditions.
  • NLNOG Looking Glass — inspect routes from external vantage points.

Talks and videos

Older deployment talks may show outdated commands or ecosystem maturity. Use current RIPE NCC and NLnet Labs documentation for production implementation.