To Lie or To Comply: Defending against Flood Attacks in Disruption Tolerant Network

To Lie or To Comply: Defending against Flood Attacks in Disruption Tolerant
Network
1. INTRODUCTION
Disruption Tolerant Networks (DTNs) consist of mobile nodes carried by human beings,
vehicles, etc. DTNs enable data transfer when mobile nodes are only intermittently connected,
making them appropriate for applications where no communication infrastructure is available such
as military scenarios and rural areas. Due to lack of consistent connectivity, two nodes can only
exchange data when they move into the transmission range of each other. DTNs employ such contact
opportunity for data forwarding with “store-carry-and-forward”; i.e., when a node receives some
packets, it stores these packets in its buffer, carries them around until it contacts another node, and
then forwards them. Since the contacts between nodes are opportunistic and the duration of a contact
may be short because of mobility, the usable bandwidth which is only available during the
opportunistic contacts is a limited resource. Also, mobile nodes may have limited buffer space.
Due to the limitation in bandwidth and buffer space, DTNs are vulnerable to flood attacks. In
flood attacks, maliciously or selfishly motivated attackers inject as many packets as possible into the
network, or instead of injecting different packets the attacker forward replicas of the same packet to
as many nodes as possible. For convenience, call the two types of attack packet flood attack and
replica flood attack, respectively. Flooded packets and replicas can waste the precious bandwidth
and buffer resources, prevent benign packets from being forwarded and thus degrade the network
service provided to good nodes. Moreover, mobile nodes spend much energy on transmitting or
receiving flooded packets and replicas which may shorten their battery life.
Although many schemes have been proposed to defend against flood attacks on the Internet
and in wireless sensor networks, they assume persistent connectivity and cannot be directly applied
to DTNs that have intermittent connectivity. In DTNs, little work has been done on flood attacks,
despite the many works on routing, data dissemination, black hole attack, wormhole attack, and
selfish dropping behaviour. Note that the packets flooded by outsider attackers can be easily filtered
with authentication techniques. However, authentication alone does not work when insider attackers
flood packets and replicas with valid signatures. Thus, it is still an open problem is to address flood
attacks in DTNs.
1

Network
Rate limiting is to defend against flood attacks in DTNs. In each node, has a limit over the
number of packets that it, as a source node, can send to the network in each time interval. Each node
also has a limit over the number of replicas that it can generate for each packet. The two limits are
used to mitigate packet flood and replica flood attacks, respectively. If a node violates its rate limits,
it will be detected and its data traffic will be filtered. In this way, the amount of flooded traffic can
be controlled. To detect if a node as violated its rate limits. Although it is easy to detect the violation
of rate limit on the Internet and in telecommunication networks where the egress router and base
station can account each user’s traffic, it is challenging in DTNs due to lack of communication
infrastructure and consistent connectivity. Since a node moves around and may send data to any
contacted node, it is very difficult to count the number of packets or replicas sent out by this node.
Basic idea of detection is claim-carry-and-check. Each node itself counts the number of packets or
replicas that it has sent out, and claims the count to other nodes; the receiving nodes carry the claims
around when they move, exchange some claims when they contact, and cross-check if these claims
are inconsistent. If an attacker floods more packets or replicas than its limit, it has to use the same
count in more than one claim according to the pigeonhole principle, and this inconsistency may lead
to detection. Based on this idea, we use different cryptographic constructions to detect packet flood
and replica flood attacks.
Because the contacts in DTNs are opportunistic in nature, provides probabilistic detection.
The more traffic an attacker floods, the more likely it will be detected. The detection probability can
be flexibly adjusted by system parameters that control the amount of claims exchanged in a contact.
A lower and upper bound of detection probability and investigate the problem of parameter selection
to maximize detection probability under a certain amount of exchanged claims. The effectiveness
and efficiency of our scheme are evaluated with extensive trace-driven simulations.
1.1 Motivation
DTNs employ such contact opportunity for data forwarding with “store-carry-and-forward”
i.e., when a node receives some packets, it stores these packets in its buffer, carries them around
until it contacts another node, and then forwards them. Since the contacts between nodes are
opportunistic and the duration of a contact may be short because of mobility, the usable bandwidth
which is only available during the opportunistic contacts is a limited resource. Also, mobile nodes
2

Network
may have limited buffer space. Due to the limitation in bandwidth and buffer space, DTNs are
vulnerable to flood attacks. In flood attacks, maliciously or selfishly motivated attackers inject as
many packets as possible into the network, or instead of injecting different packets the attacker’s
forward replicas of the same packet to as many nodes as possible.
1.2 Problem Definition
1) Defence against Packet Flood Attacks
Consider a scenario where each node has a rate limit L on the number of unique packets that
it as a source can generate and send into the network within each time interval T. The time intervals
start from time 0, T, 2T, etc. The packets generated within the rate limit are deemed legitimate, but
the packets generated beyond the limit are deemed flooded by this node. To defend against packet
flood attacks, our goal is to detect if a node as a source has generated and sent more unique packets
into the network than its rate limit L per time interval.
2) Defending against Replica Flood Attacks
To defence against replica flood considers single-copy and multi copy routing protocols.
These protocols require that, for each packet that a node buffers no matter if this packet has been
generated by the node or forwarded to it, there is a limit l on the number of times that the node can
forward this packet to other nodes. The values of l may be different for different buffered packets.
Goal is to detect if a node has violated the routing protocol and forwarded a packet more times than
its limit l for the packet.
3) Setting the Rate Limit L
One possible method is to set L in a request-approve style. When a user joins the network, he
requests for a rate limit from a trusted authority which acts as the network operator. In the request,
this user specifies an appropriate value of L based on prediction of his traffic demand. If the trusted
authority approves this request, it issues a rate limit certificate to this user, which can be used by the
user to prove to other nodes the legitimacy of her rate limit. The request and approval of rate limit
may be done offline. The flexibility of rate limit leaves legitimate users’ usage of the network
unhindered.
3

Network
1.3 Objective of Project
• Defence against Packet Flood Attacks.
• Defence against Replica Flood Attacks.
• To detect if a node as violated its rate limits.
1.4 Limitation of Project
This approach has been proposed for mobile ad hoc networks, but it is still not clear how the
approach can be applied to DTNs, where nodes are disconnected most of the time. Another recent
work proposed a batch authentication protocol for DTNs, which verifies multiple packet signatures
in an aggregated way to save the computation cost. This work is complementary to ours,and their
protocol can also be used in our scheme to further reduce the computation cost of authentication.
1.5 Organization of Documentation
Employed Rate limiting to mitigate flood attacks in DTNs, and proposed a scheme which
exploits claim-carry-and-check to probabilistically detect the violation of rate limit in DTN
environments. It uses efficient constructions to keep the computation, communication and storage
cost low. Also, we analyzed the lower bound and upper bound of detection probability. Extensive
trace-driven simulations showed that our scheme is effective to detect flood attacks and it achieves
such effectiveness in an efficient way. It works in a distributed manner, not relying on any online
central authority or infrastructure, which well fits the environment of DTNs. Besides, it can tolerate
a small number of attackers to collude.
4

Network
2. LITERATURE SURVEY
2.1 Existing System
DTNs employ such contact opportunity for data forwarding with “store-carry-and-forward”;
i.e., when a node receives some packets, it stores these packets in its buffer, carries them around
until it contacts another node, and then forwards them. Since the contacts between nodes are
opportunistic and the duration of a contact may be short because of mobility, the usable bandwidth
which is only available during the opportunistic contacts is a limited resource. Also, mobile nodes
may have limited buffer space. Due to the limitation in bandwidth and buffer space, DTNs are
vulnerable to flood attacks. In flood attacks, maliciously or selfishly motivated attackers inject as
many packets as possible into the network, or instead of injecting different packets the attacker’s
forward replicas of the same packet to as many nodes as possible. For convenience, we call the two
types of attack packet flood attack and replica flood attack, respectively. Here we consider the
problem of routing in intermittently connected networks. In such networks there is no guarantee that
a fully connected path between source and destination exists at any time, rendering traditional
routing protocols unable to deliver messages between hosts. There do however exist a number of
scenarios where connectivity is intermittent, but where the possibility of communication still is
desirable. Thus, there is a need for a way to route through such networks. PROPHET, a probabilistic
routing protocol for such networks and compares it to the earlier presented Epidemic Routing
protocol through simulations. PROPHET is able to deliver more messages than Epidemic Routing
with a lower communication overhead.
The highly successful architecture and protocols of today’s Internet may operate poorly in
environments characterized by very long delay paths and frequent network partitions. These
problems are exacerbated by end nodes with limited power or memory resources. Often deployed in
mobile and extreme environments lacking continuous connectivity, many such networks have their
own specialized protocols, and do not utilize IP. To achieve interoperability between them, a
network architecture and application interface structured around optionally-reliable asynchronous
message forwarding, with limited expectations of end-to-end connectivity and node resources. The
architecture operates as an overlay above the transport layers of the networks it interconnects, and
5

