Krill Gains Powerful ROA Management Based on BGP Routing

Create and maintain Route Origin Authorisations based on the BGP announcements with your address space.


4 min read

By Alex Band

We are incredibly excited that six months after the first release of Krill it already powers delegated RPKI for over 150 organisations. Now we are launching Krill 0.7.1 ‘Sobremesa’, the biggest update yet of our open source RPKI Certificate Authority software. This version lets you create and maintain Route Origin Authorisations (ROAs) based on your BGP announcements. This makes it incredibly easy to manage ROAs.

Krill already lets you to manage and publish ROAs seamlessly across multiple Regional Internet Registries. Now Krill will also tell you what the effect is of all ROAs that you created, indicating which announcements seen in BGP are authorised and which ones are not, along with the reason. This ensures your ROAs accurately reflect your intended routing at all times.

Manage ROAs based on what is seen in BGP with a few clicks

All status and validity information is clearly displayed in the user interface, giving you an immediate insight into which ROAs and BGP announcements require your attention. Announcements with an Invalid or NotFound state can be authorised with just a few clicks and will be published immediately.

In addition to providing an overview of all announcements that are seen in BGP, Krill will also inform you if there are any ROAs that don’t seem to affect any announcements at all. These are indicated as “Unseen”. This may be intentional, for example when pre-authorising your DDoS-protection service ASN, but it also lets you easily spot outdated ROAs that can be cleaned up.

A concise overview of all your ROAs and BGP announcements with your address space

All of this information is also exposed to the Prometheus endpoint, allowing you to set up a dashboard with Grafana and configure alerts.

A simple Grafana dashboard conveying the same information

Best Practices Applied Automatically

The ROA suggestions that Krill does are based on best operational practices, as described in RFC 7115. This RFC advises operators to be conservative in the use of the maximum prefix length (maxLength) in ROAs. For example, if a prefix will have only a few sub-prefixes announced, multiple ROAs for the specific announcements should be used as opposed to one ROA with a long maxLength. Krill will guide users towards applying these best practices.

Liberal usage of maxLength opens up the network to a “forged origin attack”. ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP.

In a forged origin attack, a malicious actor spoofs the AS number of another network. With a minimal ROA length, the attack does not work for sub-prefixes that are not covered by overly long maxLength. For example, if, instead of creating a single ROA 10.0.0.0/16–24, you issue 10.0.0.0/16–16 and 10.0.42.0/24–24, a forged origin attack cannot succeed against the announcement of 10.0.666.0/24.

BGP Data Sources

To display BGP information, Krill 0.7.1 relies on the route collector information from the RIPE NCC Routing Information Service (RIS), which is currently refreshed once every eight hours. In future releases we will extend Krill so that it can use near-real-time data, or even a local feed with your own BGP information instead. Still, for many users of the hosted RPKI systems offered by the Regional Internet Registries, Krill’s new user interface and guidance offer a huge leap forward.

Other features on the roadmap include the expansion of the monitoring and alerting features, for example allowing you to “mute” BGP announcements that are intentionally Invalid or NotFound. We will also let you tag ROAs to assign them a certain purpose or customer.

Other Goodies in this Release

For users of recent Debian and Ubuntu releases we now offer pre-built packages with our releases. Installation instructions are available in our documentation on Read the Docs.

All of the new functionality in Krill 0.7.1 is has been translated into the six languages that we now offer: English, Portugese, Spanish, French, Greek and Dutch. Our thanks go out to everyone in the community who contributed a translation!

If you would like see your preferred language in Krill and feel confident about describing Certificate Authorities, Trust Anchors and Relying Parties in your local language, do not hesitate to send a GitHub pull request on the Lagosta user interface project.

As always, please keep the feedback coming on the mailing list, GitHub and Twitter as we work our way towards Krill 1.0 and beyond! ❤️🦐


Please support us

Our thanks go out to the RIPE NCC Community Projects Fund, the Mozilla Open Source Support Fund and the Dutch National Cyber Security Centre for funding the development of our RPKI toolset throughout 2019. Now, with NIC.br and APNIC as our only remaining sponsors, we hope you join them in financially supporting our open source efforts.


IPv6 and Rust
Previous article

IPv6 and Rust

How difficult is it to use Rust and its ecosystem to write network applications that support IPv6?

Journeying into XDP: Part 0
Next article

Journeying into XDP: Part 0

Network programming using XDP has been on our radar for a while now. As tooling around this technology has vastly improved, we decided that it was time to finally get our hands dirty and see what this technology is all about.


Related Articles

Moving RPKI Beyond Routing Security
4 min read
Testing .. 123 Delegated RPKI
8 min read
Evolving Krill
5 min read
Leaping through RPKI history with Ziggy
14 min read

GO TOP