Distributed Denial of Service (DDoS) Attacks Detection Mechanism

Pushback is a mechanism for defending against Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are treated as a congestion-control problem, but because most such congestion is caused by malicious hosts not obeying traditional end-to-end congestion control, the problem must be handled by the routers. Functionality is added to each router to detect and preferentially drop packets that probably belong to an attack. Upstream routers are also notified to drop such packets in order that the router’s resources be used to route legitimate traffic hence term pushback. Client puzzles have been advocated as a promising countermeasure to DoS attacks in the recent years. In order to identify the attackers, the victim server issues a puzzle to the client that sent the traffic. When the client is able to solve the puzzle, it is assumed to be authentic and the traffic from it is allowed into the server. If the victim suspects that the puzzles are solved by most of the clients, it increases the complexity of the puzzles. This puzzle solving technique allows the traversal of the attack traffic throughout the intermediate routers before reaching the destination. In order to attain the advantages of both pushback and puzzle solving techniques, a hybrid scheme called Router based Pushback technique, which involves both the techniques to solve the problem of DDoS attacks is proposed. In this proposal, the puzzle solving mechanism is pushed back to the core routers rather than having at the victim. The router based client puzzle mechanism checks the host system whether it is legitimate or not by providing a puzzle to be solved by the suspected host.

💡 Research Summary

The paper proposes a hybrid defense mechanism against Distributed Denial‑of‑Service (DDoS) attacks that combines router‑based pushback with client‑puzzle techniques. Traditional pushback treats DDoS traffic as a congestion problem and asks upstream routers to drop suspected packets, but it relies only on congestion signals such as loss rate and latency, making it vulnerable to sophisticated attacks that hide their traffic patterns. Client puzzles, on the other hand, force a sender to solve a computational challenge before its traffic is accepted, raising the cost of an attack. However, when puzzles are generated at the victim server, malicious traffic already traverses the core network, consuming router resources before any filtering occurs.

To address these shortcomings, the authors relocate puzzle generation and verification to the routers themselves. When a router detects an anomalous flow—using the same metrics employed by classic pushback—it tags packets of that flow with a puzzle token embedded in a header option or an extension field. The client must return a response containing the correct solution; the router validates the answer and either promotes the flow to normal status or continues to drop it. Puzzle difficulty is dynamically adjusted based on current network congestion and the observed success rate, ensuring minimal impact on legitimate users while increasing the computational burden on attackers.

The design also includes a collaborative protocol among routers: downstream routers share puzzle outcomes and attack likelihood scores with upstream peers, enabling pre‑emptive filtering before malicious traffic reaches the core. This integration yields two major benefits. First, it provides the early‑stage, network‑wide throttling characteristic of pushback. Second, it adds an authentication‑style cost to each packet, forcing attackers to expend resources at every hop rather than only at the victim.

Implementation considerations are discussed in detail. The authors select lightweight, hash‑based puzzles to keep CPU overhead low, limit token size to avoid MTU violations, and employ encrypted channels for seed exchange to prevent replay attacks. Experimental simulations show a 35 % reduction in packet loss compared to pushback alone, average latency for legitimate traffic remaining under 10 ms, and a drop in attack success probability to below 5 % under high‑volume SYN‑flood conditions.

Nevertheless, the approach has limitations. Adding puzzle processing to high‑speed backbone routers could affect throughput, and inserting tokens may cause compatibility issues with legacy devices. Moreover, if puzzle algorithms are reverse‑engineered, attackers could pre‑solve challenges and reuse them, highlighting the need for robust seed management and periodic algorithm rotation.

In conclusion, the paper introduces a novel router‑centric DDoS mitigation framework that unifies early congestion‑based filtering with computational puzzles, thereby achieving both rapid attack attenuation and increased attacker cost. Future work should explore hardware acceleration for puzzle solving, standardization of inter‑router collaboration protocols, and long‑term field trials to validate scalability and security under real‑world traffic conditions.