Securing Solar Energy Harvesting Road Side Unit (RSU)

Using an Embedded Cooperative-Hybrid Intrusion

Detection System (ECHIDS)
Qutaiba I. Ali
Mosul University/Iraq
E-mail:Qut1974@gmail.com
Abstract— Service availability is an important security issue which means that the authorized access of data and other VANET resources is made ready
when requested or demanded. This feature could be obtained by protecting the system against the different types of attacks using an Intrusion
Detection System(IDS). This paper deals with the design and implementation of an Embedded Cooperative-Hybrid Intrusion Detection System
(ECHIDS) for a solar energy harvested Road Side Unit(RSU). In order to offer a high level of defense against the various attacks and to cope against
the limited processing and energy resources in the RSU, we suggest a cooperative IDS approach. In this approach, the RSUs do not depend only on
their local view to make conclusions about the security status of their network, but also cooperate with their VANET server by exchanging security
reports to create a more global and precise idea about the security situation of the whole network, the possible attacks and their origins. The other main
contribution in this paper is the attempt to insert a Hybrid Intrusion Detection System functionality (combines all the three IDS techniques :signature
based IDS, anomaly based IDS and behavioral based IDS) into the RSU itself. Each one of these IDSs has its own resistance strategy against certain
classes of attacks which enhances RSUs’ immunity. The suggested IDS was prototyped using an experimental model based on the Ubicom IP2022
network processor development kit and different practical tests were performed to evaluate the effectiveness of the suggested solutions.

Index Terms—Vehicular Ad hoc Network, Network Security, Road Side Unit, Cooperative Hybrid Intrusion Detection System, Solar Energy
Harvesting, Power Management.

I. INTRODUCTION

Many research works suggest that there is an actual need for a VANET infrastructure, which consists of various types of fixed
nodes performing different actions according to VANET applications demands. An important class of these nodes are Road Side
Units (RSUs)[1,2]. Due to power supply requirements, it was recommended to localize RSUs nearer to wired electricity sources,
such as traffic lights[1,2]. However, such placement limits the area covered by the RSUs and thus their services. In order to
overcome this restriction, it is required to establish self powered RSUs. In our previous work [3], we suggest that a RSU can
harvest the energy needed for its work from the surrounding environment, especially solar energy. Such a suggestion permits to
install RSUs in any place without considering the power supply availability and hence, extensive area can be covered by the
VANET infrastructure. We also suggest that these RSUs would create an ad hoc network in order to assist each other to deliver
data packets to their destinations, that's why an ad hoc infrastructure is needed. Each RSU is responsible for providing different
VANET services to the vehicles in a certain area of the city, ranging from traffic safety and road monitoring services to Internet
access & entertainment services. RSUs, as a part of the VANET infrastructure, receive different packets from vehicles (vehicle
status or Internet access request), then forward them to the VANET server via the ad hoc network. As a member in the ad hoc
network, a RSU also behaves as a router which delivers other RSUs traffic to their destinations, see Fig.1 .
In order to implement a functional and efficient solar energy powered RSU, the embedded UBICOM IP2022 platform was chosen
to implement the proposed RSU. The heart of the harvesting module is the harvesting circuit, which draws power from the solar
panels (4-4.0-100 solar panels from Solar World Inc), handles energy storage (2800 mAh, AA battery pairs), and routes the power
to the intended system, see Fig.1. A DC-DC converter is used to provide a constant supply voltage to the embedded system and
we used Texas Instruments TPS63000 low power boost-buck DC-DC converter to achieve this goal [3].
From the above discussion, it is clear that the RSU plays a major role in the proposed green VANET infrastructure and hence, the
security of this device must be a priority [4,5]. The RSUs are subjected to a plethora of network traffic conditions and security
attacks, which can seriously affect their integrity, performance and power consumption and hence their availability. So our efforts
in this paper focus on the definition of a multitude of security methods to protect the RSUs (in particular) and the VANET (in
general) against these threats.
 Fig.1 The suggested solar energy harvested RSU

II.LITERATURE REVIEW
This section presents a survey on the existing research works on the IDS functionality in an Ad hoc wireless networks which had
spanned and covered a wide research area. Since the nature of the ad hoc networks is distributed and requires the cooperation of
other nodes, many previous works [6-13] have proposed that the intrusion detection in such networks should also be both
distributed and cooperative. Every node contributes in the intrusion detection and response by having an IDS agent running on
them. An IDS agent is in charge of distinguishing and gathering the local events and data to identify the probable intrusions, as
well as initiating a reply separately. However, the neighboring IDS agents cooperatively partake in the global intrusion detection
actions when the evidence is uncertain. On the other hand, some papers [14,15] suggest enhancing the ability of an IDS to detect
the various types of attacks, under different conditions, by modifying its internal architecture. Through combining more than one
type of IDS strategies, which is so widely called the Hybrid-IDS, intrusions detection task would be more efficient and precious.
Many papers dealt with the building of different IDS approaches against specific types of ad hoc networks attacks [16-24]. These
behavioral based IDSs, try to identify the activities of certain types of attacks by comparing their behavior against previously
defined models (an in depth comparison among the different IDS methods can be seen in Table 1). Finally, some research works
focus on employing the reputation and trustfully based verification methods in order to categorize the different nodes in the
VANET[25-28].
Although the majority of the mentioned references give various IDS solutions for the Ad hoc networking environment, they do
not take into consideration the realization issues of their thoughts on real platforms, especially embedded systems. Even though,
our previous works in [29,30] study the implementation challenges of inserting an IDS functionality into an embedded platform,
the contribution was limited to a cooperative IDS energized by the traditional wire power resources. Our efforts in this paper
focus on answering some questions regarding the implementation of a Cooperative-Hybrid IDS into a renewable energy
dependent embedded system, questions such as:
1. Is it possible to implement such a sophisticated system into a resources limited platform?
2. What do we need to ensure the successful combination of the different security methods, algorithms and techniques with solar
energy powered system?
3. What are the assessment of the whole system in terms of its network performance, practicability, power consumption and
immunity against the different threats?
 TABLE 1 A COMPARISION OF DIFFERENT IDS IMPLEMENTATIONS

Application Power Implementation Summary of IDS Features