Network
provides key services such as in-network data storage and retransmission, interoperable naming,
authenticated forwarding and a coarse-grained class of service.
Pocket Switched Networks (PSN) makes use of both human mobility and local/global
connectivity in order to transfer data between mobile users' devices. This falls under the Delay
Tolerant Networking (DTN) space, focusing on the use of opportunistic networking. One key
problem in PSN is in de-signing forwarding algorithms which cope with human mobility patterns.
We present an experiment measuring forty-one humans' mobility at the Infocom 2005 conference.
The results of this experiment are similar to our previous experiments in corporate and academic
working environments, in exhibiting a power-law distribution for the time between node contacts.
We then discuss the implications of these results on the design of forwarding algorithms for PSN.
The low-cost, off-the-shelf hardware components in unshielded sensor-network nodes leave
them vulnerable to compromise. With little effort, an adversary may capture nodes, analyze and
replicate them, and surreptitiously insert these replicas at strategic locations within the network.
Such attacks may have severe consequences they may allow the adversary to corrupt network data or
even disconnect significant parts of the network. Previous node replication detection schemes
depend primarily on centralized mechanisms with single points of failure, or on neighbourhood
voting protocols that fail to detect distributed replications Randomized Multicast distributes node
location information to randomly-selected witnesses, exploiting the birthday paradox to detect
replicated nodes, while Line-Selected Multicast uses the topology of the network to detect
replication. Both algorithms provide globally-aware, distributed node-replica detection, and Line-
Selected Multicast displays particularly strong performance characteristics. Emergent algorithms
represent a promising new approach to sensor network security; moreover, our results naturally
extend to other classes of networks in which nodes can be captured, replicated and re-inserted by an
adversary.
Today’s cloud-based services integrate globally distributed resources into seamless
computing platforms. Provisioning and accounting for the resource usage of these Internet-scale
applications presents a challenging technical problem. Design and implementation of distributed rate
limiters, which work together to enforce a global rate limit across traffic aggregates at multiple sites,
enabling the coordinated policing of a cloud-based service’s network traffic. Abstraction not only
6

Network
enforces a global limit, but also ensures that congestion-responsive transport-layer flows behave as if
they traversed a single, shared limiter. Two designs—one general purpose, and one optimized for
TCP—that allow service operators to explicitly trade-off between communication costs and system
accuracy, efficiency, and scalability. Both designs are capable of rate limiting thousands of flows
with negligible overhead. And TCP-centric design is scalable to hundreds of nodes while robust to
both loss and communication delay, making it practical for deployment in nationwide service
providers.
Disruption Tolerant Networks (DTNs) utilize the mobility of nodes and the opportunistic
contacts among nodes for data communications. Due to the limitation in network resources such as
contact opportunity and buffer space, DTNs are vulnerable to flood attacks in which attackers send
as many packets or packet replicas as possible to the network, in order to deplete or overuse the
limited network resources. Rate limiting to defend against flood attacks in DTNs, such that each
node has a limit over the number of packets that it can generate in each time interval and a limit over
the number of replicas that it can generate for each packet. Use a distributed scheme to detect if a
node has violated its rate limits. To address the challenge that it is difficult to count all the packets or
replicas sent by a node due to lack of communication infrastructure, our detection adopts claim-
carry-and- check: each node itself counts the number of packets or replicas that it has sent and
claims the count to other nodes; the receiving nodes carry the claims when they move, and cross-
check if their carried claims are inconsistent when they contact. The claim structure uses the
pigeonhole principle to guarantee that an attacker will make inconsistent claims which may lead to
detection. And rigorous analysis on the probability of detection, and evaluate the effectiveness and
efficiency of our scheme with extensive trace- driven simulations.
Probabilistic Routing
Although the random way-point mobility model is popular to use in evaluations of mobile ad
hoc protocols, real users are not likely to move around randomly, but rather move in a predictable
fashion based on repeating behavioural patterns such that if a node has visited a location several
times before, it is likely that it will visit that location again. We would like to make use of these
observations and this information to improve routing performance by doing probabilistic routing. A
Probabilistic Routing Protocol using History of Encounters and Transitivity. To accomplish this, we
7

Network
establish a probabilistic metric called delivery predictability, at every node a for each known
destination b. This indicates how likely it is that this node will be able to deliver a message to that
destination. The operation of PROPHET is similar to that of Epidemic Routing. When two nodes
meet, they exchange summary vectors which in this case also contain the delivery predictability
information stored at the nodes. This information is used to update the internal delivery
predictability vector as described below, and then the information in the summary vector is used to
decide which messages to request from the other node based on the forwarding strategy used.
PeopleNet
A popular means of seeking information is asking around. A person may consult her friends, who in
turn will ask their friends, and so on, until the information is found. This kind of social networking is
very popular in spite of the availability of vast reservoirs of information such as the Internet and
libraries. Navigating for information via social networks works better than other methods like the
Internet when people are searching for information which is location-specific, community-specific,
or time-specific. This is because people are good sources of these types of information, e.g., a good
pizza place in Toronto. Inspired by the benefits of social networking, we conceive a wireless virtual
social network which mimics the way people seek information in their social circles. This network
leverages the fact that mobile devices are becoming increasingly sophisticated and commonly
support multiple network interfaces. For example, a mobile phone, apart from providing access to
the cellular network may also allow short-rangepeer-to-peer connectivity (e.g. using Bluetooth).
Development platforms for writing applications and middleware for mobile devices are also readily
available. The proliferation of these all-in-one devices can enable seamless information propagation
in a virtual social network, allowing automated matching between those who seek information and
those who possess it. To see the level of penetration of such devices, we conducted several
experiments in the student cafeterias at the National University of Singapore to see how any
Bluetooth enabled phones we could find. Using a laptop installed with Linux, a Bluetooth dongle,
and the BlueZ protocol stack, we scanned for Bluetooth phones in the vicinity. We conducted this
experiment during the lunch period over four days with each session lasting 90 minutes. To our
surprise, we discovered over 100 unique devices with their Bluetooth radios turned on. This
translates to about 1 unique device every 4 minutes.
8

Network
PeopleNet can support a variety of services. In fact, any application involving the mutual
exchange of information or goods, e.g., buying and selling or dating, can be supported by PeopleNet.
For example, suppose that Alice, visiting Boston on a full day business trip, discovers that there is a
sold-out Yankees/Red Sox baseball game that night. She wants to see the game but cannot afford to
spend the time and effort required in calling around or hunting on the internet. In another part of
town, Bob has a ticket but his wife just reminded him that today is their anniversary and he better
have made plans or else! Let us see how both Alice and Bob can use PeopleNet to their advantage.
Bob places a sell query for the tickets along with an asking price. Alice places a buy query for tickets
to the game with her bidding price. Although both queries may have started off in different parts of
town, both are forwarded to the sports bazaar over the cellular network. Once in the sports bazaar,
these queries are further propagated within the bazaar from device to device. If the queries match,
Alice and Bob are notified and they can make the necessary arrangements. Using PeopleNet, both
people are able to satisfy their desires by spending very little time and effort. Storing the kind of
information handled by PeopleNet (time, location and community-specific) in centralized databases
requires significant time and effort on the part of individual users. From the user perspective,
PeopleNet’s main advantages are convenience, since your mobile phone is with you wherever you
are, and time savings, as illustrated earlier. Web-based content providers like Yahoo!, Amazon, eBay
and Craigslist can provide some of these services on the Internet. Establishing such a database
requires setting up massive server warehouses, storage area networks, etc., which involves
substantial capital investment and incurs considerable recurring costs for operation and maintenance,
which may be passed on to users. From the system perspective, PeopleNet is a simple, low-cost and
scalable architecture for dynamic information storage and access. Finally, in many emerging
markets, mobile penetration is quite high, while the Internet infrastructure is poor. In fact, Business
Week reports that India now has more mobile phone than land lines. In such scenarios, PeopleNet is
a very attractive mechanism to provide access to information and services for the masses.
MaxProp
Disruption tolerant networks (DTNs) allow for routing in networks where contemporaneous
end-to-end paths are unstable or unlikely. Unstable paths can be the result of several challenges at
the link layer, for example: high node mobility, low node density, and short radio range; intermittent
power from energy management schemes; environmental interference and obstruction; and denial-
9

