## 5 A Novel Protection Mechanism against the SIP-DRDoS Attack
### Proposed Defense Mechanism in Detail: Components and Workflow
#### 5.1.1 Statistics Module:  
As given in Figure 5, the statistics module consists of three submodules: sniffer, baseline calculation, and anomaly detection engine. The sniffer submodule filters SIP traffic by sniffing the network in real time. It captures SIP traffic periodically (hourly, daily, weekly, or monthly) and creates a reference traffic pattern, named the normal traffic pattern, taking into account the network and the SIP specifications. In order to achieve this, by taking into account the amount of traffic intensity, the system operator first determines the period of traffic sampling in terms of the number of hours, days, weeks, or months. The baseline calculation submodule analyzes the collected sample traffic and utilizes certain threshold calculation algorithms by taking into account the SIP specifications and the baseline traffic for the duration of the sampling period. It dynamically measures the bandwidth usage and the number of packets per second to determine the lowest, highest, and average attack threshold values. The initial inbound and outbound traffic values are defined in kilobits per second. The baseline calculation submodule uses the maximum UDP SIP packet size of 64 KB globally and calculates the inbound packet rate by dividing the inbound traffic rate by the maximum UDP SIP packet size. After each sampling period, the following calculations are done by our baseline calculation mechanism, where the edge values are calculated within the pcap sample as given below:  
* \(Normal\)\(Edge\)\(=\) average network traffic rate for the sampling period;
* \(Present\)\(Edge\)\(=\) network traffic rate at present;
* \(Attack\)\(Edge\)\(=\) the highest momentary network traffic rate within the selected time period;
* \(Suspect\)\(Edge\)\(=\)\(\frac{Attack\)\(Edge+Normal\)\(Edge\). Furthermore, limit values are calculated within the pcap sample as follows:  
Figure 5: Proposed defense mechanism application workflow. * _Present Limit = \begin{tabular}{} \end{tabular} _  
The anomaly detection engine submodule detects anomaly states by measuring deviations from the baseline by calculating the inbound packet rate limit. When an anomaly is detected, it writes to the log, initializes an alert for the admin, and for further investigation, transmits the data to the inspection module which has a deeper protocol analyzer. Anomaly detection is achieved by using either traffic rate control or packet rate control, described as follows:  
* _Traffic rate control_: _Present Edge_ and _Suspect Edge_ values are compared. If _Present Edge_ is larger than _Suspect Edge_, an attack is presumed, and the inspection module is triggered. * _Packet rate control_: If _Present Limit_ is larger than _Suspect Limit_, based on the number of SIP connections per second or the number of requested packets per second, an attack is presumed and the inspection module is triggered. **Inspection Module:**  
As given in Figure 5, the inspection module consists of two sub-modules: a protocol analyzer and a dynamic rate-limiting rule engine. The protocol analyzer submodule analyzes in detail the data traffic received from the anomaly detection engine according to the SIP specifications. It utilizes approaches akin to those utilized by intrusion detection systems and DDoS attack defense systems. When the rate of traffic hits the threshold value defined for attack traffic, i.e., when an anomaly is presumed, the inspection module is triggered and compares the normal and the presumed attack traffic patterns. The system keeps track of the number of call initiation packets, established sessions, reflected requests, and responses within the specified time period. It inspects the headers/tags in SIP messages, e.g., Call-ID, \"from\" tag, branch tag, \"Via\" header, and \"Record-Route\" header, and tries to pin down suspicious traffic so that the action module can be triggered to drop/block it.