BGP Security: No Quick Fix

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:

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

How SDN can help

Software-defined-networking (SDN) can help by making routing configuration changes automatically in near-real time, reducing the need for maintenance windows. This addresses the constantly changing routing policy shortcoming of RPSL.

For example, when an enterprise changes its service provider, some service providers may only accept routes from the old one until their routers are reconfigured. In an SDN world, a controller can read and revalidate these policies as fast as changes happen and configure routers in real time without causing an operational hardship.

In addition, support for NETCONF/YANG  in routers and controllers can simplify configuring these policies, which is why it's good to see NETCONF/YANG support in the OpenDaylight controller.

Route analytics  

Route analytics can help with the two occurrences of route hijacking that need detecting: When an organization’s routes are being hijacked and when an operator is unwittingly the carrier of hijacked routes.

When routes are being hijacked, the data needed for detection is typically unavailable in that organization’s BGP routers. Because of the way BGP AS_path attribute works, these routes will contain the organization’s autonomous system (AS) number and therefore -- to avoid loops -- BGP will not pass them back to the routers of the organization. However, with access to external BGP sessions or to the BGP data typically found in the Route Views or RIPE/RIS projects, it's possible to monitor an organization’s own routes and be alerted when suspicious deviations are found.

When an organization is being passed hijacked routes, data from the routers can detect it in two ways. One technique to do this is BGP route baselining. This tracks what routes are typically received and detects when these routes are missing or when new non-baselined routes pop up. Organizations can baseline BGP routes with respect to their origin AS, the neighbor AS, the BGP next hop router, the border router, and various BGP route targets.

The second technique is BGP route visualization. For a given BGP prefix, or a set of prefixes specified using a filter, BGP route visualization can draw a picture of the route’s traversal across the Internet. This includes the border router in the organization’s AS, the next hop router in the next AS, neighbor, transit and origin AS. It can draw a comparative picture to contrast the picture between two different times as well as animate the changes over this time period. 

Ultimately, we need a permanent solution to secure BGP. Whether it is RPSL or SIDR, we must act with urgency to secure BGP and protect networks from malicious attacks. Both solutions require registration of policy objects. Until this is done on a broad scale, we need to closely monitor BGP for evidence of route hijacking as well as explore new technologies such as SDN that can help.