International Journal of Engineering Trends and Technology (IJETT) – Volume 4 Issue 7- july 2013
Blocking of Flooding Attacks: Using Active Internet
Traffic Filtering Mechanism
Deepthi.S#1, Prashanti.G*2, Sandhya Rani.Kr#3
#
Assistant Professor, Department of Computer Science and Engineering
Vignan’s Lara Institute of Technology and Science
Vadlamudi, Guntur, India
Abstract— Now a day there is a dramatic increase in the frequency of
distributed denial-of-service (DDoS) attacks. These attacks are an acute
contemporary problem, with few practical solutions available today; one
of the Fundamental limitations of the Internet is which allows anonymous
people to access the network. Whenever the attacker wants to block the
receiver for some amount of time they will send a disruptive flow which
halt the receiver and they consume receiver’s network link resources.
Critical infrastructures and businesses alike are vulnerable to DoS
attacks flood of data that can incapacitate their networks with traffic
floods. Unfortunately, current mechanisms require per-flow state at
routers, ISP collaboration, or the deployment of an overlay
infrastructure to defend against these events. In a bandwidth-flooding
attack. A large number of compromised sources send high-volume traffic
to the target with the purpose of causing congestion in its Receivers
circuit and disrupting its legitimate communications. We proposed a
mechanism called a enhanced Active Internet Traffic Filtering (AITF), a
network layer Defense mechanism against such attacks [3]. AITF
preserves a significant fraction of a receiver’s bandwidth in the face of
bandwidth flooding .AITF can maintain their connectivity between the
nodes that are connected in the network in the face of Bandwidth
flooding. Hence, the network-layer of the Internet can provide an
effective, Scalable and incrementally deployable solution against
bandwidth-flooding attacks.
Keywords— Denial of Services Defences, Network level security
and Protection, Traffic Filtering. Flooding
I.
INTRODUCTION
In a bandwidth-flooding attack, compromised
sources send high-volume traffic to the target with the purpose
of causing congestion in its Receivers circuit and interrupting
its legitimate communications. Active Internet Traffic
Filtering (AITF), a network-layer defence mechanism against
such attacks. AITF enables a receiver to contact misbehaving
sources and ask them to stop sending it traffic; each source
that has been asked to stop is policed by its own Internet
service provider (ISP), which ensures its compliance. An ISP
that hosts misbehaving sources both supports AITF (and
accepts to police its misbehaving clients), or risks losing all
access to the complaining receiver—this is a strong incentive
to cooperate, especially when the receiver is a popular publicaccess site.
Real-life reports complement such analysis: The first
well documented incident we are aware of is the 2001 attack
against the Gibson Research Corporation (GRC) web site. To
block the flood, GRC analysed the undesired traffic,
determined its sources, and asked from their Internet service
provider (ISP) to manually install filters that blocked traffic
from these sources; in the meantime, their site was
unreachable for more than 30hours.More recent attacks are
ISSN: 2231-5381
less well documented (the victims are increasingly unwilling
to reveal the details), but hint that botnet sizes have increased
beyond thousands of sources, while undesired traffic is harder
to identify. There are two basic steps in stopping a bandwidthflooding attack:
1) Identifying undesired traffic
2) And Blocking it.
To prevent undesired traffic from causing legitimate-traffic
loss, it must be blocked before entering the target’s tail circuit,
for example, inside the target’s ISP. The first solution that
comes to mind is to automate the approach followed by GRC:
one can imagine an ISP service, in which a flooding target
sends filtering requests to its ISP, and, in response, the ISP
installs wire-speed filters (i.e., filters that do not affect
packet-forwarding performance) in its routers to satisfy these
requests; each filtering request specifies traffic from one
undesired-traffic source to the target
AITF preserves a significant fraction of a receiver’s
bandwidth in the face of bandwidth flooding, and does so at a
per-client cost that is already affordable for today’s ISPs; this
per-client cost is not expected to increase, as long as botnetsize growth does not outpace Moore’s law. And also show
that even the first two networks that deploy AITF can
maintain their connectivity to each other in the face of
bandwidth flooding. We can say that the network-layer of the
Internet can provide an effective, scalable, and incrementally
deployable solution against bandwidth-flooding attacks.
Figure1. Typical locations for an intrusion detection system
http://www.ijettjournal.org
Page 3031
International Journal of Engineering Trends and Technology (IJETT) – Volume 4 Issue 7- july 2013
IDS should be placed in Network Topology:
Depending upon our network topology, we may want to
position intrusion detection systems at one or more places. It
also depends upon what type of intrusion activities we want to
detect: internal, external or both. For example, if we want to
detect only external intrusion activities, and we have only one
router connecting to the Internet, the best place for an
intrusion detection system may be just inside the router or a
firewall. If we have multiple paths to the Internet, we may
want to place one IDS box at every entry point. However if
we want to detect internal threats as well, we may want to
place a box in every network segment. In many cases we don’t
need to have intrusion detection activity in all network
segments and we may want to limit it only to sensitive
network areas. Figure 1 shows typical location where we can
place an intrusion detection system.
II.
LITARATURE SURVEY
Distributed denial-of-service attacks (DDoS) creates an
immense threat to the Internet, and consequently many
defense mechanisms have been proposed to combat them.
Attackers constantly modify their tools to bypass these
security systems, and researchers in turn modify their
approaches to handle new attacks. The DDoS field is
evolving quickly, and it is becoming increasingly hard to
grasp a global view of the problem.
We recently witnessed some attacks In December 2003, an
attack kept SCO's web site practically unreachable for more
than a day [13]; in June 2004, another attack _flooded
Akamai's name servers, disrupting access to its clients for 2
hours, including the Google and Yahoo search engines [14]; a
month later, an attack _flooded Double Click's name servers,
disabling ad distribution to its 900 clients for 3 hours [8].
Considering that network downtime costs hundreds of
thousands of dollars per hour [17], such incidents can translate
into millions of dollars of lost revenue for the victim. Yet, the
DDoS problem remains unsolved.
Flooding attacks, where an attacker attempts to exhaust
the downstream bandwidth of a server, are particularly
difficult to defend against. Unlike other forms of DDoS such
as SYN-flooding, computation attacks or request floods, the
downstream bandwidth is not under a web-server’s control.
And therefore, while there exist server side protection
mechanisms to protect server resources, such as syn-cookies
[18] and secure admission control schemes, few practical
solutions to defend against flooding exist today.
Part of the problem is the difficulty in pushing filtering
requests into the network where there is sufficient bandwidth
to handle the flood. An in-network element cannot distinguish
a single packet as being part of a legitimate flow without
doing flow tracking, a tricky proposition [1]
That traditionally requires per-flow state which may be
untenable for a high-bandwidth link. Other solutions are easily
fooled by source spoofing [1] or require massive architectural
changes.
A. Filters In Existing System
To prevent undesired traffic from causing legitimate-traffic
loss, it must be blocked before entering the target’s tail circuit,
for example, inside the target’s ISP. The first solution that
comes to mind is to automate the approach followed by GRC:
one can imagine an ISP service, in which a flooding target
sends filtering requests to its ISP, and, in response, the ISP
installs wire-speed filters (i.e., filters that do not affect packetforwarding performance) in its routers to satisfy these requests;
each filtering request specifies traffic from one undesiredtraffic source to the target. The problem with this approach is
that it requires more resources than ISPs can afford: Wirespeed filters in routers are a scarce resource, and this is not
expected to change in the near future.
Modern hardware routers forward packets at high rates
that allow only few lookups per forwarded packet; to reduce
the number of per-packet lookups, router manufacturers store
filters— as well as any state that must be looked up per packet,
e.g., the router’s forwarding table—in TCAM (ternary content
addressable memory), which allows for parallel accesses.
However, because of its special features, TCAM is more
expensive and consumes more space and power than
conventional memory; as a result, a router line card or
supervisor-engine card typically supports a single TCAM chip
with tens of thousands of entries.
To block the flood, GRC analysed the undesired traffic,
determined its sources, and asked from their Internet service
provider (ISP) to manually install filters that blocked traffic
from these sources.
Wire-speed filters in routers are a scarce resource, and this is
not expected to change in the near future. Modern hardware
routers forward packets at high rates that allow only few
lookups per forwarded packet; to reduce the number of perpacket lookups, router manufacturers store filters as well as
any state that must be looked up per packet.
In the figure2 attacker sends large number of packets to the
target through the routers and there is no chance to the other
node to send packets or receive the packets from that same
node so that path is congested due to the over flow of sending
packets from the attacker. Then we overcome this problem by
using the filters for stopping the attacks for some amount of
time.
Even though packets is continuously sending by the attacker
then AITF protocol Block that node.
Congested
Figure2. Blocking path through continuous data
ISSN: 2231-5381
http://www.ijettjournal.org
Page 3032
International Journal of Engineering Trends and Technology (IJETT) – Volume 4 Issue 7- july 2013
B. Ternary Content Addressable Memory.
TCAM = Ternary Content Addressable Memory.
 Special type of computer memory used in certain
