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:- 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.
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.