Addressing The DAO Insider Attack in RPL's Internet of Things Networks
Addressing The DAO Insider Attack in RPL's Internet of Things Networks
X, MONTH 201X 1
in its routing table along with the DAO sender address, as the next Algorithm 1 : DAO Insider Attack Countermeasure
hop to reach that destination; and (b) forwards the received DAO, 1: procedure I NITIALIZATION
in turn, to its own preferred parent to ensure the propagation of 2: set DAO F or M AX
the advertised destination upward to the DODAG root [3][4]. This 3: end procedure
process is repeated by each intermediate node until the DAO is
finally received by the DODAG root. 4: procedure DIO T RANSMITTED
In the non-storing mode of RPL, the same procedure is 5: for each child in Children list do
followed but a parent receiving a DAO does not store any routing 6: child DAO Counter = 0
state. Instead, it simply forwards the message to its own preferred 7: end for
parent until it is finally received by the DODAG root. Once the 8: end procedure
DODAG root receives the transmitted DAO, it records the source
route of the intended destination for later use by the data-plane 9: procedure C HILD ’ S DAO R ECEIVED
[3][4]. 10: if child DAO Counter < DAO F or M AX then
III. T HE DAO ATTACK 11: forward the child DAO
12: child DAO Counter++
RPL uses DAO messages to build downward routes enabling
13: else
bi-directional communication. The specification of RPL does
14: discard the child DAO
not stipulate when and how often DAOs are transmitted. Thus,
15: end if
different implementations may opt to use different mechanisms
16: end procedure
to achieve this process. For instance, the study in [15] has
opted to transmit periodically DAOs whereas the Contiki RPL V. T HE P ERFORMANCE E VALUATION
implementation [16] transmits the DAO based on the Trickle
timers of DIOs. In Contiki RPL, a child node should unicast a
To evaluate the effect of the DAO attack on the efficiency of
DAO to its preferred parent on three occasions: 1) upon receiving
the network and the performance of our proposed mechanism
a DIO from that parent; 2) upon changing its preferred parent;
in mitigating that attack, we have conducted a set of experi-
and 3) upon detecting some specific errors.
ments using Contiki (Contiki3.0), a lightweight and open-source
An interesting point in this context is that the transmission of
operating system designed specifically for low-power resource-
a DAO message by a child node will trigger the transmission of
constrained IoT devices [17]. Contiki features a highly optimized
multiple DAOs proportional to the number of intermediate parent
networking stack including several IoT standards such as CoAP,
nodes between that child and the DODAG root. An adversary can
UDP, 6LoWPAN and IPv6. It also features implementations for
exploit this fact to harm the network by repeatedly and judiciously
RPL standard fundamental mechanisms. Cooja [18], a cross-
(to go undetected) transmitting DAOs to its parent node. A simple
level simulator for Contiki, was used to carry out the simulation
way to mount this attack is to replay an eavesdropped DAO from a
experiments, to emulate the exact binary code that runs on
legitimate node by an outsider triggering DAO forwarding upward
real sensor devices. Cooja incorporates an internal hardware
by the nodes parents [14]. This kind of attack can be mitigated
emulator called MSPsim [19], which is used in our simulations,
using security services provided by the underlying layers or
to emulate accurately (i.e. impose hardware constraints) the
RPL itself such as MAC-layer encryption and the cryptographic
Tmote Sky platform, an MSP430-based board with an ultra-low
challenge-response handshake [14]. However, these mechanisms
power IEEE 802.15.4 compliant CC2420 radio chip. We used
will not be sufficient to counter an attack where the attacker is
the Unit Disk Graph Radio Medium (UDGM) radio protocol, the
an insider or compromised node [14].
CSMA/CA protocol at the MAC layer and the ContikiMAC as
IV. T HE P ROPOSED S OLUTION a radio duty cycling (RDC) protocol. The ContikiRPL library
In order to address a DAO insider attack in RPL, a new mecha- was altered to implement the DAO attack on some nodes. In
nism has been proposed, named SecRPL that restricts the number particular, we implemented the attack by means of malicious
of forwarded DAOs by a parent. In fact, there are two options insider nodes programmed to transmit DAO messages to their
for how this restriction can be applied: the first is to restrict the preferred parents periodically at preconfigured fixed periods. A
entire number of forwarded DAOs regardless of the source node set of three malicious nodes running the DAO attack were used.
(i.e. the node who initiated the DAO); the second is to restrict the At the application layer, we simulated a periodic data collection
number of forwarded DAO per destination.Here we opt to use the application where each node sends one packet to the sink every
second option, as the first option would result in blocking some 60 seconds (the time of sending is randomly chosen within the
DAOs coming from non-attacker nodes effecting negatively the 60 seconds period). The sink also sends a reply for each received
quality of the downward paths. It may also result in DAOs of packet to simulate the downward traffic. We have considered in
some nodes being blocked more than DAOs of some others. In our simulations a uniform distribution where 50 nodes are spread
particular, each parent node associates a counter with every child in a square area of 100m x100m. All nodes are static including
node in its sub-DODAG. When the number of forwarded DAOs the DODAG root, which is located outside the square area by a
for a child exceeds a pre-specified threshold, the parent discards distance of 10 meters. We have selected three nodes at the farthest
any DAO message carrying the prefix of the respective child. edge from the root to act as malicious nodes to cover the majority
To ensure that no node will be blocked due to the time of forwarding paths; this is what attacker might think of to harm
factor, the counter is reset between each two consecutive DIOs. the network widely. The number of allowed DAOs forwarded
Specifically, when the parent node sends out a DIO message, the by a parent per child (DAOMax threshold) is set 10 for our
counters for all of its children are reset. proposed mechanism. The rate in seconds at which the attacker
IEEE COMMUNICATIONS LETTERS, VOL. XX, NO. X, MONTH 201X 3
sends DAO messages (attack interval) is varied between 0.25 under this topology, in fact, the effect of attack may differ under
and 10 seconds. For each scenario, five simulation experiments different topologies or under different data traffic rates). This can
with different seeds were run in order to get statistically valid be attributed mainly to the congestion incurred by the increase
results. The graphs below show the mean values of the results in the number of forwarded DAOs. This has been mitigated in
and the error bars at the 95% confidence interval of the mean. The the proposed solution, which registers PDRs comparable to that
simulation time was selected to be 1800 virtual seconds for each of the reference model.
experiment. The performance evaluation was based the following
metrics
Number of DAOs Forwarded: is the average number of for- RPL
InsecRPL
700
SecRPL
warded DAOs sent by the parent nodes in the network.
is the average ratio between the number of data packets sent 200
out by the network nodes and the total number of data packets 100
0.25 1 4 8 10
Frequency of attack(seconds)
Packet Delivery Ratio in the downward direction (Downward Fig. 1: DAOs forwarding overhead under various attack intervals
PDR): is the average ratio between the number of packets
received at the nodes and the total number of replies sent out 7
RPL
by the root node. InsecRPL
SecRPL
root. 3
delay of all replies sent by the root and received at the nodes 1
RPL under DAO attack), and SecRPL (i.e. RPL under attack 0.25 1 4 8
Frequency of attack(seconds)
10
with our proposed mitigation mechanism) in terms of previous Fig. 2: Average power consumption under different attack intervals
mentioned metrics. Fig. 1 shows the average number of forwarded
DAO messages per node under various attack intervals. The 3.5
RPL
InsecRPL
SecRPL
DAOMax threshold is set to 10 per destination. As can be 3.0
Upward Latency (seconds)
interval. However, Fig.1 also shows that SecRPL has registered 1.0
0.25 1 4 8 10
Frequency of attack(seconds)
also holds true within the case of energy consumption as shown
Fig. 3: The upward latency under various attack intervals
in Fig. 2, which can be attributed to the mechanism of restricting
the number of DAOs that can be forwarded by a parent per 3.0
destination. Indeed, Fig. 2 shows that the InsecRPL has experi- RPL
InsecRPL
2.5
SecRPL
Downward Latency (seconds)
0.25 1 4 8
Frequency of attack(seconds)
10
of a forwarders children nodes, though they are not forwarders Fig. 4: The downward latency under various attack intervals
themselves, (listening component) by forcing them to listen for
longer periods due to the congestion at that forwarder node. A. The Effect of the Threshold Parameter (DAOMax)
The upward and downward latencies of compared protocols Another point we study here is the effect of our mitigation
are illustrated in Fig. 3 and Fig. 4 respectively. Similarly, it is mechanism on the reliability of networks in terms of packet
clear that the DAO attack has an adverse effect on the latency in delivery ratio. It is clear that setting the threshold value to a
both directions, which can be attributed again to the congestion small number will minimize the energy consumption and control
induced by the attack at the forwarder nodes. In Fig. 5 and 6, overhead but at the cost of reliability. This is illustrated in Figs.
we show the performance of the three protocols in terms of 5 and 6. Fig. 5 shows that setting the DAO threshold Max to a
upward PDR and downward PDR respectively. The figures show very small value reduces both the energy consumption and control
that mounting the attack with a high attacking interval, affects traffic overhead. However, as illustrated in Fig. 6, this results in
negatively both the upward and downward traffic patterns (i.e. a lower downward PDR for any threshold less than four while
IEEE COMMUNICATIONS LETTERS, VOL. XX, NO. X, MONTH 201X 4
RPL
InsecRPL
intermediate parent between that child and the DODAG root. In
1.2 SecRPL
addition, this kind of attack can be mounted simply without the
1.0
0.25 1 4 8 10
while moderately affecting downward traffic reliability under the
Frequency of attack(seconds)
Fig. 5: The upward PDR under different attack rates chosen assumptions. We have, further, proposed and assessed a
mechanism to mitigate the effect of such an attack.
1.4 R EFERENCES
RPL
InsecRPL
1.2 SecRPL [1] J. Hui and D. E. Culler, ”Extending IP to Low-Power, Wireless Personal Area
1.0
Networks, ” in IEEE Internet Computing, vol. 12, no. 4, pp. 37-45, 2008.
Downward PDR
[2] J. Hui, P. Thubert, ”Compression Format for IPv6 Datagrams over IEEE
0.8
Frequency of attack(seconds)
8 10