> While one may argue such attacks can always be explained by ‘normal’ BGP behavior, these in particular suggest malicious intent, precisely because of their unusual transit characteristics – namely the lengthened routes and the abnormal durations.
The investigation is pretty damning—it’s clear from the visuals that the traffic followed unusual routes. (Canada to South Korea via China, seriously?)
Could there possibly be an innocent explanation where the channel through PRC somehow happens to be less saturated or otherwise faster?
Could it be related to the recent objection by DoJ to the US—HK undersea link? I imagine such a link could enable even wilder hijacking scenarios.
The article is from 2018, but it seems like it was an ongoing thing at the time of publication—is it still happening with no repercussions?
I did get some laughs from the unsuccessful attempt at diverting US—Italy traffic, but overall it paints a bleak picture.
China Telecom is a global transit provider. As a sibling commenter mentioned, the document doesn't show that traffic actually went to China, just that China Telecom was an available path -- even assuming traffic transited their network, it's unreasonable to assume it actually transited through China without a traceroute at least; if the traffic did transit their network, it could be logged and sent wherever, of course. Since the routes were reported as being available for several months, the most likely explanation is that at least one the organizations' ISPs had China Telecom as a transit provider or peer, or the ISPs' transit providers had China Telecom as a provider or peer (etc). It's not an unreasonable provider to get traffic from west coast North America to east coast Asia.
It's also not unreasonable to go through Hong Kong, instead of direct to South Korea --- Hong Kong and South Korea are well connected to each other, and I believe Hong Kong has more connectivity to the US than South Korea does (I could be wrong/out of date).
Most of the non-US based global transit providers have a significant presence in US PoPs as well, because good connectivity to the US is a very important part of their business. Some of these are Telefonica, Telia, Tata. (Apparently, it's important to start your name with a T).
>China Telecom is a global transit provider. As a sibling commenter mentioned, the document doesn't show that traffic actually went to China, just that China Telecom was an available path -- even assuming traffic transited their network, it's unreasonable to assume it actually transited through China without a traceroute at least;
The paper is based upon data from the DIMES project, which uses many volunteer-contributed nodes to run traceroutes and pings. See https://arxiv.org/pdf/cs/0506099.pdf
> Could there possibly be an innocent explanation where the channel through PRC somehow happens to be less saturated or otherwise faster?
AIUI these aren't empirical measurements of routes actual traffic takes, but reconstructions from historical BGP announcements. I guess when they say traffic was hijacked, they mean there were announcements originating from China Telecom for subnets that unquestionably aren't supposed to be served by them
How to detect that? Well, I guess after a hijack ends, it is possible to compare the origin ASNs announcing those subnets with before the hijack. If a subnet suddenly starts to be announced by an origin it had no prior relationship with, then that announcement later disappears, only for the subnet's old announcements to continue, it's easy to say this may have been a hijacking
It goes without saying when some origin begins publishing new addresses, humans were almost certainly involved somewhere along the chain. So for the innocence part, nope
I think they can report that Cogent are affected by analysing Cogent's own announcements, where BGP (IIRC) records the path of ASNs causing the announcement to be made. So CT -> Cogent announcement, then Cogent -> their customers announcement, that the origin is CT is actually identified in announcements the customers receive, and likely where data for reports like this are being collected
This announcement is twice removed from the origin AS (autonomous system), and would have a lower priority than a direct announcement from the origin as or another path.
A BGP speaker can lie about the AS path and claim they have a shorter path than they really do. Then their peers either reject the route advertisement, if RPKI is configured (it is not), or accept it and forward traffic through it.
From a US West POV: I don't believe I've ever seen that kind of path through PRC to be faster. Their peering ports are insanely oversubscribed and lossy at peak in LA/SJ, and half-decent traffic via CT's Next Generation is absurdly expensive.
> China Telecom (CT) entered North American networks at the beginning of the 2000s, and has since grown to have 10 PoPs, eight in the US and two in Canada, spanning both coasts and all the major exchange points in the US. Few other non-American ISPs has such a wide-spread presence on US soil.
RPKI would allow signing of BGP routes so that networks could reject them if they were not signed by the owners. Cloudflare has been pushing it heavily to avoid this kind of crap.
I’m sure it’s a naive question, but isn’t this what route filters and community policy rules are meant to prevent? These are universally in use in the Tier 1s to automate route management permissions at a large scale.
I understand that Tier 1 backbone peers trust other Tier 1s’ announcements implicitly. But couldn’t US Tier 1s simply block announcements by China Telecom of non-transit prefixes that don’t belong to Chinese ASNs? Or would that be a monumentally unmanageable undertaking? Aren’t RIR address block delegations broadly regionalised, to the degree that one could obtain a list of all address ranges delegated by APNIC to the PRC, fairly straightforwardly?
No, IRR assignments are only regional in terms of the company requesting them. A European company can use their RIPE resources anywhere in the world without "delegating" them.
Yes, filter lists generated by recursively resolving IRR AS-SETs and RPKI can prevent incidents like this, if they were universally applied. Note that origin validation on its own (i.e. what RPKI does) does not prevent malicious attacks, which can just spoof the right origin.
Some Tier 1's - most notably NTT - also use a mechanism called "Peer Lock", where an ASN can specify that it will only ever use a given set of transit providers (i.e. "NTT should never receive a Google prefix from a China Telecom peer"), which would have prevented this.
The investigation is pretty damning—it’s clear from the visuals that the traffic followed unusual routes. (Canada to South Korea via China, seriously?)
Could there possibly be an innocent explanation where the channel through PRC somehow happens to be less saturated or otherwise faster?
Could it be related to the recent objection by DoJ to the US—HK undersea link? I imagine such a link could enable even wilder hijacking scenarios.
The article is from 2018, but it seems like it was an ongoing thing at the time of publication—is it still happening with no repercussions?
I did get some laughs from the unsuccessful attempt at diverting US—Italy traffic, but overall it paints a bleak picture.