Telegram BGP hijack due to weird blackholing config

ISP-Column

Since the Telegram’s prefix hijack (4 days ago on 17-Jun-2026) by RCom, there is visible noise in the BGP routing table from multiple other Indian ISPs, including Tata Teleservices (AS45820) / Lightstorm (AS135709/AS152144), etc. mostly in IPv6.

Let’s look at 2a0a:f280::/48 (Live lookup here)

Notice all the ASNs here largely seem to be downstreams of AS45820 in India, no major large peer or upstream that would take this announcement outside of India. Similarly, take the case of aggregate - 2a0a:f280::/32. This has TTSL (AS45820) as well as Lightstrom (AS152144/135709) originating these prefixes to smaller peers.



Analysis: Possible reason and impact of this behaviour

Today I tested some config in lab to see why this could be happening. Here’s what I strongly feel is happening (quite sure, unless someone has a better explanation):

  • Indian Govt. has asked ISPs to block Telegram and unlike past blocks mostly at the DNS layer, ISPs have been asked to drop IPs as well.
  • Technically in these cases ISPs could simply add a blackhole route and that would drop traffic going towards these prefixes (from their customers) and that would not be visible at BGP (control plane) but only in traceroutes (data plane). If any of these customers had a full routing feed from those respective ISPs, they would keep on learning Telegram’s route with the correct/expected AS_PATH and expected origin AS.
  • Very likely these players had blackhole config setup for the DDoS protection and ended up using the same i.e they are treating Telegram’s IPv6 prefixes like they would treat their own when under attack.
  • Also, blackholing is a common practice during DDoS attacks. Imagine a network with a 100G uplink gets hit by a 400G volumetric attack. It will take up all the link bandwidth and thus in these cases ISPs blackhole their own (or downstream) IPs (often small - single /32s or a few) and they signal this to their BGP adjacencies as well. There is a standard BGP blackhole community: 65535:666 as defined in RFC7999.
  • To make things worse - RPKI RoV usually excludes RFC7999, so this would not be easy to catch with RPKI as well for networks that support blackholing with these ASNs.
  • Normally ISPs are not supposed to blackhole and BGP announces the blackhole unless it’s their own or downstream prefix where they have an understanding with downstream to do it (or downstream triggers it) to protect other IPs which are not under the attack. It’s incorrect for some Indian ISPs to be blackholing and BGP originating the blackhole to their adjacencies. The effect of this so far has been harmless because these are just going to the customers, however it’s not ideal.
  • It can still create unexpected complications. Lightstorm for instance also has customers outside of India (Nepal) where Telegram is not blocked. By “BGP originating” blackhole, they would end up in creating a short AS_PATH (and hence usually preferred unless their customer de-pref it) by their multi-homed users steering traffic towards them and then drop it (as blackhole exists). Also, while they are originating /32, but if they originate a smaller more specific one that would also end up in steering traffic which is not needed otherwise.

Note

  • Check out this discussion on X with my friend Bryton Herdes here
  • Also, Bryton / Cloudflare talk at Chicago NOG last month on how remote-triggered blackhole can bypass RoV - False immunity: long prefixes that bypass ROV: Slide and Video

Disclaimer: This is my personal blog, and hence, posts made here are in my personal capacity. These do not represent the views of my employer.