Mitigation of Random Query String DoS via Gossip

This paper presents a mitigation scheme to cope with the random query string Denial of Service (DoS) attack, which is based on a vulnerability of current Content Delivery Networks (CDNs). The attack exploits the fact that edge servers composing a CDN, receiving an HTTP request for a resource with an appended random query string never saw before, ask the origin server for a (novel) copy of the resource. Such characteristics can be employed to take an attack against the origin server by exploiting edge servers. Our strategy adopts a simple gossip protocol executed by edge servers to detect the attack. Based on such a detection, countermeasures can be taken to protect the origin server and the CDN against the attack. We provide simulation results that show the viability of our approach.

💡 Research Summary

The paper addresses a novel denial‑of‑service (DoS) threat that exploits a design flaw in current Content Delivery Networks (CDNs). In many CDN implementations, edge servers treat any HTTP request that contains a previously unseen query‑string as a request for a new resource and forward it to the origin server, even if the edge server already holds a cached copy of the file. An attacker can therefore generate a flood of requests to many edge servers, appending a random query‑string to each request. The origin server, unaware that the query‑string is meaningless, returns the full file to each edge server; the attacker then aborts the connection, causing the origin to waste bandwidth and processing power on a large number of unnecessary transfers. This “random query‑string DoS” attack can overwhelm the origin server while the CDN itself appears to be functioning normally.

Existing mitigations either require the CDN to stop accelerating any URL that contains a query‑string—thereby reducing flexibility—or rely on IP‑based filtering, which can be evaded through proxies or botnets. The authors propose a lightweight, gossip‑based detection scheme that operates among edge servers and the origin server without altering the normal content‑delivery workflow.

Core Mechanism

1. When the origin server receives a request with an invalid (random) query‑string from an edge server, it serves the requested resource as usual but also attaches a flag indicating that the query‑string was spurious.
2. The edge server that received the flagged response generates a “gossip” message containing this alert and any previously collected alerts.
3. Using a simple push‑gossip algorithm, each edge server forwards the message to a randomly selected subset of the other edge servers with probability v (e.g., 0.5). This process repeats at each simulation step, allowing the alert to spread rapidly through the CDN.
4. Each edge server maintains a sliding time window Δ and counts the number of alerts it has received concerning a particular origin server. The count is divided by the total number of edge servers S. If the resulting ratio exceeds a predefined threshold θ (e.g., 0.5), the edge server concludes that the origin server is under a random‑query‑string DoS attack.
5. Upon detection, all edge servers can immediately stop forwarding requests that contain query‑strings to the affected origin server, thereby cutting off the attack vector.

Algorithmic Details
The gossip protocol is described in Algorithm 1. It is a pure push scheme: for every alert, an edge server independently decides, with probability v, whether to send the alert to each of the other S – 1 edge servers. The expected number of transmissions per alert is v · (S – 1), which is modest even for large CDNs. Gossip messages are deliberately kept small, containing only the set of alerts, to keep network overhead low.

Detection Heuristics
Rather than using the proportion of erroneous requests over total traffic (which would be biased by the popularity of the service), the authors base detection on the average number of alerts per edge server within Δ. Because random query‑strings are assumed to be rare under normal operation, a non‑negligible global alert count signals an abnormal situation. The threshold θ can be tuned to balance detection speed against false‑positive risk.

Simulation Framework
A custom discrete‑event simulator written in C (using the GNU Scientific Library for random number generation) models a CDN with configurable numbers of edge servers, attack rates, honest error rates, gossip probability, and time‑window size. The attacker is modeled as a Poisson process that sends random‑query‑string requests to a subset of edge servers; honest clients generate occasional malformed queries at a low rate (default 0.01). The simulator records the step at which the attack is first detected and the percentage of runs in which detection succeeds.

Results

• Varying the number of edge servers (10, 25, 50, 75) shows that larger CDNs detect the attack earlier (often within the first 5–6 steps) and with higher probability.
• Changing the gossip probability v from 0.5 to 0.9 yields virtually identical detection curves, indicating that a modest gossip rate is sufficient.
• Adjusting the sliding window size (Δ = 10 to 100) has little impact on detection speed, though very small windows can slightly increase false positives.
• With θ = 0.5 and a benign error rate of 0.01, the false‑positive rate is essentially zero across all configurations.
• The approach imposes minimal computational load on edge servers (simple counting and occasional message sends) and negligible bandwidth overhead (small gossip packets).

Discussion and Limitations
The proposed scheme preserves the normal CDN workflow, requiring only a small extension to the origin’s HTTP response and a lightweight gossip module on each edge server. However, the detection latency depends on the speed of gossip propagation; in highly partitioned networks or under severe packet loss, alerts may spread slowly, delaying detection. Moreover, an adversary capable of intercepting or forging gossip messages could undermine the system, suggesting a need for authenticated gossip (e.g., digital signatures). Future work could explore adaptive thresholds, reputation‑based weighting of alerts, and integration with existing CDN monitoring tools.

Conclusion
The authors present a practical, low‑overhead method to detect and mitigate random‑query‑string DoS attacks in CDN environments. By leveraging a simple push‑gossip protocol among edge servers, the system can rapidly identify abnormal spikes in spurious query‑string requests and trigger counter‑measures without sacrificing CDN flexibility or performance. Simulation results confirm high detection rates, low false‑positive incidence, and robustness to parameter variations, making the approach a promising candidate for real‑world CDN security enhancements.