very high speed searching applications.
 Where Content Addressable Memory describes a
chip design that allows for a search of entire memory
in a single operation.
 TCAM can perform a wide search in memory in a
very short fixed period of time typically less than
20ns.
 TCAM memory is expensive to build there
manufactures use a little as possible.
 TCAM chips use a lot of power and high heat
dissipation.
III.
PROPOSED METHODOLOGY
In this paper, we present Enhanced Active Internet
Traffic Filtering (AITF),[2] a network-layer filtering
mechanism that enables a receiver to explicitly deny tailcircuit access to misbehaving sources, while addressing these
challenges. We show that AITF enables a receiver to preserve
on average more than 80% of its tail circuit in the face of a
SYN-flooding attack that exceeds the target’s tail-circuit
capacity by a factor of 10.
A. Goals and Objectives of the proposed system
In this paper propose and develop an Active
Internet Traffic Filtering. Proposed model should be a
network- layer filtering mechanism that would preserve a
significant fraction of a receiver’s tail circuit in the face of
bandwidth flooding, while requiring a reasonable amount of
resources from participating ISPs. We should observe the
following Considerations on proposed model.
 The proposed should allow a receiver to preserve on
average 80% of its tail circuit in the face of a SYNflooding attack that would have ten times the rate of
its capacity.
 Should reduce the CPU Cost. Logics (AITF) should
