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 Mutually Agreed Norms for Routing Security (MANRS) Securing Border Gateway Protocol (BGP)

Even Better MANRS During August

We already discussed the MANRS activities during SANOG 32 where we organised a Network Security Workshop and signed an MoU with the ISP Association of Bangladesh (ISPAB), but the Internet Society was also involved with three other events during the month of August. This included the Symposium on Internet Routing Security and RPKI, VNIX-NOG 2018 and the inaugural INNOG 1.

Symposium on Internet Routing Security and RPKI

ZDNS along with CNCERT organised a symposium on 17th August at Crowne Plaza Beijing to discuss routing security issues and how RPKI can help address this problem. There were many prominent participants representing local, regional and international entities including Baidu, Tencent, Alibaba, Huawei, ZTE, the Chinese Academy of Sciences, APNIC, ICANN, along with the Internet Society.

Dr Stephen Kent (BBN) was the keynote speaker, having played an important role in the SIDR (Secure Internet Domain Routing) Working Group at the IETF (Internet Engineering Task Force) and also co-authored many RFCs (Request for Comments) on RPKI. He discussed the ideas behind RPKI and Route Origin Authorization/Validation.

George Michaelson (APNIC) who along with his colleague Geoff Huston co-authored RFC 6483 – Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) – followed this with a presentation on the status of RPKI deployment in the region with specific focus on China. CNNIC, the National Internet Registry (NIR) of China, only started offering ROA services in November 2017, so there is currently limited uptake, which is why the symposium is hoping to raise awareness of the importance of implementing RPKI.

I then outlined some of practical issues that network operators need to consider when deploying Route Origin Validation, as well as highlighting how the issues related to unallocated IPv4/v6 address space (aka Bogons) can be addressed.


The VNIX Network Operators Group Conference (VNIX-NOG) was held on 24 August 2018 in Danang City, Vietnam. This annual event is organised by the Vietnam Internet Network Information Centre (VNNIC), a National Internet Registry, and has become an important focus for local community to improve understanding and knowledge, and offers a platform to discuss information security issues relevant to Vietnam.

The theme of this year’s event was Routing Security, and Srinivas Chendi (APNIC) provided some background on RPKI, whilst Hiroki Kawabata (JPNIC) shared JPNIC’s experience of deploying RPKI for.

I then presented the ‘Routing Security landscape‘ that highlights the issues of BGP hijacks and leaks and how it would be beneficial for ISPs to join MANRS initiative. Very interestingly, not a single service provider in Vietnam advertises any IPv4/v6 Bogon.


The ISP Association of India (ISPAI) organised the inaugural Indian NOG (INNOG) in the capital city of New Delhi. The event comprised three days of workshops (27-29 August 2018) and a one-day conference (30 August).

The Internet Society supported the Network Security workshop with our community trainers Moinur Rehman and Anirban Data, and turned to be fully booked. Our colleague Subhashish Panigrahi presented the MANRS initiative and highlighted the routing issues impacting Indian ISPs and enterprises, as well as the simple steps can be taken to address the problems.

Following this on 3 September 2018, the Internet Society signed a MoU with the ISP Association of India (ISPAI) in order to promote the MANRS principles and encourage member ISPs to sign-up as MANRS participants. The MoU was signed by Rajnesh Singh (ISOC Regional Bureau Director for the Asia-Pacific region) and Rajesh Chhariya (President ISPAI) and will give a great boost to improving the routing security situation in India.

AusNOG 2018

I also participated in AusNOG 2018, the Australian Network Operators’ Group, on 30-31 August 2018 in Sydney, Australia. A number of interesting announcements were made here, which will be the subject of a separate forthcoming blog.

Further Information

Building Trust Deploy360 IETF Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Open Internet Standards Securing Border Gateway Protocol (BGP) Technology

New RFC 8360 – RPKI Validation Reconsidered – Offers Alternative Validation Procedures to Improve Routing Security

RFC 8360, Resource Public Key Infrastructure (RPKI) Validation Reconsidered, is now published in the RFC libraries.

What is RPKI?

Resource Public Key Infrastructure (RPKI) aims to improve the security of the Internet routing system, specifically the Border Gateway Protocol (BGP), by establishing a hierarchy of trust for BGP routes. Today, most organizations simply trust that routing updates they get are sent by authorized senders. This is how bad actors and misconfigurations can cause massive routing issues. With RPKI, the receiving organization can verify that the sending organization is authorized to send the routing update.

