{"id":35550,"date":"2019-10-31T22:04:58","date_gmt":"2019-10-31T19:04:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/pochemu-internet-do-sih-por-onlajn\/"},"modified":"2019-10-31T22:04:58","modified_gmt":"2019-10-31T19:04:58","slug":"pochemu-internet-do-sih-por-onlajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/pochemu-internet-do-sih-por-onlajn","title":{"rendered":"Why is the Internet still online?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

The internet seems like a strong, independent, and indestructible structure. In theory, the network's strength is enough to survive a nuclear explosion. In reality, the internet can be brought down by a single small router. This is due to the fact that the internet is a jumble of contradictions, vulnerabilities, errors, and cat videos. The backbone of the internet, the BGP protocol, has a host of issues. It's surprising that it still functions. In addition to errors within the internet itself, it is also attacked by anyone who can: major internet providers, corporations, governments, and DDoS attacks. What can we do about this and how do we cope with it?<\/p>\n

\"Why
\n
\nThe answer lies with Alexey Uchakov<\/b> (Night_Snake<\/a><\/noindex>) \u2014 the leader of the network engineering team at IQ Option. His main task is to ensure platform availability for users. In Alexey's presentation at\u00a0Saint HighLoad++ 2019<\/a><\/noindex> , we will talk about BGP, DDoS attacks, the internet kill switch, provider errors, decentralization, and instances where a small router sent the internet to sleep. In the end, there will be a few tips on how to survive all this.
\n<\/a><\/noindex>
\n

\r\n \"Play\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

The Day the Internet Broke<\/h2>\n

\nI will present just a few incidents when internet connectivity broke down. This will be enough for a complete picture.<\/p>\n

\"The AS7007 Incident\"<\/b>. The internet first broke in April 1997. There was a bug in the software of a router from autonomous system 7007. At some point, the router announced its internal routing table to its neighbors and sent half of the network into a black hole.<\/p>\n

\"Pakistan vs. YouTube\"<\/b>. In 2008, brave folks from Pakistan decided to block YouTube on their end. They did it so well that half the world was left without cat videos.<\/p>\n

\"The Prefix Hijacking of VISA, MasterCard, and Symantec by Ros Telecom\"<\/b>. In 2017, Ros Telecom mistakenly began announcing the prefixes for VISA, MasterCard, and Symantec. As a result, financial traffic was routed through channels controlled by the provider. The leak didn't last long, but it was unpleasant for the financial companies.<\/p>\n

\"Google vs. Japan\"<\/b>. In August 2017, Google began announcing the prefixes of major Japanese providers NTT and KDDI for part of its uplinks. The traffic was sent to Google as transit, likely by mistake. Since Google is not a provider and does not pass transit traffic, a significant portion of Japan was left without internet.<\/p>\n

\"DV LINK hijacked the prefixes of Google, Apple, Facebook, Microsoft\"<\/b>. In 2017, the Russian provider DV LINK oddly began advertising the networks of Google, Apple, Facebook, Microsoft, and some other major players.<\/p>\n

\"eNet from the USA captured the prefixes of AWS Route53 and MyEtherwallet\"<\/b>. In 2018, a provider from Ohio or one of its clients announced the networks of Amazon Route53 and the cryptocurrency wallet MyEtherwallet. The attack was successful: despite the self-signed certificate, which warned users when accessing the MyEtherwallet site, many wallets were hijacked and some cryptocurrency was stolen.<\/p>\n

There were more than 14,000 such incidents in 2017 alone! The network is still decentralized, so not everything and not everyone is affected. However, incidents occur by the thousands, and all of them are related to the BGP protocol, on which the internet operates.<\/p>\n

BGP and its problems<\/h2>\n

\nProtocol BGP - Border Gateway Protocol<\/b>, was first described in 1989 by two engineers from IBM and Cisco Systems on three \"napkins\" - A4-sized sheets of paper. These \"napkins\"<\/a><\/noindex> still lie in the main office of Cisco Systems in San Francisco as a relic of the networking world.<\/p>\n

At the core of the protocol is the interaction of autonomous systems<\/b>\u00a0\u2014 Autonomous Systems or simply AS. An autonomous system is just an ID that is linked to IP networks in the public registry. A router with this ID can announce these networks to the world. Accordingly, any route on the internet can be represented as a vector, known as AS Path<\/b>. The vector consists of the numbers of autonomous systems that must be traversed to reach the destination network.<\/p>\n

For example, there is a network consisting of a certain number of autonomous systems. We need to get from system AS65001 to system AS65003. The path from one system is represented as AS Path in the diagram. It consists of two autonomous systems: 65002 and 65003. For each destination address, there is an AS Path vector consisting of the numbers of the autonomous systems we need to pass through.<\/p>\n

\"Why
\n
\nSo what are BGP's problems?<\/p>\n

BGP is a trust-based protocol<\/h3>\n

\nThe BGP protocol is trust-based. This means that we inherently trust our neighbor. This is a feature of many protocols developed in the early days of the internet. Let's understand what \"trust\" means.<\/p>\n

There is no authentication of neighbors<\/b>. Formally, there is MD5, but MD5 in 2019 is quite questionable...<\/p>\n

There is no filtering<\/b>. BGP has filters and they are documented, but they are not used or are used incorrectly. I'll explain later why.<\/p>\n

It's very easy to set up peering.<\/b>. Configuring peering in BGP on almost any router is just a couple of lines of config.<\/p>\n

No privileges required to manage BGP.<\/b>. You don't have to take exams that confirm your qualifications. No one will revoke your rights for configuring BGP while drunk.<\/p>\n

Two main problems.<\/h3>\n

\nPrefix hijacks.<\/b>. A prefix hijack is the announcement of a network you do not own, as in the case of MyEtherwallet. We took some prefixes, negotiated with the provider or hacked it, and through it, we announce these networks.<\/p>\n

Route leaks.<\/b>. Route leaks are a bit more complicated. A leak is a change in the AS Path.<\/b>. In the best case, the change will lead to greater latency because it has to traverse a longer route or a less efficient link. In the worst case, it could repeat the situation with Google and Japan.<\/p>\n

Google itself is not an operator and not a transit autonomous system. But when it announced to its provider the networks of Japanese operators, the traffic through Google was seen as more priority due to the AS Path. The traffic went there and was dropped simply because the routing settings within Google are more complex than just filters at the edge.<\/p>\n

Why do filters not work?<\/h3>\n

\nNobody cares.<\/b>. This is the main reason\u2014everyone just doesn't care. An admin from a small provider or a company that connected to a provider via BGP took MikroTik, configured BGP on it, and doesn't even know that filters can be configured there.<\/p>\n

Configuration errors.<\/b>. Something was debugged, there was a mistake in the mask, the wrong network was set\u2014and here's another error.<\/p>\n

No technical capacity.<\/b>. For instance, communication providers have many clients. It would make sense to automatically update filters for each client\u2014keeping track of when they acquire a new network, that they have leased their network to someone. Monitoring this is difficult, and doing it manually is even harder. That's why they simply set relaxed filters or don't set any filters at all.<\/p>\n

Exceptions<\/b>. There may be exceptions for favored and large clients. Especially in the case of inter-operator interfaces. For example, Transtelecom and Rostelecom have a ton of networks, and there\u2019s an interface between them. If the interface fails, it won\u2019t be good for anyone, so they relax or completely remove the filters.<\/p>\n

Outdated or irrelevant information in IRR.<\/b>. Filters are built based on the information that is recorded in.\u00a0IRR - Internet Routing Registry<\/b>. These are registries of regional internet registrars. Often, the registries contain outdated or irrelevant information, or sometimes both.<\/p>\n

Who are these registrars?<\/h3>\n

\"Why
\n
\nAll internet addresses belong to organizations IANA - Internet Assigned Numbers Authority<\/b>. When you buy an IP network from someone, you are not purchasing the addresses, but the right to use them. Addresses are an intangible resource, and by common agreement, they are all owned by the IANA agency.<\/p>\n

The system works like this. IANA delegates the management of IP addresses and autonomous system numbers to five regional registrars. Those registrars issue autonomous systems LIR - Local Internet Registrars<\/b>. Then, LIR allocates IP addresses to end users.<\/p>\n

The drawback of the system is that each regional registrar maintains its registries in its own way. Everyone has their views on what information should be included in the registries, who should or should not verify it. As a result, we have the chaos that exists now.<\/p>\n

How else can we tackle these issues?<\/h3>\n

\nIRR - mediocre quality<\/b>. It's clear with IRR - everything is bad there.<\/p>\n

BGP communities<\/b>. This is a certain attribute described in the protocol. We can attach, for example, a special community to our announcement so that neighbors do not send our networks to their neighbors. When we have a P2P link, we exchange only our networks. To prevent a route from accidentally going to other networks, we attach a community.<\/p>\n

Communities are not transitive<\/b>. It's always a deal between two parties, and that's their drawback. We cannot attach any community except for one that is accepted by default by everyone. We cannot be sure that this community will be accepted and interpreted correctly. Therefore, at best, if you negotiate with your uplink, he will understand what you want from him regarding the community. But his neighbor might not understand it, or the operator might simply drop your tag, and you won't achieve what you wanted.<\/p>\n

RPKI + ROA only solves a small part of the problems<\/b>. RPKI is Resource Public Key Infrastructure\u00a0<\/b> \u2014 a special framework for signing routing information. It's a good idea to make LIRs and their clients maintain an up-to-date database of address space. But there is one problem with it.<\/p>\n

RPKI is also a hierarchical system of public keys. IANA has the key from which RIR keys are generated, and from them, LIR keys are created. They use these to sign their address space with ROAs \u2014 Route Origin Authorizations:<\/p>\n

\u2014 I assure you that this prefix will be announced on behalf of this AS.<\/i><\/p>\n

Besides ROA, there are other objects, but we can discuss them later. It seems that the concept is good and useful. However, it does not protect us from leaks at all and does not solve all issues with prefix hijacking. Therefore, players are not in a hurry to implement it. Although there are already assurances from major players like AT&T and large IXes that prefixes with an invalid ROA record will be dropped. <\/p>\n

They may do this, but for now we have a huge number of prefixes that are not signed at all. On one hand, it's unclear whether they are being announced validly. On the other hand, we cannot drop them by default because we are unsure whether it's right or not.<\/p>\n

What else is there?<\/h3>\n

\nBGPSec<\/b>. This is a cool concept created by academics for the network of pink ponies. They said:<\/p>\n

\u2014 We have RPKI + ROA \u2014 a mechanism for signing address space. Let\u2019s create a separate BGP attribute and call it BGPSec Path. Each router will sign its announcements with its own signature before announcing them to neighbors. This way, we will get a trusted path from the chain of signed announcements and can verify it.<\/i><\/p>\n

In theory, it sounds good, but in practice, there are many problems. BGPSec disrupts many existing BGP mechanisms for selecting the next hop and managing incoming\/outgoing traffic directly on the router. BGPSec does not work until 95% of all market participants implement it, which is, by itself, a utopia.<\/p>\n

BGPSec has huge performance issues. With current hardware, the speed of verifying announcements is about 50 prefixes per second. For comparison: the current internet table with 700,000 prefixes would take 5 hours to load, during which time 10 more updates would occur.<\/p>\n

BGP Open Policy (Role-based BGP)<\/b>. A fresh proposal based on the Gao-Rehkford<\/b>. These are two researchers studying BGP.<\/p>\n

The Gao-Rehkford model states the following. To simplify, in the case of BGP, there are a small number of interaction types:<\/p>\n