14,000 incidents — routing security in 2017

By on 24 Jan 2018

Category: Tech matters

Tags: , , ,

Blog home

How was the state of the Internet’s routing system in 2017? Let’s take a look back using data from BGPStream. Some highlights:

  • 13,935 total incidents (either outages or attacks like route leaks and hijacks)
  • Over 10% of all Autonomous Systems on the Internet were affected
  • 3,106 Autonomous Systems were a victim of at least one routing incident
  • 1,546 networks caused at least one incident

An ‘incident’ is a suspicious change in the state of the routing system that can be attributed to an outage or a routing attack, like a route leak or hijack (either intentional or due to a configuration mistake). [i]

Let’s look at just a few examples of incidents picked up by the media.

March 2017: SECW Telecom in Brazil hijacked prefixes of Cloudflare, Google, and BancoBrazil causing some outage for these services in the region.

April 2017: Large chunks of network traffic belonging to MasterCard, Visa, and more than two dozen other financial services companies were briefly routed through a Russian telecom. For several minutes, Rostelecom was originating 50 prefixes for numerous other Autonomous Systems, hijacking their traffic.

August 2017: Google accidentally leaked BGP prefixes it learned from peering relationships, essentially becoming a transit provider instead of simply exchanging traffic between two networks and their customers, causing large-scale Internet disruption. It hit Japanese users the hardest, slowing or blocking access to websites and online services for dozens of Japanese companies.

October 2017: Another BGP mishap caused reachability and performance problems for networks such as Twitter, Google, and others. For almost 20 minutes, traffic for many large CDNs was rerouted through Brazil, caused by a BGP leak.

November 2017: BGP routing issues between Level3 and Comcast caused large-scale network service degradation in North America for slightly more than 90 minutes. Another route leak.

December 2017: Several high-profile sites (Google, Apple, Facebook, Microsoft, Twitch, NTT Communications and Riot Games) were rerouted to a previously unused Russian Autonomous System. Two BGP routing incidents only lasted about three minutes each.

Not a single day passed without an incident. While none of the incidents was catastrophic, all of them continue to demonstrate the lack of routing controls like those called for in Mutually Agreed Norms for Routing Security (MANRS) that could have prevented them from happening.

This is just a small fraction of what happened in the routing system in 2017. Rather than measure routing security by anecdotal evidence, let’s look at the data.

Routing incidents

Of the 13,935 total incidents, 62% were classified as outages and 38% were considered routing attacks like route leaks and hijacks.

Figure 1: Twelve months of routing incidents.

6,128 Autonomous Systems were involved, which is more than 10% of all announced Autonomous System Numbers (ASNs) on the Internet. If we look at the outages, almost half of them happened to Brazilian operators. [ii]

Figure 2: Top 10 outages per economy.

Let’s look at incidents that represent a potential attack, be it malice or a configuration mistake. It is interesting to analyze such routing incidents by the roles a network played — whether it was a victim, a culprit, or an accomplice.

The U.S. ranks first among economies where networks became a victim of an incident, for example, when a network’s prefix is hijacked. Last year, that happened 1,193 times in the U.S. It is followed by Brazil (450), India (299), and Russia (242).

Figure 3: Top 10 incidents with a victim in a economy.

Unsurprisingly, the majority of the networks victimized by the most incidents are based in the U.S. In total 3,106 Autonomous Systems were victims of at least one routing incident in 2017.

Figure 4: Top 10 victims (AS’s) of routing incidents.

U.S. and Brazil, followed by Russia and China, lead the list of economies in which networks caused incidents. They are responsible for more than 75% of all incidents. Overall, 1,546 networks caused at least one incident during 2017.

Figure 5: Top 10 incidents with a culprit in a economy.

The ranking is different when it comes to the top 10 guilty networks. An interesting case is AS198949 — SecurityDAM, which is responsible for 54 incidents, mostly prefix hijacks. This is a security provider, offering DDoS attack mitigation among other services. Most probably these incidents were part of attack mitigation actions. Since the BGPStream only registers suspicious routing changes, without knowing intent in some cases it is impossible to distinguish an attack from a legitimate (or consented) routing change.

Figure 6: Top 10 potential culprits in routing incidents.

The U.S. also leads the list of economies with networks that could have prevented an attack but didn’t, such as not filtering false routing announcements from their customers (one of the MANRS Actions). The usual suspects — Russia, Brazil, and China — follow.

Figure 7: Top 10, incidents with an accomplice in a economy.

In the end, I’d like to note that absolute numbers tell only part of the story. They need to be put into perspective. Economies and networks differ significantly in terms of connected users, announced prefixes and other metrics.

The numbers in this report are not normalized by any of these metrics, but to give an idea, look at a possible one — the number of active networks in a economy. For example, perhaps the U.S. leads many of these lists simply because there are more networks where incidents could happen.

Figure 8: The “AS’s advertised” in this chart come from freely available data.

Another point is that it is hard to say whether these numbers are OK, or really bad. Is the system improving or getting worse? The statistics in this report will be a good basis for a trend analysis in years to come.

What you can do — Join MANRS

MANRS is a community-driven initiative coordinated by the Internet Society that provides a minimum set of low-cost and low-risk actions that, taken together, can help improve the resiliency and security of routing infrastructure. The more service providers that apply these minimum actions, the fewer incidents there will be, and the less damage they can do.

There are four MANRS Actions:

  • Filtering — Ensure the correctness of your own announcements and of announcements from your customers to adjacent networks with prefix and AS-path granularity
  • Anti-spoofing — Enable source address validation for at least single-homed stub customer networks, your own end-users, and infrastructure
  • Coordination — Maintain globally accessible up-to-date contact information
  • Global validation — Publish your data, so others can validate routing information on a global scale

Maintaining up-to-date filters for customer announcements could mitigate many route leaks. Preventing address squatting could help ward off things like spam and malware. Keeping complete and accurate routing policy data in an Internet Routing Registry (IRR) or Resource Public Key Infrastructure (RPKI) repository is essential for global validation that helps prevent BGP prefix hijacking. Having updated contact information is vital to solving network emergencies quickly.

Learn how and why you should update records in the APNIC Whois Database

Lets hope we will see more network operators joining MANRS and improvements in routing security in 2018. Happy New Year!

[i] BGPStream is an operational tool that tries to minimize false positives, so this number of total incidents may be on the low side.

[ii] This is only counting the number of incidents and not factoring in duration or number of prefixes affected, which may indicate the impact of these incidents.

Original post appeared on the MANRS website.

the Technology Program Manager at the Internet Society.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *