Born to intercept traffic

New Internet providers appear literally every day, and December 12, 2017 was no exception. A newcomer to the cross-domain routing ecosystem, AS39523 (DV-LINK-AS), began announcing 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.

Due to the specific set of services affected by the incident, we can assume that static routes flowed into BGP. However, the main question is why did these incorrect announcements 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 (Megafon), 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 inbound filters at the joints of operators of the client-supplier type:

1. Some transit operators cannot convince their customers to create the correct route objects. Since the client pays money for the service, some Internet providers do not consider it necessary 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 AS-SET! There are Internet providers who will have thousands of prefixes in their AS-SET object, with only a couple of dozens really related to their client cone. This situation only worsens closer to the core of the Internet, where large Tier2 networks can have AS-SETs, inflated to hundreds of thousands of records. 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-SETs.
3. Finally, some Internet service providers believe that filters based on AS_PATH are inadequate and, therefore, do not apply any prefix filtering at all.

It is easy to prove that all that is needed 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 quietly announced by Megafon and its Tier1 upstream.



An example from IPv6 is also easy to find. There is no route6 object for the 2a03: 34e0 :: / 32 network, which can be seen from NLNOG's IRRExplorer , but again the 2a03: 34e0 :: / 32 prefix 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 the AS39523 , but without the filters configured at the junctions between transit carriers, we are doomed to see such incidents again and again. We strongly recommend that all transit operators recheck their filtering policies by at least implementing prefix-based BGP filters on all client connections.

Just a week ago, at the Moscow peer-to-peer forum, Alexander Azimov, head of the Radar.Qrator project, presented a report on this topic - you can click on the linkin order to listen to the report and get more information about how the lack of filters becomes a security hole that allows for successful MiTM attacks even on encrypted traffic.

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