Augmented split –protocol; an ultimate d do s defender

International Journal on Computational Sciences & Applications (IJCSA) Vol.4, No.1, February 2014
DOI:10.5121/ijcsa.2014.4107 65
AUGMENTED SPLIT –PROTOCOL; AN ULTIMATE
DDOS DEFENDER
Bharat Rawal1
, Harold Ramcharan2
and Anthony Tsetse3
1&2
Department of Computer and Information Sciences
Shaw University
Raleigh, NC, USA
3
Department of Computer and Information Sciences
State University of New York
Fredonia, NY, USA
ABSTRACT
Distributed Denials of Service (DDoS) attacks have become the daunting problem for businesses, state
administrator and computer system users. Prevention and detection of a DDoS attack is a major research
topic for researchers throughout the world. As new remedies are developed to prevent or mitigate DDoS
attacks, invaders are continually evolving new methods to circumvent these new procedures. In this paper,
we describe various DDoS attack mechanisms, categories, scope of DDoS attacks and their existing
countermeasures. In response, we propose to introduce DDoS resistant Augmented Split-protocol (ASp).
The migratory nature and role changeover ability of servers in Split-protocol architecture will avoid
bottleneck at the server side. It also offers the unique ability to avoid server saturation and compromise
from DDoS attacks. The goal of this paper is to present the concept and performance of (ASp) as a
defensive tool against DDoS attacks.
KEYWORDS
Split Protocol; Protocol splitting; DDoS; Tribal Flood Network; Bare Machine Computing.
1. INTRODUCTION
In a Denial of Service (DoS) attack, an intruder penetrates and depletes a computer system,
refuting genuine users from using network services, such as a computer system, web server, or
website [1]. While, a Distributed Denial of Service (DDoS) attack is a synchronized, multiple
DoS attack that are launched through many negotiated machines. The targeted for the attack are
those of the “primary victim," while all the cooperated systems participating in the attack are
referred to as the “secondary victims.” By adding many secondary victims in a DDoS attack, it
allows the attacker the extravagance to launch a larger and more upsetting attack while remaining
concealed. This happens since the direct source of attacks is launched from the secondary victims
systems, thereby masking the true identity of the real invader.
These DDoS attacks frequently affect large network systems by disrupting or shutting down their
services, and diminishing service performance while negatively impacting returns. The Split-
protocol [2] offers mechanisms to hide the actual network services from the real world and role
change over without involving client. For example, as shown in Figure 1a, a client on the network
sends a request through the Connection Server (CS). This request will then be forwarded to the

66
Data Server (DS) through Resource Allocator ( RA), which in turn sends the requested data to the
client. The symmetrical structure of CS, RA and DS allows changing their roles dynamically.
In case of DS1 server crash, DS2 server will take the IP of DS1, relinquishing all its data to DS2.
Whenever DS1 is overloaded (CPU is around 96%), DS1 will shut down as DS* takes over (DS*
is back up to DS1, such as DS2, DS3…). By toggling between DS1 and DS*, one can avoid
saturation of the server [38].Protocol splitting enables TCP to be split into its constituent
connection and data phases, allowing for these phases to be executed on different machines
during a single HTTP request [2]. Figure 1b shows the protocol transaction for migratory (M)
Split-protocol. In its basic form of splitting, the state of the TCP connection to the original server
is transferred to a Data Server after receiving the HTTP GET request, all without client
involvement.
Figure 1a. Split Architecture
After the DS receives the TCP connection, it then transfers the data to the client, and allows for
the connection termination to be handled by either the original CS or the DS. Many variations on
basic TCP/HTTP splitting are possible and have been used to improve “Web server performance”
by use of delegation [1], split mini-clusters [4], and split architectures [5]. The security and
addressing issues that arise due to protocol splitting can be solved in a variety of ways. The
simplest solution is to deploy the servers in the same subnet or in the same Local Area Network
(LAN) if host-specific routes are supported. The latter is used in this paper for testing migration
performance by splitting. More generally, splitting can be applied to protocols other than
TCP/HTTP by identifying protocol phases that are amenable to splitting. In this paper, we adapt
TCP/HTTP splitting to devise a novel approach for DDoS defense.
Figure 1b. Augmented Split-protocol Transaction

