There have been some important developments towards improving routing security over the past few weeks, with announcements at NLNOG and AusNOG, as well as from Cloudflare about commitments to validate IP prefixes and reduce route leaks and hijacks. This supports the work we’ve being doing with the MANRS initiative to raise awareness of this issue, and to persuade network operators to take collaborative responsibility for this critical aspect of the Internet.
Cloudflare to deploy RPKI
Cloudflare has been a long-time advocate of routing security, and during their recent Crypto Week, they announced that they’ll be deploying RPKI on their networks. Resource Public Key Infrastructure (RPKI) allows IP address prefixes and AS numbers to be cryptographically verified (using Route Origin Authorization), and therefore provides some assertion that the holders of these have the right to announce them. The use of RPKI is included as one of the four MANRS actions “Global Validation – facilitating validation of routing information on global scale” which includes the creation of ROAs and the maintenance of accurate data in Internet Routing Registries (IRRs).
Cloudflare also announced GoRTR, which is an open-source implementation of the RPKI to Router (RTR) protocol (see RFC 6810). This is written in the Go Programming language, and is able to retrieve and validate RPKI (see RFC 6480) prefix origin data from a trusted cache. All major router vendors such as Cisco, Juniper, Huawei, Arista, Quagga, FRR are able to support RTR.
Lists of valid routes are now being securely distributed (via HTTPS) via Cloudflare’s Content Delivery Network (CDN) using a lightweight local RTR server. This free service is being offered in order to encourage adoption of route origin validation on the Internet.
NLnet Labs announce Routinator
This follows on from the announcement of Routinator from NLnet Labs back in July. This is an open source RPKI toolset that offers a Certificate Authority (CA) package to allow network operators to run RPKI on their own systems instead of using the hosted platforms offered by the five Regional Internet Registries; a Publication Server, to let network operators publish the certificates and ROAs generated by the CA; and finally Relying Party software that allows network operators to download the global RPKI dataset, validate it and use it their BGP decision making process.
NTT IRRdb to provide ROA validation
Job Snijders (NTT) also announced during the recent NLNOG 2018 event, that the NTT IRR database will now provide ROA validation status as well. NTT operates one of the major Internet Routing Registries, but until recently virtually anyone could create any route/route6 object and sneak those into the prefix-filters. But perhaps one of the most important points of his presentation was that he believed only about 20 major network operators needed to start doing Route Origin Validation in order to greatly improve routing security and achieve big benefits.
AusNOG & Hurricane Electric
AusNOG 2018 was held on 30-31 August 2018 in Sydney, Australia. This is one of the most important and influential national Network Operator Groups, and this year I did a lightning talk on possible route hijacks, possible route leaks and bogon announcements, based on data from bgpstream.com.
One incident of a possible route hijack occurred in Australia where a network operator started advertising a handful of prefixes that they didn’t own. Unfortunately, one of their peers Hurricane Electric accepted those advertisements and it ended up reaching the global routing table.
However, Walt Wollny (Hurricane Electric) was up next, and was able to announce they had already started to implement strict filtering with its direct peers . They also have a website showing the AS numbers of all their direct peers, what prefixes they were receiving, and what policy was being being implemented, along with a documented algorithm for prefix filtering.
Cloudflare and MANRS
Last but not least, Martin Levy (Cloudflare) mentioned the MANRS initiative in his blog and re-iterated Cloudflare’s willingness to collaborate, although expressing the view that MANRS does not go far enough or have sufficient ability to weed out bad actors. Whilst not disagreeing with this statement, I would point out that MANRS is primarily intended to be an awareness raising initiative to persuasively bring about behavioural change amongst network operators, of whom many are simply unaware that routing security is a substantial issue. As the MANRS community grows, not only will awareness increase, but it will become easier for the good actors to identify and take actions against those operators where prefix hijacks, route leaks and bosons are prevalent.
Get Involved
It’s great to see so many good things starting to happen around routing security, and more network providers getting involved in implementing the solutions. If you are running a network infrastructure then be part of the solution and help protect the core. Join MANRS.
Further Information
- MANRS: Mutually Assured Norms for Routing Security
- GoRTR – A RTR library for writing RTR clients
- Routinator – RPKI software suite
- NTTCOM IRRdb – Internet Routing Registry
- Hurricane Electric Route Filtering