What ROV Blocked, What ASPA Still Can't — the June 2026 Telegram Hijack and the Next Layer of Routing Security

• Introduction — The Day a National Block Crossed a Border
• What ROV Actually Did, and Where It Hits Its Ceiling
• Route Leaks — An Attack Where the Origin Is Legitimate
• How ASPA Actually Works — Up-Ramp and Down-Ramp
• July 10, 2026: The ASPA Stack Enters Last Call
• So How Much Is Actually Deployed Today — I Counted It Myself
• Unknown Is Effectively Valid — The Arithmetic of Partial Deployment
• The Limits the Spec Itself Admits
• Implementations Have Existed for Three Years Already
• So What Should You Actually Do Now
• Closing
• References

Introduction — The Day a National Block Crossed a Border

On June 16, 2026, the Indian government ordered Telegram blocked. Organized cheating channels around the NEET medical-entrance re-exam had become a problem, and an order came down under Section 69A of the IT Act to block it by June 22. So far, this isn't a routing story.

The problem was how the block was carried out. Indian telecom Rcom (AS18101, Reliance Communications — not Reliance Jio) chose to directly advertise Telegram's IP ranges over BGP to pull in the traffic and drop it into a black hole. According to an analysis of the BGP data written at the time by Doug Madory of Kentik, starting at 07:17 UTC, AS18101 began originating several of the IP blocks Telegram uses, and that route leaked outside India.

This is a very familiar failure pattern. In Madory's words, it belongs to the class that is both deliberate and accidental at once — a pattern where a domestic block fails to stay inside its borders and spills into the global routing table, with Pakistan Telecom's 2008 YouTube hijack as the archetype. Twitter during Myanmar's 2021 coup, Russia in 2022, Brazil's block of X (AS263276), and Iraq's block of Telegram in August 2023 all had the same shape.

This time, though, one number stood out. By Kentik's measurement, of the hijacked path for 91.108.4.0/22 — which Telegram (AS62041) normally originates — only 1.6% of Kentik's own BGP sources saw it. Madory wrote that this was likely owing to the fact that Telegram had ROAs on all of its routes, letting networks drop the RPKI-invalid path.

This figure is a vendor's own measurement against Kentik's own BGP sources, and I'm carrying over, as-is, the fact that Madory himself did not assert causation and wrote "likely." Even so, the direction is clear. RPKI ROV is a defense that actually worked in 2026.

Starting from that incident, this post looks at exactly what ROV actually blocked and where it hits its ceiling, and how far ASPA — aimed at what lies beyond that ceiling — has come as of July 2026. The fundamentals of BGP, AS, peering, and RPKI were already covered in The Complete Guide to BGP Internet Routing, so here I'll only cover what's new in 2026.

What ROV Actually Did, and Where It Hits Its Ceiling

ROV (Route Origin Validation, RFC 6811) does exactly one thing: it checks "does this AS have the authority to originate this prefix" against what's signed into a ROA (RFC 9582). The moment AS18101 originated the Telegram prefix under its own name, the origin no longer matched, so a router running ROV judges the route invalid and drops it. That's why propagation stalled at 1.6%.

What actually failed is also public. Indian network researcher Anurag Bhatia, in an analysis he wrote the day after the incident, pointed out that beyond Rcom's mistake, what actually failed was that the upstreams weren't doing RPKI ROV — specifically naming FLAG (AS15412) and Tata Communications (AS4755). His point: since the prefix was signed, if ROV had been deployed, these paths would have been filtered out easily and the hijack would have stayed contained inside AS18101 and its downstreams.

Bhatia wrote that he confirmed, across multiple collectors including RIPE RIS RRC01 in London, that 91.105.192.0/23 started being originated from AS18101 at 16:14:19 GMT (21:44:19 IST). This lines up with Madory's timeline as well — the part where, once Telegram fired off more-specific routes to reclaim its IP space, AS18101 followed suit and hijacked down to those more-specifics starting at 16:14 UTC. Two independent analyses point to the same moment.