67
The rest of the paper is organized as follows. Section II discusses related work. Section III
describes common DDoS/DoS attack and technique used. Section IV outlines a DDoS attack
architecture. Section V talks different installation mechanism for DDoS agent. Section VI
discusses possible ways to address these attacks. Section VII presents augmented Split
architecture. Section VIII describes the design and the implementation of the proposal. The
sections IX preset experimental results; section X represents performance measurements and XI
contains the conclusion.
2. RELATED WORK
The Global Defense Infrastructure (GDI) proposed by K. Wan and R. Chang in [6] and [7]
describe an approach similar to distributed management architecture in securing against DDoS
attacks. Alert exchanges make all the infrastructure's members aware of their findings. The
Cooperative Intrusion Traceback and Response (CITRA) framework [8, 9] is, also comparable to
Koutepas, G., Stamatelopoulos, F., & Maglaris, B’s Distributed management
architecture[1],and uses the concept of administrative domain communities organized as
neighbourhoods which maps out existing DDoS defense strategies mentioned in their literature.
Their current DDoS defense mechanisms include “Detection, Response, and Tolerance &
Mitigation” [36]. Attack detection aims to detect the presence of an ongoing attack followed by
separating malicious traffic from legitimate for eviction. Typical detection methodology stem
from signature based, anomaly based, hybrid, and third party attacks. SNORT IDS [10] and Bro
[11] are the two most popular used open source signature based detection approaches. A known
disadvantage in signature based techniques is that they are only capable of providing protection
against known attacks. However, the threat landscape is continuously changing as new attacks are
being developed daily, allowing them to go unnoticed.
The anomaly based detection method relies on base lining for network behaviour with valid
traffic patterns and identifies anomalies whenever they deviate from the predefined or accepted
model of behavior. Most of the commonly used DoS detection systems employed are anomaly
based [19],[ 20]. In [12], Gil and Poletto proposed a method called MULTOPS for detecting DoS
by examining the packet rates in both the up and down links. According to MULTOPS, under
normal operation, packet rates between two hosts are considered proportional. Any steep variant
or spiked disproportion in traffic to and from a host or subnet is a possibility of a DoS attack in
progress. Blazek et al. Though the majority of DoS detection systems [20] use volume based
metrics to identify DDoS attacks; they have been successful in defending against flooding attacks,
however low rate flooding attacks usually go undetected as they do not appear to inflict
significant disruptions in traffic volume, but on account of the large number of false positives and
false negatives, significant damage can be inflicted when attack is carried at slow continuous rate.
One method worth mentioning here is the entropy based DDoS detection [21]-[22] which boasts
its effectiveness in countering diluted low rate degrading flooding attacks.
Higher CPU utilization rates can occur when intruders launching deliberate attacks on servers, or
a higher than the allowable number (threshold) of users simultaneously. These unauthorized users
overwhelms the server occupying most of’ its bandwidth, rendering it useless. Kuppusamy and
Malathi [24] implemented a particular technique to detect and prevent (DoS) attacks [25], as well
as (DDoS) attacks [24]. DDoS occurs when a multitude of coordinated and distributed attack is
launched against a single target, such as a website or server. Spoofing is commonly associated
with Dos and DDoS attacks, however, in response to mitigating the effects of spoofing IP source
addresses where packets lack a verifiable IP source address, the unicast reverse path forwarding
(uRPF) [26] is a valuable tool for this purpose. Bremler-Barr and Levy proposed a Spoofing
Prevention Method (SPM) [28], where packets are exchanged using an authentication key

68
affiliated with the source and destination domains. Nowadays, there is an ever growing threat of
intruders to launch attacks utilizing both-nets [29].
3. COMMON DOS/DDOS ATTACKS AND TECHNIQUES USED
In recent times, high profile business entities have been at the receiving end of DoS/DDoS
attacks. The most common applications targeted are gateways, webservers, electronic commerce
applications, DNS servers and Voice-over IP servers. The success of these attacks gives credence
to how vulnerable and unprotected the internet has become. Considering the economic impact of
network downtime on businesses, it becomes imperative that businesses invest a lot money and
resources in protecting their IT infrastructure [34][37]. Some of the attacks employed are
discussed below
3.1. Smurf and Fraggle
Smurf attacks have gained considerable eminence as a means of performing DDoS/DoS attacks.
This approach of performing DoS attacks is based on the use of ICMP packets sent to broadcast
network addresses by the attacker [42]. Fraggle attacks are similar to smurf attacks in their
operation mechanism. In fraggle attacks however, UDP echo packets are sent instead of ICMP
echo packets. In some variants of fraggle attacks, the UDP packet is sent to the intermediary’s
port (chargen, port 19 in Unix systems) that supports character generation with the return address
spoofed to the victim’s echo service (echo, port 7 in Unix systems) thereby amplifying the
requests infinitely [40].
3.2. Flooding
In flooding, the attacker sends large amounts of packets to its victim with intent of consuming up
all the victim’s available resources to a point that the victim can no longer process any requests
from legitimate clients [23].It is worth mention that in flooding attacks the volume of the traffic is
what matters and not the actual contents of the traffic. Some of the common flooding techniques
used are TCP SYN, UDP, SIP and HTTP GET/POST flooding.
3.3. Malware
Malware is malicious software that have been programmed overwhelm a system allowing
attackers to gain unauthorized access, and in most cases escalating privileges of the attacker.
Once an attacker is able to escalate his privileges on a system, the opportunity for launching an
attack is limitless [43]. Malwares normally take advantage of vulnerabilities in Operating systems
and application software and can be in the form of Trojan horses, rootkits, viruses, worms etc.
The motivation for programming malware may be financial, for fun or to deliberately halt a
system [44].
3.4. DoS attacks
DDoS/DoS can be broadly take two forms; Attacks that flood networks resulting in bandwidth
degradation and attack that consume resources and eventually crashing services [46].In figure 5,
some methods of attack are shown.

