Summary

  • In a 2025 case revisited at APNIC 62, a SEACOM looking glass showed the legitimate SingNet /16 and no unauthorized Innove /24. A traceroute from SEACOM nonetheless crossed TISparkle and reached hops in Innove’s AS.
  • ROV judges a route’s origin and local policy can reject it. It cannot force the next AS to reject a more-specific route or prove what packets do after leaving the local router.
  • BMP can preserve selected pre- and post-policy BGP views at a monitored router. It does not see a route known only to an unmonitored neighbor, nor does it by itself measure the forwarding path.

The empty line in one table

The telling result was not a red alert. It was an empty answer. Researchers queried a SEACOM (AS37100) looking glass for 203.127.225.0/24; it replied that the network was not in the table. A query for the covering 203.127.0.0/16 showed a valid path ending at SingNet (AS3758). On that control-plane evidence, the local route-origin filter appeared to have done its job.

Then the researchers ran a traceroute from the same network toward an address inside the /24. The returned hops crossed TISparkle (AS6762), FLAG Telecom (AS15412) and Globe Telecom (AS4775), then reached addresses attributed to Innove Communications (AS17894). The original looking-glass outputs reproduced in Li and colleagues’ April 2026 Internet-Draft make the contrast inspectable: one network had no route for the invalid more-specific, yet the observed path went toward its origin. The draft says the case was reported to Globe on 10 February 2025 and last observed on 24 April. It calls a benign configuration mistake likely; it does not establish malicious intent. A traceroute to one address is not a census of all user packets or a proof that the endpoint application answered.

At APNIC 62 in Mumbai, Nokia’s Ritesh Mukherjee put this case alongside other routing incidents under a “good neighbor” question. APNIC’s session account and his presentation advocate ROV, path-validation work, BGP monitoring and peer-level hygiene. Their most useful lesson is a limit on the word protected. A correct decision at AS37100 did not govern AS6762.

Where the /24 reappeared

SingNet originated the legitimate /16. Innove announced a more-specific /24 with an origin not authorized for that space. SEACOM’s ROV rejected the invalid /24, so its own table could select a route for the covering /16 toward TISparkle. But TISparkle did not apply the same rejection. At that next network, the /24 could be selected over the /16 by longest-prefix matching. Thus a packet can leave a router that never installed the /24 and encounter the narrower route later. It is a sequence of local decisions, not a contradiction in BGP.

RFC 6811 defines Valid, Invalid and NotFound origin states against validated ROA payloads. Whether to reject an Invalid route is explicitly local policy. The state does not authenticate the whole AS path; a ROA is neither a forwarding instruction nor a remote enforcement order. In the 2025 case, the independent draft’s looking-glass and traceroute pair supports a narrow claim about one observed path at one time. It does not reveal TISparkle’s full configuration, the whole forwarding table, the cause of Innove’s announcement or the experience of every downstream customer.

The other APNIC 62 example has a different evidentiary shape. On 16 June 2026, Telegram prefixes appeared with Reliance Communications (AS18101) as origin. BGPHorizon’s reproducible collector reconstruction records 91.108.4.0/22 at 07:17:27 UTC, expected origin AS62041, with observations from four peer networks across five collectors, and a later more-specific wave. Its source paths include AS15412. Telegram’s covering authorizations made the observed origin invalid, but collector peers expose only their own slices of propagation. Neither those updates nor the APNIC slides prove a political motive, the number of affected users or exactly which packets were delivered where. The 2021 Vodafone Idea mass-announcement example concerns yet another control: a per-session prefix ceiling might contain volume without deciding the legitimacy of a single /24. Combining the cases into one undifferentiated “routing attack” obscures which lever belongs to whom.

What a monitor is entitled to say

Mukherjee recommends BMP observation at Adj-RIB-In and discusses Nokia’s RAVEN tool. RFC 7854 gives a monitored router a structured way to export BGP routes before policy, after policy, or both, including snapshots and updates for configured peers. A pre-policy feed can show an offered route that a post-policy view rejects—if that peer, stage and interval are actually included. Implementations may monitor only some peers, compress intermediate changes and omit a usable source timestamp. A clean post-policy feed therefore is not evidence that nobody offered the route; a complete local pre-policy feed still is not a window into a route received exclusively by AS6762.

Nor is BMP a data-plane probe. A BMP collector at AS37100 can report what AS37100 saw. It cannot read AS6762’s decision or its FIB without cooperation or a separate vantage. Active traceroute, carefully scoped packet tests and neighboring operator records address different questions. The slide deck’s RAVEN output is explicitly illustrative, and the product repository describes capabilities, not measured deployment or the prevention of this case. Its claim of a “data-plane hint” cannot substitute for packet evidence. A sound incident record labels the router, peer, address family, RIB stage, snapshot epoch, collector gap, route validity at that time, selected next hop and active-path result separately.

ROV enforcement at more networks would reduce the particular gap. RFC 7454 also recommends maximum-prefix controls on a peering session, with limits appropriate to expected route counts and growth; that circuit breaker addresses floods, not one deceptive sub-prefix. ASPA’s provider-relationship validation remains work in progress, not a retrospective receipt that the 2025 route was stopped. The prevention, observation and path-verification tools are complementary only when their distinct claims remain distinct.

Sources and limits

The decisive case evidence is Li et al.’s individual Internet-Draft, section 4 and Appendix A, which is not an IETF-approved standard. The meeting account and speaker’s slides explain the presentation; BGPHorizon supplies an independently inspectable Telegram routing reconstruction. Mechanism boundaries come from RFC 6811, RFC 7854 and RFC 7454. No source here supplies universal traffic loss, operator intent, a current ROV deployment census or evidence that the featured monitoring product protected these incidents.