# RPKI, ROAs and route filters for operators

Routing security has two halves that are easy to confuse. One is authorising who may originate your address space. The other is deciding what routes you accept from others. Both matter, and they are different jobs with different owners.

9 May 2026

[ISP & Network Operators](https://netavo.com/insights)

## Authorising your own origins

RPKI lets a network cryptographically state which Autonomous System is allowed to originate each of its prefixes, in a Route Origin Authorisation, a ROA. Publishing ROAs for your address space means other networks that validate can reject an accidental or malicious announcement of your prefixes by someone else. The common mistakes are in the detail: a maxLength set too loose invites more-specific hijacks, a ROA that does not match how you actually announce a prefix makes your own routes invalid, and a change made without an owner leaves a prefix unprotected after a renumber.

The rule of thumb is to create a ROA for each prefix exactly as you announce it, keep the maxLength tight, and treat any new prefix or upstream change as a ROA change with a named owner.

## Validating what you accept

The second half is what you do with routes you receive. Route Origin Validation lets you drop or deprioritise routes whose origin fails RPKI, and sensible prefix filters stop obvious nonsense, bogons, your own prefixes arriving from outside, and over-long prefixes, before they ever reach your tables. Authorising your origins protects others from a false announcement of your space; validating received routes protects you from everyone else's mistakes.

Netavo operates AS208802 and is a member of the RIPE NCC, from which address space and the RPKI trust anchor are managed, and peers at LINX with an open policy. Netavo publishes ROAs for its own address space.

## Common questions

### What does a ROA actually do?

It states which Autonomous System may originate a prefix. Networks that validate can then reject an announcement of that prefix from any other origin, reducing the impact of a route hijack or a fat-finger error.

### Why would my own routes become invalid?

Usually a ROA that does not match how you announce the prefix, for example a maxLength or origin AS that is wrong after a change. Create ROAs to match your real announcements and update them when you renumber.

### Is publishing ROAs enough?

It protects others from false announcements of your space. To protect yourself you also validate the routes you receive and keep sensible prefix filters on every external session.

## Related services

### [ISP Network Services](https://netavo.com/services/isp)

IP transit, backhaul and L2TP broadband for internet service providers and network operators.

### [Connectivity & WAN](https://netavo.com/services/connectivity)

Fibre and Ethernet access, private WAN and resilient connectivity, from a single site to a national estate.

## Hardening your routing?

Tell us about your address space and upstreams, and an engineer will talk through origin authorisation and route validation.

[Work with us](https://netavo.com/work-with-us)

Source: https://netavo.com/insights/rpki-roas-route-filters