69
Figure 5. Methods of DoS attack [28]
The magnitude of DDoS/DoS attacks increases considerably when an unlimited amount of
unknown sources are used. In the case of DDoS the attack occurs in two phase where initially
zombies are compromised and recruited and eventually these zombies launch attacks on the
victim[41][13].Buffer and stack overflow vulnerabilities in are commonly exploited by
attackers[31].
Malicious code is used to start agent tools to provide access to the victim’s system once these
vulnerabilities are detected and consequently the DDoS agent code is installed.
3.5. DoS attack techniques
Figures 5a, 5b, and 5c show some common techniques used for DoS/DDoS attack such as agent
setup, agent activation and network communication.
Figure 5a. Agent Setup [36]

70
Figure5b. Network attacks [36]
Figure 5c. Attack based on OS Support [36]
4. DDoS ATTACK ARCHITECTURES
The two most popular types of DDoS attack networks model in current use today are the Agent-
Handler model and the Internet Relay Chat (IRC)-based model. The Agent Handler model is
shown in Figure 5d, comprising clients, handlers, and agents. The client is the medium through
which the attacker communicates within the DDoS system and uses software packages scattered
throughout the internet termed handlers which the clients uses to communicate with the agents.
This allows the attacker to hide himself among the many clients participating in the attack.
Attackers will usually try to install the handler software on a compromised system, and then use
these handlers to communicate with agent’s software which is located on a compromised system

71
from which to launch their attacks [36]. As described in Figure 5e. IRC (Internet Relay Chat)
uses a communication channel to connect the client to the agents. An IRC communication
channel aides an attacker through the use of “valid” IRC ports for conveying instructions to the
agents [36]. In IRC, the attacker easily conceals his presence due to the extremely high volumes
of traffic flowing on the servers.
Figure 5d. DDoS Agent-Handler model[36]
Agent software in an IRC network communicates messages within the IRC channel thus allowing
the attacker to easily see the list of the agents as they become operational [36]
Figure 5e. DDoS IRC-Based Attack Model [36]
5. INSTALLATION DDOS AGENT
Attackers install malicious DDoS agent code either actively or passively onto a secondary victim.
In Active DDoS agent installation methods, an attacker probes the network for vulnerabilities,
and then executes scripts to gain unauthorized entry into the system, while silently installing the
DDoS agent software. Before installing DDoS software, attackers first utilize scanning tools, to
identify potential secondary victim systems. These scanning tools allow attackers to select ranges
of IP addresses from which to scan. The tool will then proceed to return information such as each

72
IP address, open TCP and UDP ports, and the underlying OS [10]. In the case of passive DDoS
installation methods, the secondary victim accidentally causes the DDoS agent software to be
installed, either by opening a corrupted file, or visiting malicious web-sites [36].
6. DOS/DDOS DEFENSE MECHANISMS
Just as in any security setting, it is virtually impossible to completely isolate risks associated with
DoS attacks. In this section we describe the Avoid –Detect- Prevent cycle approach to mitigating
the risk of DoS attacks.
6.1. Avoid
Avoidance plays a key role in the successful implementation of any efficient defensive strategy.
In an attempt to analyze DoS attacks and guide against future occurrence, a lot of technical data
has to be obtained (e.g. network topologies, vendor agreements etc.).The data can also be
acquired by monitoring traffic at network and host levels. This baseline data would help
organizations in determining services that are critical. With this information, it becomes relatively
easier for organizations to focus security strategies on service that are likely to have a relatively
higher impact on business processes should they be affected by a DoS attack.
6.2. Detect
The heterogeneous nature of modern networks has to a large extent resulted in a corresponding
increase in the complexity of networks. To this end it is important that detection systems are able
to detect, prevent, and alert personnel of any possible DoS attacks in real time.
Modern Intrusion Detection Prevention Systems (IDPS) come equipped to combat these
attacks and maintain state [43]. Detection systems should provide multiple detection mechanism,
alerts, response mechanisms [44], and short detection time with low false positive rate [43]. These
intrusion detection systems can take several forms such as anomaly detection, signature-based
detection, as discussed below [18].
6.2.1.Signature-based detection
Signature based detection is usually used to detect known attacks. In this approach packets are
analyzed to see if they conform to a known attack and based on that a decision is made. A
database is maintained of known attacks against which network traffic is compared. Even though
databases are constantly updated to reflect new threats, it possible for new attacks to be ignored
by signature based systems [18] [41][47].
6.2.2.Anomaly-based detection
Anomaly based detection systems examine network traffic and application behavior and compare
the traffic against existing ‘normal’ traffic patterns and thresholds. Some anomalous patterns that
can be captured include [59];
i.Misuse of network protocols such as overlapped IP fragments
ii.Uncharacteristic traffic patterns such as more UDP packets compared to TCP
iii.Suspicious patterns in in application payload