RPKI works by issuing X.509-based resource certificates to holders of IP addresses and AS numbers to prove assignment of these resources. These certificates are issued to Local Internet Registries (LIRs) by one of the five Regional Internet Registries (RIRs) who allocate and assign these resources in their service regions.

What Does This RFC Do?

In the IETF, participants have been discussing issues that may arise when resources move across registries. The problem happens when a subordinate certificate “over-claims” resources compared to its parent. According to the standard validation procedure specified in RFC 6487, the whole branch beneath would be invalidated. The closer to the top of the RPKI hierarchy such mistakes happen, the bigger the impact; some ISPs can lose their routing completely (assuming other networks validate, of course). The probability of such mistakes is unfortunately non-zero, especially taking into account inter-RIR address transfers. This new RFC specifies an alternative certificate validation procedure that reduces these aspects of operational fragility in the management of certificates in the RPKI, while retaining essential security features.

The RFC 8360 revised validation algorithm is intended to avoid causing CA certificates to be treated as completely invalid as a result of overclaims – only resources not covered by the parent certificate will be considered invalid. However, these changes are designed to not degrade the security offered by the RPKI. Specifically, ROAs and router certificates will be treated as valid only if all of the resources contained in them are encompassed by all superior certificates along a path to a trust anchor.

More Resources

Routing security is vital to the future and stability of the Internet, and the Internet Society is committed to helping network operators implement the crucial fixes needed to eliminate the most common malicious threats to the routing system. The Mutually Agreed Norms for Routing Security (MANRS) initiative is technology-neutral, but RPKI is one component to help improve routing security for all. We encourage all network operators to implement the four simple but concrete Actions and join the MANRS initiative. We also have more resources on Securing BGP and RPKI at, including an Introduction to PKIs and CAs.

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

BGPSec – A reality now

The Secure Inter Domain Routing (SIDR) initiative held its first BoF at IETF 64 back in November 2005, and was established as a Working Group in April 2006. Following the Youtube Hijack incident in 2008, the need to secure BGP became increasingly important and SIDR WG charter explains it well:
The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are:
  • Is an Autonomous System (AS) authorized to originate an IP prefix
  • Is the AS-Path represented in the route the same as the path through which the NLRI traveled.

This last vulnerability was the basis for defining an AS Path validation specification which has become known as BGPsec.

BGPsec attempts to assure a BGP peer that the content of a BGP update it has received, correctly represents the inter-AS propagation path of the update from the point of origination to the receiver of the route.

So far, 39 RFCs have originated from the SIDR WG, with three drafts currently under discussion. Seven RFCs were published last month (September 2017) providing a big boost to the securing routing work:

  • RFC 8205 (was draft-ietf-sidr-bgpsec-protocol) – BGPsec Protocol Specification
  • RFC 8206 (was draft-ietf-sidr-as-migration) – BGPsec Considerations for Autonomous System (AS) Migration
  • RFC 8207 (was draft-ietf-sidr-bgpsec-ops) – BGPsec Operational Considerations
  • RFC 8208 (was draft-ietf-sidr-bgpsec-algs) – BGPsec Algorithms, Key Formats, and Signature Formats
  • RFC 8209 (was draft-ietf-sidr-bgpsec-pki-profiles) – A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests
  • RFC 8210 (was draft-ietf-sidr-rpki-rtr-rfc6810-bis) – The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
  • RFC 8211 (was draft-ietf-sidr-adverse-actions) – Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)

RFC 8205 is the BGPSec Protocol Specification that has been published as standard. BGPsec is an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message propagates. BGPsec is implemented via an optional non-transitive BGP path attribute called BGPsec_Path, that carries digital signatures produced by each autonomous system propagating the update message. The digital signatures provide confidence that every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route.

BGPsec is intended to be used to supplement BGP Origin Validation [RFC6483][RFC6811], and when used in conjunction with origin validation, it is possible to prevent a wide variety of route hijacking attacks against BGP. It relies on the Resource Public Key Infrastructure (RPKI) certificates that attest the allocation of AS number and IP address resources [RFC6480].

The Resource Public Key Infrastructure (RPKI) system is a way to improve routing security by associating an IP address range with an autonomous system number (ASN) through cryptographic signatures, as described in RFC 6480. RPKI leverages X.509 certificates [RFC 5280] with added extentions for IPv4 and IPv6 prefixes, and AS numbers defined in RFC 3779.