But the sentence that really matters in Bhatia's piece is a different one. He argues this wasn't intentional but a "fat finger mistake" (his own personal judgment), and gives this reasoning:

Had this been truly deliberate, the origin ASN would have been left alone, and Telegram's AS211157 would have been forged in behind AS18101. That would have meant RPKI ROV filtering across the transit-free tier-1 layer and various backbones and IXPs would never have triggered at all.

That single sentence draws ROV's ceiling precisely. ROV only looks at the far end of the AS_PATH — the origin. If an attacker leaves the victim's ASN in the origin slot and inserts itself in front, the ROA check passes. Even if the path is completely fabricated, ROV has nothing to say about it. ROV won this time because the attack was clumsy enough to swap out the origin.

Route Leaks — An Attack Where the Origin Is Legitimate

Far more common than a forged-origin hijack is the route leak. RFC 7908, which defines and classifies this phenomenon, describes it in short as a route being re-propagated in a direction it should not have gone. If a customer leaks a route it learned from provider A to another provider B, B learns a route to A through that customer. It's a route that should never exist, but the origin is completely legitimate.

This is the crux of it. In a route leak, the origin is real. The prefix is correctly signed, and the originating AS matches its ROA. ROV will judge this route valid. The judgment isn't wrong — this simply isn't the question ROV was designed to answer. BGP accepts the route, traffic follows it, and an operator watching the routing table sees no signal at all.

A partial defense already exists. The OTC (Only to Customer) attribute defined by RFC 9234 attaches a role to a BGP session and carries a marker meaning "this route is for customers only," detecting and mitigating accidental route leaks. But OTC only works if the AS creating the leak follows the rules itself. If the party at the source is malicious, it does nothing at all — and that's exactly the point the ASPA spec itself acknowledges up front: RFC 9234 addresses accidental route leaks, and ROV addresses accidental mis-origination.

How ASPA Actually Works — Up-Ramp and Down-Ramp

The idea behind ASPA (Autonomous System Provider Authorization) is simple. Just as a ROA signs "this AS originates this prefix," ASPA signs "these, and only these, are my providers." The object itself is minimal — looking at the ASN.1 in the profile draft, its contents are just a single customerASID and a list of provider ASes.

ASProviderAttestation ::= SEQUENCE {
  version       [0] INTEGER DEFAULT 0,
  customerASID      CAS,
  providers         ProviderASSet }

CAS ::= INTEGER (1..4294967295)
ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF PAS
PAS ::= INTEGER (0..4294967295)

Verification is applying the valley-free principle to the AS_PATH. The verification draft takes a COMPRESSED_AS_PATH — the AS_PATH with consecutive duplicate ASNs removed — and holds that a normal path must consist of only two segments: an up-ramp climbing from the origin, and a down-ramp descending toward the receiver. Each hop must be a customer-to-provider relationship. In the spec's own words: if the combined length of the up-ramp and down-ramp is at least N, the AS_PATH is valid (no route leak); if the combined length is less than N, the path has either leaked or the AS_PATH is malformed.

                 AS(L) ............. AS(K)
                 /                      \
                .                        .
  (down-ramp)  .                          .  (up-ramp)
              .                            .
             /                              \
          AS(N)                             AS(1)
           /                              (Origin AS)
  Receiving/verifying AS (AS(N+1))

  Each ramp is a run of consecutive customer-to-provider hops, moving bottom to top

The APNIC example seen earlier (ASPA at APNIC) shows this concretely. AS2 is a customer of both AS1 and AS3, and AS1 has published an ASPA saying "my only provider is AS5." If AS2 accidentally leaks a route it learned from AS1 to AS3, AS3 looks up AS1's ASPA and finds that AS2 isn't listed as a provider of AS1. The route becomes ASPA-invalid and can be rejected.

There's an important property here — this verification does not require every AS along the path to verify. As in APNIC's second example, even if the AS in the middle, AS3, doesn't verify and passes the leak along, AS4 further downstream can still catch it by verifying on its own, discovering that the path moved "provider → customer → back to provider."