73
Machine Learning algorithms, Neural networks, Bayesian Learning and statistical
techniques are some of the most common techniques used in anomaly based detection
[12], [13] and [14].
6.3. Prevent
The primary objective of prevention is to detect attacks in the initial stages and prevent them from
escalating. This is normally done through the use of distributed packet filtering mechanisms
relying on information from local routing with the view of preventing flooding [3][15][16].
6.4. Reaction
Reaction techniques require the use of efficient incidence response and backup systems coupled
with filtering of excessive traffic to mitigate the effects of attacks. In addition to the defensive
techniques discussed above, several techniques have also been implemented to mitigate DoS and
DDos attacks. In [13], a technique for anomalous pattern for HTTP flood protection is proposed.
This technique tunes a level of rate limiting factors using feedback .In using this approach,
attacks are efficiently mitigate and legitimate traffic is allowed.
Specht and Lee’s [18] mitigation technique is based on similarities and patterns in different DDoS
attacks. DDoS attack tools are normally designed to be friendly with different Operating Systems
(OS). Any OS system (such as UNIX, Linux, Solaris, or Windows) may have DDoS agents or
handler code designed to work on it. Normally, a handler code is intended to support an OS that
would be positioned on a server or terminal at either a corporate or ISP site. Most of the proposed
mitigation mechanisms are also OS dependent.
In a split –protocol implementation based on the Bare Machine computing paradigm (BMC)[37] ,
no operating system is required. Because most DoS/DDoS agents are OS based, it is virtually
impossible to run any agent code on the systems that are designed based on BMC paradigm
7. AUGMENTED SPLIT ARCHITECTURE
Augmented Split- protocols (ASp) require a minimum of three servers, i.e., a Connection Server
(CS), Resource Allocator (RA) and Data Server (DS). The CS establishes the connection via
SYNs and ACKs. When the HTTP GET is received by the CS, it sends an inter server packet to
RA, this Inter Server Packet (ISP) contain the detail information about the Get. When the RA gets
ISP, it creates its own TCB entry and sends ACK to the client and RA reserve resources for
particular GET; also at the same time it sends an inter-server packet message to DS (referred to as
a Delegate Message DM1). The DM1 is used to transfer the TCP state to the DS, which sends the
data to the client. In bare PC servers, the TCP state and other attributes of a request are contained
in an entry in the TCP table (known as a TCB entry). In this architecture, CS does not reserve any
resources for received GET request. However, it forwards GET to RA and intern RA reserve
resources and state of the request (TCB Table). When CS sends or receives FIN, or FIN-ACK it
sends information to the RA through the ISP, and RA deletes the TCB records belongs to the
specific request. Retransmission and packet losses are also managed by RA. In this architecture,
CS and DS does not reserve any resources for specific GET request. In this mechanism, RA is
master and DSs servers as slaves they only follow the instruction from RA. RA knows the
distribution of data on various DSs accordingly it sends DM1. The CS also handles the TCP
ACKs for the data and the connection closing via FINs and ACKs. Typically, the RA has
information about the requested file (i.e., its name, size, and other attributes), and the DS has the
actual file (the RA may or may not have a copy). When the DS gets DM1, it starts processing the