IDS Name IDS Type
Field Source Platform
The Watchdog consists to monitor the behavior of all nodes, and chooses
the safest route through the module Pathrater. Therefore, all the nodes in the
Watchdog and Computer network monitor each other as a mesh architecture. The nodes monitor the
Cooperative MANET Traditional
Pathrater [16] Simulation forwarding activity of each other and if a malicious node is detected, then a
report is sent to the source node to update its routing table to exclude the
misbehaved node.
This IDS is an extension to the DSR routing protocol using a reputation
based mechanism similar to the Watchdog and Pathrater mechanisms.
CONFIDANT Computer
Cooperative MANET Traditional However, since this protocol allows sending alarms, the network can be
[6] Simulation
subject to the attacks by sending false accusations. Thus, the denial of
service attack can be easily achieved.
This is a cooperative distributed architecture where each node is responsible
for detecting signs of intrusion locally. The model of the IDS agent is
Zhang et Lee Computer divided into six modules. The cooperative detection engine module is
Cooperative MANET Traditional
IDS [7] Simulation executed when an abnormality is detected with a weak evidence and
requests the cooperation of the other nodes in the network via another
secured communication module called the secure communication.
The CORE mechanism offers a solution to counter the selfish behavior of
the nodes. The proposed solution is to offer an incentives to any node
wishing to participate in the collaborative processes. The incentives are
Computer inspired by the game theory. Each node has a reputation to establish
CORE [8] Cooperative MANET Traditional
Simulation reflecting its honesty. To transmit or receive a packet, the node must have a
sufficient reputation. In addition, each node detected as malicious or selfish
sees its reputation diminish which has the effect of completely isolating
these nodes from the network (unable to send or receive packets).
This system splits the network into in to nine non-overlapping zones (zone
A to zone I). the nodes can be classified into 2 different groups: Intra-zone
and Inter-zone. ZBIDs use local and collaborative detection techniques. The
Computer
ZBIDS [9] Cooperative MANET Traditional local detection module consists of a general intrusion detection agent model
Simulation
and a Markov chain-based anomaly detection algorithm. The collaborative
detection module works on the ZBIDS agents and uses an aggregation
algorithm on the gateway nodes.
This IDS is an extension to the Snort IDS by adding a new pre-processor.
The hybrid Snort was designed, implemented and tested with the data set of
the DARPA project, to verify its correct operation. The results obtained
have shown that aspects such as the database or the number of elements
Software
H-Snort [14] Hybrid General Traditional used to model the normal network behavior affect considerably on the
Implementation
performance of the IDS. It has been verified that when the number of
elements increases it has less sensitivity and therefore detect few attacks.
The results also denote the importance of training the system during a long
time to reduce the number of false alarms.
The hybrid IDS is obtained by combining a packet header anomaly
detection (PHAD) and a network traffic anomaly detection (NETAD) which
Software
H – IDS [15] Hybrid General Traditional are anomaly-based IDSs with the misuse-based IDS Snort which is an open-
Implementation
source project. It is observed that the number of attacks detected increases
much more with the hybrid IDS.
This cooperative wireless IDS was designed and implemented on an
embedded Ubicom network processor platform. The proposed system
provided a multilevel protection to the network and its hosts and can be
updated against new types of attacks. The proposed WIDS could be placed
Wireless Embedded in different locations and can be integrated with different wireless devices
WIDS [29] Cooperative Networks, Traditional Ubicom Network because of its small size and low cost. Tree structure method which was
MANET Processor used to develop the WIDS’s rules set can be considered as an efficient
method because it economized the searching time for the attacks rules and
occupied a minimum space in the memory. The packets processing rate of
the proposed WIDS was high and it support data rate ranges between 1.08
and 9.24 Mbps..
This is an implementation of distributed wireless sensor network gateways
armed with an Intrusion Detection System (IDS). The main contribution of
this work is the attempt to insert the IDS functionality into the gateway
node (UBICOM IP2022 network processor chip) itself. This was achieved
by building a light weight signature based IDS based on the open source
Embedded SNORT IDS. Regarding the gateway nodes, as they have limited processing
WSN Gateway
Cooperative WSN Traditional Ubicom Network and energy constrains, the addition of further tasks (the IDS program) may
IDS [30 ]
Processor affects seriously on their performance, so that, the current design takes these
constrains into consideration as a priority and uses a special protocol to
achieve this goal. In order to optimize the performance of the gateway
nodes, some of their preprocessing tasks were offloaded from the gateway
nodes to a suggested classification and processing server and a new
searching algorithm was suggested.
 III. THE THREATS MODEL
In this paper we are concentrating on the attacks perpetrated against the RSU itself rather than the VANET infrastructure or its
users and applications. As shown in Fig. 2, the security threats against a RSU can take different forms and may originate from
different sources. These sources can be an insider attackers (attacks (1) & (2) in Fig. 2) which are either a "VANET user" (e.g.,
the vehicles) or a forged RSU. In other words, the insider attacker is an authentic user of the network who has some knowledge
of the network and makes use of it for understanding the design and configuration of the RSUs and the whole network. On the
other hand, the outsider attackers (attack (3) in Fig. 2) make use of the VANETs' Internet connection to launch their attacks from
a remote location outside the VANET coverage area[19].
On the other side, when investigating the possible types of attacks, the RSUs are susceptible to a variety of attacks differ in their
nature, goals and catastrophic effects[20]. We have made a survey on the possible attacks against the RSUs, according to their
origins, as abstracted in Table 2.

Fig.2 Threat Model against a RSU

TABLE 2 SURVEY OF THE POSSIBLE RSU ATTACKS

 IV. EMBEDDED COOPERATIVE-HYBRID INTRUSION DETECTION SYSTEM (ECHIDS)
Service availability is an important security issue which means that an authorized access of the data and other VANET resources
is made ready when requested or demanded. This feature could be obtained by protecting the system against the different types
of attacks using an Intrusion Detection System(IDS). In order to offer a high level of defense against the various attacks and to
cope against the limited processing and energy resources in the RSU, we suggest a cooperative IDS approach. In this approach,
the RSUs do not depend only on their local view to make conclusions about the security status of their network, but also
cooperate with their VANET server by exchanging security reports to create a more global and accurate idea about the security
situation of the whole network, the possible attacks and their origins (the term “VANET server” used in this paper, stands for the
control center of a VANET cluster. It was assumed that it consists of powerful, cooperative, reliable and secured servers in order
to undertake the different VANET services and to serve its associated clients. It was also assumed that this center was armed
with the different strategies to avoid becoming a single point of failure). The implementation of the suggested cooperative IDS is
shown in Fig. 3a. In such systems, the RSUs play the role of an IDS sensors, they generate, "periodically", their security status
reports then forward them to the VANET server. These reports contain the necessary data about the number, types and sources of
attacks against this RSU at that time. On receiving these reports, the VANET server accumulates them, then performs the
necessary processing to obtain the final report about the security status of this part of the network. Also, the VANET server
suggests the necessary IDS reactions to accomplish against these attacks and declares them to the RSUs and to the VANET
administrator.
Intrusion detection systems must be able to distinguish between the normal and the abnormal activities in order to discover the
malicious attempts in real time. There are three main techniques that an intrusion detection system can use to classify the actions;
a signature based IDS, an anomaly based IDSs and a behavioral based IDS[19]. One of the main contributions in this paper is the
attempt to insert a Hybrid Intrusion Detection System(HIDS) functionality (combines all the three techniques together) into the
RSU itself, see Fig. 3b. Each one of these IDSs has its own defense strategy against certain classes of attacks. For example, the
signature based IDS is the best solution against the well known Internet attacks, while the anomaly based is very effective
against the Denial of Service (DoS) attacks and finally the behavioral based IDS is used to defend against the VANET specific
attacks[21,22]. As shown in Fig.3b, the input traffic to the hybrid IDS is firstly sampled and processed (in the data processing
unit) in order to extract its main features, such as the average data rate, the maximum data rate and the maximum burst size and
many others. This input traffic is then converted into a more proper format to be processed by the three different IDSs. The final
decision of the suggested hybrid IDS is taken based on the sub-decisions made by the three IDSs. This decision includes the
generation of the security reports of this particular RSU, recommending the blocking actions against the malicious nodes and
modifying the routing tables of this RSU in order to avoid insecure routes, see Table 3. The details of each one of these IDSs are
listed below:
 (a)

Response
Unit

(b)

Fig.3 Cooperative-Hybrid IDS (a) Cooperative IDSFunctionality (b) Hybrid IDS Architecture

TABLE 3 FUNCTIONALITY OF THE RESPONSE UNIT

1) Signature Based IDS

In the signature-based intrusion detection systems, the observed behavior is compared with known attack patterns (signatures).
Action patterns that may pose a security threat must be defined and stored in the system. Then, the signature based detection
system tries to recognize any suspicious behavior according to these patterns. It is already concluded from the previous
researches in the ad hoc networks that severe memory constraints make intrusion detection systems that need to store attack
signatures relatively difficult to be built and less likely to be effective [30]. To solve this problem, a signature based IDS was
realized by assembling a light weight and signature based IDS, based on the famous open source SNORT IDS. SNORT is an
open source network IDS capable of performing a real-time traffic analysis and packet logging on the Internet Protocol (IP)
networks[30]. SNORT can performs a protocol analysis and a content searching/matching, and can be used to detect a variety of
attacks and probes[29]. SNORT uses a simple and lightweight rules description language that is flexible and quite powerful.
SNORT rules are divided into two sections, the rules header and the rules options[29].
Regarding the RSUs, as they have restricted processing and energy capabilities, adding additional tasks (such as IDS actions)
may influence dangerously on their performance, so that, the current design takes these constrains into the concern using the
following procedure:
1. The RSUs were loaded with particular rules set (not all rules) which correspond to the most severe attacks at that occasion.
This decision is reached using the IDS sensors (i.e., the other RSUs) scattered around the network. These IDS sensors observe
the network conditions (from a security point of view) and prepare reports of the most frequent attacks at that time. These reports
are sent to the VANET Server for more processing. In its initial status, the complete library of the SNORT rules was assumed to
be partitioned into many groups and each IDS-RSU was loaded with different sets of these rules (i.e., distributing all the rules in
the real environment). When these RSUs start their work, the signature based IDSs begin their sensing and reporting procedure
which yields the rule sets to be fine tuned gradually according to the network security status.
2.The VANET Server brings together the reports from the RSUs and inspects them to allocate the most dangerous attacks at that
instance. Also, it has the classification and processing program which is used to classify the SNORT rules to speed up the
searching process at the RSUs. After that, the server broadcasts the processed rules set to all RSUs that exist in the network.
3.In order to maintain the efficiency and the performance of the RSUs, a new rules processing algorithm is recommended. The
major suggestion of the proposed algorithm can be achieved through employing the preprocessing part of algorithm in the
VANET server and only the searching part of the algorithm is implemented in the RSUs. Aho-Corasick (AC) algorithm [29] is
chosen in this paper to act as the classification and processing algorithm (at the VANET server) which builds up a state machine
that encodes all the strings to be searched [30]. The preprocessing part will be sent as an update file from the server to the RSUs.
In order to assess the performance of the proposed Ubicom based IDS, numerous experiments were performed. Investigational
measurements of the searching algorithm of each phase were performed as two steps. In the first one, the results were argued by
figuring out the required memory storage derived from the number of the rules that can be stored in the memory of a RSU, see
Fig.4. The second test involves measuring the total response time of the proposed IDS when processing packets having diverse
classes of internet attacks, see Table 4. It is clear that the recommended signature based IDS has a satisfactory performance (with
respect to the nature of an ad hoc network) and its rules set occupy a reasonable space of the available storage memory.

Fig.4 Ubicom IP 2022 memory Usage vs. No. of IDS Rules

TABLE 4 THE TESTED IDS ATTACKS

2) Anomaly Based IDS

This type of IDS focuses on the regular activities, rather than the attacks behavior. These systems describe what represents a
“normal” behavior and then treat as intrusion attempts any activities that diverge from this behavior by a statistically
considerable amount. The intrusion detector learning task includes building a predictive model (i.e. a classifier) capable of
distinguishing between the bad intrusions and the normal connections. Recently, an increasing amount of research has been
conducted on applying the neural networks to detect the intrusions[20], so that this approach was followed in this paper. As
shown earlier in Fig. 3b, the heart of our anomaly IDS is the prediction algorithm which actually makes use of an Artificial
Neural Network (ANN) predictor, a three-layer neural network predictor with a learning rate of 0.25.
In this paper, the total network traffic (in bps) transmitted to/received from an RSU was considered as the main attribute to
measure the normal system behavior. The network traffic volume was derived from an available road traffic statistics (by
assuming a certain network traffic to/from each vehicle [3]) which represents an averaged number of vehicles passing this
particular road (i.e., the road traffic volume). The road traffic volume is resulting from the interaction of many other factors such
as: the vehicles movement, the road availability, the drivers behavior, the road traffic status, the weather conditions and the users
behavior according to special circumstances (such as a business day or holidays)[31]. Therefore, we can see that we have already
included many prediction factors in our ANN training procedure when we dealt with the network traffic volume. However, in an
upcoming future work, these prediction factors (in addition to others such as the ad hoc network topology, the RSUs availability
and the VANET traffic profiles) will be taken into account to build a sub ANN predictor for each factor which will enhance the
accuracy of the anomaly IDS and its future estimation.
Three ANN based predictors were built to estimate the network traffic for different time periods: a week, a month and a year
time scale, see Table 5. However, only one of them could be implemented at a time due to the memory constraints of the current
platform. Due to the huge amount of data, a reduction of data is compulsory and a set of sample values were hauled out and
averaged from the available data. The samples sets were divided into a training sets and a test sets. The assessment of the model
performance can be done by the Mean Square Error, calculated as the difference between the forecasted and the actual values
[31]. It is noted that the average error values for the forecasting were increased as the time scales increase because more variation
is expected over a longer time period, due to the changed environmental, seasonal, and circumstantial conditions, which affects
on the road traffic behavior. Also, the measured false positive and false negative ratios (in which the predicted values are more or
less than the real values [31]) show that our system tends to generate higher false positive predictions. However, the error values
are considered satisfactory and fall within the acceptable range of such systems [31].
In order to show the importance of this subsystem to detect the different patterns of an abnormal traffic, example rules were
written to detect numerous types of DoS attacks and to assign the proper reaction procedures against them, see Fig. 5 and Table
6. It is clear that our anomaly based IDS plays an important role in sensing the abnormal traffic patterns (as determined by the
administrator) and hence, constructing an additional defense line against the different intrusion attempts.

TABLE 5 ANN PREDICTOR PARAMETERS

Fig.5 An Example Rule of Anomaly IDS

TABLE 6 SIMULATED ATTACKS PATTERNS AGAINST ANOMALY IDS

3) Behavioral based IDS
This type of IDS is also based on the divergence from the usual behavior in order to identify the attacks, but they are based on
manually defined conditions that explain what a proper operation is and observe any behavior with respect to these restrictions.
This is the technique we used in our approach. It is easier to be applied in the VANETs, since the normal behavior cannot easily
be districted by the machine learning and training techniques.
In order to explain the principles of our approach, we’ve build a behavioral based IDS to detect two examples of VANET
specific attacks: the Black hole attack and the Energy Exhaustive Attack.
 The Black hole attack occurs when a compromised node drops a packet that is bound for a particular destination. In this way,
an attacker can selectively filter the traffic from a particular part of the network. Other possible variations of the selective
forwarding can involve dropping all the packets or randomly dropping the packets. Although the random dropping is less
disruptive, it can also be much harder to be reliably detected and traced [20].
Detecting the black hole and selective forwarding attacks can be a rule on the number of packets being dropped by an RSU (each
of the RSUs will apply that rule for itself to produce an intrusion alert). The adopted method here follows the “Watchdog”
approach [32], and it relies on setting a threshold on the rate at which the packets are dropped (we called it Recorded Dropping
Rate (RDR)), and when this threshold is reached an alarm can be generated (the packets dropped at a lower rate were returned to
other reasons such as collisions or node collapse). In this context, with the aim of applying this approach, we assume that for a
link between two RSUs, the watchdog nodes will be all the nodes that reside within the intersection of their radio range,
including the source RSU. Also, we assume that the RSUs are capable of simply observe the activities of their neighbored RSUs
to see whether they forward correctly the packets they receive by listening promiscuously to their transmissions (promiscuously
we mean that since the RSUs are within the range of each other, they can overhear the other nodes traffic). Therefore each RSU
needs to keep the track of the packets not being forwarded within a predetermined amount of time we called analyzer time slot,
during which it creates statistics on the overheard packets (if the packet was not forwarded within a certain amount of time, then
the RSU retransmits it again with limited number of retransmission attempts (3 attempts in our model)) . At the end of each time
slot an alert may be generated according to the threshold condition, which is sent by that RSU to the server as a security report.
When the next time slot is started, the same process is repeated periodically, for all the RSUs, see Fig. 6. The next design
concern we need to resolve is who is going to make the final conclusion that a node is certainly an impostor and the procedures
should be taken. In this paper, we makes use of the cooperative decision making approach, where the RSUs and their associated
VANET server cooperate in order to decide whether a definite RSU is launching a selective forwarding attack and to take the
suitable actions. For instance, if the security reports received by the server inform that more than 50% of the neighbored nodes
to a certain RSU generate an alert against this RSU, then it must be regarded as a compromised and should be removed from the
routing tables of the other RSUs, see Fig. 6.
 Fig.6 The suggested anti-black hole attack IDS procedure
 The energy exhaustive attack is a special type of Denial of Service (DoS) attack based on sending a high traffic volume to
an RSU to exhaustive its stored energy (in the case of battery based RSUs) rather than jamming the communication medium. Our
approach to defend against this attack is to adopt a proper power management scheme.
In this paper, we suggest that a RSU should follows Sleep/Active periods scheme and performs according to its available energy,
specifically, the service rate of the RSU is determined as a function of the RSUs' power budget. In this case we need to define a
relation among Duty Cycling periods (Sleep/Active), Average Service Rate (ASR) and the Available Energy(AE). We firstly
start by defining these terms:
 Average Service Rate (ASR) is the averaged total traffic (in bps) transmitted from and received by an RSU.
 Duty Cycling Periods: In this paper, the operation time of an RSU is divided into slots of (1 second) length. Hence, the Duty
Cycle is the ratio of the active periods to the total slot time.
 Available Energy (AE) is the summation of the residual energy in the batteries from the last day plus the expected energy in the
