BGP hijacks and route leaks are a well-publicized problem on the Internet. Many thousands of incidents happen every year — some accidental, others malicious. No matter what the provenance, each incident creates the potential for connectivity loss for the networks it affects.
In the IXP community, we interface with organizations of all shapes and sizes and we’ve noticed that accidental leaks happen just as often to large companies as smaller ones. The common factor across most of these incidents is pilot error: network devices are complicated, and will blindly do as they’re told, no matter whether it makes sense or not. A misplaced comma, a juxtaposed digit, or a command issued in the wrong sequence — these are things that all of us in the network operators community have done from time to time.
When INEX wrote IXP Manager several years ago, one of its first production applications was to automatically generate route server configuration with no operator input. In fact, we went one step further and coded it aggressively to ensure that every time our route server configurations were updated, any local changes would be lost. We identified automation not just as an advantage, but as a way of cutting out the weakest link in the configuration chain — ourselves.
Filtering at IXPs
Internet Exchange route servers are peering broker systems. They allow organizations to exchange traffic at IXPs with other organizations, even where there are no explicit BGP sessions enabled. At a well-run IXP, route server peering sessions will usually make up the overwhelming majority of interconnection sessions, as they provide an easy, low overhead method of multilateral connection. Filtering is critical though. An unconstrained routing leak at a route server could easily cause all the route server clients to redirect their traffic to the source of the leak, or blow out all the BGP sessions that had maximum prefix limits enabled. IXP operators have found out the hard way that proactive BGP filtering is critical to running a stable service.
Until recently, industry best practice was to implement strict ingress prefix filtering using prefix lists gleaned from an Internet Routing Registry database (IRRDB). The information in these databases is maintained by the organizations who run the networks, and in theory, this allows anyone with Internet addresses or an Autonomous System Number (ASN) to indicate how their prefixes should be routed on the Internet. In practice, though, implementation problems plagued the IRRDBs: stale information abounded; new IRRDBs popped up with claims to fix problems with the old IRRDBs, thereby doubling the problems; cultural and trust issues simmered, creating the conditions for poor uptake across large swathes of the globe. The result was a mishmash of different grades of data, ranging from production quality to toxic sludge. Filtering the junk out of these filters became an art in itself — the irony of it!
But even then, it didn’t scale. The gigantic lists of Internet address prefixes created vast configuration files, unparseable on anything except specialized BGP implementations. INEX — a mid-sized IXP in Ireland with about 100 peering members — was generating 50 megabyte BGP configuration files several times daily. The largest IXPs — those with the largest filtering problems — generated configuration files many times larger.
Fitting RPKI in
No one is going to claim that RPKI will fix all these problems today or tomorrow, but we know that it will provide the basis to fix many of them over time, and in an incremental way. The hundreds of thousands of lines of prefix lists can be replaced with a single configuration statement pointing to a local RPKI validator — or more than one if you value redundancy. Automation is part of the design — as soon as a ROA is changed at an RIR, it will appear in local RPKI caches sooner or later without any further operator intervention. There are still some dependencies on the IRRDBs, especially for validating peering ASN lists, but work is ongoing to replicate this functionality in RPKI.
We can’t turn our backs on IRRDB support yet, though. AS path filters are still generated from IRRDB as-sets and this isn’t going to change until we see either viable BGPsec deployment, or possibly some other simpler mechanisms like RPKI AS cones, currently under discussion at the IETF. This is disappointing because as-sets are inherently insecure, as they can be abused by malicious operators, albeit creating a public and easily verifiable audit trail in the process.
So, RPKI is a weapon in the arsenal, and an important one. New categories of routing leaks can now be stopped dead in their tracks. Global routing policy can now be changed with an expectation that it will have an effect — globally. Even malicious routing leaks can be hindered much more easily by using AS path filters instead of prefix lists. And on IXP route servers, it tightens up routing security by a considerable margin.
Watch: Barry O’Donovan presents
IXP Manager
Helped by a generous grant contributed by APNIC, we’ve been able to build support for this all into IXP Manager v5.0.0, which will allow IXP operators to deploy RPKI-capable route server configurations out of the box. Even better, the default IXP Manager route server configuration will ensure that your IXP is compliant with the hard bits of the MANRS IXP Programme, which works towards securing routing in the core of the Internet.
The operator-side configuration is designed to be simple and secure by default. There’s a single tick-box per route server in the IXP Manager administrative user interface, which allows RPKI to be enabled or disabled. If it’s enabled, then RPKI is automatically configured on all peering sessions to the route server, with no exceptions. This no-nonsense approach surprised some people at first, but an RPKI ROA is a cryptographically signed attestation by a legally validated resource holder about how they want their resources to be routed on the Internet.
Who is the IXP to argue with the resource holder? And why should the route server peering participants get to override what the resource holder says they want for their resources. After a round of shrugs, we admitted we couldn’t answer those questions, other than to say that if a resource holder is going to make a strong statement about how they wanted their resources to be handled, the responsible thing would be to honour their ROAs.
No changes are needed for IXP route server users. Things will work just like before, except it’ll be that little bit more secure.
IXP Manager v5.0.0 is available for download on github.
Nick Hilliard is the Chief Technical Officer at INEX, the Internet Exchange Point in Dublin, Ireland.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.