74
request. When a DS sends data to the client, it uses the CS’s IP address. After the CS receives the
FIN-ACK, it sends another inter-server packet DM2 to RA. The receipt of DM2 closes the state
of the request in the RA. Furthermore, when CS reaches a threshold value, it migrates to a new
server. It enables an alternate Connection Server (called CS* for convenience) to dynamically
take over active TCP connections and pending HTTP requests from the original Connection
Server upon receiving a special inter-server message from it. Migration based on splitting can be
used to improve Web server reliability with only a small penalty in performance. Additional
benefits of splitting such as Data Server anonymity and load sharing can also be achieved with
this approach to migration. We first implement Web server migration using split bare PC
Web servers [38] that run the server applications with no operating system or kernel support. We,
then, conduct preliminary tests to evaluate performance with migration in a test LAN where the
split bare PC servers are located on different subnets. Protocol splitting is especially convenient to
implement on bare machine computing systems due to their intertwining of protocols and tasks.
However, the migration technique based on splitting is general, and can be implemented using
conventional servers that require an operating system or kernel to run [39]. More details of
migration and role changeover are given in a Split-protocol technique for Web Server Migration
[38]. For Web server migration, inter server packet would be sent with a special massage,
indicating that the CS is going to crash, and the TCB entry moved from one CS to another CS* ,
enabling the latter to take over the connection. Migrating server content in this manner and
requiring that CS and CS* use the same IP. address for two-way communication, poses a new
challenge: now CS* must be able to send and receive packets with the IP of CS, which has a
different prefix. Furthermore, the client must remain unaware that migration or protocol splitting
has occurred. The main focus of this work is to address these issues and migrate (or transfer) a
client connection to a new server, when the current connection server detects that it is going down
or is being taken down. The means by which the server might detect its imminent failure is
beyond the scope of this paper.
8. DESIGN AND IMPLEMENTATION
Split-protocol client server architecture design and implementation differ from traditional client
server designs. As the traditional client server architecture is modified in this approach, we have
designed and implemented a client server based on a bare PC, where there is no traditional OS or
kernel running on the machine. This made our design simpler and easier to make modifications to
conventional protocol implementations. Figure 6 shows a high level design structure of client
server architecture in a bare PC design. Each client and a server consist of a TCP state table
(TCB), which consists of the state of each request. Each TCB entry is made unique by using a
hash table with key values of IP address and a port number. The CS and DS TCB table entries are
referred by IP3 and Port#. The Port# in each case is the port number of the request initiated by a
client. Similarly, the TCB entry in the client is referenced by IP1 and Port#.
The TCB tables form the key system component in the client server designs. A given entry in this
table maintains complete state and data information for a given request. This entry requires about
160 bytes of relevant information and another 160 bytes of trace information that can be used for
traces, error, log, and miscellaneous control. This entry information is independent of its
computer and can be easily migrated to another PC to run at a remote location. This approach is
not the same as process migration [5] because there is no process information contained in the
entry.
The client does not know IP2 address to communicate during the data transmission. We solved
this problem by including the IP2 address in the HTTP header using a special field in the header
format. In this design, a client could get data from any unknown DS and it can learn the Data
Server’s IP address from its first received data (i.e., header). This mechanism simplifies the

75
design and implementation of Split-protocol client server architecture. This technique also allows
the CS to distribute its load to DSs based on their CPU utilization without implementing a
complex load balancing technique [4]. By implementing limited ACKs, the linear performance
improvement continues up to 4 DSs [5]. This is also expected as CS poses no bottleneck for 4
DSs. For limited ACKs, the number of DSs connected to a single CS can be estimated to be 13 by
extrapolating the CS CPU time and the number of DSs.
Normally, both the intermediary and victim of this attack may suffer degraded network
performance either on their internal network or on their connection to the Internet. Performance
may reduce to the point that the network cannot be used. Most of the time, the attacker identifies
the primary operating system from data structure of communication packets, which can further
maximize the attack. Protocol-splitting, in our study, hides the underlying operating system
thereby making it more difficult for a Smurf attacker to circumvent. Furthermore, implementing
protocol-splitting on BMC makes it harder to run a DDoS agent or handler code designed to work
on operating systems.
Figure 6. Design Structure
Figure 7. DDoS Defense Architecture

76
The anonymous nature of Data Server and migratory capability within single connections of
Split-protocol architecture offers a strong defensive mechanism against Smurf attacks.
9. EXPERIMENTAL SETUP
The experiments were conducted using a prototype server cluster consisting of Dell Optiplex
GX260 PCs with Intel Pentium 4, 2.8GHz Processor, 1GB RAM, and an Intel 1G NIC on the
motherboard. All systems were connected to a Linksys 16-port 1 Gbps Ethernet switch. Bare PC
Web clients capable of generating 5700 requests/Sec were used to create the server workload.
While attacking the server, there was not any other traffic going to the server, which was not
connected directly to the Internet. The experiment was done without any network intrusion
prevention and detection system or any firewall installed, so that all packets from the client
machine that reached the server were captured. From the wire shark, it was possible to see that no
packets were lost during the capture in the server. The experiment was repeated several times, by
varying LOIC/ parameters. The first three experiments tested the TCP option with 10, 100 and
1000 parallel connections. The fourth experiment tested the attack over the HTTP protocol with
100 parallel connections. A second experiment was conducted using HOIC with varying number
of thread 1, 2, 3, 4, 5 and 30 keeping the same security setting as the LOIC experiment.
10. PERFORMANCE MEASUREMENT
Figure 8, describes protocol transaction time for 4k resource file size on WAN subnet. We have
compared transaction times with No-Split, Split system and M-Split system. The transaction time
depends on the distance between client and server on a given network topology. In Split
architecture, the server component (CS, RA, and DS) is located at different subnets. For
convenience, we have placed CS at the same distance but varied DS by plus or minus one hop.
We have noted there is a delay 976 microseconds when DS is placed one hop further than the CS.
Furthermore, we have observed that when DS is placed closer to the client in comparison to CS
distance, the transaction time was lesser by 674 microseconds. For larger file, multiple DSs
involved to get faster transmission of data [3].
Figure 8. Protocol Transaction Time