Network
of-service attacks. Such environments can exist in undeveloped areas or when a stable infrastructure
is destroyed by natural disaster or military efforts. DTNs are useful when the information being
routed retains its value longer than the disrupted connectivity delays delivery. DTNs can be based on
moving nodes such as vehicles or pedestrians. Vehicles can provide substantial electrical supplies
and transport bulky hardware, which may be inappropriate for use by non-mechanized peers. The
disadvantage of a vehicle based network is that the nodes move more quickly, reducing the amount
of time they are in radio range of one another. Accordingly, one limited resource in a vehicle-based
DTN is the duration of time that nodes are able to transfer data between one another as they pass.
Storage can be a limited resource as well. Several contributions in this paper using our deployed
DTN as well as simulation environments. DTN routing protocol, called MaxProp, that performs
significantly better than previous approaches. Protocol addresses scenarios in which either transfer
duration or storage is a limited resource in the network. MaxProp extends our previous routing work
to address several problems that we have observed in our real network topology. Existing
approaches have a bias towards short-distance destinations, which MaxProp addresses by using hop
counts in packets as a measure of network resource fairness. Additionally, existing approaches fail to
remove stale data from network buffers. MaxProp uses acknowledgments that are propagated
networkwide, and not just to the source. MaxProp stores a list of previous intermediaries to prevent
data from propagating twice to the same node.
A Delay-Tolerant Network Architecture for Challenged Internets
The DTN architecture is based most closely on work that originated with the Interplanetary
Internet design, but represents a significant generalization to other types of networks suffering from
non-Internet-like performance characteristics. It addresses several of the issues raised in the
“network survivability” literature, especially with respect to networks lacking continuous
connectivity. With respect to store-and-forward routing in other frequently disconnected networks, a
number of recent efforts have arisen. In Zebra Net, wireless sensor nodes (attached to animals)
collect location data and opportunistically report their histories when they come in radio range of
base stations. They explore the case of mobile base stations and sensor devices and the use of a pair
of flooding-based routing protocols. In Data Mules, low-power sensor nodes can save power if
periodically visited by a “mule” that travels among them and provides a non-interactive message
store-and-forward service. In these two efforts plus that of Vahdat, mobility models are employed in
10

Network
simulation to predict the ability of partially connected networks to deliver data eventually. The use
of late binding for names in DTN is shared with, although not directly based upon, the work on
Intentional Naming. Here, names represent a form of query and are used specifically for any cast in
order to locate nearby network services. Routing based on names is shared, to some degree, with
Internet Content Routing. This work focuses on using routing on names to provide a content
distribution facility for the Internet, addressing its scalability and performance. It does not use two
separate name components as in DTN, but does suggest the viability of the name-based routing
mechanism. The generality of the entity portion of names is influenced by, where database-like
queries are effectively used as addresses for groups of sensor nodes. The architectural thinking
regarding interoperability and layering is guided by principles of the ARPANET/Internet. DTN
gateways operate in many ways similar to Internet routers, but are adapted for use in high-delay and
disconnected environments by storing messages for potentially long periods of time.
Forwarding strategies
In traditional routing protocols, choosing where to forward a message is usually a simple
task; the message is sent to the neighbour that has the path to the destination with the lowest cost
(usually the shortest path). Normally the message is also only sent to a single node since the
reliability of paths is relatively high. However, in the settings we envision here, things are
completely different. For starters, when a message arrives at a node, there might not be a path to the
destination available so the node have to buffer the message and upon each encounters with another
node, the decision must be made on whether or not to transfer a particular message. Furthermore, it
may also be sensible to forward a message to multiple nodes to increase the probability that a
message is really delivered to its destination.
Unfortunately, these decisions are not trivial to make. In some cases it might be sensible to
select a fixed threshold and only give a message to nodes that have delivery predictability over that
threshold for the destination of the message. On the other hand, when encountering a node with a
low delivery predictability, it is not certain that a node with a higher metric will be encountered with
in reasonable time. Thus, there can also be situations where we might want to be less strict in
deciding who to give messages to. Furthermore, there is the problem of deciding how many nodes to
give a certain message to. Distributing a message to a large number of nodes will of course increase
11

Network
the probability of delivering a message to its destination, but in return, more system resources will be
wasted. On the other hand, giving a message to only a few nodes (maybe even just a single node)
will use little system resources, but the probability of delivering a message is probably lower, and
the incurred delay high.
Routing in Socially Selfish Delay Tolerant Networks
Though the current design of SSAR does not consider malicious behaviors, it can tolerate
many of them. Suppose a malicious attacker joins the network and launches flooding based DoS
attacks. If other network members do not trust this attacker and assign zero or very low social tie
strength to the attacker, the flooding traffic will not be allocated any buffer/bandwidth resource or
only allocated very few resources to mitigate the DoS attack. If the attacker launches a black hole
attack (i.e., drop all received packets), SSAR can still tolerate it with the least modification that a
node never forwards packets to those without social ties from its point of view. Therefore, the black
hole attack also fails. In summary, SSAR can deal with outside attackers. For an inside attacker
which is already known by some existing members, it may successfully launch flooding-based DoS
or black hole attacks in the short run. However, the effect of such attacks is limited by the number of
social ties the attacker has, and will be weakened beyond one hop. Furthermore, when such
behaviors are detected, the attacker may lose social ties with others, rendering its future attacks
impossible. Certainly, this does not mean SSAR should not take care of such behaviors, but we
believe such insider attacks deserve a separate study. Issues like how to determine legitimate or
malicious packet droppings in DTN nodes are different from those in mobile ad hoc networks where
people often make such decisions based on wireless channel reliability. We leave it as our future
work. We note that misreporting behaviors are possible in SSAR. For example, a node may set
higher priority values for its buffered packets than they should have to make them more competitive
in the next hop. To prevent such behaviors, we can apply ideas similar to rate limiting. For example,
a node may limit the number of high-priority packets or the total priority from a neighbor; when the
actual received number is over the limit, it will randomly degrade some of them.
Distributed Maintenance of Cache Freshness in Opportunistic Mobile Networks
Due to the intermittent network connectivity in opportunistic mobile networks, data is
forwarded in a “carry-and-forward” manner. Node mobility is exploited to let nodes physically carry
12

Network
data as relays, and forward data opportunistically when contacting others. The key problem is hence
how to select the most appropriate nodes as relays, based on the prediction of node contacts in the
future. Some forwarding schemes do such prediction based on node mobility patterns. In some other
schemes, stochastic node contact process is exploited for better prediction accuracy. Social contact
patterns of mobile users, such as centrality and community structures, have also been exploited for
relay selection. Based on this opportunistic communication paradigm, data access can be provided to
mobile users in various ways. In some schemes, data is actively disseminated to specific users based
on their interest profiles. Publish/subscribe systems are also used for data dissemination by
exploiting social community structures to determine the brokers. Caching is another way to provide
data access. Determining appropriate caching policies in opportunistic mobile networks is
complicated by the lack of global network information. Some research efforts focus on improving
data accessibility from infrastructure networks such as Wi-Fi or Internet and some others study peer-
to-peer data sharing among mobile nodes. In, data is cached at specific nodes which can be easily
accessed by others. In, caching policies are dynamically determined based on data importance, so
that the aggregate utility of mobile nodes can be maximized. When the versions of cached data in the
network are heterogeneous and different from that of the source data, research efforts have been
focusing on maintaining the consistency of these cache versions. Being different from existing work,
in this paper we focus on ensuring the freshness of cached data, i.e., the version of any cached data
should be as close to that of the source data as possible discussed the practical scenario in which data
is periodically refreshed, but did not provided specific solutions for maintaining cache freshness. We
propose methods to maintain cache freshness in a distributed and hierarchical manner, and
analytically ensure that the freshness requirement of cached data can be satisfied
Encounter–Based Routing in DTNs
Delay and disruption tolerant networks (DTNs) transport application data by creating a “store
and forward” network where no infrastructure exists. Although end-to-end connectivity may not be
available between two nodes, DTN routing protocols instead take advantage of temporal paths
created in the network as nodes encounter their neighbors and exchange messages they have been
asked to forward. Since there are no guarantees that a route will ever be available, many current
DTN routing protocols apply epidemic-style techniques, leveraging the fact that an increased
number of copies of a particular message in the network should improve the probability that the
13

Network
message will reach its intended destination. However, such techniques come at a high price in terms
of network resources, resulting in the rapid depletion of buffer space and energy on resource limited
devices, the rapid depletion of available bandwidth, and the potential to greatly increase end-to-end
delay. A number of routing protocols have been proposed to enable data delivery in such challenging
environments. However, many of these protocols trade overhead and computational complexity for
increased successful delivery. This overhead expresses itself as more traffic in the network creating
more contention in clusters of high connectivity and increased energy consumption for nodes
exchanging messages. Furthermore, many DTN protocols make routing and forwarding decisions
based on advertised contact information, allowing for denial-of-service attacks over the already
intermittently connected network. All of these effects can decrease overall network performance.
One method to mitigate this overhead is to identify key properties in the network that allow for more
intelligent forwarding and message replication decisions. For example, environments targeted by
DTNs, such as disaster scenarios and certain vehicular networks, different classes of nodes naturally
tend to have more node encounters than others. The main contribution of our research capitalizes on
this network property to design a DTN routing protocol that uses local observations about a node’s
environment. Our protocol, Encounter-Based Routing (EBR), uses an encounter-based metric for
optimization of message passing that maximizes message delivery ratio while minimizing overhead
both in terms of extra traffic injected into the network and control overhead, as well as minimizing
latency as a second order metric. Furthermore, we present a security component to our protocol that
protects against denial-of-service attacks aimed at eliminating copies of messages in the system. To
fully evaluate EBR, we propose the use of three composite metrics, which clearly illustrate the
interplay between fundamental metrics like message delivery ratio, good put, and end-to-end delay.
Detecting Wormhole Attacks in Delay Tolerant Networks
Ad hoc networks can be easily deployed because they do not require fixed network
infrastructures such as base stations or routers. Due to its self-organizing nature, an ad hoc network
can be formed in real-time where all participating nodes willingly perform packet forwarding for one
another. Thus, ad hoc networks are flexible and can provide mission critical services, especially in
emergency applications and battlefield scenarios. However, in practice, due to high node mobility,
low node density, and short radio ranges, traditional ad hoc routing protocols do not work well in
some challenging network scenarios as end-to-end paths may not always exist. For instance, nodes
14

