The Explorer Suite’s use by many of the world’s largest service providers and network operators gives us the opportunity to see how they operate. We get to witness the sorts of issues they deal with during their everyday operations and how many of them are resolved. We decided to share some of these stories periodically through the Life in the Control Plane blog series. After all, life in the control plane is never dull!
Here we go again:
BGPMON announced that close to 80 prefixes belonging to popular organizations such as Apple, Facebook, Google, Microsoft, etc., were announced by an Autonomous System (AS) in Russia. While it’s possible this was the result of a simple network configuration mistake, it could well be another case of BGP route hijacking. This is where spurious prefixes are announced by an AS, causing traffic intended for the legitimate destination to be redirected to another location.
We have blogged numerous times about the risks associated with BGP:
And we have also talked about the security vulnerabilities in BGP that make it easy for anyone to hijack traffic by simply announcing more specific prefixes:
But the fact is, organizations world-over, including network operators, service providers and telcos have only BGP to depend on for Internet routing. Under these circumstances, what can network operators do to ensure that route hijacks and inadvertent route leaks are detected before traffic is redirected? How can service providers ensure that highly sensitive data, such as those from financial organizations or government entities, are not redirected to an unknown Autonomous System that hijacked a prefix?
The answer is route analytics. Using route analytics, network service providers can find out in real time the routing path taken by traffic and if there is any change in the BGP peering. Here is how this recent possible route hijack was detected in real time by a European service provider using Packet Design’s Route Explorer.
During the alleged route hijack by AS 39523, the service provider’s NOC team received alerts about the change in BGP routing path to prefixes announced by Google. Because the change was unexpected, the NOC team used Packet Design Route Explorer to analyze the current path from their network to Google’s prefix. Route Explorer captures BGP routing path information in real time and stores the routing path history. After the current path was analyzed, the NOC team used Route Explorer’s DVR-like playback feature to go back in time and see how the path had changed.
During the playback, the NOC team saw that the routing path to Google’s prefix 22.214.171.124/24 had changed at 04:43:27 UTC and was taking a new path over a suspicious AS. As you can see, the time at which Route Explorer captured the routing path change matches that mentioned in the BGPMON blog.
Thus, using route analytics the service provider successfully detected the alleged route hijack as soon as it occurred and was ready to remove the peering in case traffic was redirected to this Autonomous System. Luckily, the event was short lived and ended with no major impact.
These types of events happen with alarming frequency. Are you ready and able to respond? Check out how route analytics can help you detect BGP security issues before your business is impacted.