FreeTransit
Learning Centre navigation

Learn before you apply

FreeTransit Learning Centre

How RPKI authorises route origins, what ROA maxLength allows and how networks validate the routes they receive.

RPKI, ROAs and route origin validation

With the Resource Public Key Infrastructure (RPKI), the holder of an IP prefix publishes a signed statement saying which ASN may originate it. That statement is a Route Origin Authorisation, or ROA.

Origin validation catches routes announced from the wrong ASN, by accident or on purpose. It says nothing about the rest of the AS path, and you still need normal import and export filters.

Two sides of RPKI

As a resource holder: publish ROAs

For each prefix you announce, publish a ROA with:

  • the ASN allowed to originate it
  • the prefix
  • a maxLength that allows only the prefix lengths you actually announce

As a network operator: validate what you receive

A validator (relying-party software) downloads and checks the RPKI data. Your routers get the result over the RPKI-to-Router (RTR) protocol and mark every BGP route with one of three states:

  • Valid: a ROA covers the prefix and allows this origin ASN and prefix length.
  • Invalid: a ROA covers the prefix, but the origin ASN or the prefix length doesn't match.
  • Not Found: no ROA covers the prefix.

Most networks reject Invalid routes once they have watched the results for a while. Not Found is not Invalid and is normally accepted.

FreeTransit rejects RPKI-invalid routes on every session, including the ones you send us. A wrong ROA for your own prefix means we drop it. Routes we pass on to you carry a large community with their RPKI state (see the features page).

Understand maxLength

maxLength lets you announce more-specifics. Leave it equal to the prefix length unless you really announce them.

Examples:

  • 2001:db8:1000::/48, origin AS64512, maxLength 48: allows only that /48.
  • 2001:db8:2000::/44, origin AS64512, maxLength 48: allows the /44 and every more-specific from /45 to /48.
  • If you announce only the /44, maxLength 48 grants more than you need. Anyone who can forge your origin can then announce a valid /48 out of your space.
  • If you do announce some /48s, the ROA has to allow them, or you publish separate ROAs for exactly those /48s.

Use the tightest ROAs that fit your real routing plan. Don't pick /24 for IPv4 or /48 for IPv6 out of habit.

Official resources

Open-source RPKI software

Routinator

Routinator is an open-source validator from NLnet Labs. It checks RPKI data and serves the result to your routers. See the manual page and the interactive mode, which is handy for checking a single prefix.

Krill

Krill is an open-source RPKI Certificate Authority and publication server. Most applicants are better off with their RIR's hosted CA; Krill is useful for learning delegated RPKI.

Rolling out validation

  1. List every prefix and origin ASN you operate.
  2. Compare what you intend to announce with what is visible in BGP today.
  3. Create narrow ROAs that match the plan.
  4. Check the published result with a tool you don't control, such as RIPEstat.
  5. Watch for Invalid announcements before you change any router policy.
  6. Run at least two independent validators in production.
  7. Connect routers to them following your vendor's guidance on failures and caching.
  8. Watch validation states without rejecting anything.
  9. Fix legitimate routes that show up as Invalid.
  10. Turn on rejection of Invalid routes as a planned change.
  11. Monitor validator freshness, RTR sessions and the number of rejected routes.
  12. Revisit your ROAs whenever prefixes, origins or traffic-engineering announcements change.

Monitoring

  • RIPEstat shows routing and RPKI data for an ASN or prefix.
  • BGPlay replays routing changes over time.
  • RIPE RIS Live streams BGP messages in real time.
  • BGPalerter alerts on lost visibility, unexpected origins and RPKI problems.
  • NLNOG Looking Glass shows your routes from many outside networks.

Talks

The older talks show older software. Take commands from the current RIPE NCC and NLnet Labs documentation.