Network
are sparsely connected in tactical fields for the search and rescue missions. To address this issue, the
Delay Tolerant Network (DTN) concept is introduced, which uses a store-and-forward approach to
deal with challenging network scenarios. In DTNs, nodes store packets if they cannot find a next-
hop node to deliver them to destinations. New routing schemes have been designed for DTNs. For
example, Prophet requires each node first stores packets in its memory and then selectively transmits
packets when it encounters other nodes based on various metrics including the numbers of previous
encounters, the last encounter time, and the estimated packet delivery probability values to other
nodes. In DTNs, the portability of modern devices makes them tempting targets for thefts. Moreover,
authenticated devices in chaotic battlefield environments are also likely to be captured by the enemy.
Thus, it is easy for an adversary to compromise nodes within a DTN, and use these nodes to launch
insider attacks. Such insider attacks can cause significant problems in networks. For instance, an
adversary can use the compromised nodes to launch a particularly harmful attack called wormhole
attack. In a wormhole attack, the adversary connects two compromised nodes which are far away in
the network using a low-latency link. Then, one compromised node records and tunnels data packets
to another compromised node which replays them there. Such an action can give the nodes within
the transmission range of the compromised nodes an impression that they are the neighbors of some
other nodes that are actually far away. By creating such wormhole links between distant nodes,
attackers can corrupt the topology views of the attacked networks, disrupt the routing in such
networks and significantly impact the normal operations of packet delivery. There have been active
work developed in detecting wormhole attacks in ad hoc networks. However, these methods have
their limitations when applying to DTNs by either imposing rigorous requirements on resource-
constrained nodes or relying on connectivity information, which is scarce in sparsely connected
DTNs. In this article, we first give an overview of how an wormhole attack can be launched, its
impact, and existing methods that have been developed to deal with this type of attack. Then, we
present the characteristics of delay tolerant networks and use Prophet as an example to describe
routing in a DTN. We also describe how nodes in ad hoc networks typically move using two
representative mobility models: namely the Random Way Point and Zebranet models. Next, we
describe a detection scheme we have designed, which only utilizes the network topology information
for detecting a wormhole attack. In our scheme, nodes in the network will reduce their transmission
range for a short time period if necessary to detect the presence of a forbidden topology structure.
Such a forbidden structure is caused by a wormhole attack and cannot be present under normal
15

Network
situations without attacks. Our detection mechanism does not require the deployment of additional
devices in the DTNs. To show the effectiveness and efficiency of our detection scheme, we present
simulation results by sing a 40-node network running PROPHET. We examine the feasibility of our
scheme for detecting wormhole attacks under various scenarios with different node densities and
movement patterns.
Cloud Control with Distributed Rate Limiting
The problem of online, distributed resource allocation is not a new one, but to our knowledge
we are the first to present a concrete realization of distributed traffic rate limiting. While there has
been considerable work to determine the optimal allocation of bandwidth between end-point pairs in
virtual private networks (VPNs), the goal is fundamentally different. In the VPN hose model, the
challenge is to meet various quality-of-service guarantees by provisioning links in the network to
support any traffic distribution that does not exceed the bandwidth guarantees at each end point in
the VPN. Conversely, the distributed rate limiting problem is to control the aggregate bandwidth
utilization at all limiters in the network, regardless of the available capacity at the ingress or egress
points. Distributed rate limiting can be viewed as a continuous form of distributed admission control.
Distributed admission control allows participants to test for and acquire capacity across a set of
network paths, each edge router performs flow-admission tests to ensure that no shared hop is over-
committed. While our limiters similarly “admit” traffic until the virtual limiter has reached capacity,
they do so in an instantaneous, reservation-free fashion. Ensuring fairness across limiters can be
viewed as a distributed instance of the link-sharing problem. A number of packet scheduling
techniques have been developed to enforce link-sharing policies, which provide bandwidth
guarantees for different classes of traffic sharing a single link. These techniques, such as weighted
fair queuing, apportion link capacity among traffic classes according to some fixed weights. These
approaches differ from ours in two key respects. First, by approximating generalized processor
sharing, they allocate excess bandwidth across backlogged classes in a max-min fair manner; we
avoid enforcing any explicit type of fairness between limiters, though FPS tries to ensure max-min
fairness between flows. Second, most class-based fair-queuing schemes aim to provide isolation
between packets of different classes. In contrast, we expose traffic at each limiter to all other traffic
in the system, preserving whatever implicit notion of fairness would have existed in the single-
limiter case, it use a token bucket to define the reference behavior of a single limiter. There are a
16

Network
broad range of active queue management schemes that could serve equally well as a centralized.
Determining whether similar distributed versions of these sophisticated AQM schemes exist is a
subject of future work. The general problem of using and efficiently computing aggregates across a
distributed set of nodes has been studied in a number of other contexts. These include distributed
monitoring, triggering, counting, and data stream querying. Two systems in particular also estimate
aggregate demand to apportion shared resources at multiple points in a network. The first is a token-
based admission architecture that considers the problem of parallel flow admissions across edge
routers. Their goal is to divide the total capacity fairly across allocations at edge routers by setting an
edge router’s local allocation quota in proportion to its share of the request load. However they must
revert to a first-come first-served allocation model if ever forced to “revoke” bandwidth to maintain
the right shares.
Data Delivery in Delay Tolerant Networks
Delay-Tolerant Networks, also called disruption tolerant networks (DTNs), represent a fairly
new networking paradigm that allows inter-connection between devices that current networking
technology cannot provide. There are a wide variety of networks where an end-to-end connection
between a given source and destination may never be present. Consequently, traditional routing
protocols cannot be directly applied in these scenarios for delivering data. However, if one were to
take the graph formed by the nodes based on their connectivity dictated by their radio range and
consider the overlap not only over space but also time then there is a high likelihood that the network
will appear as a single connected component. So while at any given instant, the network may not be
connected, it may still be possible to route data from a source to a destination. DTNs are sometimes
also called Intermittently-Connected Mobile Networks (ICMNs). The primary goal in such networks
is to get the information from a source to the destination; these networks can tolerate a relatively
higher delay. A wide variety of ”challenged” networks fall under this category ranging from outer-
space networks, under-water networks, wireless sensor networks, vehicular networks, sparse mobile
ad-hoc networks etc. Students moving about in a college campus or buses moving about in a small
metropolitan area, or a wireless sensor network with some mobile nodes acting as relays to assist in
the data-collection phase provide representative examples of DTNs. This chapter strives to provide a
survey of some of the most relevant studies that have appeared in the domain of data delivery in
delay tolerant networks. First, we introduce some fundamental challenges that are unique to DTNs.
17

Network
Then we present the major parameters of interest that various proposed routing solutions have
considered, examples include end-to-end delay, throughput, mobility model of the nodes, energy
efficiency, storage etc. Subsequently, we provide a classification of various approaches to routing in
DTNs and pigeon-hole the major studies that have appeared in the last few years into the classified
categories.
Privacy-preserving Relay Filtering Scheme
Delay Tolerant Networks (DTNs), such as inter-planetary communication, networking in
sparsely population areas, and vehicular ad hoc networks, have been subject to extensive research
efforts in recent years. Different from the traditional networks, DTNs are distinguishably
characterized by high transmission delays, frequent link disruptions, and non-exist end-to-end
connections. As such, the packet propagation process in DTNs is typically composed of multiple
relays in a store, carry and forward fashion upon the node contacts. As the node contacts are often
uncoordinated and purely unpredictable, especially in sparse DTNs, packet delivery is therefore
opportunistic. To increase the delivery ratio and reduce the average delivery delay, an extensive
body of research has been devoted recently to the DTN routing, and a variety of multi copy DTN
routing schemes/protocols have been proposed for sparse DTNs. Despite the significant progress, the
challenges imposed by the security concerns have, however, often been neglected in DTN routing; if
the security issues are not resolved, those well-designed DTN routing schemes cannot be practical
for real-world deployments, not mention to exert their vantage. Aiming at security in DTN routing,
there are mainly two efforts underway in research. One primarily focuses on the incentive
mechanism in DTN to stimulate selfish DTN nodes to faithfully forward packets during the relay.
Another one is to address the fundamental packet authentication and access control. The
fundamental packet authentication mainly utilizes the signature technique to deal with the traffic
storm problem: if a malicious node inserts some false packets in the network, the signature
verification executed by intermediate relay nodes can efficiently detect the forged signatures, drop
the inserted false packets and save the scarce DTN resources. Although the fundamental packet
authentication can filter false packets inserted by malicious nodes, it cannot use signature to identify
those “junk” packets which are encrypted, sent by the legitimate nodes, but are of no interest to the
destination nodes. Of course, the encrypted junk packets can be decrypted and discarded by the
destinations immediately upon the receipt. However, before their reaching the destinations, the
18

