In this article we are looking in some more detail at BGP leak in Indonesia and illustrate how RIPEstat visualisations can help to assess the impact.
Wednesday evening a misconfiguration by Indosat (AS4761), one of Indonesia's largest service providers, caused AS4761 to start announcing prefixes which were not allocated to them. A report released by BGPmon on Thursday mentions over 400,000 affected prefixes. In this article we discuss how the event was seen by RIPE NCC's routing information service ( RIS ) and demonstrate how RIPEstat visualisations can help to assess the impact.
Usually, AS4761 announces in the order of 300 IPv4 prefixes and 15 IPv6 prefixes. These routes have been reasonably stable in the last week, only limited activity was recorded in RIS for the AS. On the evening of 2 April 2014, however, RIPEstat shows an explosion in BGP activity. Between 18:00 UTC and 21:00 UTC, the RIS route collectors recorded a total of 3.8 million updates with origin AS4761.
Compiling the list of all prefixes avertised in these updates from AS4761, we find a grand total of 10,635 unique prefixes announced by AS4761 between 18:00 and 22:00 UTC. This is significantly less than the 417,038 new prefixes reported by BGPmon . However, that does not necessarily imply our results are incompatible. RIS has a different set of BGP peers than BGPmon. When two different ASes announce the same prefix from different locations, it really depends on topology and a peer's local policy which of the two routes is selected and propagated further. Also, the BGPmon report mentions 8,182 of the 400,000 prefixes were more widely seen, by at least 10 peers ('probes' in BGPmon terminology). So for 98% of the affected prefixes the impact in BGP was minimal, the unauthorised announcements did not reach very far.
As in BGPmon, the impact of the event in RIS differs per prefix. For many it was only a handful of RIS peers announcing the new routes, for others it was all but a few peers who preferred the route from AS4761. Figure 2 shows the distribution, the number of prefixes with origin AS4761 observed by a given number of RIS peers.
As an example of an almost fully 'hijacked' prefix, the BGPlay screenshot in Figure 3 shows the state for 18.104.22.168/19 at 19:52:27 UTC. At that moment just 4 out of 101 RIS peers observing the prefix prefered the route with the legitimate origin, AS42334. All others had selected the route injected by Indosat's AS4761.
Playing the example from start to end suggests this misconfigured announcement came in waves. Starting at 18:27 UTC the first peers switch to the route from AS4761. 4 minutes later all but 5 peers prefer the route with this new origin. In the next 2 minutes the situation restores to normal, all but 2 peers switching back to routes with origin AS42334. Another 24 minutes later the wrong announcement from AS4761 is back, peers again preferring these routes. This time it lasts for 30 minutes. Next we see the original state from 19:27 to 19:37 UTC, folllowed by various other switches back and forth between hijacked and original state in the subsequent hour. Finally at 20:43 UTC the situation stabilizes, no more unauthorised announcements were observed for this /19 since.
In sharp contrast to the /19 mentioned above, is the situation for 22.214.171.124/24. In RIS the announcement from AS4761 only is seen by 4 peers. BGPlay shows the abnormal activity in RIS for this prefix was relatively short lived, from 18:47 to 19:07 UTC. The screenshot in Figure 4 demonstrates how BGP topology for this /24 is much simpler, sees fewer hops, fewer transit providers to the RIS peers. That causes most peers to prefer the original route over the route from Indosat.
Although most of the prefixes had limited reach, the impact was significant for networks whose prefixes spread widely. The RIPEstat country routing statistics for Idonesia (Figure 5) show a clear drop in AS numbers. These ASes may have been completely unreachable during the event.
Finally we would like to stress that RPKI and BGP Route Origin Authorisations (ROAs) can provide an adequate protection against accidents like this. When a peer receives updates for a prefix from two different origin ASes, the presence of a ROA can help decide which of the two routes to prefer and install in the BGP routing table.