China Telecom's Internet Traffic Misdirection

In recent weeks, the Naval War College published a paper that contained a number of claims about purported efforts by the Chinese government to manipulate BGP routing in order to intercept internet traffic.

In this blog post, I don’t intend to address the paper’s claims around the motivations of these actions. However, there is truth to the assertion that China Telecom (whether intentionally or not) has misdirected internet traffic (including out of the United States) in recent years. I know because I expended a great deal of effort to stop it in 2017.

Traffic misdirection by AS4134

On 9 December 2015, SK Broadband (formerly Hanaro) experienced a brief routing leak lasting little more than a minute. During the incident, SK’s ASN, AS9318, announced over 300 Verizon routes that were picked up by OpenDNS’s BGPstream service:

The leak was announced exclusively through China Telecom (AS4134), one of SK Broadband’s transit providers. Shortly afterwards, AS9318 began transiting the same routes from Verizon APAC (AS703) to China Telecom (AS4134), who in turn began announcing them to international carriers such as Telia (AS1299), Tata (AS6453), GTT (AS3257) and Vodafone (AS1273). This resulted in AS paths such as:

… {1299, 6453, 3257, 1273} 4134 9318 703

Networks around the world who accepted these routes inadvertently sent traffic to Verizon APAC (AS703) through China Telecom (AS4134). Below is a traceroute mapping the path of internet traffic from London to address space belonging to the Australian government. Prior to this routing phenomenon, it never traversed China Telecom.

Over the course of several months last year, I alerted Verizon and other Tier 1 carriers of the situation and, ultimately, Telia and GTT (the biggest carriers of these routes) put filters in place to ensure they would no longer accept Verizon routes from China Telecom. That action reduced the footprint of these routes by 90% but couldn’t prevent them from reaching those who were peering directly with China Telecom.

At times in the past year, Verizon APAC sent routes from Verizon North America (AS701) via this AS path creating AS paths such as:

… (peers_of_4134) 4134 9318 703 701

When these routes were in circulation, networks peering with China Telecom (including those in the US) accepted AS701 routes via AS4134, sending US-to-US traffic via mainland China. One of our affected clients was a major US internet infrastructure company. Shortly after alerting them of the situation, they deployed filters on their peering sessions with China Telecom to block Verizon routes from being accepted. Below is a screenshot of one of thousands of traceroutes from within the US to Verizon (in the US) that illustrate the path of traffic outside of the country.

Internet Path Monitoring

The common focus of BGP hijack alerting is looking for unexpected origins or immediate upstreams for routed address space. However, traffic misdirection can occur at other parts of the AS path. In this case, Verizon APAC (AS703) likely established a settlement-free peering relationship with SK Broadband (AS9318), unaware that AS9318 would then send Verizon’s routes exclusively on to China Telecom and who would in turn send them on to the global internet.

We would classify this as a peer leak and the result was China Telecom’s network being inserted into the inbound path of traffic to Verizon. The problematic routing decisions were occurring multiple AS hops from the origin, beyond its immediate upstream.

Conversely, the routes accepted from one’s peers also need monitoring – a fairly rare practice. Blindly accepting routes from a peer enables the peer to (intentionally or not) insert itself into the path of your outbound traffic.


In 2014, I wrote a blog post entitled “Use Protection if Peering Promiscuously” that highlighted the problems with bad route propagation, such as in the incidents described above. It is problems such as this that spurred my friend Alexander Azimov at QRator Labs to lead an on-going effort to create an IETF standard for RPKI-based AS path verification. Such a mechanism, if deployed, would drop BGP announcements with AS paths that violate the valley-free property, for example, based on a known set of AS-AS relationships. Such a mechanism would have at very least contained some of the bad routing described above.

In the meantime, sign on to the Internet Society’s MANRS project to enforce routing security and watch your routes!

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha