1.1 Problem Definition
DTN consists of mobile nodes which are carried by human beings, vehicles, etc. DTN enables data transfer when mobile nodes are intermittently connected. Due to lack of consistent connectivity, two nodes can only transfer data when they move into the transmission range of each other. Since the contacts between nodes are opportunistic and duration of contact may be short because of mobility, the bandwidth which is only available during the opportunistic contacts is limited resource. Also, mobile nodes have limited buffer space. Due to the limitation in bandwidth and buffer space, DTNs are vulnerable for flood attack. In flood attack, attackers inject different packets (packet flood attack) or replicas of same packet (replica flood attack) into the network. Flooded packets and replicas were wasted in the precious bandwidth and buffer space. The battery life of mobile is also wasted for the transmission of flooded packets. It prevents the benign packets from being forwarded and thus degrades the network service. So, it is necessary to secure DTNs against flood attack.
1.2 Models and Assumptions
1.2.1 Network Model
In DTNs, since the duration of contacts may be small, a data item is usually split into smaller packets (or fragments) to facilitate the data transfer. For simplicity, all packets are assumed to have the predefined size. Though in DTNs the allowed delay of packet delivery is usually lengthy, it is still not practical to allow unlimited delays. Thus, each packet will have a lifespan. The packet has no significance after its lifespan expires and it will be discarded. Every packet generated by the node is different. This is done by adding the source node ID and a unique sequence number, which is allocated by the source for the packet, in the packet header.
1.2.2 Adversary Model
There are many attackers in the network. An attacker can produced its packets or replicas. When flooding packets, the attacker will act as a source node. It generates and introduces more packets into the network than its rate limit. When flooding replicas, the attacker forwards its buffered packets more times than its limit for them. The attackers may be insiders in the network.
1.2.3 Identity Based Cryptography Model
Identity based Cryptography is applicable for DTNs. It is a type of public-key cryptography in which the public key of a user is some unique information about the identity of the user (e.g. a user's email address). This can use the text-value of the name or domain name as a key or the physical IP address where it translates to.
In 1984, Shamir introduced ID-based systems in order to avoid the explicit authentication of the public keys by means of public-key certificates. The idea was to create public-key cryptosystems, were the identity of a user plays the role of the public key. From a user's identity (which is publicly known and in a standardized form), a PKG computes the corresponding private key and securely transmits it to the user. The PKG must be unconditionally trusted. Analogously, the idea behind ID-based secret-key systems is to derive the (secret) keys from the identity. Since, in secret-key cryptography, the security relies on these keys, this operation can only be performed by a PKG. This PKG also serves as an arbitrator when disputes arise due to a user denying for certain actions.
1.3 Basic Idea: Claim-Carry-and-Check
1.3.1 Packet Flood Detection
To detect the attackers that violate their rate limit L, count the number of unique packets that each node as a source has generated and sent to the network in the present interval. However, since the node may send its packets to any other node for its contact, no other node can monitor all of its sending activities. To address this challenge, the idea is to let the node itself, count the number of unique packets that a source has generated, and claim the up-todate packet count (together with information such as its ID and a time stamp) in each packet and send out. If an attacker is flooding more packets than its limit of the rate, it has to dishonestly claim a count smaller than the real value in the flooded packet. Since the value is larger than its limit of the rate, there is a clear indication of attack.
The count which is claimed must have been used prior by the attacker in another claim, which is fulfilled by the Pigeonhole principle, and the two claims are inconsistent. The nodes which have received the packets from the attacker carry the claims added in those packets when they moved around. When two of the nodes contact, they check if there is any inconsistency between their collected claims. Thus, the attacker is detected when an inconsistency is found.
In Figure1, S is an attacker that successively generates out four packets to A, B, C, and D. Since L = 3, if S claims the count 4 in the fourth packet m4, the packet will be discarded by D. Thus, S with no honesty claims the count to be 3, which has already been claimed in the prior packet m3. m3 (including the claim) is then forwarded to node E. When D and E contact, they exchange the count claims included in m3 and m4, and checks that S has used the same count value in different packets. Thus, they detect that S to be an attacker.
Figure 1. Packet Flood Attack Detection
1.4 Replica Flood Detection
Claim-Carry-and-Check can also be used to detect the attacker that forwards a buffered packet more times than its limit l. In an exact way, when the source node of a packet or an intermediate node transmits the packet to its next hop, it claims a transmission count to the node it encounters, which means the number of times it has transmitted that particular packet (including the current transmission). Depending upon this, the node is the source or an intermediate, which is routing the protocol used, the next hop node can know the limit of the node l for the packet, and ensure that the count which is claimed is within the correct range. Thus, if an attacker wants to transmit the packet more than l times, it must claim a count which has been used prior. Similarly the attacker will be detected, as in case of packet flood attack[2]. Figure 2 shows the Replica Flood Attack Detection.
Figure 2. Replica Flood Attack Detection
2. Proposed Scheme
2.1 Claim Construction
Two pieces of metadata are added to each packet, Pclaim 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 hop nodes along with the packet. T-claim is produced and processed hop-by-hop.
Specifically, the source produces a T-claim and appends it to the packet. When the first hop gets this packet, it removes the T-claim; when it forwards the packet out, it appends a fresh T-claim to the packet. This process continues in future hops. Each hop keeps the P-claim of the source and the Tclaim of its prior hop to detect attacks. Figure 3 shows the Claim Construction.
Figure 3 Claim Construction
2.1.1 P-Claim (Table 1)
When a source node S sends a new packet m (which has been generated by S and not sent out before) to a communicated node, it generates a P-claim as follows
S, CP , t, H(m),SIGs[H(H(m)|S |Cp |t)]
The P-claim is attached to packet m as a header field, and will always be forwarded together with the packet to future hops. When the communicated node receives this packet, it checks the value of CP. If CP is greater than L, it discards this packet; otherwise, it stores the packet and P claim.
2.1.2 T-Claim (Table 2)
When node A transmits a packet m to node B, it appends a T-claim to m. The T-claim includes as current transmission count C for m (i.e., the number of times it has transmitted m out) and the current time t. The T-claim is as follows:
A, B, Ct, t, H(m),SIGA[(H(A|B|H(m)|Ct |t)]
2.2 Detection of the Attacker
Suppose two nodes contact and they have a number of packets to forward to each other, the nodes will exchange their collected P-Claims and T-Claims to detect the flood attacks. If all the claims are communicated, the communication cost will be too high. So, inter contact sampling technique is used. A node redirects the received claims to next K (a system parameter) nodes it will contact, and this contacted node will exchange (but not redirect again) these redirected claims in the subsequent contacts[2]. Figure 4 shows the Detection of Attackers.
Figure 4. Detection of Attackers
- Metadata (P-claim and T-claim) exchange and attack detection [9]
- if Have packets to send then
- For each new packet, generate a P-claim;
- For all packets, generate their T-claims and sign them
- with a hash tree;
- Send every packet with the P-claim and T-claim attached;
- end if
- if Receive a packet then
- if Signature verification fails or the count value in its Pclaim or T-claim is invalid then
- Discard this packet;
- end if
- Check the P-claim against those locally collected and generated in the same time interval to detect inconsistency;
- Check the T-claim against those locally collected for inconsistency;
- if Inconsistency is detected then
- Tag the signer of the P-claim (T-claim, respectively) as an attacker and add it into a blacklist;
- Disseminate an alarm against the attacker to the network;
- else
- Store the new P-claim (T-claim, respectively);
- end if
- end if
If a node has packets to send, then for each packet, it will generate a P-claim and T-Claim. Tables 1 & 2 shows P&T Claim Parameters. If a node receives a packet, it verifies the P-Claim and T-Claim against the locally collected Claims. If inconsistency is detected, then the signer of the Claims is tagged as an attacker and an alarm is disseminated against the attacker to the network.
Table 1. P-Claim Parameters
Table 2. T-Claim Parameters
2.3 Different Rate Limits
When nodes have different rate limits, each intermediate node that receives a packet needs to know the rate limit L of the source of the packet, such that it can check if the packet count is within the range. To do so, when source sends out a packet, it attaches its rate limit certificate to the packet. The certificate contains the id of the node, its approved rate limit L, validity time and the trusted third party’s signature.
2.4 Probability of Detecting the Attackers
The probability of detecting the attacker is illustrated as follows,
In Figure 4, the attacker S floods two sets of inconsistent packets to two good nodes A and B, respectively. Each flooded packet received by A is inconsistent with one of the flooded packets received by B. In the contacts with A and B, S also forwards some normal, not flooded, packets to make the attack harder to detect.
Let y denote the proportion of flooded packets among those sent by S. For simplicity, y is assumed to be same in both the contacts. Suppose A and B redirect the claims sampled in the contact with S to C and D, respectively. Then the probability of detecting the attacker is given by,
The expected number of flooded packets that A or B can sample is yZ. Since Z is small while a is not that small (which is assumed to be realistic), Povp is negligible. Considering that K << N, Pd is approximated as follows
2.5 Analysis Verification
The performance of the proposed scheme is analyzed by taking two parameters into account. From the obtained result, it is inferred that the performance of the detection scheme increases with increasing the number of intermediate nodes. The following are the parameters which are taken into account for the evaluation of performance using NS2 simulator. Table 3 shows thevariables used in analysis.
- Packet Delivery Ratio
- Detection Rate.
Table 3. Variable Used In Analysis
2.5.1 Comparison of Packet Delivery Ratio
Packet delivery ratio is defined as the ratio of the number of delivered data packets to the destination. It is compared before and after deploying the flood attackers and how it is improved after applying the detection scheme. The detection scheme generates an alarm message after identifying the attacker. So, the receiver drops all the duplicate packets from the attackers. Thus, the packet delivery ratio is increased. The packet delivery ratio variation is shown in Figure 5. Table 4 tabulates the details about the experimental setup.
Figure 5. Nodes Vs Packet delivery ratios
Table 4. Experimental Setup
2.5.2 Nodes Vs Detection rate
Detection Rate is defined as the number of attackers detected to the total number of attackers in the network. The detection rate increases by increasing the number of neighbor nodes. The neighbor nodes that come in contact with each other will exchange claims frequently and identify the attackers. The detection rate is shown in Figure 6. Table 4 shows the experimental setup.
Figure 6. Nodes Vs Detection rate
Conclusion
In this paper, rate limiting is used to mitigate flood attacks in DTNs, and the proposed scheme exploits Claim-Carryand- Check to probabilistically identify the violation of rate limit in DTN environments. Trace-driven simulations showed that the scheme is effective to detect the flood attacks. The scheme works in a distributed manner, not only relying on any infrastructure or online central authority, which also well for suits the environment of DTNs.