Network
scarce DTN resources have already been wasted. Therefore, similar to the forged packets inserted by
malicious nodes, those encrypted junk packets are equally harmful which would also lead to
significant wastes of scarce DTN resources if without effective control.
POCKET SWITCHED NETWORKING
Delay Tolerant Networking (DTN) explores networking in the presence of networks with
challenged networking conditions, such as links which are often disconnected, or are subject to long
delays. To date, activities in the DTN area have addressed various communication environments
where standard Internet protocols would be difficult to use or would provide very poor performance,
e.g. networking using buses following predictable routes, interplanetary networking, interfacing with
sensor networks, and using mobile nodes to bridge data between remote village networks and the
Internet. Another scenario in which DTN can be useful is in networking for devices carried by users
of mobile and portable devices. For example, mobile workers move between connectivity islands
(e.g., Wi-Fi at home and work). Outside these islands, end-to-end connectivity becomes expensive,
slow, or simply unavailable. Moreover, many communication services rely on access to centralized
resources such as the DNS. That prevents, for example, two users sitting beside each other from
easily exchanging data. There is a huge amount of untapped resource in portable networked devices
such as laptops, PDAs and mobile phones, including in local wireless bandwidth (e.g. 802.11 and
Bluetooth), storage capacity, and CPU power. The only scarce resource is power, but advances in
power engineering and battery technologies have meant that mobile phones now last for a week on a
single charge, while remaining in constant network contact. We expect that this innovation will
continue, allowing devices to participate in wireless networks while minimizing power consumption.
We envision a world where these resources can be used to provide networking functionality
alongside access networks, and where users applications make use of both types of bandwidth
transparently.
2.2 Disadvantages
• Selfishly motivated attackers inject as many packets as possible into the network.
• Bandwidth and buffer space, DTNs are vulnerable to flood attacks.
19

Network
• DTN’s follows store-carry-and-forward.
• Attacks generated in DTN’s are two types of attack packet flood attack and replica flood
attack
2.3 Proposed System
Rate limiting to defend against flood attacks in DTNs. In our approach, each node has a limit
over the number of packets that it, as a source node, can send to the network in each time interval.
Each node also has a limit over the number of replicas that it can generate for each packet (i.e., the
number of nodes that it can forward each packet to). The two limits are used to mitigate packet flood
and replica flood attacks, respectively. If a node violates its rate limits, it will be detected and its data
traffic will be filtered. In this way, the amount of flooded traffic can be controlled. Our main
contribution is a technique to detect if a node has violated its rate limits. Basic idea of detection is
claim-“carry-and-check”.
Use two different cryptographic constructions to detect packet flood and replica flood attacks
independently. When it is deployed to propagation routing protocols, the detection of replica flood
attacks is deactivated. The detection of packet flood attacks works independently for each time
interval. Without loss of generality, we only consider one time interval when describing our scheme.
For convenience, we first describe our scheme assuming that all nodes have the same rate limit L,
and relax this assumption. In the following, we use SIG i(*) to denote node i’s signature over the
content in the brackets.
Claim Construction
Two pieces of metadata are added to each packet, Packet Count Claim (P-claim) and
Transmission Count Claim (T-claim). P-claim and T-claim are used to detect packet flood and
replica flood attacks, respectively. P-claim is added by the source and transmitted to later hops along
with the packet. T-claim is generated and processed hop-by-hop. Specifically, the source generates a
T-claim and appends it to the packet. When the first hop receives this packet, it peels off the T-claim
20

Network
when it forwards the packet out, it appends a new T-claim to the packet. This process continues in
later hops. Each hop keeps the P-claim of the source and the T-claim of its previous hop to detect
attacks.
• P-Claim
When a source node S sends a new packet m (which has been generated by S and not sent out
before) to a contacted node, it generates a P-claim. The P-claim is attached to packet m as a header
field, and will always be forwarded along with the packet to later hops. When the contacted node
receives this packet, it verifies the signature in the P-claim, and checks the value of cp. If cp is larger
than L, it discards this packet; otherwise, it stores this packet and the P-claim.
• T-Claim
When node A transmits a packet m to node B, it appends a T-claim to m. The T-claim
includes A’s current transmission count ct for m (i.e., the number of times it has transmitted m out)
and the current time t. In single-copy and multi copy routing, after forwarding m for enough times, A
deletes its own copy of m and will not forward m again.
Inconsistency Caused by Attack
In a dishonest P-claim, an attacker uses a smaller packet count than the real value. However,
this packet count must have been used in another P-claim generated earlier. This causes an
inconsistency called count reuse, which means the use of the same count in two different P-claims
generated by the same node. For example the count value 3 is reused in the P-claims of packet m3
and m4. Similarly, count reuse is also caused by dishonest T-claims.
Protocol
Suppose two nodes contact and they have a number of packets to forward to each other.
When a node forwards a packet, it attaches a T-claim to the packet. Since many packets may be
forwarded in a contact and it is expensive to sign each T-claim separately, an efficient signature
construction is proposed. The node also attaches a P-claim to the packets that are generated by itself
and have not been sent to other nodes. When a node receives a packet, it gets the P-claim and T-
21

Network
claim included in the packet. It checks them against the claims that it has already collected to detect
if there is any inconsistency. Only the P-claims generated in the same time interval are cross-
checked. If no inconsistency is detected, this node stores the P-claim and T-claim locally. To better
detect flood attacks, the two nodes also exchange a small number of the recently collected P-claims
and T-claims and check them for inconsistency. This metadata exchange process is separately
presented. When a node detects an attacker, it adds the attacker into a blacklist and will not accept
packets originated from or forwarded by the attacker. The node also disseminates an alarm against
the attacker to other nodes.
Local Data Structures
Each node collects P-claims and T-claims from the packets that it has received and stores
them locally to detect flood attacks. Let us look at a received packet m and the P-claim and T-claim
included in this packet. Initially, this pair of P-claim and T-claim are stored in full with all the
components. When this node removes m from its buffer (e.g., after m is delivered to the destination
or dropped due to expiration), it compacts this pair of claims to reduce the storage cost. If this pair of
claims have been sampled for metadata exchange, they will be stored in full until the exchange
process ends and be compacted afterward.
Inconsistency Check
Suppose node W wants to check a pair of P-claim and T-claim against its local collections to
detect if there is any inconsistency. The inconsistency check against full claims is trivial: W simply
compares the pair of claims with those collected. In the following, we describe the inconsistency
check against compactly stored claims.
• Inconsistency Check with P-Claim
From the P-claim node W gets: the source node ID S, packet count cp, timestamp t, and
packet hash H. To check inconsistency, W first uses S and t to map the P-claim to the structure Ci S.
Then it reconstructs the hash remainder of H using the locators in Ci S. If the bit indexed by the
packet count cp is set in the bit-vector but the hash remainder is not included in Ci S, count reuse is
detected and S is an attacker. The inconsistency check based on compact P-claims does not cause
false positive, since a good node never reuses any count value in different packets generated in the
22

Network
same interval. The inconsistency check may cause false negative if the two inconsistent P-claims
have the same hash remainder. However, since the attacker does not know which bits constitute the
hash remainder, the probability of false negative is only 2^-8. Thus, it has minimal effect on the
overall detection probability.
• Inconsistency Check with T-Claim
The inconsistency check based on compact T-claims does not cause extra false negative.
False positive is possible but it can be kept low as follows: node W may falsely detect a good node R
as an attacker if it has received two T-claims generated by R that satisfy two conditions:
1) They are generated for two different packets, and
2) They have the same hash remainder.
For 32-bit hash remainder, the probability that each pair of T-claims lead to false detection is
2^-32. In most cases, we expect that the number of T-claims generated by R and received by W is
not large due to the opportunistic contacts of DTNs, and thus the probability of false detection is
low. As W receives more T-claims generated by R, it can use a longer (e.g., 64-bit) hash remainder
for R to keep the probability of false detection low. Moreover, such false detection is limited to W
only, since W cannot convince other nodes to accept the detection with compact T-claim.
2.4 Advantages
• Our main goal is a technique to detect if a node has violated its rate limit.
• The two types of attack packet flood attack and replica flood attack are detected.
• In Proposed System DTNS follows “claim-carry-and-check”.
23

Network
3. ANALYSIS
3.1 Problem Statement
Packet flood attack can waste more than 80 percent of the transmissions made by good
nodes in all routing strategies when the fraction of attackers is higher than 5 percent. When 20
percent of nodes are attackers, replica flood attack can waste 68 and 44 percent of transmissions in
single-copy and multi copy routing, respectively. However, replica flood attack only wastes 17
percent of transmissions in propagation routing. This is because each good packet is also replicated
many times.
3.2 Approach Method
Network Model
In DTNs, since contact durations may be short, a large data item is usually split into smaller
packets (or fragments) to facilitate data transfer. For simplicity, we assume that all packets have the
same predefined size. Although in DTNs the allowed delay of packet delivery is usually long, it is
still impractical to allow unlimited delays. Thus, we assume that each packet has a lifetime. The
packet becomes meaningless after its lifetime ends and will be discarded. We assume that every
packet generated by nodes is unique. This can be implemented by including the source node ID and
a locally unique sequence number, which is assigned by the source for this packet, in the packet
header. And assume that time is loosely synchronized, such that any two nodes are in the same time
slot at any time. Since the inter contact time in DTNs is usually at the scale of minutes or hours, the
time slot can be at the scale of one minute. Such loose time synchronization is not hard to achieve.
Adversary Model
There are a number of attackers in the network. An attacker can flood packets and/or
replicas. When flooding packets, the attacker acts as a source node. It creates and injects more
packets into the network than its rate limit L. When flooding replicas, the attacker forwards its
buffered packets (which can be generated by itself or received from other nodes) more times than its
24