be modifiable at any instance of time
 Should be able to detect the attacks that cause server
to crash
 Should be able to detect the flooding and bandwidth.
B.
Active Internet Traffic Filtering (AITF) A networklayer filtering Mechanism.
Source S sends undesired traffic to receiver R through
routers Sgw ( in S’s domain ) and Rgw (in R’s domain) SNET
and RNET have deployed AITF ( and the underlying pathidentification mechanism). R identifies {S Sgw Rgw R} as an
undesired flow. As shown in Figure 3
Here we divided entire working functionality into following
modules.
C. Path Identification:
The domain-level path of a received packet as the
sequence of border routers that forwarded the packet; a border
router is a router that interconnects different administrative
domains. I assume that there exists a (not necessarily globally
deployed) path-identification mechanism that enables
participating domains to associate the packets they forward
with some form of identity, such that the receiver of a packet
can combine these identities and reconstruct part of the
packet’s domain-level path.
E.g., in an early deployment scenario, where only and
have deployed path identification, the receiver can identify as
part of the domain-level path, to provide path identification
via record route, i.e., by enabling routers to mark forwarded
packets, such that a packet’s path is specified inside its
headers: NIRA , WRAP , and the Points of Control approach
[8] all provide sufficient path identification for AITF.
Whatever the underlying record-route mechanism, i do not
assume that it is globally deployed; the only domains that
have to deploy it are the ones that also deploy AITF.
D. Undesired-Traffic Identification:
We define a packet flow as a sequence of packets with a
common source IP address, domain- level path specification,
and destination IP address;
use notation {source domain_level_path destination} to
specify a flow. For instance, in Fig. 1, traffic with source IP
address, domain-level path specification, and destination IP
address constitutes a flow, denoted by. We assume that a
receiver can run an “undesired-flow identification system,”
which takes as input incoming traffic and outputs
specifications of undesired flows; a flow is classified as
undesired once the receiver decides it does not want to receive
it for a certain amount of time.
From this assumption on the fact that existing technology
already identifies undesired flows in terms of their source and
destination prefixes (and potentially other header fields in use
today); once the domain-level path is specified inside a
packet’s headers, it should be possible to extend this
technology to take it into account.
E. Path-Based Wire-Speed Filtering:
We assume that a router that runs the AITF protocol
(which, as i will see, is necessarily a border router) can install
a wire-speed filter that blocks all traffic matching a certain
flow specification. we base this assumption on the fact that
modern routers already use wire speed filters to block packets
based on their IP and transport layer headers; once the
domain-level path is specified inside a packet’s headers, it
Figure 3. Source S sends undesired traffic to receiver R
ISSN: 2231-5381
http://www.ijettjournal.org
Page 3033
International Journal of Engineering Trends and Technology (IJETT) – Volume 4 Issue 7- july 2013
should be possible to use the same technology to filter the
packet based on its domain-level path.
F. Provider-Client Message Authentication
A provider can verify the authenticity of messages
sent from its own clients, and a client can verify the
authenticity of messages sent from its own provider. This can
be achieved with message authentication codes or three-way
handshakes.
G.
Non-Compromised Path:
Here for a source-receiver pair to be able to
communicate, the network elements (typically routers) that are
on the path between them must not be compromised. Our
rationale is that, once a router gets compromised, all the
communications served by it are at its mercy: the router can
drop their traffic or hijack their TCP connections. Of course, if
a source-receiver pair can communicate over multiple paths,
and at least one of them is not compromised, they should be
able to maintain their communication— akin to how multipath communication between access points and clients
increases attack resilience in the Stateless Multipath Overlays
approach. Combining multi-path with AITF is part of our
future work.
H. The Basic AITF Protocol
H.1 Players
AITF involves four players per undesired flow, illustrated in
the above figure 3
• The receiver R is the target of the undesired flow.
• The source S is the node generating the undesired flow.
• The receiver’s gateway Rgw is a border router located in R’s
ISP, on the path from S to R, before R’s tail circuit.
Note that Rgw is not significantly affected by the
attack; if it were (i.e., if its own tail circuit were congested),
Rgw itself would be the “receiver,” while the role of the
receiver’s
gateway would be played by another router
upstream.
• The source gateway Sgw is a border router located in S ’s
ISP, on the path from S to R. .
These four players communicate through AITF
messages, which include one or more filtering requests. Each
filtering request includes the specification of an undesired
flow and the amount of time (called the filtering window) for
which the Requester does not want to receive F.
For simplicity, we make three temporary assumptions they are
 The source gateway Sgw cooperates with the
