Born to intercept traffic

New Internet providers appear literally every day, and on December 12, 2017 was no exception. A newcomer to the cross-domain routing ecosystem, AS39523 (DV-LINK-AS), began to announce its own address space (one prefix), adding to it at the same time another 80 foreign prefixes belonging to both Russian and international content providers, such as Google, Facebook, Mail.ru, Vkontakte and many others.


The incident lasted more than 2 hours, starting at 4:44 UTC with a peak of 80 prefixes, ending at 7:19 with another peak around 7:04 UTC.

Because of the specific set of services that have experienced the impact of the incident, we can assume that static routes have flowed through BGP. However, the main question is why these incorrect announcements have spread at all? The fact that intercepted prefixes have spread to all corners of the Internet demonstrates the absence of any filters between AS39523 and its direct supplier AS31133 (Megaphone), and between AS31133 (Megafon) and the world's largest telecom operators, such as Level3 (AS3356), Cogent (AS174), Zayo (AS6461), Hurricane Electric (AS6939) and others.

There are three most common reasons for the lack of incoming filters at the interfaces of operators of the client-supplier type:
')

1. Some transit operators cannot convince their customers to create correct route objects. As the client pays money for the service, some Internet providers do not consider it obligatory to impose strict filters, and as a result we have exceptions.
2. Another problem is that there is no authorization for AS-SET objects. As a result, any ASN or AS-SET can be added to the AS-SET! There are Internet providers that have thousands of prefixes in their AS-SET object, with just a couple dozen actually belonging to their client cone. This situation is only getting worse closer to the core of the Internet, where large Tier2 networks may have AS-SET, bloated to hundreds of thousands of entries. Instead of working with their clients to solve this problem, some Tier1 operators prefer to simply remove any filters for providers with too large AS-SET.
3. Finally, some Internet providers believe that filters based on AS_PATH are inadequate and, accordingly, do not apply any filtering of prefixes at all.

It is easy to prove that all you need is to find a globally visible prefix without a route object. For example, the network 91.243.129.0/24 does not have any corresponding route-objects in any database , but at the same time it is calmly announced by Megaphone and its Tier1-Upstream.



An example of IPv6 is also easy to find. There is no route6 object for the 2a03: 34e0 :: / 32 network, as seen from NLNOG's IRRExplorer , but again, the prefix 2a03: 34e0 :: / 32 is distributed without difficulty. From this we can conclude that there are no filters between AS12695 and AS31133 (Megaphone), or the filters do not work, and also that there are no filters between Megaphone and Hurricane Electric (AS6939).



This interception once again raised the problem of filtering prefixes at the joints of customers and suppliers. Of course, you can blame all the blame on AS39523 , but without customized filters at the interfaces between transit operators, we are doomed to see such incidents again and again. We strongly recommend all transit operators to double-check their filtering policies by at least implementing prefix-based BGP filters on all client connections.

Just a week ago at the Moscow Peering Forum, Alexander Azimov, head of the Radar.Qrator project, presented a report on this topic - you can follow the link to listen to the report and get more information about how the lack of filters becomes a security hole, allowing conduct successful MiTM attacks even on encrypted traffic.

Special thanks to Job Snijders from NTT Communications for their help in preparing this publication.