NETWORKING

  • 02/26/2015
    8:00 AM
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

BGP Security: No Quick Fix

The routing protocol is plagued by multiple security vulnerabilities, which attackers are exploiting. However, securing BGP is no small feat.

Border Gateway Protocol (BGP), which is the routing protocol different networks use to find communication paths to each other, was not designed with security in mind. It has security vulnerabilities that nefarious individuals and governments can and do exploit, causing varying degrees of damage.

The BGP performance failures you often hear about are fairly simple issues to address. For instance, a BGP routing table overflow last year got widespread attention because it impacted users of companies and services such as eBay, Facebook, LinkedIn, and Comcast. However, BGP security failures are not so easy to tackle, with malicious attacks increasing and causing issues across the world.

Let's look at how attackers are exploiting BGP vulnerabilities, industry efforts to address the flaws, and why those efforts have fallen short, as well as other technologies that can help improve BGP security.

BGP attacks

One type of BGP attack is route hijacking, caused by someone using BGP to announce illegitimate routes. This easily disrupts the Internet by causing cyberattacks, shutting down services, or creating reliability issues. One use of hijacking is to block social media sites. In early 2014, for example, Turkish service providers hijacked Google’s DNS servers to prevent citizens from accessing social media sites. 

In another high-profile attack, Pakistani service providers -- complying with government wishes to block YouTube -- injected a BGP route for YouTube that directed its traffic to nowhere. When this route inexplicably leaked outside of Pakistan, service providers across the Internet carried it and caused YouTube’s removal from the Internet. 

Recently, a new kind of BGP route hijack attack has come to the fore: a man-in-the-middle attack. In this type of attack, traffic is diverted, giving criminals access to it before it goes to its final destination. Just this year, researchers at Dell SecureWorks uncovered multiple man-in-the-middle BGP attacks used to steal bitcoins. The thief earned about $83,000 in profits in more than four months, compromising 51 networks from 19 different ISPs.

According to The Washington Post, Internet monitoring company Renesys says man-in-the-middle attacks began surfacing in 2013. In February 2013, traffic from major financial institutions, governments, and network service providers  was diverted from its usual paths and went through Belarus before it was sent back through to the normal destinations.

In another case, all traffic between Europe and North America was rerouted through a service provider in Iceland. The culprits probably carefully crafted this so that the additional delays created little to no performance degradation. The victims of man-in-the-middle attacks may never realize that their traffic was diverted.

More worrisome still is that malicious attacks are becoming more widespread. A 2014 study by Andrei Robachevsky of the Internet Society found that at least 10% of routing incidents are real threats. There are a few malicious attacks every month. 

Securing BGP

What can be done to thwart these attacks? The Internet Engineering Task Force (IETF) has undertaken two efforts to fix BGP security issues over the years, RPSL and SIDR, but both have problems that have impeded their success.

RPSL

In 1995, the IETF formed the Routing Policy System Working Group, which in turn standardized a language called Routing Policy Specification Language (RPSL), and a security model (RP-SEC).

RPLS works by having network operators -- both service providers and enterprises -- register their authorized routes (by chain of trust starting from the Internet Assigned Numbers Authority) along with the neighbor autonomous systems that receive these routes. The security credentials (authentication and authorization) are checked at the time of registration. The working group participants then wrote a tool that read these validated policy specifications and generated router configurations that would be immune to these kinds of attacks.

Unfortunately, RPSL adoption has been low for two reasons. One, policy registrations had to reach a critical mass to get the full benefit of the system; early adopters do not benefit much.

Two, operators need to configure their routers from these policy specifications to filter routes from their customers and maybe even from their peers. This poses an operational hardship, because routing policies change constantly due to the high number of policy objects needed to represent all BGP routes and autonomous systems. Also, these changes are made during maintenance windows, which typically are scheduled a few times a week. This leaves windows when new policies are not enacted, which can result in poor routing performance. As a result, few service providers in the U.S. adopted the system; adoption was more widespread in Europe.

SIDR

Another effort, developed by the IETF’s Secure Inter-Domain Routing Working Group (SIDR), can check the security credentials in-band as BGP routes are exchanged (BGPSEC). Regrettably, this technology does not adequately solve the problem for three reasons:

  1.  It requires heavy cryptographic computational power that today’s routers do not have;
  2. It does not protect against man-in-the-middle BGP route hijack attacks, but only the earlier attacks; and
  3. It does not address the reason why RPSL adoption has been low.

The good news is that networks that use SIDR are better protected: none of their customers can hijack routes. Therefore, a service provider can ensure that at least its customers can always reach each other. With the increase in malicious attacks, now may be the time for more service providers to deploy either RPSL- or SIDR-based systems.

NEXT:  Looking to SDN & route analytics for help

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.