The RIRs [APNIC, ARIN, RIPE NCC, AFRINIC, LACNIC] issue these certificates to resource holders when a resources are requested. Certificates are typically renewed every year and each RIR uses a self-signed root certificate to sign the certificates they issue.

RPKI allows network operators to create cryptographically verifiable statements about the route announcements they authorise to be made with the Autonomous System (AS) numbers an IP address prefixes they hold. These statements are known as Route Origin Authorisations (ROAs), can also be used to determine the maximum length of the prefix that the AS is authorised to advertise.

A record for AS25 and AS42 collected through RIPE NCC RPKI Validator Tool shows the validity of prefixes announced.

In case of BGPSec, the mechanism requires the use of a new BGP attribute and negotiation of a new BGP capability between eBGP peers, so it means little will change over night. An incremental deployment is going to be the way forward, starting with adjacent AS’s offering to speak BGPsec with their eBGP peers.

In a perfect future Internet, interconnected ASes all speaking BGPsec will be able to provide assurance about the correctness of all routes originated and propagated amongst the same interconnected ASes. Therefore the benefits of secure BGP will mostly only be realised when there are fewer non-BGPSec speakers in the routing paths.

RPKI and origin validation is nearing a point of maturity in terms of understanding the need for it, but there is still a long and winding road ahead to ensure a decent level of RPKI deployments. The RIRs have already launched their RPKI services, and working code for implementing origin validation in BGP has been released by a few vendors (Cisco, Juniper, Quagga), but the Internet community has likely been waiting for the announcement of BGPSec specification.

Now that BGPSec is a reality though, there’s no longer any excuse for network operators to not be signing their resources, and thereby contributing towards a stable, secure and trusted Internet routing system.

Deploy360 also want to help you deploy Secure Routing, so please take a look at our Start Here page to learn more.


Deploy360 Events IETF IPv6

Deploy360@IETF94, Day 2: Homenet, SPRING & SIDR

Geoff Huston at APNIC 38The second day at IETF 94 in Yokohama is all about home networking and secure routing for the Deploy360 team.

Not to mention of course the evening social event which is also a chance to come and say hello .

NOTE: If you are unable to attend IETF 94 in person, there are multiple ways to participate remotely.

The homenet (Home Networking)Working Group is meeting during the 0900-1130 UTC+9 block to continue its work on IPv6 based protocols for residential networks. This is usually one of the best attended working groups and this session will be focused on autoconfiguration, naming architecture and service discovery, as well as multiple interfacing support in home-type scenarios. No less than eight new drafts are up for discussion here, as well as updates to another seven, so expect an active session.

Running in parallel with homenet is the spring (Source Packet Routing in Networking) Working Group that’s looking into how to specify explicit packet forwarding paths to take advantage of certain network characteristics. Whilst similar mechanisms are already employed in MPLS traffic engineering, spring is also considering the use of IPv6 as a data plane.

There’s a bit of gap until the secure routing session, so the more politically conscious may want to check out the proposed hrpc (Human Rights Protocol Considerations) Research Group. Although not an obvious subject for the IETF, this group aims to look at how protocols can be developed to protect the Internet as a human rights enabling environment. IP, DNS, HTTP, P2P, XMPP and VPN protocols are up for specific discussion, so there are obvious IPv6, DNSSEC and TLS implications here.

The sidr (Secure Inter-Domain Routing) Working Group is running a split session in the 17.10-18.40 UTC+9 block today, but continuing on Friday during the 09.00-11.30 block. Today’s session is primarily devoted to the operational issues in deploying RPKI, and in particular referencing the experience of the Regional Internet Registries. These concerns include the consequences of mismatched resources in the digital certificate chain, when resources are transferred to a new holder in a different registry, and the handling RKPI validation locally when the CA authority is inaccessible. Four drafts that seek to address these issues are up discussion this evening.

At the same time as SIDR, the DBOUND Working Group will meet .We monitor this WG primarily because the “boundaries” of how you look at domain names can impact other security mechanisms such as TLS certificates. The DBOUND problem statement gives a good view into what the group is trying to do.

Then don’t forget the social event over at the Yokohama Bay Hotel Tokyu, starting at 19.00!

