QUIC Responses as a Topology Oracle: What Backscatter Reveals About Hypergiant Infrastructure

The companies that carry most of the internet’s traffic operate infrastructure that is deliberately difficult to measure from the outside. Google, Cloudflare, Meta, Akamai, and a handful of others collectively called hypergiants announce thousands of IP prefixes, deploy servers on every continent, and route traffic through anycast so efficiently that a packet from Tokyo and a packet from Frankfurt headed to the same IP may never touch the same physical machine. This opacity is partly by design. Operators do not publish the topology of their points of presence, and standard measurement techniques struggle to see through anycast routing to the physical infrastructure underneath.

A recent post on the APNIC blog describes a technique that cuts through this opacity in a non-obvious way: using QUIC backscatter to passively infer deployment configurations. The approach is elegant precisely because it exploits a property of the QUIC protocol itself, rather than relying on active probing from distributed vantage points.

What Backscatter Means in This Context

Backscatter, in the network measurement sense, refers to unsolicited response traffic. The classic form comes from DDoS attacks: when an attacker floods a victim with TCP SYN packets spoofed to appear from addresses in a network telescope’s space, the victim sends SYN-ACK replies back to the telescope. Researchers at CAIDA and elsewhere have used this phenomenon for years to measure global DDoS activity without being anywhere near the attack or the victim.

The same logic applies to QUIC, but with a twist that makes it more informative. When a QUIC client sends an Initial packet to a server, it includes a version field and a Destination Connection ID. If the server does not support the advertised QUIC version, RFC 9000 requires it to send a Version Negotiation packet back to the source address. Critically, this response is stateless: the server generates it without establishing any connection context. Send a QUIC Initial with a spoofed source IP pointing at a network telescope, and the Version Negotiation packet lands in the telescope regardless of where the server is or how it is routed.

This is the primitive the researchers exploit. A network telescope is a large block of routed but unoccupied IP space. Any traffic arriving there is anomalous by definition. By spoofing Initial packets to appear from telescope addresses and directing them at hypergiant IP ranges, the researchers can observe all QUIC responses that arrive at the telescope, with full visibility into which IP the response came from and what it contains.

The Connection ID as a Routing Oracle

Version Negotiation packets are useful on their own, but the real signal comes from the Server Connection ID (SCID) embedded in QUIC responses. QUIC connection IDs are not opaque tokens; in practice, large deployments use them to encode routing information so that load balancers can forward packets to the correct backend without maintaining per-connection state. This design is formalized in RFC 9484 (QUIC-LB), which specifies how connection IDs should encode a server ID and a nonce:

+----------+------------------+-----------+
| config   | server ID        | nonce     |
| (2 bits) | (variable bytes) | (padding) |
+----------+------------------+-----------+

The server ID portion is stable per backend and can be decrypted with a shared key known to all load balancers in a deployment. From an external observer’s perspective, even without the key, the structure produces a useful property: probes that hit the same backend will produce SCIDs with the same encrypted server ID, while probes that hit different backends will produce SCIDs that differ in a consistent bit range.

By sending many probes to a target prefix and clustering the returned SCIDs, a researcher can count distinct server IDs and estimate the number of physical backends. By comparing SCIDs returned from probes sent at different times or from different source addresses (which may route differently under anycast), they can determine whether multiple backends are fronted by the same anycast prefix or separate ones.

Distinguishing Anycast from Unicast

Anycast detection has historically required either access to multiple globally distributed vantage points or cooperation from the operator. The standard active technique, described in “Anycast in Context” (IMC 2021), involves measuring RTT variance and traceroute path diversity from many locations and inferring whether different vantage points hit different physical servers.

Backscatter sidesteps the vantage point problem. Because the telescope receives responses regardless of where they originate physically, a single telescope can observe responses from every PoP that handles traffic addressed to a given prefix, as long as those PoPs see the probe. An anycast prefix will generate responses with diverse SCIDs and potentially diverse TTLs, reflecting different physical distances from the target ranges. A unicast prefix will produce consistent SCIDs and a tighter TTL distribution.

This is a significant improvement in measurement efficiency. Active probing at scale requires either a large botnet of vantage points (which raises ethical and operational concerns) or cooperation with IXPs and network operators. A single telescope with a large address block can observe hypergiant responses passively and continuously.

What the Infrastructure Actually Looks Like

The findings from this technique align with and extend what previous work has suggested about hypergiant deployments. Providers like Cloudflare operate over 300 PoPs globally and use anycast extensively for their authoritative DNS, DDoS scrubbing, and CDN services. Google’s infrastructure is similarly distributed, with deep peering into ISPs through programs like Google Global Cache.

What backscatter adds is the ability to observe this distribution continuously and at the prefix level, without relying on self-reported data. Operators publish high-level topology information, but they rarely disclose per-prefix anycast scope, the number of backends behind a given prefix, or how that configuration changes over time. QUIC backscatter can capture configuration changes as they happen, making it possible to track rollouts, failovers, and geographic expansion in near real time.

For the research community, this is valuable for longitudinal studies of internet centralization. A small number of hypergiants now carry a disproportionate share of global traffic, and understanding how their infrastructure is deployed and changes over time informs policy discussions about resilience and concentration risk.

Limitations and Countermeasures

The technique has real limitations. It works best for services that respond to QUIC Version Negotiation or Stateless Reset, which means it covers HTTP/3 endpoints but not services that run QUIC only over specific ports or that drop probes from unrecognized addresses. Some deployments may also generate SCIDs that do not follow the QUIC-LB structure, either because they use proprietary load-balancing schemes or because they embed different metadata.

Operators could also mitigate this entirely by not responding to Initial packets from unrecognized address ranges, or by using random SCIDs with no routing structure. Whether this tradeoff makes sense depends on how much they value load-balancer statefulness versus infrastructure opacity. For most hypergiants, the operational benefit of structured SCIDs likely outweighs the measurement surface.

A New Passive Measurement Primitive

What makes this work interesting beyond the specific findings is what it represents methodologically. QUIC was designed to be a better transport protocol, and it largely succeeds at that. But the design choices that make it operationally efficient, stateless responses, structured connection IDs, version negotiation, also create a new measurement primitive that was not available with TCP.

Prior passive measurement techniques that exploited protocol design included TCP ISN analysis for OS fingerprinting, TTL-based hop counting, and IPID sequencing for idle scanning. QUIC adds connection ID structure to this list. As HTTP/3 adoption continues to grow (currently serving roughly 30% of web traffic globally according to W3Techs), the measurement surface grows with it.

For anyone building network measurement tooling or thinking about infrastructure topology research, QUIC backscatter is worth understanding. The protocol’s transparency at connection setup time, combined with the scale at which hypergiants respond to unauthenticated probes, makes it a surprisingly readable signal about how the internet’s backbone is actually organized.