DATA CENTERS

  • 12/14/2016
    7:30 AM
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

BGP Security: Preventing Bad Route Propagation

Find out best practices for filtering and other techniques to thwart route leaks and hijacks.

In my previous blog, I discussed strategies that network operators can use to mitigate the performance and security impacts of route leaks and hijackings. While these mitigation strategies are crucial to putting out ongoing fires, they are ultimately Band-Aids for the deeper issue that BGP is inherently insecure.

Solving the problem of BGP insecurity to prevent future route leaks and hijackings requires greater coordination in the Internet community. Networks will need to be good Internet citizens, carrying out best practices for route filtering, implementing BGP security standards, and preventing malicious hijacking activities throughout the Internet. Each network and its operators are instrumental in fortifying BGP security. Here’s how you can help.

Route filtering

Because BGP relies on routes to be shared across networks, network operators must be vigilant in only accepting legitimate routes into their routing tables and propagating them to other autonomous systems. The first line of defense in preventing leaks is filtering out illegitimate route advertisements, whether accidental or intentionally malicious. Route filtering can be based on the prefix, AS path or community within the route advertisement.

The key to proper route filtering is to build a set of robust heuristics into your network’s filtering rules. Some of these rules should likely include:

  • Filter out Bogon prefixes and routes with Bogon autonomous system numbers anywhere in the AS path. Bogon prefixes and ASes are located in reserved or unallocated IP space; these should never be advertised.
  • Filter out routes with more than two Tier 1 (“transit-free”) networks in the AS path. When there are three or more Tier 1 networks in the path, at least one of the networks is providing transit to another. This is usually a mistake.
  • If you don’t sell transit to large networks (like Tier 1 networks), filter out routes from customers that contain a large network that you wouldn’t sell transit to in the AS path. To go a step further, also keep a whitelist of prefixes that each of your customers may announce to you.
  • Use peer locking, as described by Job Snijders at the NANOG 67 conference. Email your peers and ask who all of their possible upstream networks are, and only allow those upstreams to be intermediate networks between you and your peers.
  • Use BGP Maximum-Prefix to set the maximum number of prefixes that can be announced from your peers. This acts as a circuit breaker in route leak situations where many prefixes are announced in a short period of time.

BGP security standards

There are also a number of security standards used to authorize part or all of the AS path in route advertisements, including RPKI, RPSL, and BGPSEC.

RPKI only validates the origin AS. It relies on Route Origin Authorizations (ROAs) published in Regional Internet Registries (RIRs) to ensure that an AS actually owns the prefixes it’s announcing. Make sure to publish ROAs for your own prefixes so that they can be verified by others who have deployed RPKI. Other security standards exist as well: RPSL verifies ASes with their intended routing policies, as published in Internet Routing Registries (IRRs), while BGPSEC aims to validate the entire AS path in route advertisements.

security-geralt.jpg

network security
Caption Text: 

(Image: geralt/Pixabay)

Unfortunately, adoption of these standards is low, and will need much higher adoption in the Internet community to effectively prevent large-scale events like route leaks. While the benefits of using security standards are not immediate, don’t let this deter you—the Internet needs networks to begin the hard work of deployment to ensure a more secure future.

Block malicious hijacking

While route filtering and origin validation like RPKI can do a lot to prevent accidental route leaks, they are less effective at combating the activities of clever, malicious hijackers. Preventing intentionally malicious events requires an additional set of security mechanisms.

One technique is TCP MD5, which uses a secret key to compute a hash over TCP headers. This ensures that route advertisements are authentic and haven’t been tampered with. Another technique is the Generalized TTL Security Mechanism (GTSM), where your peer sets the time to live (TTL) value of route advertisements to the maximum of 255, so that attackers more than one hop away from your network won’t be able to fake the TTL. As a result, attackers are blocked from spoofing route advertisements and impersonating other networks.

This overview of preventative techniques isn’t comprehensive, but it will provide a good start for protecting your network and prefixes against both accidental route leaks and malicious hijackings. The BGP protocol was never meant to be used to knit together the Internet on such a large scale, and the Internet community will need to work together to push BGP toward a more secure and reliable future.

Young Xu is an analyst on the product marketing team at ThousandEyes, where she dives into network data, reports on internet and cloud health and investigates the causes of outages that impact critical services. Previously, she was a product manager in the consumer hardware industry and has experience in data analysis in the financial services industry. Young holds a Bachelor of Arts in Economics from Yale University.


Comments

BGP Vulnerability Testing

If you want to check out your own BGP vulnerabilities, testing with tools like dsniff, tcphijack, ttt, bgpcrack, pif and more recent tools can (in the hands of the right pentester) speak volumes about your adherance to standards, and any vulnerabilities that exist "in spite of them". True, not as many folks are designing to or implementing to standards but even those who are often tick that checkbox and get a false sense of security. Get familiar with papers and standards like An Attack Tree for the Border Gateway Protocol (S. Convery et al. 2003) and really understand your ecosystem, do a deep network diagram (a la Chesapeake NetCraftsmen) and highlight all the potential single-points-of-failure, or intrusion, and then test them until they are no longer on the risk list. Adhering to standards is one thing, but true due diligence is entirely another...