Network
limit l for them. The attackers may be insiders with valid cryptographic keys. Some attackers may
collude and communicate via out-band channels.
Trust Model
Assume that a public-key cryptography system is available. For example, Identity-Based
Cryptography (IBC) has been shown to be practical for DTNs. In IBC, only an offline Key
Generation Center (KGC) is needed. KGC generates a private key for each node based on the node’s
id, and publishes a small set of public security parameters to the node. Except the KGC, no party can
generate the private key for a node id. With such a system, an attacker cannot forge a node id and
private key pair. Also, attackers do not know the private key of a good node(not attacker). Each node
has a rate limit certificate obtained from a trusted authority. The certificate includes the node’s ID,
its approved rate limit L, the validation time of this certificate and the trusted authority’s signature.
The rate limit certificate can be merged into the public key certificate or stand alone.
3.3 Software Requirements Specification (SRS)
Introduction
A software development process, also known as a software development life-cycle (SDLC),
is a structure imposed on the development of a software product. Similar terms include software life
cycle and software process. It is often considered a subset of systems development life cycle. There
are several models for such processes, each describing approaches to a variety of tasks or activities
that take place during the process. Some people consider a life-cycle model a more general term and
a software development process a more specific term. For example, there are many specific software
development processes that 'fit' the spiral life-cycle model.
Software development organizations implement process methodologies to ease the process of
development. Sometimes, contractors may require methodologies employed, an example is the U.S.
defence industry, which requires a rating based on process models to obtain contracts. The
international standard for describing the method of selecting, implementing and monitoring the life
cycle for software is ISO/IEC 12207.
25

Network
Software development activities
Planning
Planning is an objective of each and every activity, where we want to discover things that
belong to the project. An important task in creating a software program is extracting the
requirements or requirements analysis. Customers typically have an abstract idea of what they want
as an end result, but do not know what software should do. Skilled and experienced software
engineers recognize incomplete, ambiguous, or even contradictory requirements at this point.
Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.
Once the general requirements are gathered from the client, an analysis of the scope of the
development should be determined and clearly stated. This is often called a scope document.
Certain functionality may be out of scope of the project as a function of cost or as a result of unclear
requirements at the start of development. If the development is done externally, this document can
be considered a legal document so that if there are ever disputes, any ambiguity of what was
promised to the client can be clarified.
Implementation, testing and documenting
Implementation is the part of the process where software engineers actually program the code
for the project. Software testing is an integral and important phase of the software development
process. This part of the process ensures that defects are recognized as soon as possible.
Documenting the internal design of software for the purpose of future maintenance and enhancement
is done throughout development. This may also include the writing of an API, be it external or
internal. The software engineering process chosen by the developing team will determine how much
internal documentation (if any) is necessary. Plan-driven models (e.g., Waterfall) generally produce
more documentation than Agile models.
Deployment and maintenance
Deployment starts directly after the code is appropriately tested, approved for release, and
sold or otherwise distributed into a production environment. This may involve installation,
26

Network
customization (such as by setting parameters to the customer's values), testing, and possibly an
extended period of evaluation. Software training and support is important, as software is only
effective if it is used correctly. Maintaining and enhancing software to cope with newly discovered
faults or requirements can take substantial time and effort, as missed requirements may force
redesign of the software.
Software development models
Several models exist to streamline the development process. Each one has its pros and cons,
and it is up to the development team to adopt the most appropriate one for the project. Sometimes a
combination of the models may be more suitable.
Waterfall model
The waterfall model is a sequential design process, often used in software development
processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the
phases of Conception, Initiation, Analysis, Design, Construction, Testing and Maintenance.
The waterfall development model originates in the manufacturing and construction
industries; highly structured physical environments in which after-the-fact changes are prohibitively
costly, if not impossible. Since no formal software development methodologies existed at the time,
this hardware-oriented model was simply adapted for software development.
Spiral model
The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A
software project repeatedly passes through these phases in iterations (called Spirals in this model).
The baseline spiral, starting in the planning phase, requirements are gathered and risk is
assessed. Each subsequent spirals builds on the baseline spiral. Requirements are gathered during
the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate
solutions. A prototype is produced at the end of the risk analysis phase.
27

Network
Software is produced in the engineering phase, along with testing at the end of the phase.
The evaluation phase allows the customer to evaluate the output of the project to date before the
project continues to the next spiral.
INCREMENTAL MODEL
The incremental model combines elements of the linear sequential model with the iterative
philosophy of prototyping. Each linear sequence produces a deliverable “increment” of the software.
When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed, but many supplementary features (some known, others unknown)
remain undelivered. The core product is used by the customer (or undergoes detailed review). As a
result of use and/or evaluation, a plan is developed for the next increment. The plan addresses the
modiﬁcation of the core product to better meet the needs of the customer and the delivery of
additional features and functionality. This process is repeated following the delivery of each
increment, until the complete product is produced.
PROTOTYPE MODEL
The prototyping paradigm begins with requirements adhering. Developer and customer meet
and dine the overall objectives for the software, identify whatever requirements are known, and
outline areas where further definition is mandatory. A "quick design" then occurs. The quick design
focuses on a representation of those aspects of the software that will be visible to the customer/user .
The quick design leads to the construction of a prototype. The prototype is evaluated by the
customer/user and used to refine requirements for the software to be developed. Iteration occurs as
the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the
developer to better understand what needs to be done. Ideally, the prototype serves as a mechanism
for identifying software requirements. If a working prototype is built, the developer attempts to use
existing program fragments or applies tools that enable working programs to be generated quickly.
RAD MODEL
Rapid application development (RAD) is an incremental software development process
model that emphasizes an extremely short development cycle. The RAD model is a “high-speed”
adaptation of the linear sequential model in which rapid development is achieved by using
28

Network
component-based construction. If requirements are well understood and project scope is constrained,
the RAD process enables a development team to create a “fully functional system” within very short
time periods (e.g., 60 to 90 days).
CONCURRENT DEVELOPMENT MODEL
The concurrent process model can be represented schematically as a series of major technical
activities, tasks, and their associated states All activities exist concurrently but reside in different
states. The concurrent process model deﬁnes a series of events that will trigger transitions from state
to state for each of the software engineering activities. This generates the event analysis model
correction which will trigger the analysis activity from the done state into the awaiting changes state.
In reality, the concurrent process model is applicable to all types of software development and
provides an accurate picture of the current state of a project. Rather than, confining software
engineering activities to a sequence of events, it defines a network of activities. Each activity on the
network exists simultaneously with other activities. Events generated within a given activity or at
some other place in the activity network trigger transitions among the states of an activity
SDLC Methodology
This document play a vital role in the development of life cycle (SDLC) as it describes the
complete requirement of the system. It means for use by developers and will be the basic during
testing phase. Any changes made to the requirements in the future will have to go through formal
change approval process.
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of
Software Development and Enhancement. This model was not the first model to discuss iterative
development, but it was the first model to explain why the iteration models.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase
starts with a design goal and ends with a client reviewing the progress thus far. Analysis and
engineering efforts are applied at each phase of the project, with an eye toward the end goal of the
project.
The steps for Spiral Model can be generalized as follows
29

Network
The new system requirements are defined in as much details as possible. This usually
involves interviewing a number of users representing all the external or internal users and other
aspects of the existing system. A preliminary design is created for the new system. A first prototype
of the new system is constructed from the preliminary design. This is usually a scaled-down system,
and represents an approximation of the characteristics of the final product.
Spiral Model Diagram
A second prototype is evolved by a fourfold procedure
30

Network
Evaluating the first prototype in terms of its strengths, weakness, and risks. Defining the
requirements of the second prototype. Planning an designing the second prototype. Constructing and
testing the second prototype. At the customer option, the entire project can be aborted if the risk is
deemed too great. Risk factors might involved development cost overruns, operating-cost
miscalculation, or any other factor that could, in the customer’s judgment, result in a less-than-
satisfactory final product. The existing prototype is evaluated in the same manner as was the
previous prototype, and if necessary, another prototype is developed from it according to the
fourfold procedure outlined above. The preceding steps are iterated until the customer is satisfied
that the refined prototype represents the final product desired. The final system is constructed, based
on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance
is carried on a continuing basis to prevent large scale failures and to minimize down time.
ADVANTAGES
• Estimates(i.e. budget, schedule etc .) become more relistic as work progresses, because important
issues discoved earlier.
• It is more able to cope with the changes that are software development generally entails.
• Software engineers can get their hands in and start woring on the core of a project earlier.
3.3.1 Software Requirement
• Language : java (jdk1.6.0)
• Front End : java swings
• Back End : Oracle10g
• IDE : My eclipse 8.0
31

Network
• Operating System : Windows XP
3.3.2 Hardware Requirement
• Processor : Pentium IV 2.4 GHz.
• Hard Disk : 80 GB.
• Ram : 512 Mb.
3.3.3 Functional &Non-Functional Requirements
Functional Requirements
1) Enter node id
2) Enter no of nodes
3) Register with cost
4) Check the node path list
5) Processing the message details.
6) Verify the rate limits in the nodes
7) Apply the claim-carry and check
8) One node helps another node to detect attacker.
9) Data is transferred successfully
Non Functional Requirements
32

