That, we must say, is the unique story so far.

Here’s the beginning: for approximately an hour, starting at 19:28 UTC on April 1, 2020, the largest Russian ISP — Rostelecom — was announcing prefixes belonging to prominent internet players: Akamai, Cloudflare, Hertzner, Digital Ocean, Amazon AWS, and other famous names.

Before the issue was resolved, paths between the largest cloud networks were somewhat disrupted — the Internet blinked. The route leak was distributed quite well through Rascom (AS20764), then Cogent (AS174) and in a couple of minutes through Level3 to the world. The issue suddenly became bad enough that it saturated the route decision-making process for a few Tier-1 ISPs.

At 17:13 UTC on March 31, 2020, the AS50048 (NEWREAL-AS) leaked, in total, 2658 IPv4 network prefixes to the Tier-2 transit provider Transtelecom. Those prefixes included Orange, Akamai, Rostelecom and more than 300 other companies’ networks.

February 7, 2020 - one of the biggest carriers and ISPs in Russia - MTS - AS8359, created two route leaks involving prefixes belonging to such companies as Imperva, GCore, IPTP, Akamai and many others. MTS took those prefixes from HKIX (AS4635) and sent them to Level3 (AS3356) for further distribution.

Today we often talk about SLA and redundancy. And the increasing role of clouds in the overall Internet infrastructure. Someone says that they will play a crucial role in traffic share in the nearest future. However, there are other huge ISPs - Tier-1, aka the biggest transit operators, which have transnational cables and indeed are part of the historical Internet backbone. They often play the role of last resort in the filtration process of bad routes. Because they have hundreds of customers. Also, almost all of these customers believe in what they got from the provider ISPs. That is the main reason why modern internet drafts rely on Tier-1s as flag carriers and hope that they’ll apply a new security mechanism among all the others.

Is this always a real scenario?

Two days ago, May 5 of the year 2019 we saw a peculiar BGP outage, affecting autonomous systems in the customer cone of one very specific AS with the number 721.

Right at the beginning, we need to outline a couple of details for our readers:
 

1. All Autonomous System Numbers under 1000 are called “lower ASNs,” as they are the first autonomous systems on the Internet, registered by IANA in the early days (the late 80’s) of the global network. Today they mostly represent government departments and organizations, that were somehow involved in Internet research and creation in 70-90s.
2. Our readers should remember, that the Internet became public only after the United States’ Department of Defense, which funded the initial ARPANET, handed it over to the Defense Communication Agency and, later in 1981, connected it to the CSNET with the TCP (RFC675)/IP (RFC791) over X.25. A couple of years later, in 1986, NSF swapped the CSNET in favor of NSFNET, which grew so fast it made possible ARPANET decommission by 1990.
3. IANA was established in 1988, and supposedly at that time, existing ASNs were registered by the RIRs. It is no surprise that the organization that funded the initial research and creation of the ARPANET, further transferring it to another department because of its operational size and growth, only after diversifying it into 4 different networks (Wiki mentions MILNET, NIPRNET, SIPRNET and JWICS, above which the military-only NIPRNET did not have controlled security gateways to the public Internet.

On March 13, a proposal for the RIPE anti-abuse working group was submitted, stating that a BGP hijacking event should be treated as a policy violation. In case of acceptance, if you are an ISP attacked with the hijack, you could submit a special request where you might expose such an autonomous system. If there is enough confirming evidence for an expert group, then such a LIR would be considered an adverse party and further punished. There were some arguments against this proposal.

With this article, we want to show an example of the attack where not only the true attacker was under the question, but the whole list of affected prefixes. Moreover, it again raises concerns about the possible motives for the future attack of this type.

It was an ordinary Wednesday on 4.04.2019. Except that at some point of the midday timeline an AS60280 belonging to Belarus’ NTEC leaked 18600 prefixes originating from approximately 1400 ASes.

Those routes were taken from the transit provider RETN (AS9002) and further announced to NTEC’s provider - RU-telecom’s AS205540, which, in its turn, accepted all of them, spreading the leak.

A little historical overview

• BGP hijacks - when an ISP originates an advertisement of address space that does not belong to it;
• BGP route leaks - when an ISP advertises prefixes received from one provider or peer to another provider or peer.

This week it has been 11 years since the memorable YouTube BGP incident, provoked by the global propagation of a more specific prefix announce, originated by the Pakistan Telecom, leading to an almost 2 hour in duration traffic disruption in the form of redirecting traffic from legitimate path to the bogus one. We could guess if that event was intentional, and even a correct answer wouldn’t help us completely prevent such incidents from happening today. While you read this, a route leak or a hijack is spreading over the networks. Why? Because BGP is not easy, and configuring a correct and secure setup is even harder (yet).

In these eleven years, BGP hijacking became quite damaging attack vector due to the BGP emplacement in the architecture of modern internet. Thanks to BGP, routers not only acquire peer information, and therefore all the Internet routes - they are able of calculating the best path for traffic to its destination through many intermediate (transit) networks, each representing an individual AS. A single AS is just a group of IPv4 and/or IPv6 networks operating under a single external routing policy.

And thanks to BGP in its current state attackers are capable of conducting massive heists of traffic, efficiently hijacking target network’s prefixes, placing themselves in the middle. And that’s just the beginning - in the era of state-sponsored cyber actors, it is evident that the keystone of Border Gateway Protocol, which is trust, is no longer sufficient enough to prevent malicious outbreaks of routing incidents, deliberate or not, to occur. Since BGP plays such an essential role in the existence of the internet as we know it (it is the only exterior gateway protocol to control traffic flow between different Internet Service Providers all over the world), for a decade we’ve seen attempts to patch things up.

Several times in our posts we discussed consequences of lack of ingress filtering. Such mistake configuration can work fine most of the time, but one day may result in an outage at regional or even global scale. And yesterday, 25.11.2018, it happened again, this time in Russia.

Three Mistakes in a Boat (To Say Nothing of the Outage)

Yesterday, on 12.11.2018 a BGP configuration mistake happened at Mainone Cable Company (AS37282), a Nigerian ISP. It mainly hit two content providers: Google (AS15169, AS36384, AS36492, AS43515) and Cloudflare (AS13335). Leaked routes were accepted by its direct upstream, China Telecom (AS4809), further advertised in Russia to TTK (AS20485) and finally learned by NTT (AS2914) in Europe. After reaching the Tier-1 providers level leaked prefixes propagated globally, redirecting traffic to unusual Europe-Russia-China-Nigeria route.