July 10, 2026: The ASPA Stack Enters Last Call

That's the design so far — here's the 2026 news. On July 10, 2026, three ASPA-related drafts entered IETF working group last call (WGLC) simultaneously. Querying the document events on the IETF Datatracker directly confirms all three changed to "IETF WG state changed to In WG Last Call from WG Document" at 13:20–13:21 on the same day.

The third one matters especially. RTR (RPKI-to-Router) is the channel through which a validator hands RPKI data to a router, and carrying ASPA payloads requires RTR version 2. In other words, ASPA needs all three layers — the object profile, the verification procedure, and the delivery protocol — standing at once, and all three entered last call on the same day.

Comparing this against predictions from late last year shows how much progress this is. Job Snijders wrote in his RPKI 2025 year in review, published in February 2026, that "working group last call is close! With luck, the specs could be published by the end of 2026." Last call actually started five months after that.

That said, it is not an RFC yet. In the Datatracker, all three documents still have an empty rfc field, and the IESG state is "I-D Exists" — the stage where the IESG hasn't even begun processing them. Last call is only a working-group-internal step; IESG review and the RFC Editor queue still lie ahead. Early reviews are already coming in — on July 15, 2026, an ARTART review closed as "Ready with Nits" and a BGPDIR review closed as "Almost Ready."

And on the RIR side, publication capability has already opened up. RIPE NCC added ASPA to its RPKI dashboard on December 15, 2025, and ARIN announced in its January 20, 2026 release notes that "ARIN's implementation of Autonomous System Provider Authorizations (ASPA) is now fully available in ARIN Online." APNIC, announcing MyAPNIC and Registry API support on July 9, 2026, wrote that RIPE NCC, ARIN, and APNIC had all deployed support since November 2025, and that all five RIRs are expected to support ASPA by the end of 2026.

So How Much Is Actually Deployed Today — I Counted It Myself

If the spec has entered last call and three RIRs have flipped on publication, how far has actual deployment gotten? Better to count than to trust the marketing copy.

As of July 16, 2026, I looked at two independent sources. First, I pulled and directly parsed the ASPA dump from Job Snijders's rpki-client console (page generated Thu Jul 16 13:14:42 2026). Second, I pulled Hurricane Electric's RPKI & ASPA report the same day.

The two sources line up almost exactly.

Two independent tools converge to within 3 objects on the object count and about 200 on the total ASN count. HE.net's own internal arithmetic checks out too — summing ASPA-holding ASNs by RIR (RIPE 1,473 + ARIN 442 + LACNIC 107 + APNIC 100 + AFRINIC 0) comes to exactly 2,122, and 2,122 divided by 87,781 is 2.42 percent.

The core point is the contrast in the last two rows. ROA covers 67 percent of prefixes; ASPA covers ASNs in the low single digits. These are different orders of magnitude.

Breaking it down by RIR shows the rollout order plainly.

RIPE opened first, so it's highest; ARIN comes next; APNIC just opened this month, hence 0.49 percent; AFRINIC doesn't support it yet, hence exactly 0. What's interesting is LACNIC's 107 — per the APNIC post's account, LACNIC hasn't deployed support yet. Looking at the publication points I parsed, these objects come out of rpki-repo.registro.br — because Brazil's NIC.br runs its own CA. That means an org can publish directly via delegated RPKI without waiting for the RIR's hosted service, and in fact a good chunk of the 32 distinct publication hosts I counted were individual organizations running Krill.

The growth rate is real. Job Snijders's year-in-review post has a "Uniq ASPA Customer ASIDs" gauge that went from 87 at the end of 2024 to 556 at the end of 2025 (+539 percent). The unique customer ASes I counted today are 2,393. That's 87 → 556 → 2,393 across a year and a half.

At the same time, the commonly cited figure is already stale. Job's line about "roughly 0.5 percent" is from February 2026, and a RIPE Labs post from as late as end of June 2026 still says "well under 1% of the global ASN space." Measured today with two sources, it's 2.42 percent. The direction is good, but the fact remains that 97.6 percent of ASNs still have no ASPA.