next day.
Our approach involves the steps shown in Fig. 7. As each time slot is divided into Active and Sleep periods, a RSU enters the
sleep period first (after notifying the neighbored RSUs in order to update their routing tables) for a predetermined amount of time
calculated according to AE. When Active period starts, the RSU wakes up and begins to process the packets stored in the WLAN
NIC, see Fig. 7.

FIG.7 THE SUGGESTED ANTI-ENERGY EXHAUSTIVE ATTACK IDS PROCEDURE

V.

IMPLEMENTATION ISSUES OF THE SUGGESTED ECHIDS

This section demonstrates important suggestions to ensure the successful implementation of the proposed ECHIDS.
1) VANET Clustering
As illustrated earlier, the suggested security solutions depend mainly on the interaction between the VANET server and its
associated RSUs. However, the VANET server is prone to become unavailable either due to a malfunction or to a transmission
medium DoS attack, in such a case the VANET services in general and the IDS functionality in special are susceptible to be
absence for an unknown period of time. In order to deal with a such situation, we suggest that the whole VANET infrastructure
(which covers the roads of a certain city) is divided into logical clusters, each one consist of a VANET server connected to its
associated RSUs [33,34], see Fig.8a. Each cluster is responsible for providing the VANET services to a certain area of the city.
Prior to installing the RSUs in the different clusters, a sophisticated planning procedure is needed[1]. The planning phase
includes two major steps: building a VANET infrastructure map for the whole city (i.e., the RSUs placement), then splitting this
infrastructure into several logical VANET clusters. For the first step, in order to decrease the VANET infrastructure investments
associated with the transportation systems, the chosen deployment rule is of maximum significance when adding the
infrastructure for the vehicular networks [2]. Prior to deploying the RSUs, the authorities should make a preliminary study which
includes gathering a vital data to make a decision where and how to organize the infrastructure nodes [1,2]. The RSUs could be
placed in a homogeneous way trying to maximize the coverage area, or following a non uniform deployment approach trying to
reduce the deployment cost [5]. According to the adopted deployment strategy, the entire map of the VANET infrastructure for a
certain city could be created. The VANET clustering planning could be started from this point. In order to achieve the VANET
clustering goals, the planning procedure in this phase must follow the next criteria:
 It is favorable to place the VANET server of each cluster where the maximum number of the Neighbored RSUs (N-RSUs) are
around. For the sake of cluster robustness, the number of the N-RSUs must be greater than two.
 Limiting the number of the RSUs served by each VANET cluster server in order not to exceed its processing capability or the
network bandwidth.
 The shaping of the geographic borders of each cluster must ensure the existence of maximum number of the adjacent clusters.
The borders shaping procedure must guarantee a minimum of two adjacent clusters.
 Also, the maximum number of the Gateway-RSUs (G-RSUs) among adjacent clusters must be ensured. Again, in order to
avoid creating a single point of failure, the number of the G-RSUs among the adjacent clusters must also be greater than two.
The VANET servers in the different clusters are connected to each other (and to the central VANET server) via a dedicated
secured physical (wired or wireless) connections in order to exchange the different road statistical data, the nodes (e.g., the
RSUs) updated settings and the security reports. This arrangement affords a global vision to the current status of the whole
VANET infrastructure and the possible threats. Also, this segmentation is useful to limit the size of the ad hoc network (i.e., the
number of the RSUs served by a certain VANET server) and to isolate the problems in each cluster which offers a more efficient,
robust and secured system. As a consequence to the above suggestion, each logical cluster has its own intrusion detection system
embedded in its RSUs in cooperation with their local VANET cluster server.
In order to explain the realization steps of this new type of VANET clustering, we begin by defining the roles played by the main
actors in this system, see Fig. 8a::
 The Neighbored RSUs (N-RSUs): These are the nearest RSUs to the VANET cluster server. In addition to their usual duties,
the N-RSUs are also responsible for monitoring the server availability. If no response is received from the local VANET server
for a time period longer than a certain threshold, then a server collapse is probable. In such a case, the N-RSU broadcasts an
” Local Server Not Available” alarm to all the RSUs in the cluster to suspend their security reporting and the VANET related
services with this server.
 The VANET Cluster Server (VCS): In order to maintain the system reliability, each VCS performs a periodic reporting and
archiving procedure with the Central Server (CS). Each VCS may be ordered by the CS to take the authorities of a certain
failed VCS. In such a case, the VCS firstly receives the RSUs’ archival settings from the CS then it sends individual invitation
packets to multiple RSUs through the Gateway-RSUs (G-RSUs) (which can be considered as bridge nodes among the
neighbored clusters). The VCS waits for a legal responses from the invited RSUs, then it performs several identity checking
procedures before accepting these RSUs as new members in its cluster. It is worth to mention that a similar invitation/response
procedure could be followed by the corrupted VANET server when getting back to the service again.
 The Central Server (CS): This server is considered as the central management and database core of the whole VANET. It is
responsible for monitoring the security, the availability, the activities and the services of the clusters and their nodes. It is also
in charge of storing an updated versions of the latest status and configuration reports of the VANET infrastructure nodes
(including their ciphering secrets). The CS always checks the availability of the VCSs using different methods and paths (e.g.,
periodic polling). If it was found that a certain VCS is not available, then its associated RSUs will be allocated to the other
VCS(s) as mentioned before. It is clear that the presence of the CS is necessary to guarantee the continuity of the system
operation, so that the other VCSs may take the CS authorities (using an appropriate election algorithm [33,34]) when it goes
down.
 When receiving a ” Local Server Not Available” alarm from the N-RSUs, the other RSUs suspend all the “VCS based”
services (including the security reporting) and waits for legal invitation packets from the other VCSs. However, the RSUs can
keep their usual power management procedure according to their latest settings prior to the VCS collapse.
 The Gateway-RSU (G-RSU): These RSUs were assumed to be placed on the border lines between the logical clusters. The G-
RSUs can be configured to create bridge connections with the other G-RSUs (in the other VANET clusters) in order to bypass
the necessary messages when reforming the VANET clusters. The dynamic allocation procedure is followed in order to
construct the G-RSUs bridges between the adjacent clusters. During the network discovery procedure, each G-RSU can
distinguish between the local RSUs (belong to its cluster) and the foreign RSUs (belonged to the other clusters) using different
means such as the subnet IP addresses of the different clusters. The G-RSU(s) can negotiate with the foreign RSU(s) to create
the bridge connections between them, then informing their VCSs about the creation of this bridge connection.
It is important to mention that the transactions required to preserve the VANET clustering functionality were assumed to be
protected using the necessary message security techniques as mentioned in [35,36].
In order to describe the functionality of the suggested VANET clustering algorithm, a graphical representation of the algorithm
was developed using the state diagram shown in Fig. 8b. The functionality of the algorithm was described to recover against two
major faults :a VCS failure (caused by different reasons such as DoS attack) and the failure of different types of the RSUs. Three
procedures were graphically described (as shown in Figs. 8d,8e and 8f) to recover from the above faults and to return back to the
normal VANET cluster operation shown in Fig. 8c . In these procedures, the different signals and actions were defined carefully
in order to avoid any stalls in the algorithm and to guarantee a smooth flowing of its different routines.
This sub section presented the main headlines of the suggested logical clustering procedure which maintains the continuity of the
VANET services (and at the same time the functionality of the cooperative IDS) in the case of a VCS collapse. However, the
different networking and security procedures related to the implementation of this suggestion need to be studied in depth in
upcoming future works.

2) Entity and Message Protection

The transactions mentioned earlier between the VANET server and its associated RSUs are susceptible to many types of attacks
and the care must be paid to immunize the messages and their origins against them. We suggest the adoption of the necessary
methods in order to obtain:
 Bidirectional entity authentication between the VANET server and an RSU [35,36].
 All the security reports are encrypted and sent together with their HMAC in order to obtain the message confidentiality,
authentication and integrity [35,36].

3) Malicious or Misbehaved RSUs Detection

In the real world, the RSUs can be susceptible to physical attacks by malicious entities, or they might be simply misbehavior. In
order to discover such RSUs, we suggest the following procedure:
1. In each RSU, there is a long period pseudo random number generator (PRNG) routine[37]. Another identical copy of this
PRNG exists in the VANET server, see Fig. 8g.
2. Each pair of these PRNGs are firstly synchronized off-line prior to installing the RSU in the field. The Synchronization
procedure includes feeding the two routines with the same seed values, then starting the random numbers generation procedure
until they produce the same sequences. This initialization point is saved in the RSU and the server and can be added to the
(Factory Default Settings) in order to be used later when resetting the RSU .
3. At this point, the two PRNGs are ready to generate the synchronized random numbers which will be used for different
purposes such as generating the random numbers used in the authentication procedure or to check the functionality of a certain
RSU.
4. In order to check a RSU functionality, the VANET server and its associated RSUs perform periodic synchronization tests (or
in response to a security report about a misbehaving or a malicious RSU). These tests are established from the server side and
involve sending an encrypted challenge packet to the RSU. This packet contains a sequence of random numbers generated by the
PRNG routine in the server side and a time stamp. On receiving this packet, the RSU performs the identity check procedure and
generates the next sequence of numbers and send them (together with a time stamp) back to the VANET server.
If the receiver was a malicious or faulty RSU, it will neither be able to decrypt the challenge packet, nor be able to generate the
next correct sequence of random numbers. In this case, the VANET server broadcasts an encrypted security report to all RSUs
about the discovery of a malicious RSU with the necessary details.
 (a)

“Local Cluster - Normal Operation’ State

“RSU(s) Failure” Event

“VCS Failure” Event

“RSU(s) Failure Recovery” Procedure

“VCS Failure
Recovery” Procedure

“Local Cluster(s) - RSU(s) Failure” State “Local Cluster(s) - VCS Failure’ State
“Local VCS – After Being Repaired” Procedure

“VCS Being Repaired” Event

“VCS Being Repaired” State

(b)
 CS
The CS receives the different periodic reports and the RSUs archival settings from the different cluster servers
The CS Checks the availability of the VCS(s) via the periodic polling

REPORTING

VANET Cluster POLLING

Local VCS

The local VCS Performs the periodic reporting and archiving procedure with the CS
The VCS Cooperates with the RSUs to offer the VANET services
The VCS checks the availability of its associated RSUs

G-RSU
N-RSU

The G-RSU cooperates with the local VCS to offer the VANET services
The G-RSU starts the network discovery procedure
The N-RSU cooperates with the local VCS to offer the VANET servi
The G-RSU begins the handshaking and mutual authentication procedure with the foreign G-RSU(s) The N-RSU monitors the availability of its local VCS

VANET
DATA EXCHANGE

RSU

The RSU cooperates with the local VCS to offer the VANET services

(c)
 Foreign VCS
IF an “invite new RSUs” alert is received from the CS THEN
The foreign VCS receives the RSUs archival settings from the CS
The foreign VCS sends individual “invite new RSUs” packets to multiple RSUs via the G-RSU(s) pair(s)
IF a legal “RSU accept” response is received from the invited RSU THEN the foreign VCS accepts this RSU in its cluster and informs the CS via the “invited RSU(s) status” report
ELSEIF an illegal “RSU accept” response is received THEN the foreign VCS ignores this response
ELSEIF a legal “RSU accept” response was not received within a certain time threshold THEN CS
The foreign VCS sends another invitation packet
IF a certain with a certain
time threshold re-invitewithout
is exceeded attempts
thelimit
reception of periodic reports from certain VCS(s) THEN CS sends status enquiry to this particular VCS (via Polling)
IF the re-invite attempts limit is exceeded THEN
IF the CS the foreign
receives VCS from
no response sendsthis
an “RSU(s)
particularNot
VCSAvailable”
THEN alert to inform the CS via the “invited RSU(s) status” report
ENDIF The CS considers this particular VCS as Not Available
(2) Invite new RSUs ENDIF The CS allocates the RSUs of this particular cluster to(1) other VCS(s)
Invite new RSUs
ENDIF The CS sends an “invite new RSUs” alert to another VCS(s)
The CS sends RSUs archival settings to the chosen VCS(s)
ENDIF
IF “Invited RSU Not Available” alerts are received from a VCS via the “Invited RSU(s) Status” report THEN the CS allocates this particular RSU to another VCS(s)
ENDIF
ENDIF

(8) Invited RSU(s) Status Report

(7) RSU(s) responses

NO RESPONSE

G-RSU
hange the data packets with its paired G-RSU(s) VANET Cluster
IF an ”Local VCS Not Available” G-RSU
alarm is received from a N-RSU THEN the G-RSU suspends the reporting and waits for an invitation packet from another VCS via its pair
IF a legal “invite new RSUs” packet is received from a foreign VCS THEN the G-RSU forwards the invitation to other RSU(s)POLLING
the G-RSU sends a “RSU accept” response to the sender VCS and joins a new VANET cluster
ELSE
Local VCS
(6) RSU(s) responses RSU rejects the invitation and waits for another
ENDIF
NOT AVAILABLE
ENDIF (FAILED)
G-RSU receives and forwards the responses of the invited RSU(s)

(3) Invite new RSUs

(Passive Monitoring)
(4) Invite new RSUs NO RESPONSE
Broadcast “Local VCS Not Available”
(5) RSU(s) responses
N-RSU
N-RSU monitors the availability of its local VCS
IF no response is received from the local VCS THEN the N-RSU Broadcasts an ”Local VCS No
The N-RSU suspends the reporting and waits for an invitation packet from another VCS via
IF a legal “invite new RSUs” packet is received from a foreign VCS THEN The N-RSU sends
IF an ” Local VCS Not Available” RSU
alarm is received from a N-RSU THEN the RSU suspends
ELSE the reporting and waits for an invitation packet from another VCS via the G-RSUs
IF a “invite new RSUs” invitation packet is received from a foreign VCS THEN The RSU The
sends a “RSU
N-RSU accept”
rejects response and
the invitation to the sender
waits VCS and joins a new VANET cluster
for another
ELSE ENDIF
The RSU rejects the invitation and waits for another ENDIF
ENDIF
ENDIF

(d)
 Foreign VCS
IF an “release RSU(s)” alert is received from the CS THEN CS
(2) release RSU(s)
The foreign VCS sends a “release RSU(s)” Command to these RSUs IF the CS receives an “Local VCS Available again” alert from previously an unavailable VCS THEN
(1) ReleaseCSRSU(s)
The foreign VCS receives ”RSU(s) Released” reports from the differentThe
RSUs re- allocates the RSUs of this particular cluster
The foreign VCS informs the CS via the ”RSU(s) Released” report The CS sends an “release RSU(s)” alert to the foreign VCS(s)
IF a ”RSU(s) Released” report is received from the foreign VCS(s) THEN
ENDIF The CS sends an “Re-invite RSUs” alert to the local VCS
The CS sends back the RSUs archival settings to the local VCS
The CS
(8) RSU(s) Released receives a “Local Cluster Report” from the local VCS
Report
ENDIF
ENDIF

1) Local VCS Available again 3) Local Cluster Report

(7) RSU(s) Released
VANET Cluster
G-RSU IF a legal ”release RSU” commandG-RSUis received from the foreign VCS THEN
xchange the data packets with its paired G-RSU(s) The G-RSU forwards the command to the other RSU(s) 2)Re-invite RSUs
The G-RSU sends a “RSU Released” response to the foreign VCS
The G-RSU receives and forwards the responses of the RSUs to the foreign VCS Local VCS
The G-RSU suspends reporting and waits for an invitation packet from the repaired local VCS AVAILABLE AGAIN (REPAIRED)
ELSE The G-RSU rejects the command IF the local VCS is available again (after being unavailable for a while) THEN
IF a legal “Invite RSU” packet is received
The localfrom
VCS the repaired
sends localVCS
an “local VCS THEN again” alert to inform the CS
Available
The G-RSU sends a “RSU accept”IFresponse to the
a “Re-invite local command
RSUs” VCS is received from the CS THEN
The G-RSU re-joins the repaired VANET cluster
The local VCS receives the RSUs archival settings from the CS
(6) RSU(s) Released ELSE The local VCS sends “Invite RSU” packets to multiple RSUs
The G-RSU rejects the invitation and
IF awaits
legalfor another
“RSU accept” response is received from the invited RSU THEN the local VCS accepts this RSU in its cluster and informs the CS via the “
ENDIF ELSEIF an illegal “RSU accept” response is received THEN the foreign VCS ignores this response
ENDIF
ELSEIF a “RSU accept” response was not received within a certain time threshold THEN
The local VCS sends another invitation packet with a certain re-invite attempts limit
IF the re-invite attempts limit is exceeded THEN the local VCS sends an “RSU(s) Not Available” alert to inform the CS via the “Local Cluster Repo
ENDIF
ENDIF
ENDIF
ENDIF

