MANET Attack Impact Prediction Models
The process for creating models to predict traffic hijacking consists of three steps: collecting a dataset, designing a network description scheme, and building the prediction models (or classifiers). These steps are used in the experimentation workflow depicted in Figure 1.
Collecting a Dataset
The common open research emulator (CORE) (Ahrenholz, Danilov, Henderson, & Kim, 2008) allows analysts to design and run network scenarios using a graphical interface. Topologies are generated by dragging and dropping icons into a workspace. Scenario variables such as node positions, protocols used, and custom processing (for logging data during execution) scripts are stored in a configuration file. A dataset was generated by running combinations of several variables. The pseudo code along with the variables used for this process is shown in Figure 2.
Attack node number. This indicates which of the 10 nodes in the scenario will issue an attack.
Topology. In attempts to achieve a suitable data distribution, rather than using randomly generated topologies, which are sometimes either too sparse or compressed, 10 nodes were used to populate 7 different static topologies. The topologies were generated by first manually positioning nodes to fulfill the desired connectivity. Next, the position values were hardcoded into the execution script (Figure 2). The topologies are labeled chain, connected grid, cycle, star, tree, two-centroid, and wheel. These can be seen at the top of Figure 1.
Eventually, this work will investigate whether survivability predictions extend to mobile scenarios. At first glance, it seems likely; when nodes move, the topologies change. It may be the case that survivability predictions can be made for each topology formed during the movement.
Routing protocol. This is the underlying network layer protocol that will be used to communicate data necessary for route maintenance. The dataset contains OLSR and OSPFv3MDR protocols. Both of these protocols are proactive meaning that they continually publish route information, as opposed to reactive protocols, which publish route information when requested. The OLSR implementation is provided by NRL and uses IPv4 addressing. OSPFv3MDR is part of the Quagga suite of protocols. OSPFv3MDR is a modification of OSPF that is optimized for mobile ad-hoc networks. OSPFv3MDR uses IPv6 addressing.
Attack. The types of attacks are spoofing and forwarding, as described in the previous section. For the automated process, the attack scripts take additional inputs, start time and duration.
The following parameters that were controlled across all emulation executions are described below.
Attack time. This parameter indicates how long a node must wait before executing the attack. This was a set to 60 seconds.
Scenario duration. Each scenario was separated into three phases—before, during, and after an attack was issued.
Data flow. During each scenario, nodes communicate using TCP and UDP data packets. Packets are 1280 bytes in size and are sent 50 times per second. The traffic was generated using mgen (Multi-Generator (MGEN), 2016). Each node opens six sockets, three outgoing and three incoming. Table 1 contains the data flows that were used during each instance.
Table 1. Traffic Data flows between nodes.
| Node | TCP Outgoing | UDP Outgoing |
|---|---|---|
| 1 | 10 | 2,3 |
| 2 | 1 | 3,4 |
| 3 | 2 | 4,5 |
| 4 | 3 | 5,6 |
| 5 | 4 | 6,7 |
| 6 | 5 | 7,8 |
| 7 | 6 | 8,9 |
| 8 | 7 | 9,10 |
| 9 | 8 | 10,1 |
| 10 | 9 | 1,2 |