Using QUIC Backscatter to Infer Hypergiant Deployment Configurations

QUIC (RFC 9000), a transport-layer protocol widely adopted by large content providers (or 'hypergiants'), promises low latency paired with encryption and enhanced privacy. Despite these privacy protections, we found that passive measurements can reveal detailed information about the QUIC deployments of large content providers.

The starting point of our study was a simple question: What can we learn about QUIC deployments just by listening to unsolicited QUIC traffic? This question becomes specifically exciting since QUIC aims for enhanced privacy by obfuscating metadata.

In our study, we used a network telescope and QUIC flow records. Network telescopes passively capture Internet Background Radiation, traffic from (malicious and benign) scanners and responses to packets with a spoofed source address (backscatter). Notably, our analysis makes benign use of the response traffic (backscatter) likely caused by attackers. To assess completeness and verify our results, we also performed active measurements.

Our telescope data came from the UCSD network telescope covering a /9 and /10 IPv4 prefix. We considered one month of QUIC packets captured each year between 2021 and 2025.

CESNET, the Czech National Research Network, provides the flow data from the same month of telescope traffic in 2024 and 2025. We used this dataset to verify our telescope observations. Every property in this blogpost was also verified with observations in flow records.

We analysed different properties of QUIC packets received by the telescope. In this blog post we focus on traffic from Cloudflare, Google, and Meta servers, more details can be found in our paper.

Figure 1 depicts the time gaps between the first received packet and subsequently detected retransmissions within the same connection - re-sent by QUIC servers in reply to spoofed traffic that the servers see as unresponsive clients. Peaks indicate common configurations of when and how frequently these messages were re-sent.

In 2025, the first retransmission happened after 0.1 s in 94% of QUIC connections from Meta, 0.3 s in 51% from Google, and 1.0 s in 67% from Cloudflare. Except for Cloudflare (0.3 s in 31% of the connections in 2022), this observation was stable throughout our entire measurement period, but the share of the most frequent retransmission varied. At 0.1 ms, we observed more retransmissions than QUIC connections from Meta. We found that these connections did two resends at ~0.1 ms.

We observed exponential backoff in retransmission timeouts from Cloudflare, Meta, and Google servers. The maximum number of resends differed between hypergiants, showing that servers require differing resources to keep connection states.

Overall, we detected the shortest resend timeouts and most retransmissions from Meta. This indicates that Meta reacts faster to packet loss, and expects shorter delays between clients and servers than Google and Cloudflare. In comparison, Google and Cloudflare reserve less resources to cope with faulty connections. This reduces vulnerability to QUIC flood attacks that build up state.

Retry packets are rarely used to counter Denial of Service (DoS) attacks

QUIC Retry packets enable QUIC servers to verify the client address by mandating that the client reconnects with a Retry Token given by the server. Those Retries can be effective against QUIC floods, but add one round-trip time. We observed this defence strategy is rarely deployed. For example, Cloudflare started in 2025, with 3% of QUIC packets from Cloudflare being retries. This indicates that deployments favour low latency connections over DoS mitigation.

QUIC connection IDs carry information

QUIC uses Connection IDs (CIDs) to link packets to connections, instead of the source and destination port used by TCP and UDP. Server CIDs can leak data if hypergiants encode information in them. Such encoding distorts the random distribution of server CIDs. Figure 2 visualises the frequencies of server CID nybble values as monitored in the backscatter traffic. Frequencies that diverge from the expected random distribution (shown in light-yellow and -green) show server CIDs encoding specific information.

Entirely passively, we were able to observe in backscatter that all hypergiants encode information in CIDs. The resulting distinct patterns can be used to detect off-net deployments outside of the Autonomous System (AS) of the hypergiant. Details and the accuracy of this method are discussed further in our paper.

In 2021 and 2022, the server CIDs from Google followed a random distribution. In 2023 and 2024, the load balancer configuration changed. We observed server CIDs starting with 0b11 in 99% (2023) and 0b111 in 99.9% (2024) of long header packets. According to the IETF Draft for Generating Routable QUIC Connection ID, this indicates that Google was not encoding server CIDs with information to aid in load balancing. Surprisingly, Google’s QUIC implementation adopts format changes of the Internet Draft, but does not use CIDs for load balancing.

The Meta QUIC implementation, mvfst, encodes details about hosts, workers, processes, and the version of this encoding within the server CID. The presence of higher densities of some values in the first five bytes indicates that Meta currently encodes information in server CIDs.

Observing load balancer configuration migration

