Every week, CEO Casey interviews an expert leading the charge on empowering security experts and practitioners with the knowledge and insights needed to excel in the future of cybersecurity.

He recently spoke with Donika Mirdita, Security Researcher at Fraunhofer Institute for Secure Information Technology. Here are the top takeaways from the interview.

#1: Build Isolated Test Environments for BGP Attack Research

“So the problem was setting up a large tree of publication points because you have to use customized software because public vacation points have very specific features. It's not just a simple repository. And there is open source tools to do that. Actually there's just one open source tool to do that, Krill, and you have to set it up, you have to make sure that it works with self signed certificates because it was an isolated environment, we didn't want to put anything on the Internet.

“We had to create major subtrees, I mean subtrees of 50 or 100 publication points for that. Then we had to install all the different relay part implementations that were available at the time and make sure that they were compatible with this isolated tree, which again, was not always something possible to do out of the box.

“We had to do some tweaking and in the end of course there was a router, but the router we installed, I think FRR routing software package to do all the comparisons of what the routers would receive at the end of these attacks. So installing the router itself was not the problem. It was just making sure that the entire infrastructure was working completely isolated from the actual trans anchors that it relies on.”

Actionable Takeaway: When testing potential BGP routing vulnerabilities, constructing an isolated test environment is essential but complex. The process requires setting up large publication point trees using Krill with self-signed certificates, implementing multiple relay party configurations, and deploying FRR routing software for validation. This isolation ensures safe testing while maintaining realistic behavior of RPKI infrastructure components.

#2: Deploy Your Own RPKI Publication Points for Enhanced Control

“There are a lot of entities that set up publication points. At the root are the five regional Internet registries, and they in general have their own in-house implementations. But you don't have to necessarily use the service of original Internet registry. You can also set up your own, a delegated publication point, and you just have to purchase resources from them. You have to create an account with them, to connect your publication point with them, but you can host your own. And if you're hosting your own, either you have to build something up from scratch from the RFC or you use this open source implementation, which is very good, to be frank. So there is no reason to invent the wheel with it.”

Actionable Takeaway: Instead of relying solely on regional Internet registries, organizations can establish delegated publication points for greater control over their routing security infrastructure. Although this requires purchasing resources and account setup with registries, using open-source tools like Krill eliminates the need to build from RFC specifications. This approach provides flexibility while maintaining compatibility with existing RPKI systems.

#3: Implement Historical Analysis to Prevent RPKI Processing Attacks

“One of the things that you could do to prevent it is to make sure that it is impossible, more or less, to stall the process for so long. Because the fact that you can stall it for so long is an issue in itself. So one way that you could do that is by — in a later paper we propose the option of creating a history of the different publication points that are on the Internet. So for every single iteration you have a history: how they behaved, how long does it take to process them? When new things come into the system and they are behaving anomalously, you can tag them as such. When you tag publication points or repositories that are benign and some who are behaving in suspicious ways, you can prioritize or deprioritize them. And that's a way to speed up the processing. For all the repositories that you know are behaving well and those who are taking a very long time to process, you can just deprioritize. And also you would have to decouple the process of generating the data that you send over to the routers, which means you don't have to wait until the entire process is done to generate the new data and send it over, but also be able to do that also piecewise. Because if there is such stalling in this way, you can make sure that new data is continuously fed to the router and it's not waiting for 8 hours or 10 hours until something expires and therefore becomes invalid.”

Actionable Takeaway: Protect against stalling attacks by building comprehensive monitoring of publication point behavior across iterations. Track processing times and tag anomalous patterns to enable dynamic prioritization of well-behaving repositories. By decoupling router data generation from complete processing cycles, organizations can maintain continuous updates without waiting for full iteration completion, preventing extended processing delays from compromising security.

Listen on Apple

Listen on Spotify

Watch on YouTube