77
As shown in figure 9, we have studied CPU utilization of three systems (Single system, Split
system (CS-DS) and M-Split system (CS- RA-DS) at 6000 requests /Sec. CPU of Single system
is almost at saturation point with 95%, Split system 45% and M-Split system is only at 20% CPU
utilization. For availability, point of view M-Split system is freely available. In addition, for
bigger resource file size of 128K single server can just handle up to 735requests/second and
CPU utilization reaches 95%, whereas CPU utilization of CS in Split system is 5% and in M-
Split just 1% .
Figure 10 shows the total CPU utilization of all components of the systems for 4K resource file
size. Overall CPU utilization of M-Split system is 87% and Split system 88% and Single system
95%
Figure 9. CPU Utilization three systems at 6000 requests /Sec.
Figure 10 shows the total CPU utilization of all components of the systems for 4K resource file
size. Overall CPU utilization of M-Split system is 87% and Split system 88% and Single system
95%.
Figure 10. CPU Utilization overall systems at 6000 requests /Sec.

78
Figure 11 illustrates the CPU utilization for varying LOIC/ parameters for TCP option with 10,
100 and 1000 parallel connections with five clients. The CPU utilization of CS is less than 5%
and DS utilization was 10% and attack over the HTTP protocol with 100 parallel connections
CS utilization around 5% and DS utilization is around 70%. And we found there is no effect of
UDP protocol 10,000 threads CS CPU utilization was around 40% for the DS were around 1%
only. This behavior is same as genuine clients, and we do not see the effect of DDoS attack even
though LOIC clients are connected on the same LAN. Figure 12 shows the utilization CS/DS
under HOIC attack with five clients, there is also no effect up to five threads; however, for 30
threads CPU is 96%, which was expected. The both experiments with LOIC and HOIC, CS and
DS were performing normal servers as if there is no DDoS attack.
Figure 11. CPU utilization CS/DS under LOIC attack with five clients
Figure 12. CPU utilization CS/DS under HOIC attack with five clients
11. CONCLUSION
In multiple ways, the DDoS attack involves the attacker, the intermediary, and the victim.
Connection server in Split-protocol architecture does not reserve any resource for all requests it

79
receives, so it can handle many connection requests. In our experiment, we have noted that for
a large resource file, CS CPU utilization was only 1% as compared to 95% of the single
server. Since there are many DSs in the system, they can handle very large loads without
compromising services. Furthermore, the self-delegating mechanism in the split-protocol allows
the server to deny any additional request to process and changes his identity within a single TCP
connection. As shown in Figure 1a, toggling the same IP address between multiple servers
minimizes the incoming load on Split-servers. As shown in the figure 7, client only
communicates with the CS, and only handles SYN and does not reserve any resource for
connection requests, therefore, logically CS appears very large. CS is capable of handling many
fold more requests than the number of requests generated by genuine clients or DDoS attackers.
ACKNOWLEDGEMENTS
The authors would like to thank Dr. Ramesh Karne, Dr. A. L. Wijesinha and IT department at
Shaw University, just everyone!
Authors
Dr. Bharat Rawal, has conducted research in the area of computer networks, including
wireless networks, Split- protocol designs and analyzes, and network performance
evaluations, HPC and Network security . He was the author and co-author in several
papers in networking and security area. Currently, he has focused on solving a big
integers and data compression in Split-protocol infrastructure. He is now server as CIS
program coordinator and teaches computer science courses at Shaw University.
REFERENCES
[1] Koutepas, G., Stamatelopoulos, F., & Maglaris, B. (2004). Distributed management architecture for
cooperative detection and reaction to DDoS attacks. Journal of Network and Systems Management,
12 (1), 73-94.
[2] B. Rawal, R. Karne, and A. L. Wijesinha. “Splitting HTTP Requests on Two Servers,” The Third
International Conference on Communication Systems and Networks: COMPSNETS 2011, January
2011, Bangalore, India.
[3] Bharat. Rawal, Lewis I. Berman and H.Ramcharan, “Multi-Client/Multi-Server Split Architecture,”
Accepted in The International Conference on Information Networking (ICOIN 2013), Jan 28-30,
[4] B. Rawal, R. Karne, and A. L. Wijesinha. “ Mini Web Server Clusters for HTTP Request Split,” 13th
International Conference on High performance Computing and Communication, HPCC-2011, Banff,
Canada, I Sept 2-4,2011
[5] B. Rawal, R. Karne, and A. L. Wijesinha. “ Split Protocol Client/Server Architecture,”
The 17th IEEE Symposium on Computers and Communications - ISCC 2012, 1 - 4 July
2012Cappadocia, Turkey.
[6] K. K. Wan and R.Chang, "Engineering of a Global Defence Infrastructure for DDoS Attacks," in
Proc.
of IEEE International Conference on Networking, Aug. 2002
[7] Q. Zhang and R. Janakiraman, "Indra: A Distributed Approach to Network Intrusion Detection and
Prevention," Washington University Technical Report # WUCS-01-30, 2001
[8] D. Sterne, K. Djahandari, B. Wilson, B. Babson, D. Schnackenberg, H. Holliday, and T. Reid,
"Autonomic Response to Distributed Denial of Service Attacks," In Proceedings of the 4th
International Symposium on Recent Advances in Intrusion Detection, RAID 2001, Davis, CA,
USA,pp.134-149, October 2001
[9] D. Schnackenberg, K. Djahandari, and D. Sterne, "In Proceedings of the DARPA Information
Survivability Conference and Exposition (DISCEX II), Anaheim, CA, USA, January 2000
[10] V. Paxson. (1999). Bro: A System for Detecting Network Intruders in Real-Time. International
Journal of Computer and Telecommunication Networking. 31 (24). pp. 2435-2463.

80
[11] M. Roesch, “Snort-Lightweight Intrusion Detection for Networks,” in the Proceedings of the
USENIX Systems Administration Conference (LISA ’99), Nov.1999, pp.229- 238.
[12] T. M. Gil , M. Poletto, “Multops: a data-structure for bandwidth attack detection, “in the
Proceedings of the
10th USENIX Security Symposium, Washington, DC, USA, 2001, pp. 23-38.
[13] Martin Roesch. Snort - lightweight intrusion detection for networks.” http://www.snort.org accesse
on Jully 11,2013
[14] Chonka, Ashley, Jaipal Singh, and Wanlei Zhou. "Chaos theory based detection against network
mimicking DDoS attacks." Communications Letters, IEEE 13.9 (2009): 717-719.
[15] Abouzakhar, N., et al. "Bayesian learning networks approach to cybercrime detection." proceedings
of the 2003 PostGraduate Networking Conference (PGNET 2003), Liverpool, United Kingdom. 2003.
[16] Hal Burch and Bill Cheswick, “ Tracing anonymous packets to their approximate source,”In
Proceedings of the USENIX Large Installation Systems Administration Conference, pages 319–327,
New Orleans, USA, Decemeber 2000.
[17] H Alefiya, J Heidemann, and C Papadopoulos, "A framework for classifying denial of service
attacks," 2003 conference on Applications, technologies, architectures, and protocols for Computer
Communications. ACM, 2003.
[18] Y. Xu and R. Guerin, “On the robustness of router-based denial-ofservice (dos) defense systems,”
SIGCOMM Comput. Commun. Rev., vol. 35, no. 3, pp. 47–60, 2005.
[19] A Chesla,"Generated anomaly pattern for HTTP flood protection." U.S. Patent No. 7,617,170. 10
Nov. 2009
[20] S M Specht and Ruby B. Lee. "Distributed Denial of Service: Taxonomies of Attacks, Tools, and
Countermeasures." In ISCA PDCS, pp. 543-550. 2004.
[21] Y. Chen, K. Hwang, W. Ku. (2007, December). Collaborative Detection of DDoS Attacks over
Multiple Network Domains. IEEE Transaction on Parallel and Distributed Systems. 18 (12), TPDS-
0228-0806.
[22] L. Feinstein, D. Schnackenberg, R. Balupari, D. Kindred, “Statistical Approaches to DDoS Attack
Detection and Response, ” in the Proceedings of DISCEX’03, Washington, DC, USA, 2003, vol. 1,
pp. 303-314.
[23] A. Lakhina, M. Crovella, and C. Diot. (2005). Mining Anomalies Using Traffic Feature Distributions.
ACM SIGCOMM Computer Communication Review. 35(4). 217-228, 2005.
[24] Dynamic and Auto Responsive Solution for Distributed Denial-of-Service Attacks Detection in ISP
Network
[25] K.Kuppusamy and S.Malathi, “An Effective Prevention of Attacks using GI Time Frequency
Algorithm under DDoS”, IJNSA journal, Vol. 3, No. 6, November 2011, PP. 249-257.
[26] K. Park and H Lee, “On the Effectiveness of Probabilistic Packet Marking for IP Trackback under
Denialof Service Attack,” Network Systems Lab, Department of Computer Sciences, Purdue
University, West Lafayette.
[27] Team Cymru Inc “Bogon route server project”, http: //www.cymru.com/BGP/bogon-
rs.htm.Accessed on July 11, 2013.
[28] K. Park and H Lee, “On the Effectiveness of Probabilistic Packet Marking for IP Trackback under
Denialof Service Attack,” Network Systems Lab, Department of Computer Sciences, Purdue
University, West Lafayette.
[29] J. Li, J. Mirkovic, M. Wang, P. Reiher and L. Zhang, “SAVE: Source Address Validity Enforcement
protocol,” In IEEE INFOCOM, Vol.6, No.2, June 2002, pp. 81-95.
[30] S. Kandula, D. Katabi, M. Jacob and A. Berger, “Surviving Organized DDoS Attacks that Mimic
Flash Crowds,” NSDI'05 Proceedings of the 2nd conference on Symposium on Networked Systems
Design & Implementation, 2005, Vol.2, PP 287 – 300.
[31] D. Moore, G. Voelker and S. Savage “Inferring internet Denial-of-Service activity,” In proceedings
of 10th Usenix Security Symposium, August 2001, PP.9-22.
[32] R. Pang, V. Yegneswaran, P. Barford, V. Paxson and L. Peterson, “Characteristics of internet
background radiation,” In Proceedings of ACM Internet Measurement Conference, October 2004.
[33] M. Dalal,“Improving TCP's robustness to blind in-window attacks,” Internet- Draft, May 2005, work
in progress.
[34] R. Beverly and S. Bauer. “The Spoofer Project: Inferring the extent of Internet source address filtering
on the internet,” In Proceedings of Usenix Steps to Reducing Unwanted Traffic on the Internet
Workshop SRUTI'05, 2005, PP.53-59.

81
[35] K. Kuppusamy and S.Malathi, “Prevention of Attacks under DDoS Using Target Customer Behavior
“IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 2, September 2012
[36] S. Specht, and R.lee “Distributed Denial of Service: Taxonomies of Attacks, Tools and
Countermeasures,”
[37] Harold Ramcharn and Bharat Rawal “Smurf Security Defense Mechanism with Split-protocol” The
Seventh International Conference on Emerging Security Information, Systems and Technologies
SECURWARE 2013.
[38] L. He, R. K. Karne, and A. L. Wijesinha, “Design and Performance of a bare PC Web Server,”
International Journal of Computer and Applications, vol. 15, pp. 100-112, Acta Press, June 2008.
[39] B. Rawal, R. Karne, and A. L.Wijesinha,H.Ramcharan and Songjie Liang. "A Split-protocol
Technique for Web Server Migration,” The 2012 International workshop on Core Network
Architecture and protocols for Internet (ICNA-2012) October 8-11, 2012, Las Vegas, Nevada, USA .
[40] S Ratnaparkhi and A Bhangee, “Protecting Against Distributed Denial of Service Attacks and its
Classification: An Network Security Issue,” IJCSI International Journal of Computer Science Issues,
Vol. 3, Issue 1, Jan 2013
[41] http://www.javvin.com/networksecurity/SmurfAttack .html. Accessed on July 12, 2013.
[42] P. Jain et al., “Mitigation of Denial of Service (DoS) Attack,” IJCSI International Journal of
Computer Science Issues, Vol. 9, Issue 5, No 2, September 2011.
[43] J. Mirkovic and P. Reiher, “A Taxonomy of DDoS Attack and DDoS Defense Mechanisms,” ACM
SIGCOMM Computer Communications Review, Volume 34, Number 2, April 2004, pp. 39-53
[44] T.Peng et al, “Survey of Network-based Defense Mechanisms Countering the DoS and DDoS
Problems,” ACM Transactions on Computational Logic, Vol. 2, No. 3, 09 2006, Pages 1
[45] D Slee, “ Common Denial of Service Attacks,” Jul 10, 2007.
[46] J. Mirkovic and P. Reiher, “A Taxonomy of DDoS Attack and DDoS Defense Mechanisms,” ACM
SIGCOMM Computer Communications Review, Volume 34, Number 2, April 2004, pp. 39-53
[47] F Gong, “Detection Techniques: Part III Denial of Service Detection,” McAfee Network Security
Technologies Group Jan 03

Augmented split –protocol; an ultimate d do s defender

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (9)

Similar a Augmented split –protocol; an ultimate d do s defender

Similar a Augmented split –protocol; an ultimate d do s defender (20)

Último

Último (20)

Augmented split –protocol; an ultimate d do s defender