The shape of the objects themselves shows a few things too. Across the 2,394 objects I parsed, there were 7,941 provider entries total — an average of 3.32 per object, a median of 2. Objects listing exactly one provider were the most common, at 718 (30 percent of the total), and the largest listed 204 — AS14789. There were 59 AS0 ASPAs declaring no providers at all. And the verification draft recommends (SHOULD) that "an AS should register a single ASPA object" — of the 2,394 objects, only one AS violated this (AS61574), and even that one turned out to be a university research testbed. The recommendation is, in effect, being followed.

Unknown Is Effectively Valid — The Arithmetic of Partial Deployment

So how much work is ASPA actually doing at 2.42 percent coverage? Reading the spec gives the answer. And this is the most important part of this post.

ASPA verification produces one of three outcomes — Valid, Unknown, Invalid. How these three are split apart is decisive. Section 5.2 of the verification draft defines a provider-authorization function that, for a pair (AS x, AS y), returns one of three results: "No Attestation" if AS x has no ASPA or an invalid one, "Provider+" if an ASPA exists and AS y is on the list, and "Not Provider+" if one exists but AS y is not on the list.

And Section 5.3 defines the upper and lower bounds on ramp length like this:

• max_up_ramp: up to the point where "Not Provider+" first appears. In other words, a hop with no ASPA is optimistically included in the ramp.
• min_up_ramp: up to the point where either "No Attestation" or "Not Provider+" first appears. In other words, if there's no ASPA, it stops right there (pessimistic).

The verdict then splits like this.

max_up_ramp + max_down_ramp < N   ->  Invalid
min_up_ramp + min_down_ramp < N   ->  Unknown   (insufficient information)
otherwise                         ->  Valid

There's a conclusion that falls out of this. For a verdict of Invalid, someone has to have published an ASPA, and that ASPA has to explicitly deny the hop in question. If an ASPA simply doesn't exist, that's "No Attestation," which never trips the max calculation — so it can never become Invalid. The result is Unknown.

And Section 5.6's recommended relaxation policy goes like this — if Invalid, exclude the route from path selection (but keep it in Adj-RIB-In for re-evaluation). But a route evaluated as Unknown should (SHOULD) be treated at the same preference level as Valid.

Put these two together and you get today's reality. Coverage of 2.42 percent means that, at any given AS_PATH, the odds that the AS at the exact hop where a leak happened had published an ASPA are low. So the verdict comes back Unknown, Unknown is treated like Valid, and nothing happens. RIPE Labs's ASPA Is Live. Can You See It Working? reaches the same conclusion running an actual RPKI-data lab — most routes come back Unknown, not because the routes are suspicious, but because most operators simply haven't registered ASPA objects yet.

This isn't a bug — it's the design. Under partial deployment, being this conservative is exactly what's needed to avoid killing perfectly fine routes with false positives. ROV walked the same road. In exchange, the cost is clear — turning ASPA on gets you almost no protection right now, today. The payoff comes once coverage builds up.

The Limits the Spec Itself Admits

Plenty of write-ups sell ASPA as a silver bullet for route leaks, but the spec itself is fairly honest about its own limits. Worth reading.

It can't catch a provider hijacking its customer. Section 7.3 states that a provider can hijack a direct or indirect customer's prefix with a forged-origin or forged-segment AS_PATH, and can also manipulate the AS_PATH of routes sent to its customer — and such attacks may go undetected by ASPA. The spec's defense here isn't technical, it's contractual — it argues this isn't a realistic scenario even though theoretically possible, and that customers and providers usually have a signed contract, so this kind of policy violation either has legal consequences or the customer can simply end the relationship and delete the ASPA record. Whether that's convincing is up to you, but it's worth knowing that part of the threat model has been pushed off onto a contract.

It can't catch AS_PATH prepend manipulation. Section 7.4 — the ASPA verification procedure cannot detect the removal or addition of repeated AS number instances in the AS_PATH. The spec adds, though, that this particular attack doesn't affect route-leak detection capability itself.

