Deploy360 Mutually Agreed Norms for Routing Security (MANRS) Securing Border Gateway Protocol (BGP)

Routing Security boosted by major network operators

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

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

Deploy360 Domain Name System Security Extensions (DNSSEC)

NLnet Labs Releases Helpful DNSSEC Infrastructure Audit Framework

NLNet Labs DNSSEC Infrastructure Audit FrameworkHow secure is your DNSSEC infrastructure? If you operate a registry for a top-level domain (TLD) or if you are a DNS operator providing DNSSEC signing services, how secure are your operations?  And how secure are your mechanisms for communicating DNSSEC information with registrars and other entities?  Or, if you are a security auditor or researcher, how can you best assess the security of your client’s DNSSEC infrastructure?

To help assess DNSSEC infrastructure and answer questions like these, the great folks at NLnet Labs recently released a “DNSSEC Infrastructure Audit Framework” available publicly for anyone to use.  You can download the document and use it as a checklist to audit your own infrastructure or that of someone else.

As noted in the introduction, this document is not intended to be any kind of formal standard or assessment, but rather a guide and checklist to help people looking to understand how secure their DNSSEC infrastructure is:

A DNSSEC audit is the process of structural examination of a DNSSEC infrastructure. The purpose of this process is to evaluate the level of assurance of the system. This is achieved by reviewing the implementation and operation of the system controls and whether they are in compliance with the corresponding policy requirements or, in absence of formal policies, with best current industry practices.

A key document for performing an audit is a review checklist. The review checklist provides structure of the actual work and gives confidence that the audit scope is adequately covered. This document is a generic checklist for a DNSSEC review and provides a framework that assists auditors to perform an actual DNSSEC audit. However, the actions herein do not conform any formal audit standards and are merely intended to provide directions of how an audit might look like.

This document is neither standard nor best practice and is not suitable for any form of formal certification. Its intention is to offer a basis for a structured review of a DNSSEC environment.

The authors welcome feedback on this document so that it can mature. The licensing terms of the document are such that any entity may modify and publish the document on their own terms as long as NLnet Labs is being acknowledged. Incorporation in other documents, including standards is encouraged.

This is great contribution to the larger work of DNSSEC deployment and we thank Matthijs Mekking and Olaf Kolkman for both writing this document and then also making it public under a lenient license.

We hope many of you will find it helpful and do encourage you to provide feedback to Matthijs and Olaf. Using documents like this we can make the Internet more secure!