CNoA: Challenging Number Approach for uncovering TCP SYN flooding using SYN spoofing attack

The challenging number is used for the detection of Spoofing attack. The IP Spoofing is considered to be one of the potentially brutal attack which acts as a tool for the DDoS attack which is considered to be a major threat among security problems in today’s internet. These kinds of attack are extremely severe. They bring down business of company drastically. DDoS attack can easily exhaust the computing and communication resources of its victim within a short period of time. There are attacks exploiting some vulnerability or implementation bug in the software implementation of a service to bring that down and some attacks will use all the available resources at the target machine. This deals on attacks that consume all the bandwidth available to the victim machine. While concentrating on the bandwidth attack the TCP SYN flood is the more prominent attack. TCP/IP protocol suite is the most widely used protocol suite for data communication. The TCP SYN flood works by exhausting the TCP connection queue of the host and thus denying legitimate connection request. There are various methods used to detect and prevent this attack, one of which is to block the packet based on SYN flag count from the same IP address. This kind of prevention methods becomes unsuitable when the attackers use the Spoofed IP address. The SYN spoofing becomes a major tool the TCP SYN flooding. For the prevention of this kind of attacks, the TCP specific probing is used in the proposed scheme where the client is requested challenging number while sending the ACK in the three way hand shake. This is very useful to find the Spoofed IP Packets/TCP SYN flood and preventing them.

💡 Research Summary

**
The paper addresses the problem of TCP SYN flooding attacks that exploit IP spoofing, a common technique used in Distributed Denial‑of‑Service (DDoS) campaigns. Existing defenses such as SYN‑cookies, hop‑count filtering, OS fingerprinting, and IP puzzles each have limitations, especially when attackers spoof source addresses or launch low‑rate attacks that avoid triggering threshold‑based mechanisms. To overcome these shortcomings, the authors propose a host‑based method called CNoA (Challenging Number Approach).

In CNoA, the server augments the normal SYN‑ACK response with a randomly generated “challenging number”. The client, when replying with the final ACK, must echo this number back. The server validates the returned value; a match indicates a legitimate client, while a mismatch (or absence of the number) leads the server to classify the packet as spoofed and drop the connection attempt. The architecture consists of a TCP probe that embeds the challenging number, a packet‑capture engine that records the three‑way handshake, a decision module that checks the number, and a history logger that records blocked attempts.

The authors describe three experimental scenarios using both IPv4 and IPv6: (1) normal connection establishment, (2) detection and prevention of a spoofed SYN attempt, and (3) mitigation of a high‑volume SYN flood. Tests were conducted on a blade server acting as the attacker and a storage server as the victim. Results are presented qualitatively, showing that legitimate clients successfully complete the handshake while spoofed packets fail to return the correct number, allowing the server to drop them. The paper claims that CNoA introduces less processing overhead and lower false‑positive rates compared with SYN‑cookies and hop‑count filtering.

In the conclusion, the authors argue that CNoA provides an efficient, low‑overhead mechanism for detecting IP‑spoofed SYN floods at the server level, without requiring changes to network routers. However, the manuscript lacks detailed specifications of the challenging‑number generation, does not discuss compatibility with existing TCP implementations, and provides no quantitative performance metrics (e.g., latency, CPU usage, throughput) or large‑scale evaluation. Moreover, potential replay attacks and the impact on middleboxes (load balancers, firewalls) are not addressed. Consequently, while the concept is straightforward and potentially useful, further rigorous analysis, implementation details, and extensive testing are needed before CNoA can be considered a practical replacement or complement to established SYN‑flood mitigation techniques.