What QUIC Responses Reveal About the Hidden Architecture of the Internet's Biggest Networks

Most of the internet’s traffic flows through a surprisingly small number of networks. Researchers have taken to calling these “hypergiants”: Google, Meta, Cloudflare, Akamai, Amazon, Microsoft, and a handful of others. A 2019 IMC paper by Gigis et al. put numbers to this intuition, finding that just a few dozen autonomous systems were responsible for the majority of interdomain traffic. What makes these networks interesting from a measurement perspective is not just their scale but their opacity. They operate complex, layered deployment strategies combining anycast routing, embedded caches inside ISP networks, peering at hundreds of IXPs, and their own private backbone fibers. From the outside, understanding how any of this fits together has historically required either insider knowledge or expensive active measurement campaigns. A recent post on the APNIC blog describes a technique that changes this calculus significantly: using QUIC backscatter to passively infer hypergiant deployment configurations at scale.

What QUIC Backscatter Actually Means

The term “backscatter” in networking originally described a DDoS measurement technique. When attackers flood a target with packets carrying spoofed source IPs, the target’s responses flow back to whoever owns those source addresses. By running a darknet (a block of unused IP addresses) and collecting these misdirected responses, researchers could estimate DDoS attack volumes globally without being the target themselves. CAIDA has run the UCSD Network Telescope along these lines for years.

QUIC backscatter is a related but distinct phenomenon. It exploits a fundamental property of the QUIC protocol: servers must respond to certain packet types before any cryptographic handshake is complete, and before they have verified anything about the client. RFC 9000, which standardized QUIC in May 2021, defines two such mechanisms that are particularly useful for measurement.

First, Version Negotiation. When a QUIC server receives an Initial packet advertising a protocol version it does not support, it must respond with a Version Negotiation packet listing the versions it does support. This response is sent to whatever source address appeared in the triggering packet, with no authentication and no connection state required. Second, Stateless Reset. QUIC servers can terminate connections they have no state for by sending a Stateless Reset packet, which is generated using a keyed hash of the Connection ID but requires no per-connection memory.

Both of these create a situation where a server will send packets to an address it has never established a relationship with. If you control a range of addresses and send crafted QUIC packets claiming to come from them to infrastructure you want to study, you receive back responses that carry information about that infrastructure.

Connection IDs as Infrastructure Fingerprints

The truly interesting signal is in the Connection IDs embedded in these responses. QUIC Connection IDs (CIDs) are opaque byte strings, up to 20 bytes long, that routers and load balancers use to route packets to the correct backend server in a cluster. Unlike TCP, where routing is based on the 4-tuple of source IP, source port, destination IP, destination port, QUIC was designed from the start to support connection migration: a client can change its IP address mid-connection and the server uses the CID, not the source address, to find the right connection state.

This design requirement means that large QUIC deployments need their Connection IDs to be meaningful to load balancers. The IETF has been working on draft-ietf-quic-load-balancers (QUIC-LB), which describes how servers can encode routing information inside CIDs in a way that load balancers can decode without needing per-connection state. Cloudflare has written publicly about using encrypted CIDs for their own load balancing to allow any frontend to route to any backend. Google’s QUIC implementation has similar mechanisms dating back to the original GQUIC deployment.

What this means practically is that the Connection ID returned by a server is not random noise. It encodes, in some implementation-specific format, information about which backend cluster or server generated it. Two servers that return CIDs with the same structural format are almost certainly running the same software version with the same load balancer configuration. Two servers that return identical CID prefixes are likely in the same cluster. Servers that return structurally different CIDs despite being announced under the same IP block may be running independent deployments or serving different products.

Mapping Anycast from the Outside

Hypergiants make heavy use of anycast: a single IP address announced from dozens or hundreds of Points of Presence simultaneously, with BGP routing directing any given client to the topologically nearest PoP. From inside the network, anycast is elegant. From outside, it is measurement-hostile. When you ping an anycast address, you reach one PoP and have no direct way to know which one, let alone how many exist or where they are.