For more background, please read the Rough Guide to IETF 94 from Andrei, Mat, Karen, Dan and myself.

Relevant Working Groups:

Deploy360 Improving Technical Security Securing Border Gateway Protocol (BGP)

BGPmon: Using BGP Data To Fight Spam

BGPmon logoCan we use BGP data to find email spammers? And could securing BGP provide a mechanism to help reduce spam?

In a fascinating article on BGPmon’s site, Andree Toonk explores how they found that “IP squatting” is used by spammers.  Essentially the attack seems to work like this:

  1. The spammers identify a block of IP addresses (IPv4) that are not currently being used on the actual Internet.
  2. The spammers send out BGP announcements routing that block of IP addresses to their servers.
  3. The spammers send out their spam email messages.
  4. When done (or when the IP address block is blocked by anti-spam tools), the spammers stop announcing the BGP routes for those IP address blocks.

They then can move on to announcing other IP address blocks to send more spam.

The article provides a very compelling and very readable description of two case studies where they found this to happen. In one case the spammers also used an Internet Route Registry (IRR) to attempt to give their BGP route announcement more legitimacy.

The BGPmon article doesn’t get into solutions… but preventing these kind of attacks is precisely why we set up the Securing BGP topic area of this site.

A general area of “source address validation” is critical here – the idea being to have some way to know that the router announcing the BGP routes has the actual authority to do so. New tools such as RPKI are emerging that let us securely validate the origin of route announcements to prevent spammers from performing the attacks like this.  With such tools a router would reject BGP announcements that came from the spammers’ systems because the spammers would not be able to securely assert that they had the right to announce those IP address blocks.  The challenge, of course, is to get more routers start signing route announcements – and more routers start validating route announcements.  (Read about how Jan set up RPKI for his lab.)  There are other tools and methods being explored, too.  The point is to not allow “spoofed” IP address blocks to get into the global routing tables.

This idea of securing BGP route announcements is also part of the “Routing Resilience Manifesto” that continues to be developed as (voluntary) guidelines for network operators.

If we are collectively able to implement some of these mechanisms for securing BGP we can potentially make a significant reduction in the ability of spammers to send their email – and make the Internet more secure and working better in the process.  Please do check out our Securing BPG section and consider what you can do in your network today!

IETF Improving Technical Security Technology

Routing Security on the Internet – Is it Really Worth the Effort?

A security researcher from Georgia Institute of Technology has called into question the efforts underway to secure the Internet’s routing infrastructure. Robert Lychev’s findings are striking and the paper he and his co-authors wrote earned them the third Applied Networking Research Prize for 2014.

Many widely used communication protocols on the Internet were not originally designed with security in mind: they were intended for parties that trust each other. As the Internet has evolved, many new protocols intended to address specific security vulnerabilities have been developed. Deployment of these new protocols can take a long time and therefore questions about the interactions of new secure protocol solutions with legacy insecure protocols are important.

For routing of Internet traffic, Border Gateway Protocol (or BGP) is a key technology and much work has been done to address the real security vulnerabilities of BGP through developments like the Resource Public Key Infrastructure (RPKI) and BGP Security Extensions (BGPSEC). Lychev and his collaborators were interested in understanding the security properties of BGPSEC in partial deployment. In particular, what does partially deployed BGPSEC offer over RPKI or, “Is the juice (additional security benefits) worth the squeeze (extra efforts of deployment)?”

In their paper, “BGP Security in Partial Deployment” (Proc. ACM SIGCOMM, Hong Kong, China, August 2013), Lychev and his co-authors Sharon Goldberg and Michael Schapira found that partially deployed security measures sometimes introduce new vulnerabilities and partial deployment provides only meagre benefits over RPKI if operators do not prioritise security over all other considerations in their routing policies.

Speaking about the award and his trip to the IETF meeting in Toronto, Lychev said, “Thank you very much for making this trip possible. I think that I have learned quite a bit from this meeting. I met a lot of people, and I hope to start new collaborations with some of them in the near future.”

Lychev received his award at the recent Internet Research Task Force open meeting at IETF 90 in Toronto, where he also presented his results. His slides are available and audio from the presentation is also available (starting at 00:09:00).

The nomination period for Applied Networking Research Prizes to be awarded in 2015 is now open. Please submit your nominations for the 2015 ANRP award before the closing date of October 31, 2014. Nominations can be submitted via the submission site or by email to