Network
The major non-functional Requirements of the system are as follows
Usability
The system is designed with completely automated process hence there is no or less user
intervention.
Reliability
The system is more reliable because of the qualities that are inherited from the chosen platform java.
The code built by using java is more reliable.
Performance
This system is developing in the high level languages and using the advanced front-end and back-
end technologies it will give response to the end user on client system with in very less time.
Supportability
The system is designed to be the cross platform supportable. The system is supported on a wide
range of hardware and any software platform, which is having JVM, built into the system.
3.4 Algorithms
Algorithm: The protocol runs by each node in a contact
1: Metadata (P-claim and T-claim) exchange and attack detection
2: if Have packets to send then
3: For each new packet, generate a P-claim;
4: For all packets, generate their T-claims and sign them with a hash tree;
33

Network
5: Send every packet with the P-claim and T-claim attached;
6: end if
7: if Receive a packet then
8: if Signature verification fails or the count value in its P-claim or T-claim is invalid then
9: Discard this packet;
10: end if
11: Check the P-claim against those locally collected and generated in the same time interval to
detect
inconsistency;
12: Check the T-claim against those locally collected for inconsistency;
13: if Inconsistency is detected then
14: Tag the signer of the P-claim (T-claim, respectively) as an attacker and add it into a blacklist;
15: Disseminate an alarm against the attacker to the network;
16: else
17: Store the new P-claim (T-claim, respectively);
18: end if
19: end if
34

Network
4. DESIGN
4.1 Introduction to UML
UML stands for Unified Modeling Language. This object-oriented system of notation has
evolved from the work of Grady Booch, James Rumbaugh, Ivar Jacobson, and the Rational Software
Corporation. These renowned computer scientists fused their respective technologies into a single,
standardized model. Today, UML is accepted by the Object Management Group (OMG) as the
standard for modeling object oriented programs.
Types of UML Diagrams
UML defines nine types of diagrams: class (package), object, use case, sequence,
collaboration, state chart, activity, component, and deployment.
Use Case Diagram:
A use case diagram in the Unified Modeling Language (UML) is a type of behavioral
diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical
overview of the functionality provided by a system in terms of actors, their goals , and any
dependencies between those use cases.
Actor:
You can picture an actor as a user of the IT system, for example Mr. Steel or Mrs. Smith
from check-in. Because individual persons are irrelevant for the model, they are abstracted. So the
actors are called “check-in employee” or “passenger”:
35

Network
Actors represent roles that users take on when they use the IT system, e.g., the role of a check-in
employee. One person can act in more than one role toward the IT system. It is important for the IT
system in which role a person is acting. Therefore, it is necessary to log on to many IT systems in a
certain role, for instance, as a normal user or as an administrator. In each case access to the
appropriate functionalities (use cases) is granted.
Actors themselves are not part of the IT system. However, as employees they can be part of the
business system
Use Case
Use cases describe the interactions that take place between actors and IT systems during the
execution of business processes:
A use case represents a part of the functionality of the IT system and enables the user (modeled as an
actor) to access this functionality.
Anything that users would like to do with the IT system has to be made available as a use case (or
part of a use case). Functionalities that exist in the IT system, but that are not accessed by means of
use cases, are not available to users.
Even though the idea behind use cases is to describe interactions, flows of batch processing, which
generally do not include interactions, can also be described as use cases. The actor of such a batch
use case is then the one who initiates batch processing. For instance, generating check-in statistics
would be a batch use case.
36

Network
Class Diagram
Class diagrams are the most common diagram found in modeling object- oriented systems. A
class diagram shows a set of classes, interfaces, and collaborations and their relationships. You use
class diagrams to model the static design view of a system. For the most part, this involves modeling
the vocabulary of the system, modeling collaborations, or modeling schemas. Class diagrams are
also the foundation for a couple of related diagrams: component diagrams and deployment diagrams.
Class diagrams are important not only for visualizing, specifying, and documenting structural
models, but also for constructing executable systems through forward and reverse engineering.
A class diagram is just a special kind of diagram and shares the same common properties as
do all other diagrams- a name and graphical content that are a projection into a model. What
distinguishes a class diagram from all other kinds of diagrams is its particular content.
Sequence Diagram
Sequence diagrams belong to a group of UML diagrams called Interaction Diagrams. A sequence
diagram is an interaction diagram that emphasizes the time ordering of messages. We use interaction
diagrams to model the dynamic aspects of a system. For the most part, this involves modeling
concrete or prototypical instances of classes, interfaces, components, and nodes, along with the
messages that are dispatched among them, all in the context of a scenario that illustrates a behavior.
Interaction diagrams may stand alone to visualize, specify, construct, and document the dynamics of
a particular society of objects, or they may be used to model one particular flow of control of a use
case.
Collaboration Diagram:
Collaboration diagrams belong to a group of UML diagrams called Interaction Diagrams .
Collaboration diagrams, like Sequence Diagrams, show how objects interact over the course of
time. However, instead of showing the sequence of events by the layout on the diagram,
collaboration diagrams show the sequence by numbering the messages on the diagram. This makes
it easier to show how the objects are linked together, but harder to see the sequence at a glance.
37

Network
State chart Diagram
State chart diagrams are one of the five diagrams in the UML for modeling the dynamic
aspects of systems. A state chart diagram shows a state machine. An activity diagram is a special
case of a state chart diagram in which all or most of the states are activity states and all or most of
the transitions are triggered by completion of activities in the source state. Thus, both activity and
state chart diagrams are useful in modeling the lifetime of an object. However, whereas an activity
diagram shows flow of control from activity to activity, a state chart diagram shows flow of control
from state to state.
A state chart diagram shows a state machine, emphasizing the flow of control from state to
state. A state machine is a behavior that specifies the sequences of states an object goes through
during its lifetime in response to events, together with its responses to those events. A state is a
condition or situation in the life of an object during which it satisfies some condition, performs some
activity, or waits for some event. An event is the specification of a significant occurrence that has a
location in time and space. In the context of state machines, an event is an occurrence of a stimulus
that can trigger a state transition. A transition is a relationship between two states indicating that an
object in the first state will perform certain actions and enter the second state when a specified event
occurs and specified conditions are satisfied. An activity is ongoing non atomic execution within a
state machine. An action is an executable atomic computation that results in a change in state of the
model or the return of a value. Graphically, a state chart diagram is a collection of vertices and arcs.
ACTIVITY DIAGRAM
Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar
to state diagrams because activities are the state of doing something. The diagrams describe the state
of activities by showing the sequence of activities performed. Activity diagrams can show activities
that are conditional or parallel.
Activity diagrams should be used in conjunction with other modeling techniques such as
interaction diagrams and state diagrams. The main reason to use activity diagrams is to model the
38

Network
workflow behind the system being designed. Activity Diagrams are also useful for: analyzing a use
case by describing what actions need to take place and when they should occur; describing a
complicated sequential algorithm; and modeling applications with parallel processes.
An activity diagram illustrates the dynamic nature of a system by modeling the flow of
control from activity to activity. An activity represents an operation on some class in the system that
results in a change in the state of the system. Typically, activity diagrams are used to model
workflow or business processes and internal operation. Because an activity diagram is a special kind
of state chart diagram, it uses some of the same modeling conventions.
Component Diagram
Component diagrams are one of the two kinds of diagrams found in modeling the physical
aspects of object-oriented systems. A component diagram shows the organization and dependencies
among a set of components.
You use component diagrams to model the static implementation view of a system. This
involves modeling the physical things that reside on a node, such as executable, libraries, tables,
files, and documents. Component diagrams are essentially class diagrams that focus on a system's
components.
Component diagrams are not only important for visualizing, specifying, and documenting
component-based systems, but also for constructing executable systems through forward and reverse
engineering.
A component diagram shows a set of components and their relationships. Graphically, a
component diagram is a collection of vertices and arcs. A component diagram is just a special kind
of diagram and shares the same common properties as do all other diagrams—a name and graphical
contents that are a projection into a model. What distinguishes a component diagram from all other
kinds of diagrams is its particular content.
Deployment Diagram
39

