Donate
BGPSec – A reality now Thumbnail
‹ Back
Deploy360 16 October 2017

BGPSec – A reality now

By Aftab Siddiqui Technical Engagement Manager for Asia-Pacific
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.

 

‹ Back

Related articles

ISOC Rough Guide to IETF 93: Routing Resilience
ISOC Rough Guide to IETF 93: Routing Resilience
IETF14 July 2015

ISOC Rough Guide to IETF 93: Routing Resilience

There is considerable work underway across several IETF working groups to ensure the Internet's routing infrastructure is more secure and...

ISOC Rough Guide to IETF 90: Routing Resilience
ISOC Rough Guide to IETF 90: Routing Resilience
IETF16 July 2014

ISOC Rough Guide to IETF 90: Routing Resilience

Security and resilience are important aspects of IETF work and there are many Working Groups (WGs) that contribute to the...

Rough Guide to IETF 94: Routing Security & Resilience
Rough Guide to IETF 94: Routing Security & Resilience
IETF27 October 2015

Rough Guide to IETF 94: Routing Security & Resilience

There is significant work underway across several IETF working groups to ensure the Internet's infrastructure is more secure and resilient...

Join the conversation with Internet Society members around the world