receiver’s gateway Rgw to help the Receiver.
 Filtering requests are not malicious, i.e., they indeed
originate from the specified undesired-traffic receiver
R and correspond to traffic indeed sent from the
specified source.
 The receiver can trust the path specified inside each
received packet, i.e., it knows the true source S and
the true source gateway Sgw for each undesired flow.
Once a receiver R identifies an undesired flow F, it
contacts the corresponding source S and asks it to stop
sending F for an amount of time Wf. R’s request is
ISSN: 2231-5381
propagated through Rgw and Sgw, which temporarily block F to
immediately protect R until S complies.
Filtering request
R
Forward
request
Forward
request
S
To block F
For Wf
Rgw
Sgw
Installs temporary filters
And block F for time
Installs temporary filters
And block F for time
Tdr << Wf
Tds << Wf
Figure4. Algorithm overview
More specifically, R sends a filtering request to its
gateway Rgw to block F for Wf . In response, Rgw installs a
temporary filter that blocks F for time Tdr<<Wf and forwards
the request to the source gateway Sgw ; once Sgw satisfies
the request,
Rgw removes its temporary filter. Similarly, Sgw installs a
temporary filter that blocks F for time Tds<<Wf , logs the
request for Wf , and forwards the request to S ; once S
satisfies the request, Sgw removes its temporary filter.
If S does not cooperate (i.e., continues to send F),
classifies S as non -cooperating and blocks all S -originated
traffic. If S “pretends” to cooperate.
R sends a second filtering request against S; upon
receiving this second Request, Sgw checks its log, detects that
has already been told to stop sending F, classifies S as noncooperating, and blocks all S -originated traffic. as shown in
figure 4
IV.
SIMULATION RESULTS
In this section, we use simulation to analyse the effect of
undesired traffic on AITF-enabled receivers and illustrate the
effectiveness of AITF against bandwidth flooding.
We developed site and we followed below steps
 When users Login into the popular website he can