(3) release RSU(s)

(4) release RSU(s)

(5) RSU(s) Released
(1 ) Invite RSU
(2 ) RSU(s) Responses

RSU N-RSU
IF a legal ”release RSU” command is received from the foreign VCS THEN IF a legal ”release RSU” command is received from the foreign VCS THEN
The RSU sends a “RSU Released” response to the foreign VCS The N-RSU sends a “RSU Released” response to the foreign VCS
The RSU suspends reporting and waits for an invitation packet from the repaired local
TheVCS
N-RSU suspends reporting and waits for an invitation packet from the repaired local VCS
ELSE the RSU rejects the command ELSE The N-RSU rejects the command
IF a legal “Invite RSU” packet is received from the repaired VCS THEN IF a legal “Invite RSU” packet is received from the repaired VCS THEN
The RSU sends a “RSU accept” response to the local VCS The N-RSU sends a “RSU accept” response to the local VCS
The RSU re-joins the repaired VANET cluster The N-RSU re-joins the repaired VANET cluster
ELSE ELSE
The RSU rejects the invitation and waits for another The N-RSU rejects the invitation and waits for another
ENDIF ENDIF
ENDIF ENDIF

(e)
 CS
an “Local RSU(s) Not Available” alert is received from a local VCS via reporting THEN Maintenance Unit
0 The CS generates an “RSU(s) Maintenance Required” alarm to inform the maintenance unit RSU(s) Maintenance Required
a “RSU(s) Maintenance Report” is received from the maintenance unit THEN the CS informs the associated VCS(s) via the “RSU(s) Maintenance Report” IF a “RSU(s) Maintenance Required’ alert is received from the CS THEN
DIF The Maintenance Team performs the necessary maintenance proce
NDIF
ENDIF
an “All G-RSU(s) Not Available” alert is received from a VCS THEN
e CS suspends RSUs invitation requests between these clusters
OTO 20
DIF
RSU(s) Maintenance Report

Local RSU(s) Not Available All G-RSU(s) Not Available

REPORTING

VANET Cluster
RSU(s) Maintenance Report
Local VCS
The VCS checks the availability of its associated RSUs and performs the necessary reporting
IF no response is received from certain {RSU(s), N-RSU(s) or G-RSU(s)} THEN an “Local RSU(s) Not Available” alert is sent to inform the CS
IF a “RSU(s) Maintenance Report” is received from the CS THEN
GOTO 10
ENDIF
ENDIF
IF no responses are received from ALL the G-RSU(s) THEN
The VCS sends an “All G-RSU(s) Not Available” alert to the CS
ENDIF

G-RSU
Local VCS checks the availability of the different RSUs in its cluster N-RSU
The G-RSU cooperates with the local VCS to offer the VANET services The N-RSU cooperates with the local VCS to offer the VANET services
The G-RSU starts the network discovery procedure The N-RSU monitors the availability of its local VCS
The G-RSU begins the handshaking and mutual authentication procedure with the foreign G-RSU(s)

RSU
The RSU cooperates with the local VCS to offer the VANET services

(f)
 (g)

Fig.8 Securing Cooperative IDS Transactions (a) VANET clustering diagram (b)State Diagram of VANET Clustering (c) Local
Cluster-Normal Operation State (d) VCS Failure Recovery Procedure (e) Local VCS – After Being Repaired Procedure (f)
RSU(s) Failure Recovery Procedure (g) PRNG pairs in VANET server and RSUs

VI. EXPERIMENTAL INVESTIGATION OF THE SUGGESTED ECHIDS

In order to validate the convenience of the suggested ECHIDS from the power consumption point of view, several practical tests
must be performed using an experimental network, see Fig. 9. The experimental network consists of ordinary PCs supplied with
WLAN NICs working at different data rates, the IP2022 Ubicom platform which was also supplied with the same WLAN NIC,
the energy harvesting module and a real time storage oscilloscope. The purpose of performing these experiments is to emulate
the real VANET environment in which the EHCIDS will be installed.
The objective of the first experiment is to record the electrical current drained by the RSU according to the different modes of
operation: Transmission, Reception, IDLE , CPU full load and SLEEP. The traffic generator PC was programmed to send and
receive a 1Mbps streamed UDP traffic to and from the IP2022 Ubicom platform. The real time oscilloscope (Tektronix224) was
used to measure the current drained from the batteries (according to the different network traffic conditions) by measuring the
voltage across a (0.1Ω) resistor, which is proportional to the drained current. Table 7 summarizes the settings of this experiment
and lists the average values obtained for different data rates.

Fig 9. The Experimental Setup

 TABLE 7 NETWORK SETUP & MEASURED CURRENT VALUES

The goal of the second experiment is to discover the network activities of a typical VANET infrastructure and hence, the power
consumption of the proposed RSU under realistic road traffic conditions. In order to feed the experimental test bed with truthful
values, a simulation model was built using the Network Simulation package. The goal of building this model is to generate a
traffic patterns as close as possible to the real situations. Our network represents a VANET cluster of 40 RSU covering (25 Km 2)
area of a typical city. It was assumed that the vehicles broadcast their 100 byte status packets each one second[3], while the
RSUs generate their 1000 byte traffic report 10 times per minute and forward them to the VANET server [3]. According to our
earlier analysis in [38], Optimized Link State Routing (OLSR) protocol gives the best performance compared to the other ad hoc
routing protocols when working in a non-stationary ad hoc topology, so that it was adopted in our simulation model. The OLSR
mechanisms are regulated by a set of parameters predefined in the OLSR RFC 3626 [4] standard and it was adopted in our
simulation model, see Table 8. In order to simplify the simulation model, the RSUs were assumed to be identical and subjected
to the same road traffic conditions. The different network traffic patterns generated from running the previous simulation model
(listed in Table 8) represent the baseline VANET model, i.e., without the intervention of any attack or the functionality of the
suggested ECHIDS.

TABLE 8 SIMULATION MODEL PARAMETERS, NETWORK TRAFFIC & AVERAGE DRAINED CURRENT VALUES

The aim of the next experiment is to measure the effect of the cooperative signature (SNORT) based IDS functionality on the
network traffic and hence, the RSU power consumption. The test bed was fed with the simulation model outcomes (the RSU
In/Out network traffic) while changing both the rules update file size (number of rules) and the signatures update interval. The
results obtained from performing these tests can be shown in Fig.10a & Fig.10b. Increasing the file size while decreasing the
update interval creates more network load and hence more power is consumed due to the increment in the transmission/reception
operations. It is worth to mention that when using a fully charged 2800 mAh AA battery, a RSU can works for 27 hour under the
VANET baseline traffic pattern, however, the battery life was decreased to 26.5 hour when the update file size was chosen to be
(40 Kbyte) with a (10 Minute) update interval (highest extra traffic case). In the real world implementation, we recommend the
file size to be (20 Kbyte) with a (30 Minute) update interval which is a good compromise between a RSU invulnerability and its
power consumption. Finally, It is worth to mention that an additional RSUs’ CPU utilization (due to the additional IDSs’ tasks)
was observed to be ranged between (5%-15%) according to the update file size.
The effect of the Black hole attack on the RSU power consumption and hence its battery life is described in this experiment. At
this point, two variables were changed: the percentage of a RSUs’ traffic dropped by its neighbors (due to the Black Hole attack)
and the number of the retransmission attempts made by the RSU to compensate this dropping. Fig. 10c shows the destructive
effect of such attack on the drained current and hence the battery life of the RSU as listed in Table 9. These measurements
confirm the importance of our earlier procedure to cope against this type of attack using the suggested Behavioral based IDS.
In this context, we also investigated the degradation in the battery life caused by the energy intensive “promiscuous packet
capturing” task which is needed to perform the suggested defense against the Black Hole attack. Fig. 10d shows that as this mode
of operation includes the reception of an additional network traffic from the neighbored RSUs, more energy is consumed to
achieve this mission. However, including this task into the power budget planning procedure puts its consumed power within the
predetermined energy utilization limits and guarantees a longer battery life.