Traditional approaches to anycast mapping have relied on distributed probing infrastructure like RIPE Atlas, where thousands of probes in different networks each send a packet to the same anycast address and report their round-trip times. By clustering probes that see similar RTTs, you can estimate the number of distinct PoPs and their approximate locations. This works reasonably well but requires access to a probing platform and produces noisy results in regions with sparse probe coverage.

QUIC backscatter offers a complementary approach. Because Version Negotiation responses are stateless and generated per-packet rather than per-connection, you can probe the same anycast address from many source addresses in a darknet within a short time window and correlate the CID structures in the responses. If two source addresses, presumably routed to different PoPs by BGP, receive responses with structurally identical CIDs but different encoded routing values, that tells you the PoPs are running the same software stack but are genuinely independent deployments. If the CID structures differ entirely, the PoPs may be running different software versions or entirely different server infrastructure behind the same IP.

This is a meaningful advance over RTT-based methods because it gives you signal about the deployment architecture, not just the geographic distribution. Knowing that a CDN has 30 anycast PoPs is useful. Knowing that 20 of them are running one generation of QUIC stack and 10 are running another, or that certain regions use a different load balancing scheme, gives you insight into how the operator manages their rollout process and what their internal migration constraints look like.

Embedded Caches and the Unicast Complication

Not all hypergiant infrastructure is anycast. Embedded caches, sometimes called “landlocked” or “eyeball network” caches, are servers that hypergiants place directly inside ISP and carrier networks under negotiated peering agreements. Netflix’s Open Connect program is the most public example of this, but Google, Meta, and Akamai run similar programs. These caches are often addressed with unicast IPs, sometimes in the ISP’s own address space, and may or may not be directly visible in public routing tables.

QUIC backscatter can probe these as well, assuming you can enumerate their addresses. Public BGP data from RouteViews and RIPE RIS gives you announced prefixes. Active scanning of QUIC ports (UDP/443 is the common deployment target) across those prefixes with ZMap-style tooling can identify QUIC-capable hosts. Comparing CID structures from these unicast caches against CID structures from the hypergiant’s anycast addresses reveals whether the embedded caches are running the same software stack and, if the QUIC-LB encoding is consistent, possibly which backend cluster or version they correspond to.

The picture that emerges from combining anycast and unicast measurement is a deployment graph: which IP addresses belong to the same logical cluster, which clusters are running which software versions, and how that maps onto geography and network topology.

What Operators Should Take From This

The security implications here are subtle but real. None of the information revealed by QUIC backscatter is secret in the traditional sense: no credentials are leaked, no user data is exposed. What is revealed is infrastructure topology that operators might have assumed was opaque because it was not directly documented anywhere.

Knowing the internal cluster structure of a CDN is useful for competitive intelligence, for targeted traffic engineering, or for planning denial-of-service attacks against specific infrastructure components rather than entire anycast clouds. The QUIC-LB draft addresses this concern somewhat: it defines an encrypted CID format where the routing information is only decryptable by the load balancer, not by an observer who just sees the CID. But deployment of encrypted CIDs is not universal, and even encrypted formats can leak structural information through their length and position fields.

For researchers, the more immediate value is in understanding how the internet actually works at the infrastructure layer. The gap between the theoretical routing protocols and the messy reality of hypergiant deployments is significant. Techniques like QUIC backscatter help close that gap without requiring cooperation from the operators themselves, which they are generally not inclined to provide.

QUIC was designed with measurement in mind in some respects: the QUIC Spin Bit, for example, is an explicit concession to network operators who need to measure RTT passively. But the Connection ID design, optimized for operational flexibility and load balancing, turns out to be an equally rich source of inference for anyone willing to collect and analyze the responses that QUIC servers generate before they know who they are talking to.