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.


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