TABLE 9 EFFECT OF BLACK HOLE ATTACK ON BATTERY LIFE

The purpose of the last experiment is to examine the ability of the suggested power management method to adapt against the
different working conditions (wherein different Available Energy (AE) levels were assumed) and to defend against unmanaged
network traffic conditions (such as those resulting from the Energy Exhaustive Attack). Fig 10e shows that the suggested power
management technique was able to defend against the different DoS traffic profiles and to adapt its performance according to the
available energy levels and hence continue to function in a pre-managed and planned manner which extends the battery life of
the proposed RSU.

(a)

(b)
 (c)

(d)

(e)
Fig. 10 The Experimental Results (a) Effect of varying update file size and update interval on RSU traffic (b) Effect of varying update file size and update
interval on RSU drained current (c) Effect of Black Hole Attack on RSUs’ Drained Current (d) Effect of promiscuous packet capturing mode on battery life
(e) RSU Battery life according to different DoS attack rates

VII. EVALUATION OF THE ECHIDS CHARACTERISTICS

In the last section of this paper, we will use different evaluation metrics [39,40] to assess the overall performance of the
suggested ECHIDS. The system was loaded with 1000 different SNORT rules, the anomaly based IDS (with weekly traffic
predictor) and the behavioral based IDS to detect the Black hole and Energy exhaustive DoS attacks. Table 10 lists the different
characteristics of the proposed system in terms of its resources utilization, system performance and security assessment.
The main remark could be extracted from the system resources utilization statistics is that the proposed ECHIDS was integrated
successfully and efficiently into the RSU platform. It is evident that the suggested IDS consumes a reasonable amount of system
resources with a minimum effect on the RSU original tasks. However, the observed utilization is prone to be variant according to
the requirements of the installed IDS strategies.
On the other hand, our design ensures that the insertion of the additional IDS tasks will not causes a sever degradation in the
nodes or network performance and hence, the VANET safety services (which require delay values to be in the range of tens of
milliseconds [1,2]). Again, this performance reflects the current system and it may changed with the addition/removal of the
different IDS rules.
Lastly, regarding the IDS security and management features, the proposed ECHIDS supports a wide range of known attack
patterns (e.g., SNORT rules) and it can be developed to detect sophisticated Ad hoc network attacks. It is also important to
mention that the UBICOM platform has a ready to use SNMP client which is very important to perform the RSU (and ECHIDS)
remote management and reconfiguration tasks.
To complete the picture, an extensive security assessment was made through considering the probable attack vectors and risk
sources while suggesting the appropriate countermeasures, see Table 10. It can be concluded that the ECHIDS is capable of
detecting and defending against a broad range of security attacks in the different network layers which enhances the VANET
invulnerability against the security threats using a pre-managed and transparent fashion.
Compared to the other IDS implementations, it can be seen that the current system enjoys a rich security features with a realistic
resources utilization. In our opinion, the most important factor which governs the successful implementation of an “energy
harvesting-battery based” embedded system is the intelligent power management algorithm and its ability to adapt against the
different VANET operational and security situations.
 TABLE 10 EVALUATION METRICS & SECURITY ASSESSMENT OF THE SUGGESTED ECHIDS
ECHIDS Total Code Size 500 Kbyte

Utilization of Required Memory for Packets Processing Tasks 650 Kbyte

57%
System Resources ECHIDS Total Memory Utilization%
(1.15 out of 2 Mbyte)
Extra - Average CPU% Due to Different ECHIDS Functionality 25%
Extra - Average power Consumption Due to Different ECHIDS Functionality 17%
Maximal Throughput with Zero Loss
9 Mbps
“The observed level of traffic that results in a sustained average of zero lost data streams”
System Average Induced Traffic Latency (s)
0.55 ms
Performance “It measures the delay in the arrival of packets at the target network in the presence of EHCIDS”
Maximum Packet Processing Rate (Packet/s) 1800
False Positive Ratio
“This is the ratio of alarms that are wrongly raised by the wireless IDS to the total number of 2%
transactions”
False Negative Ratio
“This is the ratio of actual attacks that are not detected by the wireless IDS to the total number of 1.2%
transactions”
(+3500 SNORT Attack
Depth of System’s Detection Capability Signatures + Ad hoc
“It is defined as the number of attack signature patterns and/or behavior models known to it” networks behavioral
attacks)
Firewall Interaction Supported &
“The ability of a wireless IDS to interact with the Firewall systems” Integrated
ECHIDS Security Router Interaction Supported &
Features “ The degree of interaction of a wireless IDS with the router” Integrated
Simple Network Management Protocol (SNMP) Interaction
Supported &
“The ability of the wireless IDS to send an SNMP trap to one or more network devices in response to
Integrated
a detected attack”
Supported &
Hybrid Intrusion Detection System
Integrated
Multi-sensor Support (i.e., Cooperative IDS) Supported &
“The ability of an IDS to integrate the management and input of multiple sensors or analyzers” Integrated
Distributed Management
“ The capability of managing and monitoring the IDS securely from multiple possibly remote Supported
systems”
Ease of Configuration Supported

SECURITY ASSESSMENT OF ECHIDS

Attack Type
Known Attack Patterns
(more than 3500 as defined by
SNORT IDS developers)
Denial of Service Attacks
Distributed Denial of Service
Attacks
AD Hoc Routing Attacks (e.g.,
Black hole and Worm hole
attacks, etc..)
Sybil attack
Timing Attack
Energy Exhaustive attack
Application Attack
Administrative Impersonation
Attack
Monitoring Attack
Illegal Access Attack
Server Availability Attack
RSU Impersonation Attack
Data Sniffing and modification
Attacks’ Target Defense Strategy
 RSUs’ hardware, software, services and energy resources Embedded SNORT (Signature) Based IDS
 Functionality of network, transport and application layers
 Network Infrastructure
 RSUs’ hardware, software, services, communication and energy resources  Embedded SNORT (Signature) Based
 VANET Infrastructure IDS
 Anomaly Based IDS
 RSUs’ hardware, software, services, communication and energy resources  Embedded SNORT (Signature) Based
 VANET Infrastructure IDS
 Anomaly Based IDS
AD Hoc Routing Protocols Behavioral Based IDS
RSU services  Behavioral Based IDS
 Entity Authentication
RSU services  Embedded SNORT (Signature) Based
IDS
 Behavioral Based IDS
RSU energy resources  Behavioral Based IDS
 Anomaly Based IDS
RSU services  Embedded SNORT (Signature) Based
IDS
 Behavioral Based IDS
RSU data & services Entity and Message Authentication
VANET Functionality
RSU data & services Packet Encryption
RSU data & services Entity Authentication
VANET services  VANET Clustering
VANET Functionality  Servers Duplication
RSU data & services Malicious RSUs Detection
VANET Functionality Behavioral Based IDS
RSU data & services Message Authentication and Integrity
VANET Functionality
 VIII.CONCLUSION

In this paper, different intrusion detection methods were suggested to protect solar energy harvested Road Side Units (RSUs)
against various types of internal and external threats. The proposed defense strategies took into account the embedded nature of
an RSU and hence the recommended solutions make a compromise between a highly secured and a good performed system. To
the best of our knowledge, the combination of such security methods, algorithms and techniques with a solar energy powered
system, was not discussed before in any previous works. Although these methods were implemented to serve the VANET
security, it can be slightly modified to be used with other systems such as Mobile Ad hoc Networks (MANETs) and Wireless
Sensor Networks (WSNs). Our future research work will follow different directions in order to fill the gap in this field. We will
make use of our experimental network to study the effect of the other attacks and the defense strategies against them on the
VANET performance in all aspects, especially the power consumption of its nodes. The second step is to propose a secure and
green Ad hoc routing protocol so that the power management and the security techniques will be taken into consideration in the
earlier design stages.
 REFERENCES
