
China Telecom's BGP Hijacking [pdf] - panarky
https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca
======
goblin89
> 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.

~~~
CameronNemo
>Could there possibly be an innocent explanation where the channel through PRC
somehow happens to be less saturated or otherwise faster?

BGP prioritizes routes via the number of hops in the AS path. A prefix
announcement could be described like this:

    
    
        subnet: 169.254.0.0/16
        origin-as: 65419
        as-path: 65419 -> 65420 -> 65416
    

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.

~~~
dylz
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.

~~~
solotronics
China Unicom / China Telecom / China Mobile suck as transit, not sure what the
above poster is getting at.

[https://jpgamboa.com/peering-chinese-internet/](https://jpgamboa.com/peering-
chinese-internet/)

------
mirimir
> 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.

So can't the US government just shut them down?

I mean, do US firms operate ten PoPs in China?

~~~
nyolfen
this is probably a bad precedent to set

~~~
Sabinus
It's not like US infrastructure does very well in China.

------
creato
Is there a benign explanation for the recurring, seemingly very precisely
targeted hijacks mentioned in this paper?

~~~
pstrateman
Doesn't seem to be.

------
abalashov
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?

~~~
lima
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.

[https://archive.nanog.org/sites/default/files/Snijders_Every...](https://archive.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf)

[https://blogs.akamai.com/Minimizing%20BGP%20Hijacking%20Risk...](https://blogs.akamai.com/Minimizing%20BGP%20Hijacking%20Risk_2018-10-29.pdf)

