As I’m writing this, I’m flying somewhere over Germany, on my way to the ENOG 3 conference in Odessa, Ukraine to give the local ISP community an update on where we are with the Resource Certification (RPKI) service.
As the RIPE NCC Product Manager, I’ve been responsible for this project for about two and a half years now, taking it from a prototype to a full production service that launched on 1 January 2011. It has been a bumpy ride for sure, just like this flight. Introducing a brand new system that can be used to help secure something as fundamental to the Internet as BGP was never going to be easy. There is a lot of listening and a lot of explaining involved, and a flame-repellent suit has become part of my standard hand luggage.
As real-world implementors of a set of IETF standards, we’re tackling technical concerns, political concerns, security concerns and many others to find the perfect balance between the routing freedom network operators know and love, and offering security that actually makes a tangible difference. Mind you, I use the word ‘security’ loosely; if we can solve accidental mis-origination of prefixes by Autonomous Systems (ASNs), just fat-fingering really, then I’m happy enough. Once we’ve covered origin validation and built the foundation, then we’ll see if we can move on to fancier things like path validation.
I believe we’re on the right track. We’ve had a successful launch. Given my experience with IPv6 and DNSSEC, my expectation was that only a handful of early adopters would request a resource certificate, and just a fraction would have used it to make a cryptographically validatable statement about their BGP routing. But here we are, 18 months later, with nearly 1,000 resource certificates requested by our members and more than twelve percent of the RIPE NCC address space covered by a so called Route Origin Authorisation (ROA). Not bad for a Regional Internet Registry with about 8,000 members.
Now that we’re making some headway with the interest that people have in the system, there still is a long way to go. Having a system with active users and a dataset is one thing, but it’s quite another to have accurate and well-maintained data. We’re giving network operators sharp tools to play with and they have proven to be quite adept at cutting their fingers. It was just a couple of months ago that half of the BGP announcements covered by a ROA were marked as invalid; BGP hijacks, in other words. Not good. Nobody in their right mind would base a routing decision on such a dataset.
Enter RPKI, phase two: education, education, education. One of the fundamental differences with an RPKI ROA and a “route” object that people are used to with the Internet Routing Registry system is the fact that you can specify a Maximum Length. This determines the smallest prefix that the authorised ASN may originate. If you do not specify the Maximum Length, the ASN may only originate the entire aggregate and any more specific announcement will be marked as invalid. If you combine the pathological deaggregation that some operators do with poorly created ROAs, you have a recipe for disaster. Luckily, RPKI data quality has improved by leaps and bounds thanks to the enthusiasm and tenacity (read: bullying) of RIR staff working with operators to fix ROAs and, in some cases, unintended BGP announcements.
This means we can start looking at the third phase: that operators actually use RPKI data to drive routing decisions. To do this, they need tools that integrate with existing workflows and methodologies. A couple of implementations are available and have matured quite a bit through the feedback received from the industry. A big differentiator is that the validation tools have the option to communicate with RPKI-capable routers. This will make workflows a lot easier, because Cisco, Juniper and Quagga are committed to offering this as a free update. A couple of platforms already have production support, and betas are available for others. After the validation toolset does cryptographic verification of the ROAs, the data can be fed directly into a supported router, allowing you to create route maps based on RPKI validity states. When will the first operator take that step? Time will tell. Maybe I should add a crystal ball to my kit. One that matches my flame suit…