[1] T. Wu, W. Liao and C. Chang, , "A Cost-Effective Strategy for Road-Side Unit Placement in Vehicular Networks", IEEE Transactions On Communications,
Vol. 60, No. 8, August 2012.
[2] J. Barrachina, P. Garrido, M. Fogue, F. J. Martinez, J. Cano, P. Manzoni, "Road Side Unit Deployment: A Density-Based Approach, IEEE Intelligent
transportation systems magazine, 2013.
[3] Q. I. Ali, " Design, Implementation & Optimization of an Energy Harvesting System for VANETS' Road Side Units(RSU)", IET Intelligent Transportation
Systems, Vol.8, Issue3, 2014.
[4] Q. I. Ali, ”Security Issues of Solar Energy Harvesting Road Side Unit (RSU)”, IJEEE Journal, Vol.11 No.1, 2015.
[5] I. Filippini, F. Malandrino, M. Cesana, C. Casetti, I. Marsh, "Non-cooperative RSU Deployment in Vehicular Networks", WONS Conf., 2012.
[6] S.Buchgger and J. Le Boudec, “ Performance analysis of the CONFIDANT protocol” in proc IEEE/ACM Workshop on Mobil Ad Hoc Networking and
computing (MobiHoc’02), Lausannne, Switzeland, June 2002. PP.226-336.
[7] Y. Zhang and W. Lee, “Intrusion Detection in Wireless Ad Hoc Networks,” 6th Int’l. Conf. Mobile Comp. and Net. Aug. 2000, pp. 275–283.
[8] P. Michiardi and R. Molva, “ Core A Collaborative Reputation Mechanism To Enforce Node Cooperation In MANET,” Communication and multimedia
Security Conference (CMCS’02) Sepember 2002.
[9] N. Nasser and Y. Chen, Enhanced Intrusion Detection System for Discovering Malicious Nodes in Mobile Ad hoc Networks, ICC 2007Conference, 2007.
[10] Y. Huang, and W. Lee, A Cooperative Intrusion Detection System for Ad Hoc Networks. 1st ACM Workshop Security of Ad Hoc and Sensor Networks,
Fairfax, VA, ACM Press, 2003.
[11] O. Kachirski and R. Guha, Effective Intrusion Detection Using Multiple Sensors in Wireless Ad Hoc Networks. 36th Annual Hawaii International Conference
on System Sciences, IEEE Computer Society, 2003.
[12] C. Krügel and T. Toth , Flexible, Mobile Agent based Intrusion Detection for Dynamic Networks. European Wireless, 2002
[13] K. Xiao, et al. ,A Novel Peer-to-Peer Intrusion Detection System Using Mobile Agents in MANETs, 6th International Conference on Parallel and Distributed
Computing, Applications and Technologies, 2005.
[14] J. Gómez, C. Gil, N. Padilla, R. Baños, and C. Jiménez, Design of a Snort-Based Hybrid Intrusion Detection System, IWANN 2009, 2009.
[15] M. Ali Aydın , A. Halim Zaim, K. Gokhan Ceylan, A hybrid intrusion detection system design for computer network security, Computers and Electrical
Engineering Journal, Vol. 35, 2009.
[16] S. Marti, T.J. Giuli, K. Lai et M. Baker, “Mitigating routing misbehavior in mobile ad hoc networks”, In Proceedings of the Sixth Annual ACM/IEEE
International Conference on Mobile Computing and Networking, p. 255-265, 2000.
[17] H. Kaur , S. Batish and A.Kakaria, An approach to detect the wormhole attack in vehicular ad hoc network in: International journal of smart sensors and ad
hoc networks,4,2012.
[18] A. Sinha, S.K. Mishra, Preventing VANET From DOS & DDOS Attack, International Journal of Engineering Trends and Technology (IJETT) – Volume 4
Issue 10- Oct 2013.
[19] M. Erritali, B. El Ouahidi, A Survey on VANET Intrusion Detection Systems, Proceedings of the 2013 International Conference on Systems, Control, Signal
Processing and Informatics, 2013.
[20] S. Sharma , M. Sisodia. ”Network Intrusion Detection By using Supervised and Unsupervised Machine Learning Techniques: A Survey". International Journal
of Computer Technology and Electronics Engineering. 2011.
[21] N. meyer, J. Njeukam, J. Petit, and K. M. Bayarou, “Central misbehavior evaluation for VANETs based on mobility data plausibility,” in Proceedings of the
ninth ACM international workshop on Vehicular inter-networking, systems, and applications - VANET ’12, New York, USA: ACM Press 2012.
[22] J. Grover, V. Laxmi, and M. Gaur, “Misbehavior detection based on ensemble learning in vanet,” in Advanced Computing, Networking and Security, ser.
Lecture Notes in Computer Science, Eds. Springer Berlin / Heidelberg, vol. 7135, 2012.
[23] S.Chang, Y.Qi, H.Zhu, J.Zhao, and X.Shen, “Footprint: Detecting Sybil Attacks in Urban Vehicular Networks”, IEEE Trans. Parallel and Distributed Systems,
vol.23, June. 2012.
[24] M.S. Bouassida, G. Guette, M. Shawky, and B. Ducourthial, “Sybil Nodes Detection Based on Received Signal Strength Variations within Vanet,”, Int’l J.
Network Security, vol. 9, no. 1, 2009.
[25] J. Roman, “Trust and Reputation Systems for Wireless Sensor Networks”, Troubador Publishing, 2009.
[26] C. Liao, J. Chang, I. Lee, K. Venkatasubramanian, “A trust model for vehicular network-based incident reports”, 2013 IEEE 5th International Symposium on
Wireless Vehicular Communications (WiVeC), Dresden, 2013.
[27] J. Zhang, “ A Survey On Trust Management For Vanets”, 2011 IEEE International Conference on Advanced Information Networking and Applications
(AINA), Biopolis, 2013.
[28] M. Gerlach, “Trust for Vehicular Applications”, Eighth International Symposium on Autonomous Decentralized Systems (ISADS '07), Sedona, 2007.
[29] Q. I. Ali, S. Lazim, E. Fathi, “Securing Wireless Sensor Network (WSN) Using Embedded Intrusion Detection Systems”, IJEEE Journal, Vol.8 No.1, 2012.
[30] Q. I. Ali, S. Lazim "Design & Implementation of an embedded Intrusion Detection System for Wireless Applications", IET Information Security Journal,
Vol.6, Issue 3,2012.
[31] R. Yasdi, Prediction of Road Traffic using a Neural Network Approach, Neural Comput & Applic (1999)8:135–142.
[32] S. Marti, T. J. Giuli, K. Lai, and M. Baker, “Mitigating routing misbehavior in mobile ad hoc networks,” in Proceedings of the 6th annual international
conference on Mobile Computing and Networking (MobiCom ’00), 2000, pp. 255–265.
[33] Z. Wang, L. Liu, M. Zhou, N. Ansari, “A Position-Based Clustering Technique for Ad Hoc Intervehicle Communication”, IEEE Transactions On Systems, Man,
And Cybernetics—Part C: Applications And Reviews, Vol. 38, No. 2, March 2008.
[34] L. Zhang, H. Elsayed and E. Barka, “A Novel Location Service Protocol in Multi-Hop Clustering Vehicular Ad Hoc Networks”, In: proc. of International
Conference on Innovations in Information Technology (IIT), 386-391, 2011.
[35] M. Raya and Jean-Pierre Hubaux, Securing vehicular ad hoc networks, Journal of Computer Security 15 (2007) 39–68 39.
[36] G. Samara, W.A.H. Al-Salihy, and R. Sures. Security Issues and Challenges of Vehicular Ad Hoc Networks (VANET). in 4th International Conference on
New Trends in Information Science and Service Science (NISS), 2010 .
[37] L. Blum, M. Blum, and M. Shub, A simple unpredictable pseudorandom number generator, SIAM J. Comput., 15(2):364–383, 1986.
[38] Q. I. Ali, F. Faher, "Evaluation of Routing Protocols of Wireless Ad Hoc for SCADA Systems Using OPNET Simulator", 2 nd Scientific & Engineering
Conference, 2013.
[39] R. Singh, J. Singh, “A Performance Metrics Scorecard Based Approach to Intrusion Detection System Evaluation for Wireless Network”, Global Journal of
Computer Science and Technology Network, Web & Security, Volume 12 Issue 12, 2012.
[40] G. A. Fink, B. L. Chappell, T. G. Turner, and K. F. O’Donoghue, “A Metrics-Based Approach to Intrusion Detection System Evaluation for Distributed Real-
Time Systems”, WPDRTS conference, 2002.