Indian backbones need AS_PATH filters

isp-Column

The security of India’s routing infrastructure is something that isn’t discussed as much as cybersecurity, software vulnerabilities, etc. Part of the blame for that has to go to our industry, which is relatively closed when it comes to sharing incidents and also lacks good documentation on the deployment side of things. Some of these things came to light after the RCom (AS18101) BGP hijack of Telegram prefixes in June 2026. One silent problem for a long time has been route leaks.


BGP route leak

Route leaks happen when a network ends up announcing a route to a BGP adjacency where it is not supposed to announce that route. Take, for example, a network “leaking” routes learnt from a peer to transit, or vice versa. One can filter downstreams which are small, but it’s very hard to filter large downstream networks which have further downstreams, or if one is far removed from that ASN. IRR AS-SETs exist for this reason, but they have not worked well due to tooling challenges. Furthermore, IRR (Internet Routing Registry) by design is a public register where one “publishes intent” before actually doing that in BGP, and then anyone can match the intent with the state in BGP. New tech ASPA will help address this issue, but it’s new, vendor support is still in the development phase and it will take its own adoption time.


AS_PATH filters / Peer lock

This is older tech which can play a very effective role in controlling leaks. If network A decides to peer with network B, they both can agree to announce all routes to each other over the peering & agree to reject each other’s ASN from all other BGP sessions. It’s a common practice between large transit-free Tier-1 networks as well as major backbones and is often referred to by the fancy name of “peer lock”. In India, I doubt backbones like Airtel, Jio, and Tata Comm can have AS_PATH filters rejecting each other from everywhere except direct sessions because there is some indirect routing visible all the time. It could be because of cold potato routing design or peering capacities.

Most of the leaks which these networks learn are not from their other large peers or upstreams but actually from smaller downstreams. Let’s look at an example of ongoing leaks right now:

PrefixAS_PATHReason
103.166.14.0/24 & 103.166.15.0/249498 134674 134674 4755 17762 141846 141846Tata Play broadband AS134674 learning route from its upstream Tata Comm and leaking it to Airtel
103.126.170.0/244755 17426 9498 138282PRIMENET AS17426 leaking Airtel route to Tata Comm
163.128.230.0/234755 134674 9498 154622Tata Play broadband AS134674 leaking Airtel route to Tata Comm
185.228.168.0/244755 45815 9498 20473 205157ESDS AS45815 leaking route learnt from Airtel to Tata Comm
103.146.120.0/24 & 103.154.251.0/244755 136306 9498 45942 140114 140114Texes Connect AS136306 leaking Airtel route to Tata Comm

All these leaks reach transit free / tier 1 networks and thus the larger internet. While these are small ones, the ability for larger leaks is there and they can impact a lot.


Take, for example, this leak reported on 28 May 2026 by friends at Qrator:

In this case AS21859 was able to leak 1,334 routes from Tata Comm to Airtel because Airtel’s filters accepted them.

What we logically need is basic AS_PATH rejection towards downstreams of Airtel, Tata Comm, Jio, Vodafone Idea, BSNL, Sify, etc., rejecting everyone else from their downstream side. That would kill 90% of these leaks, as they would be very localised. So something like this towards customer-facing sessions:

policy-options {
 as-path Large-Indian-ASNs "_(9498|4755|55836)_";

 policy-statement REJECT-LARGE-ASNS {
 term BLOCK {
 from {
 as-path Large-Indian-ASNs;
 }
 then reject;
 }

 (...Existing rules...)

 term ACCEPT {
 then accept;
 }
 }
}

Happy routing! 😀