It can't stop a leak the AS itself initiates. Section 8.4 states explicitly that ASPA-based verification detects and mitigates route leaks created by ASes earlier in the AS_PATH, but it cannot stop the local AS from initiating a leak to its own neighbor. Complex relationships along a path can also cause leak detection to fail. The spec notes that this is why the OTC attribute (RFC 9234) fills that gap, and recommends (RECOMMENDED) implementing the OTC procedure to complement ASPA verification. ASPA is a companion to OTC, not a replacement for it.

A wrong ASPA hurts you in both directions. Section 7.2 — omitting a provider reduces leak-detection capability, and including a provider that's wrong can later cause a perfectly good route to come back ASPA-invalid. That's why Section 4 recommends registering standby providers, like a DDoS-mitigation vendor, or emergency-only providers, ahead of time — to avoid a race condition between ASPA propagation and route propagation. Operationally, this is the most painful part — right at the moment you want to reroute traffic during an emergency, a route through a provider you never registered dies as Invalid.

IPv4/IPv6 asymmetry gets flattened toward the permissive side. Section 7.1 — because the provider set is managed jointly across IPv4 and IPv6, a customer-provider relationship that exists on only one address family ends up looking like it's permitted on the other as well. The spec calls this a "reasonable compromise," made in exchange for simpler registration and verification and no false positives.

Implementations Have Existed for Three Years Already

The reason deployment hasn't happened isn't a lack of code.

• OpenBGPD supports ASPA from 7.8 onward, per the verification draft's implementation-status section. Checking the openbgpd-portable tags on GitHub, 7.8 shipped on February 3, 2023 — three years and five months ago.
• BIRD, per its own NEWS file, added "ASPA support in filters, Static and RPKI" in 2.16 (2024-12-04), followed by a parser bug fix in 2.16.1, AS_SET handling in 2.18 (2025-12-26), and a downstream-verification fix in 2.19.0 (2026-05-25). This means it's under active maintenance.
• Routinator (NLnet Labs) added ASPA and RTR version 2 support in 0.13.0, and it's been compiled in by default since 0.14.1 (2025-01-22). Even so, it still has to be explicitly turned on with --enable-aspa — the official docs still list ASPA under "Advanced Features," with the caveat that it's based on "two Internet-Drafts currently at the IETF."
• Commercial vendors — not yet. What the verification draft records is Cisco's IOS-XR-based Early Field Trial implementation from 2025, plus RTRlib, NIST-BGP-SRx (no IXP/RS extension support), and FreeRTR. APNIC wrote that "several commercial vendors have released or are developing support" but didn't name which ones.

One more thing worth adding: the draft's implementation-status section is itself already stale. The BIRD entry still says it's "on a side branch (mq-aspa), with release expected after RTR v2 is finalized," while BIRD's own NEWS says support has been in releases since 2.16. This isn't a knock on the draft — the section itself states that "no effort has been spent to verify" the information listed there, that it's contributor-submitted, and that the section is explicitly meant to be removed before RFC publication. It does mean, though, that this section shouldn't be read as a vendor-support status table.

To sum up: ASPA verification code has existed in open-source routers since three years ago, and coverage sits at 2.42 percent. The bottleneck isn't code — it's the objects, and the will to actually enforce against them.

So What Should You Actually Do Now

Worth doing right now: publish an ASPA object. This is an asymmetrically cheap move. If I publish an ASPA, the benefit doesn't go to me — it goes to everyone else who verifies my routes (and if my prefix ever leaks, it's also everyone else's validators that catch it). It doesn't require flipping anything on in my own router, and it has no effect on my own traffic. If you're a member of RIPE NCC, ARIN, or APNIC, it's a dashboard action. Even if you're not one of those three, the registro.br case above shows you can publish through delegated RPKI. Watch out for what's noted above — don't forget standby or emergency providers, keep it to one object per AS, and build an operational routine to update it whenever your provider relationships change. An ASPA you forget to update ends up killing your own routes later.