Network
Deployment diagrams are one of the two kinds of diagrams used in modelling the physical
aspects of an object-oriented system. A deployment diagram shows the configuration of run time
processing nodes and the components that live on them.
You use deployment diagrams to model the static deployment view of a system. For the most
part, this involves modelling the topology of the hardware on which your system executes.
Deployment diagrams are essentially class diagrams that focus on a system's nodes.
Deployment diagrams are not only important for visualizing, specifying, and documenting
embedded, client/server, and distributed systems, but also for managing executable systems through
forward and reverse engineering.
A deployment diagram is a diagram that shows the configuration of run time processing
nodes and the components that live on them. Graphically, a deployment diagram is a collection of
vertices and arcs. A deployment diagram is just a special kind of diagram and shares the same
common properties as all other diagrams—a name and graphical contents that are a projection into a
model. What distinguishes a deployment diagram from all other kinds of diagrams is its particular
content.
Relationships in the UML
There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
These relationships are the basic relational building blocks of the UML. You use them to write well-
formed models.
40

Network
Dependencies
Dependency is a semantic relationship between two things in which a change to one thing (the
independent thing) may affect the semantics of the other thing (the dependent thing). Graphically, a
dependency is rendered as a dashed line, possibly directed, and occasionally including a label.
Dependencies
Associations
An association is a structural relationship that describes a set of links, a link being a connection
among objects. Aggregation is a special kind of association, representing a structural relationship
between a whole and its parts. Graphically, an association is rendered as a solid line, possibly
directed, occasionally including a label, and often containing other adornments, such as multiplicity
and role names.
Associations
Generalizations
Third, a generalization is a specialization/generalization relationship in which objects of the
specialized element (the child) are substitutable for objects of the generalized element (the parent).
41

Network
In this way, the child shares the structure and the behavior of the parent. Graphically, a
generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent.
Generalizations
Realizations
Fourth, a realization is a semantic relationship between classifiers, wherein one classifier specifies a
contract that another classifier guarantees to carry out. You'll encounter realization relationships in
two places: between interfaces and the classes or components that realize them, and between use
cases and the collaborations that realize them. Graphically, a realization relationship is rendered as a
cross between a generalization and a dependency relationship.
Realization
42

Network
4.3 UML Diagrams
Use Case Diagram:
Enter node id
Enter no. of nodes
Node registration with cost
Check the node path list
Client
Message details processing
Verify packets with ratelimit
ExtraNode
Claim carry check
Reciever
Data transfered successfully
43

Network
Class Diagram
DataBase
Connection con
Statement st
ResultSet rs
String s
Database()
createCon()
chek()
insertToLogin()
checkUserName()
Details
Sting info
int index
ArrayList path
ArrayList ipList
ArrayList portList
ArrayList costList
ExtraNode
File dbFile
String str
String strLine
long length
claimCarry()
packetCount()
NodeCreation
No. of node
Node ID
Cost
getPath()
conncet()
construct()
Reciever
String nid
DatagramPacket dp
DatagramSoket ds
int randomNo
receiver()
getData()
display()
Server
Database db
Details ds
Reciever r
String add
setDb()
setDs()
setR()
setAdd()
getDb()
44

Network
Sequence Diagram
c:Client i:Intermediate
Node
c:ClaimCarry
Check
s:Server
enter node id()
enter no. of node()
enter cost()
check node pathlist()
routing path()
upload file()
message detail processing()
detect attacker()
send successful data()
45

Network
Collaboration Diagram
c:Client i:Intermedia
teNode
c:Cccs:Server
message detail processing()
1: enter node id()
2: enter no. of node()
3: enter cost()
4: check node pathlist()
6: upload file()
5: routing path() 7: deteck attacker()
8: send sucessful data()
46

Network
State Chart Diagram
Enter node
id
Enter no.of
nodes
Node registration
with cost
Check the
node path list
message details
processing
enter destination,Browse
the file and Get route
erify the packets in each
node with ratelimit
one node assists another
node to detect attcker
data is transfered
successfully
47

Network
Activity diagram
Enter node ID
Enter no.of
Nodes
Node registration
with Cost
Check the
Node path list
Message Details
Processing
Enter
Destination
Browse the File
and get the Route
Verify the packets in
each node with ratelimit
one node assists another
node to detect attcker
data is transfered
successfully
48

Network
Component Diagram
reciever usr
interface.java
database
extra node
DTN.exe
49

Network
Deployment diagram
Intermediate
Client reciever
Node
Details
Claim Carry
Check
50

Network
5. IMPLEMENTATION
5.1 Modules Description
1. Defence against Packet Flood Attacks
Many nodes may launch flood attacks for malicious or selfish purposes. Malicious nodes,
which can be the nodes deliberately deployed by the adversary or subverted by the adversary via
mobile phone worms each node has a rate limit L on the number of unique packets that it as a source
can generate and send into the network within each time interval T. The time intervals start from
time 0, T, 2T, etc. The packets generated within the rate limit are deemed legitimate, but the packets
generated beyond the limit are deemed flooded by this node. To defend against packet flood attacks,
our goal is to detect if a node as a source has generated and sent more unique packets into the
network than its rate limit L per time interval.
2. Defense against Replica Flood Attacks
The n defense against replica flood considers single-copy and multi copy routing protocols.
These protocols require that, for each packet that a node buffers no matter if this packet has been
generated by the node or forwarded to it, there is a limit l on the number of times that the node can
forward this packet to other nodes. The values of l may be different for different buffered packets.
Our goal is to detect if a node has violated the routing protocol and forwarded a packet more times
than its limit l for the packet.
3. Rate Limit (L)
One possible method is to set L in a request-approve style. When a user joins the network,
she requests for a rate limit from a trusted authority which acts as the network operator .In the
request, this user specifies an appropriate value of L based on prediction of her traffic demand. If the
trusted authority approves this request, it issues a rate limit certificate to this user, which can be used
by the user to prove to other nodes the legitimacy of her rate limit. To prevent users from requesting
unreasonably large rate limits, a user pays an appropriate amount of money are selectively deployed
to high-connectivity nodes. Attackers are randomly deployed. virtual currency (e.g., the credits that
51

Network
she earns by forwarding data for other users [25]) for her rate limit. When a user predicts an increase
(decrease) of her demand, she can request for a higher (lower) rate limit. The request and approval of
rate limit may be done offline. The flexibility of rate limit leaves legitimate users’ usage of the
network unhindered.
4. Claim -carry and check:
To detect the attackers that violate their rate limit L, we must count the number of unique
packets that each node as a source has generated and sent to the network in the current interval.
However, since the node may send its packets to any node it contacts at any time and place, no other
node can monitor all of its sending activities. To address this challenge, our idea is to let the node
itself count the number of unique packets that it, as a source, has sent out, and claim the up-to-date
packet count (together with a little auxiliary information such as its ID and a timestamp) in each
packet sent out. The node’s rate limit certificate is also attached to the packet, such that other nodes
receiving the packet can learn its authorized rate limit.
5.2 Technology Used
A project is a series of activities that aim at solving particular problems within a given time
frame and in a particular location. The activities include time, money, human and material resources.
Before achieving the objectives, a project goes through several stages. Implementation should take
place at and be integrated into all stages of the project cycle.
Implementation is the stage where all the planned activities are put into action. The most
crucial stage in achieving a new successful system and in giving confidence on the system for the
users that will work efficiently and effectively.
The query optimizer is the component of a database management system that attempts to
determine the most efficient way to execute a query. The optimizer considers the possible query
plans for a given input query, and attempts to determine which of those plans will be the most
efficient. Cost-based query optimizers assign an estimated "cost" to each possible query plan, and
choose the plan with the smallest cost. Costs are used to estimate the runtime cost of evaluating the
query, in terms of the number of I/O operations required, the CPU requirements, and other factors
determined from the data dictionary. The set of query plans examined is formed by examining the
52

Network
possible access paths (e.g. index scan, sequential scan) and join algorithms (e.g. sort-merge join,
hash join, nested loops). The search space can become quite large depending on the complexity of
the SQL query.
Cost estimation models are mathematical algorithms or parametric equations used to estimate
the costs of a product or project. The results of the models are typically necessary to obtain approval
to proceed, and are factored into business plans, budgets, and other financial planning and tracking
mechanisms.
The system can be implemented only after through testing and if it is found to work according
to the specification. It involves careful planning, investigation of the current system and its
constraints on implementation.
Feasibility Study
Preliminary investigation examine project feasibility, the likelihood the system will be useful
to the organization. The main objective of the feasibility study is to test the Technical, Operational
and Economical feasibility for adding new modules and debugging old running system. All system is
feasible if they are unlimited resources and infinite time. There are aspects in the feasibility study
portion of the preliminary investigation:
• Technical Feasibility
• Operational Feasibility
• Economical Feasibility
Technical Feasibility
The technical issue usually raised during the feasibility stage of the investigation includes the
following:
• Does the necessary technology exist to do what is suggested?
• Do the proposed equipments have the technical capacity to hold the data required to use the new
system?
• Will the proposed system provide adequate response to inquiries, regardless of the number or
location of users?
53

To Lie or To Comply: Defending against Flood Attacks in Disruption Tolerant Network

To Lie or To Comply: Defending against Flood Attacks in Disruption Tolerant Network

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Similar to To Lie or To Comply: Defending against Flood Attacks in Disruption Tolerant Network

Similar to To Lie or To Comply: Defending against Flood Attacks in Disruption Tolerant Network (20)

Recently uploaded

Recently uploaded (20)

To Lie or To Comply: Defending against Flood Attacks in Disruption Tolerant Network