view or download the books stored in that website.
 Any Number of users can download the books at
the same time

While any user downloading the books initially the
request being serve by all the nodes.
 At one particular instance attacker attack one node i.e
connected in the network and send more number of
packets continouly from the same IP address.
 At that time AITF Filter in that attacked node block
that node from the network and provides other path
for sending the requests.
http://www.ijettjournal.org
Page 3034
International Journal of Engineering Trends and Technology (IJETT) – Volume 4 Issue 7- july 2013

Even though the node is blocked user impact wont be
there .
As there should be no user impact the other nodes
serving the requests .

30
IN1
25
IN2
IN3
20
IN4
IN5
15
IN6
IN7
10
IN8
IN9
5
IN10
0
5sec
10sec
15sec
20sec
25sec
30sec
35sec
40sec
45sec
Figure 5 Graph shows Flow of traffic at all nodes and attack at one node.
In the Figure 5 we are showing ten nodes that are connected
in the network.
In the above graph all requests are serving through all the
nodes while at IN3 node at the time of 22 sec the attacker
send more packets from that particular node then AITF.
Immediately block that node even though the node is
blocked requests are serving through the other nodes. Here
user impact won’t be there though the floe is continuous then
AITF blocks that particular node.
25
20
Good Traffic
15
Bad Traffic
10
5
More specifically, we showed the following:
1. AITF offers filtering response time equal to the one-way
delay the victim to the victim's gateway. I.e., a victim can
have an undesired flow blocked within milliseconds.
2. AITF offers filtering gain on the order of hundreds of
blocked flows per used filter. I.e., a router can block two
orders of magnitude more flows than it has wire-speed filters.
For example, suppose eBay is receiving a million undesired
flows; with 10,000 filters, eBay's gateway can have all flows
blocked within 100 seconds. In the worst-case scenario,
eBay's gateway blocks all traffic from each domain that hosts
attack sources and refuses to filter their traffic, which (in
today's Internet) requires a few tens of thousands of filters.
3. A set of malicious nodes can practically not abuse AITF to
disrupt communication from node A to node B, as long as they
are not located on the path from A to B. This holds even
during initial deployment, where most Internet domains are
AITF-unaware.
The idea behind AITF is that the Internet does have
enough filtering capacity to block large amounts of undesired
flows -- it is just that this capacity is concentrated close to the
attack sources. AITF enables service providers to "gain
access" to this filtering capacity and couple it with a
reasonable amount of their own filtering resources, in order to
protect their customers in the face of increasingly distributed
denial-of-service attacks.
The feasibility of AITF shows that the network-layer
of the Internet can provide an effective, scalable, and
incrementally deployable solution to bandwidth-flooding
attacks. But still some flow based attacks may not be detected
effectively by the AITF. So, there should be some
enhancements made to AITF so that it can defend all flow
based attacks.
0
2sec
6sec
10sec
ACKNOWLEDGMENT
14sec
Figure 6: Graph shows the Flow of traffic at single node.
See figure 6 represents only single node
At 2sec time good traffic is going on smoothly at 7 sec
attacker spoof this node and send more traffic from same IP
address then bad traffic is more then the good traffic . Then
ISP of that particular node installs filters to stop the flow even
though the floe is continuous then AITF blocks that particular
node.
V.
CONCLUSION AND FUTURE ENHANCEMENTS
Enhanced Active Internet Traffic Filtering (AITF), a
mechanism for filtering highly distributed denial-of-service
attacks. We showed that AITF can block a million undesired
flows, while requiring only tens of thousands of wire-speed
filters from each participating router -- an amount easily
accommodated by today's routers. It also prevents abuse by
malicious nodes seeking to disrupt other nodes'
communications.
ISSN: 2231-5381
We take this opportunity to acknowledge those who have
been great support and inspiration through the research work.
Our sincere thanks to Mrs.B.RenukaDevi Head of the
department of CSE to her diligence and motivation. Special
thanks to Vignan’s Lara Institute of Science and Technology,
for giving us such a nice opportunity to work in the great
environment and for providing the necessary facilities during
the research and encouragement from time to time. Thanks
to our colleagues who have been a source of inspiration and
motivation that helped to us. And to all other people who
directly or indirectly supported and help us to fulfill our task.
Finally, we heartily appreciate our family members for their
motivation, love and support in our goal.
[1]
[2]
REFERENCES
Flow-Cookies: Using Bandwidth Amplification to Defend Against
DDoS Flooding Attacks Martin Casado, Pei Cao Stanford University
{casado,cao}@cs.stanford.edu.
Active Internet Traffic Filtering: Real-Time Response to Denial-ofService Attacks ,Katerina Argyraki David R. Cheriton, Distributed
Systems
Group,
Stanford
University.Fargyraki,
cheritong@dsg.stanford.edu
http://www.ijettjournal.org
Page 3035
International Journal of Engineering Trends and Technology (IJETT) – Volume 4 Issue 7- july 2013
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
A. Kuzmanovic and E. Knightly, “Low-rate targeted TCP denial-ofservice attacks (The shrew vs. the mice and elephants),” in Proc. ACM
SIGCOMM, Karlsruhe, Germany, Aug. 2003.
A. Stavrou and A. Keromytis, “Countering DoS attacks with stateless
multipath overlays,” in Proc. ACM Conf. Computer and
Communications Security (CCS), Alexandria, VA, Nov. 2005.
] Z. Chen, C. Ji, and P. Barford, “Spatial-temporal characteristics of
internet malicious sources,” in Proc. IEEE INFOCOM MiniConference, Phoenix, AZ, Apr. 2008.
B. Agrawal and T. Sherwood, “Modeling TCAM power for next
generation network devices,” in Proc. IEEE Int. Symp. Performance
Analysis of Systems and Software (ISPASS), Austin, TX, Mar. 2006.
X. Yang, “NIRA: A new internet routing architecture,” in Proc. ACM
SIGCOMM Workshop on Future Directions in Network Architecture
(FDNA), Karlsruhe, Germany, Aug. 2003.
K. Argyraki and D. R. Cheriton, “Loose source routing as a mechanism
for traffic policies,” in Proc. ACM SIGCOMMWorkshop on Future
Directions in Network Architecture (FDNA), Portland, OR, Aug. 2004.
A. Greenhalgh, M. Handley, and F. Huici, “Using routing and
tunneling to combat DDoS attacks,” in Proc. USENIX Workshop on
Steps Towards Reducing Unwanted Traffic in the Internet (SRUTI),
Cambridge, MA, Jul. 2005.
A. Markopoulou, F. Tobagi, and M. Karam, “Loss and delay
measurements of internet backbones,” Elsevier Computer Commun.,
Special Issue on Measurements and Monitoring of IP Networks, vol. 29,
pp. 1590–1604, Jun. 2006.
Scalable Network-layer Defense Against Internet Bandwidth-Flooding
Attacks by Katerina Argyraki and David R. Cheriton
]D. G. Andersen. Mayday: Distributed Filtering for Internet
Services. In USITS, March 2003.
Attack downs Yahoo, Google.
http://news.zdnet.co.uk/internet/security/0,39020375,39157748,00.htm,
June 2004.
DDoS Attack Knocks Out DoubleClick Ads.
http://www.eweek.com/article2/0,1759,1628340,00.asp, July 2004.
Ihoneycol: A Collaborative Technique For Mitigation Of Ddos Attack
FireCol: A Collaborative Protection Networkfor the Detection of
Flooding DDoS Attacks.Jéerôme François, Issam Aib, Member, IEEE,
and Raouf Boutaba, Fellow, IEEE.
D. A. Patterson. A simple way to estimate the cost of downtime. In
USENIX Systems Administration Conference,November 2002.
D. Bernstein. Syn cookies. http://cr.yp.to/syncookies.html, 1996.
ISSN: 2231-5381
http://www.ijettjournal.org
Page 3036