No need to rush yet: turning on rejection of ASPA-invalid routes. At 2.42 percent coverage today, turning this on buys you almost no defense, while the risk of killing a perfectly fine route because of a badly registered ASPA is real. On top of that, the spec still isn't an RFC, and the last-call review just came back "Almost Ready." RTR v2 is in the same queue. Watching from logging mode (Section 6.6 covers logging separately) while coverage climbs is the right fit for this stage.

Still a high priority: ROV. The evidence for that is this post's own starting point. In the Telegram incident, the actual damage was done by the upstreams that weren't doing ROV, and the damage was stopped by everyone else who was. ROA coverage is 67 percent; ASPA is in the low single digits. If you haven't enforced ROV yet, do that before you even look at ASPA. And look at RFC 9234's OTC alongside it — the ASPA spec itself recommends OTC as a complement, OTC is already an RFC, and it's the only layer that stops you from being the one who starts a leak against someone else.

ASPA might not be your problem at all. If you're a stub AS with a single upstream, publishing takes a few minutes (a single-provider ASPA — 30 percent of all objects today look exactly like that), and there's not much reason to run verification yourself. Verification pays off for networks that take routes from multiple peers and multiple transits.

Closing

The Telegram incident of June 2026 is evidence that RPKI ROV actually works. By Kentik's measurement, the hijacked route only reached 1.6 percent of its own sources, and both Madory and Bhatia point to Telegram's ROAs and upstream filtering as the reason. Compared to the Pakistan-YouTube incident of 2008, the internet has clearly gotten better.

At the same time, that same incident shows the ceiling. As Bhatia pointed out, ROV won this round because the attack was a clumsy one that swapped out the origin. Had the origin been left alone with the attacker inserted in front, ROV would have stayed silent — and a route leak, by nature, keeps the origin legitimate, so it was never going to trip ROV's question in the first place.

ASPA is the next layer aimed at that gap, and 2026 is the year that layer took shape — three drafts entered last call on July 10, three RIRs opened publication, and all five are expected to be open by year's end. The implementation has existed in OpenBGPD for three years.

Yet counted today, it's 2.42 percent. And by the structure of the verification algorithm, low coverage means the verdict comes back Unknown, and Unknown gets treated the same as Valid. In other words, ASPA, even switched on right now, still blocks almost nothing. That's not a failure — it's simply how this kind of technology gets deployed. ROA started at 87 objects too, and now covers 67 percent of prefixes.

So the conclusion is unglamorous but clear. Publish now, don't enforce yet, and take care of ROV and OTC first. And before you cite any number, count it yourself as of today — while the phrase "well under 1%" keeps showing up in posts even in the second half of 2026, what two independent sources measured today came out to 2.42 percent.

References

• When Local Blocks Go Global: The India-Telegram BGP Incident — Doug Madory, Kentik
• Telegram prefixes hijack by Rcom AS18101 — Anurag Bhatia
• draft-ietf-sidrops-aspa-verification — BGP AS_PATH Verification Based on ASPA Objects
• draft-ietf-sidrops-aspa-profile — A Profile for Autonomous System Provider Authorization
• draft-ietf-sidrops-8210bis — The RPKI to Router Protocol, Version 2
• RFC 9234 — Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
• RFC 7908 — Problem Definition and Classification of BGP Route Leaks
• RFC 6811 — BGP Prefix Origin Validation
• RFC 9582 — A Profile for Route Origin Authorizations (ROAs)
• ASPA at APNIC: Strengthening BGP path validation — APNIC Blog
• RPKI's 2025 year in review — Job Snijders, APNIC Blog
• ASPA in the RPKI Dashboard — Tim Bruijnzeels, RIPE Labs
• ASPA Is Live. Can You See It Working? — Ritesh Mukherjee, RIPE Labs
• New Features Added to ARIN Online (2026-01-20)
• The RPKI Console — ASPA object dump
• Hurricane Electric — RPKI & ASPA Adoption Report
• Routinator — Advanced Features (ASPA)
• The Complete Guide to BGP Internet Routing — AS, Peering, Path Selection, RPKI (related post)