Categories
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 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

Categories
Deploy360 IPv6

Sky Broadband now IPv6 enabled for 90% of customers

skyThe good news in the IPv6 world continues with Sky Broadband announcing that over 90% of its customers are now IPv6 enabled. Sky Broadband is the second-largest UK Internet Service Provider with an estimated 6 million residential subscribers, and once its rollout on home CPEs (Consumer Premises Equipment) is completed at the end of 2016, IPv6 will be available to all customers with the exception of those using older non-compliant equipment.

IPv6 connectivity is being provided as dual stack alongside existing IPv4 connectivity, with link-local WAN addressing and each subscriber being provided with a /56 address prefix. The Sky software also supports a stateful IPv6 firewall.

In a related presentation at NLNOG last week, Richard Patterson of Sky Broadband discussed the lessons learned from rolling out IPv6.

The deployment started at the end of July 2015 and was gradually ramped up until September that year, when there was a pause for six months to ensure their RADIUS authentication and recursive DNS systems were scalable, and to evaluate unexpected behaviour encountered from some end client operating systems. The deployments resumed earlier this year once the issues had been ironed out, although these issues were more due to the loads on supporting systems rather than connectivity failures.

Another positive to be drawn is that when Sky Broadband experienced a widespread network outage last month, this affected IPv4 but not IPv6 connectivity, demonstrating how dual stack networking is able to function seamlessly.

At Deploy360 we’d like to help you take advantage of IPv6, so please take a look at our Start Here page to understand how you can get started.