Closely tracking the reception of QUIC backscatter from Meta allowed us to observe the migration to a new load balancer configuration, from server CID version 1 to version 2, in July 2023 (see Figure 3).

The migration took 10 days, and follow-up active measurements confirmed the changes.

Before this migration, host IDs denominated individual load balancer instances. After the migration, Meta used the same host IDs in different clusters. We detail our method of cluster inference in the next section.

Revealing the load balancer count of Meta

After detecting information encoding, and even encoding of specific load balancer IDs in our passive dataset, we wondered how complete our view was, and whether we could fill potential gaps with active measurements. To this end, we scanned all QUIC IP addresses active at the time (up to 7,355 IP addresses in 2025) in the Meta AS 32934. For each IP address, we completed 20k handshakes while successively decreasing the client port.

We grouped IP addresses into clusters where the same host ID was used by multiple IP addresses in the same /24 prefix. We confirmed the derived structure of clusters using reverse DNS, with the IATA airport code encoded in DNS PTR records of all cluster VIPs being identical, showing that clusters are limited to a single /24. This method revealed the number of load balancers per cluster. Figure 4 shows the distribution of cluster sizes for clusters observed worldwide. You can find more details about cluster structure and usage in our paper.

We compared the number of host IDs in backscatter with our active measurements. While in 2023, 2,366 QUIC connections allowed detection of 93% of all host IDs in a cluster, we achieved 100% coverage with only 545 QUIC connections in 2025 following the new structure. This is related to the lower median number of load balancers per cluster. Compared to active measurements, backscatter observed the largest proportion of Meta host IDs in 2023 at 29%.

Why use passive measurements?

Our analysis showed that:

1. Even small amounts of backscatter reveal QUIC stack configurations of hypergiants.
2. Enumeration of load balancer instances is possible at high fidelity, with less than 1,000 spoofed QUIC connections in backscatter.

Observation from passive measurements is reproducible with active measurements, but active measurements require prior knowledge of potential targets, cost additional network traffic, and might trigger intrusion detection. Telescope measurements can help to improve active measurements as they shed light on real world QUIC traffic. Given the variety of existing QUIC libraries and their potential configurations, reproducing realistic behavior for active measurement.

Will deployment of structured connection IDs increase? Can we apply the same methods to other deployments?

Structured CIDs may serve as a fingerprint of specific hypergiants. We found that Google migrated to such CIDs in 2023, and we observed distinct information encoding from Akamai, Amazon, Apple, Cloudflare, Fastly, Meta, and Microsoft in backscatter. We argue that the usage of structured CIDs will increase over time because they simplify fine-grained provider controlled routing.

However, standardization might limit the uniqueness of the identification properties, and as such our ability to associate them with specific hypergiants. Advanced QUIC features such as client migration even require additional data encoded in such IDs to reduce overhead from synchronizing connection state.

Our detection of off-net deployments is applicable to other deployments and measurement methods, such as flow records without ground-truth knowledge from open source implementations. Detection of layer 7 load balancers is limited to Meta, since only Meta uses a cleartext encoding.

What are the implications from knowing the number of load balancers?

Encoding the destination load balancer into a connection ID enables clients to steer traffic to specific load balancer instances. This is unwanted behaviour because attackers could direct traffic to a single load balancer, bypassing single point of failure mitigation.

Although the number of load balancer instances does not reveal the underlying capacity and compute power, knowing the distribution in a geographic region, or size of a single cluster, can be used to estimate the load necessary to overload that Point of Presence (POP).

This information is not only valuable for attackers but also for competitors, allowing them to anticipate business opportunities and local competition, assess the importance of a region, and improve their own infrastructure.

Why detecting off-net deployments matters to network operators

Understanding and predicting traffic between networks is a challenge. It is, however, necessary to provide stable, low latency Internet connections to customers. Inferring more details about exchanged traffic, like the types of servers communicating, may improve capacity planning or enable the detection of unwanted traffic.

Fine-grained infrastructure details embedded in QUIC connection IDs may reveal cache replication between off-net deployments, an activity normally billed as transit from the hosting networks.

For more detailed information about other large deployment configurations like Akamai, Amazon, Apple, Fastly, and Microsoft, read our paper - Waiting for QUIC: Passive Measurements to Understand QUIC Deployments - which was presented at CoNEXT in December 2025.

If you want to investigate QUIC traffic in more depth, CESNET, one of the data providers for this work, publishes a dataset covering detailed QUIC flows recorded at the network edge of CESNET for one year from June 2024 to May 2025.