Ensuring cybersecurity for industrial networks: A solution for ARP-based MITM attacks

2.1. Distinctive challenges in industrial networks

Industrial networks diverge significantly from the classical Internet across several dimensions, profoundly influencing the prerequisites for the protocols in use. The array of connected devices can be numerous, necessitating robust scalability and minimal overhead in the adopted solutions. Additionally, a considerable portion of these devices may possess scarce resources, encompassing processing power, memory, and communication capabilities, which, once again, accentuates the preference for lightweight solutions. The devices themselves are highly specialized in executing specific tasks, making them inherently resistant to customizations beyond these tasks. Furthermore, the spectrum of devices extends beyond transmission technologies, as explored in Section 1, to encompass heterogeneous components, ranging from cloud-based servers to SCADA systems overseen by employees, as well as Remote Terminal Units (RTUs) and/or PLCs, responsible for managing actuators and monitoring sensors. Given this heterogeneity, solutions must be broadly applicable across all network technologies and system components, while also adhering to established standards. The intricacy inherent in ICS platforms mandates the adoption of autonomic solutions [51], equipped with the ability to self-heal in response to misbehavior, devoid of human intervention. Furthermore, when misbehavior is induced by security threats, the countermeasures must activate within a remarkably short time frame to safeguard the ICS platform. This challenge is exacerbated by devices that may lack the necessary resources or proficiency in swiftly executing complex tasks, including data encryption and machine learning.

2.2. Scheme in network communication

The Internet is a complex network comprising numerous LANs, each governed by its own set of protocols. These protocols, responsible for regulating the behavior of devices within a LAN, are situated within the Data Link Layer of the OSI model. In contrast, inter-network protocols like TCP/UDP and IP operate at the Network and Transport layers, as outlined in [5].

In this intricate ecosystem, two distinct addressing schemes come into play. Within the confines of a LAN, devices are uniquely identified by their 48-bit MAC (hardware) address. This MAC address, a permanent and manufacturer-assigned identifier, is embedded in the network interface card of each device. On the other hand, for communication across different LANs, a 32-bit IPv4 (network) address is employed. The allocation of IPv4 addresses can take one of two forms: either a network administrator manually assigns a static IP address, or a dynamic IP address is automatically assigned by a DHCP server, contingent on the specific network to which the device connects. Furthermore, devices also have the option to autonomously select a dynamic IPv4 address from the 169.254.0.0/16 range, as described in [15].

This intricate addressing system means that every device h connected to the Internet is uniquely identified by a paired set, denoted as ⟨ MAC h , IP h ⟩ , where both the IP and MAC addresses of two devices are distinct from each other.

2.3. Address resolution protocol

The Address Resolution Protocol (ARP) is a data link layer protocol running on all devices of a LAN as well as on its routing elements. ARP main task is to learn the host’s MAC address associated to a certain IPv4 address. In order to perform such a task, every running instance of ARP maintains in the device’s memory a table containing the known mappings ⟨ MAC address, IPv4 address ⟩ ; such a data structure is known as ARP cache.

Roughly speaking, ARP cache entries are either built through a static or a dynamic method. Static entries are manually added to the cache and never automatically removed, while dynamic entries are constructed as follows: consider two devices h and k on the same LAN. h needs to send a packet to k, but it only knows k’s IP address. To reach k in the local network, h must know k’s MAC address. First, h searches its own ARP cache for an entry ⟨ MAC k , IP k ⟩ . If the entry is not found or has expired, h sends an ARP request message to all devices in the LAN asking for the MAC address of IP k . When k receives the message, it sends an ARP reply to h with its own MAC address. Once h receives the reply, it updates its cache with ⟨ MAC k , IP k ⟩ , and similarly, k updates its cache with ⟨ MAC h , IP h ⟩ . Dynamic entries in the ARP cache are frequently refreshed, with a lifetime that ranges from 30 seconds to 65535 seconds, after which the entry is automatically removed.

ARP also provides the option for a device to announce its IPv4 and MAC addresses upon boot or changes. This is useful, for example, when a device joins a LAN. Such an announcement, known as a gratuitous ARP message, is usually broadcast as an ARP request or an ARP reply. A gratuitous ARP sent as an ARP request is not intended to solicit a reply, but rather updates any cached entries for the sending device in the ARP tables of the packet receivers. This update is performed because of the implicit ARP assumption that all devices in a LAN are trustworthy.

2.4. ARP poisoning MITM attacks

The ARP protocol can be easily subverted by performing Man-in-the-Middle (MITM) attacks (see e.g. [10]), using a technique known as ARP poisoning or ARP spoofing, described in the following.

Let us consider three devices in a LAN x, w, z and their corresponding MAC and IP addresses ⟨ MAC x , IP x ⟩ , ⟨ MAC w , IP w ⟩ , ⟨ MAC z , IP z ⟩ . If w convinces z that x’s MAC address is MAC w , all messages that z wants to send to x will be actually addressed to MAC w ; consequently, they will be received by w. In this way, the attacker w will hijack all the communications from z to x, acting as it sits in the middle of the communication, hence the name. More precisely, this is the case of a half-duplex MITM as the attacker is able to intercept only one traffic flow. We talk of full-duplex MITM when the attacker is able to monitor both traffic flows; this would imply that w is also able to convince x that z’s MAC address is MAC w . In the rest of the paper, we name victim the host that the attacker wants to impersonate and target the host whose ARP cache the attacker tries to poison.

The goal of MITM attacks is to take over a communication session between two devices in order to intercept and view the information being exchanged between them. ARP poisoning is not difficult to obtain by leveraging some of the features of the ARP protocol. Here there are some methods adopted to perform a MITM attack:

In all cases, the ARP caches of the devices receiving the forged packets – and either being the packet destination or already having a cache entry for IP x  – are poisoned with a wrong value, and the device h (attacker) will intercept all messages that those devices send to x. Note also that, since the non-static ARP cache entries are periodically refreshed, an attacker who is interested in maintaining a MITM attack for a long time has to continuously send forged ARP packets so as to maintain the target’s cache poisoned.

4.1. Overview

ArpON is a solution designed to work in parallel with the standard ARP protocol. It utilizes the same message formats and does not require cryptography, making it compatible with legacy ARP implementations. In a LAN environment, devices that use either the traditional ARP or the “ARP + ArpON” solution can coexist. The latter devices will have their ARP caches protected from man-in-the-middle ARP poisoning attacks.

The core idea behind ArpON is to supervise ARP cache management to detect and recover from ARP poisoning attacks. This is achieved by relying on its own cache, which is separate from the ARP cache. ArpON works in user space and cooperates with the ARP protocol in the kernel to manage Ethernet interfaces. An instance of the ArpON daemon exists for each Ethernet interface. The overall architecture is depicted in Fig. 1.

OPEN IN VIEWER

Fig. 1.

ArpON general architecture.

ArpON has the responsibility of overwriting the ARP cache based on its policies upon the reception of ARP messages. It tracks the outbound messages generated by the device in its cache, and classifies inbound messages that do not match previous outbound messages as “unsolicited.” This allows ArpON to detect ARP cache poisoning attacks such as ARP requests, unsolicited replies, or gratuitous messages.

At start-up, the ARP cache and ArpON cache are emptied, and the generation of ARP replies and creation of new ARP cache entries are disabled in the operating system (clean operation). To ensure the correctness of ArpON, all messages exchanged by it are broadcast in the LAN. If well-known static persistent addresses exist (HARPI mode, Flow Diagram in the Appendix), such as those of some servers, they are a-priori recorded in a config_file supplied to the devices by the network administrator, and used to perform an initial population of the ARP cache (update op). Furthermore, if a device x receives an ARP message from a device y claiming to own ⟨ MAC y , IP y ⟩ as its address, and IP y is a persistent address, then x performs the following actions:

By contrast, messages concerning either unknown static addresses or dynamic addresses are managed with the support of state information maintained in the ArpON cache (DARPI mode). Specifically, the information carried by potentially dangerous messages (see Section 2.4) is checked using the following verification procedure: The value of T D equals 1 s; a daemon is run every second in order to remove from the ArpON cache the expired entries. The aim of the verification is to ask all devices – and thus the real owner of IP y too – the correspondence for IP y before inserting it into the ARP cache. The removal from the ARP cache is performed so as to delete the – potentially poisoned – correspondence just inserted by ARP on message reception (see Fig. 1). The reply of the honest IP y owner is waited for the short T D interval.

The verification procedure is used as follows:

If a host x has to resolve the IPv4 address of the destination of a locally generated UDP message, similarly to the operations above, it records an entry for that IP in the ArpON cache.

These procedures aim at preventing ARP cache poisoning of devices. Consider a device k which receives an ARP message (request, gratuitous, or unsolicited reply) from h: in order to verify the information contained in the message, k broadcasts an ARP request for IP h . At the same time, ArpON removes the ⟨ MAC h , IP h ⟩ entry from k’s ARP cache and adds the ⟨ IP h , T D ⟩ entry in k’s ArpON cache. In response to k’s message, h sends an ARP reply to k. When k receives the ARP reply from h, k removes the ⟨ IP h , T D ⟩ entry from its ArpON cache, and inserts in its ARP cache the ⟨ MAC h , IP h ⟩ information contained in h’s ARP reply.

Note, however, that the above protocol has a transient flaw which happens when a malicious device m anticipates h’s ARP reply, with a packet containing the ⟨ MAC m , IP h ⟩ pair. This race condition is unavoidable, as explained in Section 6 and formally proved in [11] whose findings are summarized in Section 4.2. In such a case, a match is found in ArpON cache and these data are inserted in k’s ARP cache thus poisoning it. Fortunately, the poisoning will last only until k receives the correct ARP reply by device h, which at this point is detected as an unsolicited reply. When this happens, ArpON removes the ⟨ MAC m , IP h ⟩ entry from the ARP cache and activates the verifying procedure. As we will show in Section 5, this procedure takes a very short time interval in which it is not possible to perpetrate any attack.

In our previous work, outlined in [11], we conducted a comprehensive analysis of both the ARP poisoning problem and the ArpON algorithm. In this subsection, we provide a concise summary of the key findings from [11]. Regarding the ARP poisoning problem, [11] furnishes a formal proof utilizing logical and algebraic formalisms, establishing the inherent challenge of preventing ARP cache poisoning within a network with one or more malicious attackers, especially in the absence of cryptography. In essence, the proof demonstrates that the only address resolution algorithm capable of thwarting ARP cache poisoning is a simplistic one, whereby, for each IP address, it maintains an undefined MAC address in the cache. While this algorithm ensures safety by never associating an incorrect MAC address, it renders network communication effectively impossible. The crux of this proof hinges on the absence of a reliable authenticator, which could verify the source of a message.

Regarding the ArpON algorithm, when implemented across hosts within a LAN, it can be formally represented as an infinite-state reactive parameterized system. In [11], we employed model checking, utilizing the MCMT tool [24], to model both the actions performed by a process employing the algorithm and potential malicious behaviors exhibited by attackers. The safety property, verified by MCMT for any number of hosts within the LAN, guarantees that in the event of cache poisoning (as indicated by the aforementioned impossibility result), ArpON consistently and successfully eradicates it. This property aligns with the concept of ‘self-healing’ seen in industrial networks, as discussed in Section 2. Furthermore, the performance evaluation discussed in Section 5 reveals that the elimination of poisonings occurs in less than a millisecond, ensuring the requisite “promptness”, another crucial requirement in the context of industrial networks, as elaborated in Section 2.

4.3. Implementation aspects

The ARP protocol, as defined in the network kernel subsystem, consists of two main components: (1) ARP cache management and (2) I/O ARP functions (Fig. 1). The first component updates the ARP cache based on ARP network traffic observations, while the second component manages ARP packet transmission operations for each network interface present in the host machine.

For ArpON to function properly, it needs to handle the ARP requests/replies associated with a specific network interface and apply its own policies rules. To achieve this, ArpON modifies the arp_ignore and arp_accept parameters in the proc filesystem. These parameters enable ArpON to exclusively operate on ARP packets for a specific network interface and are configured by the sysadmin to dictate ARP behavior in response to ARP requests and ARP gratuitous announces.

By setting arp_ignore, ArpON is capable of intercepting any ARP request and preventing the kernel from answering these packets. In this manner, ArpON can apply its own detection rules without any kernel interference and respond to ARP packets as dictated by its policies. All other ARP operations and protocol features are handled by the network kernel subsystem, in accordance with the ARP protocol standard.

For each network interface, the system spawns an ArpON instance (e.g., a user space application) that is responsible for sending and receiving ARP packets. Specifically, ArpON exclusively handles the sending of ARP reply packets when a request ARP packet has been received. The ARP cache is handled by both ArpON and the network kernel subsystem, based on the detection rules previously described.

It is important to note that ArpON only modifies some network function calls related to interception and leaves all other operations to the kernel subsystem. This design allows for easy deployment of ArpON on a vast majority of operating systems and permits coexistence with other detection systems without requiring complex authentication among network devices.

5.1. Network and protocols configuration

The network under consideration consists of N identical hosts connected in a network. Looking at the documentation of industrial network equipment producers [19,20,66,67], three topologies are usually adopted: star, ring, or linear. The star topology (that may also represent wireless networks with thin devices communicating via an access point) has the central point usually settled in the PLC; it supplies greater reliability, resilience, real time timeliness and lower probability of bottlenecks than the other two schemes. The linear topology, for cabled networks, is less expensive than the star but less performant under the other aspects. The ring topology is intermediate between the other two.

In most of the presented simulations, a star topology was considered with a central switch; but we also considered a linear topology in some experiments. Each host implements a protocol stack consisting of UDP, IP, ARP, and Fast Ethernet (100 Mbps) at the MAC layer. Each host runs two applications as it may act as both a source and destination for UDP messages.

The simulations run for 3600 seconds of simulated time with varying number of hosts N, ranging from 10 to 150. As a source, a host generates a new message with an exponential distribution with a parameter of 15 s, and selects a random destination according to a uniform distribution. If an ARP cache entry for the message destination does not exist, then either ARP or ArpON is run to find out the correspondence. During the initialization phase, each node uploads the correct correspondence between IP and MAC addresses of all nodes from a file. This information is used throughout the simulation for measurement purposes only, so as to detect the start and end of poisonings (if a correct information overwrites a poisoned one). In this phase, one of the nodes is randomly selected to act as the attacker for the entire simulation. All updates to the ARP caches are performed either according to ARP (modeled as per RFC 826 [45]) or ArpON. Each ARP cache entry has a lifetime of 120 seconds before it expires.

Table 1 summarises the configuration parameters used in the simulations.

As explained in Section 2.4, there are two ways to perform ARP cache poisoning:

poisoning a single cache, by crafting either an ARP request or reply containing a mistaken correspondence ⟨ MAC y , IP x ⟩ apparently generated by a host with network address IP x ;

Both ways were modeled in the simulated networks, for both ARP and ArpON. In each simulation, just one strategy of attack is considered in order not to mix up their effects and ease the interpretation of the results. In case (a), a full MITM attack is perpetrated via unsolicited replies: the two selected hosts are simultaneously victims and targets, and the attacker generates an unsolicited reply to both of them; renewals are as well sent to both nodes at the same time. In case (b), a half MITM attack is perpetrated via gratuitous announces.

When an attack is started, the attacker randomly extracts – with uniform distribution – and records the identity of both a target node and a victim, and repeats the attack every 110 s so as to avoid the removal of the poisoned information from the ARP cache of the target(s); this is repeated three times, thus achieving an attempted attack duration of around 6–7 minutes. When an attack finishes, the attacker schedules the time to start the next attack according to an exponential distribution with variable parameter τ. For both kinds of attacks, the aggressiveness of the attacker was determined by changing the value of τ in between 60 s and 900 s. The value τ = ∞ represents the case of no attacks, used as a benchmark.

It is worth to notice that the identity of node y is not relevant, be it either the attacker itself or a further node different from both victims and targets. In the simulation, y is the attacker itself. Though, there is no loss of generality with this setting, as ArpON is – unavoidably – blind to the identities of the involved nodes; it simply reacts to the insertion of a non-requested correspondence into the cache. In the experiments, we were just interested in observing whether and how long a poisoning occurs.

5.3. Performance indexes

The performance evaluation centers around the unique characteristics of industrial networks detailed in Section 2.1. Specifically, we scrutinize three critical aspects:

As far as robustness to poisonings is concerned, the following indexes are analysed in Section 5.4:

As far as autonomic and self-healing capabilities and healing promptness are concerned, the following index is analysed in Section 5.5: duration of cache poisonings.

As far as scalability and system overhead are concerned, the following indexes are analysed in Section 5.6:

As far as the promptness is concerned, the following index is analysed in Section 5.7: address resolution latency.

OPEN IN VIEWER

Fig. 2.

ARP: average number of cache poisoning suffered by a host (a) with variable number of hosts and τ = 300 , and (b) with variable τ and 75 hosts.

As far as ArpON is concerned, in the performed simulations with the star topology no cache poisoning has ever been observed. By contrast, ARP was heavily affected. Figure 2 shows the number of ARP cache poisonings suffered by a host running ARP,1

In Fig. 3(a), the percentage of targets poisoned by a gratuitous announce is shown in a sample case (125 hosts and τ = 300 s), as a function of the simulation time. In spite of being different attacks, the growth is stable and depends on the progressive population of the caches as time progresses.

OPEN IN VIEWER

Fig. 3.

(a) ARP: percentage of hosts poisoned via gratuitous announces, in case of 125 hosts in the LAN and τ = 300 s. (b) Occurrence of cache poisonings with ArpON and emulated linear topology.

In the case of attacks carried out with unsolicited replies, the lowest average for fixed τ and N = 150 hosts equals 0.24 attacks, while with fixed N it is included between 0.71 (with τ = 90 s) and 0.27 (with τ = 900 s). The average is very low because many nodes are never chosen as the target throughout the simulation, in particular with large networks where the target is extracted from a larger set. In this scheme, the attacker generates between 30 and 36 poisoned unsolicited replies in case of τ = 300 and variable N: since we model full MITM and three renewals for each attack, this means that 5–6 different pairs of target/victim hosts are subject of an attack throughout a simulation. Figure 2(a) also shows the maximum number of attacks suffered by nodes (dotted line) throughout the simulation, which is higher for smaller N as a node has a greater probability of being selected as target. In the case of variable τ, the attacker generates between 20 and 52 poisoned unsolicited replies (3 to 9 pairs attacked throughout a simulation).

In Section 4, the possibility of a transient flaw of ArpON has been explained. In order to be able to evaluate the impact of this event, an ad-hoc setting was reproduced, emulating a linear topology with connected in order target ⇆ attacker ⇆ victim, that is, the victim is further away than the attacker from the target. In the emulation, the 3 hosts are connected to the same switch; yet, both the target and the attacker are connected to the switch via FastEthernet (100 Mbps) links, while – in order to artificially magnify the distance between the victim and the target – the victim is connected to the switch via an Ethernet (10 Mbps) link. Hence, the victim receives ARP requests after the attacker, and its replies take more time to go back to the target, essentially reproducing the race condition described in Section 4.1. For the sake of clarity, in this case attacks are not renewed. With this scheme, also ArpON is affected by the occurrences of ARP cache poisonings, as shown by Fig. 3(b) along the simulation time.

OPEN IN VIEWER

Fig. 4.

(a) Zoom of a single poisoning event with ArpON in the emulated linear topology. (b) Cumulative distribution of the duration of ARP cache poisoning in case of unsolicited replies, with variable τ and 75 hosts.

As anticipated in Section 4.2 and formally proved in [11], ArpON is able to remove cache poisonings and self-heal. In Fig. 4(a), a zoom of a particular attack affecting ArpON hosts in the emulated linear topology shows that the observed cache poisonings last 0.10548 ms, which account for the difference in transmission times of a packet of around 50 bytes along links with the considered heterogeneous bit rates. Since ARP cache poisoning is removed in less than milliseconds, the capability of an attacker of stealing sensitive information in the meantime is limited to a very large extent.

By contrast, standard ARP is not able to remove poisonings, thus paving the way to attacks that can last a long time and therefore potentially cause severe damage to the infrastructure. In case of full MITM attacks perpetrated using unsolicited replies, Fig. 4(b) shows the cumulative distribution of the duration of the poisonings that affected ARP caches, in case of 75 hosts in the LAN and variable τ. The graph shows that 60–80% of the poisonings are resolved before the expiration of the cache entry, due to the reception of an ARP message from the victim of the poisoning, which generates a UDP message and broadcasts a request trying to resolve the IP address of the message destination. In average, these poisonings last 38.99 s (five orders of magnitude more than with ArpON); all the UDP traffic addressed to the victim and generated by the target in the meanwhile is actually intercepted by the attacker. Moreover, 20–40% of the attacks last more than or equal to 120 s; they correspond to either attacks successfully renewed by the attacker, or to entries removed only when the target generates a UDP message for the victim after the cache entry expiration, invalidates the entry, and generates a new request to refresh the entry. The average duration of those poisonings equals 224.1 s.

Figure 5(a) reports a similar behaviour in case of unsolicited replies, τ = 300 s and variable number of hosts. Short poisonings last in average 41.5 s, while long poisonings have an average duration of 215.4 s.

A similar behavior is observed with attacks perpetrated via gratuitous announces (Fig. 5(b)). In this case, all measures are averaged over a greater number of affected nodes, which as a consequence (i) lowers the result for short poisonings removed by several nodes at a time when the victim of the attack generates a UDP message, and its request to resolve the message destination IP address arrives to the (multiple) poisoned hosts; while (ii) increases the result in case of poisonings not removed by multiple nodes. In fact, the difference between the two values is magnified with respect to the previous cases: short poisonings last 36.9 s in average, while long poisonings last 232.2 s.

OPEN IN VIEWER

Fig. 5.

(a) Cumulative distribution of the duration of ARP cache poisoning in case of full MITM attack via unsolicited replies with τ = 300 s and variable number of hosts. (b) Cumulative distribution of the duration of ARP cache poisoning in case of gratuitous announces, with variable τ and 75 hosts.

Communication overhead. Since the choice of both UDP message sources and destinations is uniform, the need of resolving IP addresses is evenly distributed across nodes, and for each host the number of sent ARP requests and replies is always almost equal.

In case of full MITM perpetrated through unsolicited replies, load balancing is also observed among the nodes with both protocols. Table 2 shows – for both protocols and for both attacked and non-attacked hosts – the average number of replies sent by a node throughout the simulation, the standard deviation σ, the max and min values, the range (difference between max and min), and the interquartile range (IQR). These indexes prove the scarce variability among hosts. In all cases, 6 pairs of nodes were involved in the attacks. Yet, ArpON generates more traffic since every potentially dangerous message – be it actually poisoned or not – raises a verification. The indexes do not differ too much when considering the number of sent requests, nor – for what we just said – when changing τ.

OPEN IN VIEWER

Fig. 6.

Average number of both sent replies and requests for both ARP and ArpON, with variable number of nodes and full MITM attack via unsolicited replies and τ = 300 s.

OPEN IN VIEWER

Fig. 7.

Number of both sent requests and replies for ArpON, in case of attacks perpetrated using gratuitous announces, (a) with variable number of hosts and τ = 300 s; (b) with variable τ and 75 hosts in the LAN.

By contrast, the performance is affected by the variable number of hosts, as each host can generate UDP messages that may raise an address resolution. In Fig. 6, the number of both sent requests and sent replies is shown for both protocols, in case of full MITM attacks via unsolicited replies and τ = 300 s. Yet, the traffic due to the verification requests sent by ArpON does not grow exponentially; on the contrary the ratio between ArpON and ARP is roughly constant between 4 and 6 as shown by the secondary curves in the plot. Moreover, the traffic load is easily disposed; indeed, the maximum observed length of ArpON queues of outpending messages in the hosts is 2: one for a possible UDP message sent by the node (for which the destination address is under resolution) and one for a contemporary ARP message carrying a correspondence to be verified.

Things change when malicious gratuitous announces are sent. While the behavior of ARP obviously stays comparable, the fact that gratuitous announces simultaneously try to poison the ARP cache of several hosts, and all of them broadcast verification requests to avoid this event, make ArpON performance depend on both the number of hosts (Fig. 7(a)) and the arrival of messages, which is more frequent for more frequent attacks (lower τ, Fig. 7(b)). The generated traffic for the highest frequency of attack is 10.6% greater than without any attack. Moreover, the generation of ARP messages is unfairly distributed on nodes, differently from the previous case, as shown in Table 3: the hosts chosen as victims (6 in our simulations) generate 50 % ARP messages more than non-attacked hosts due to the verification requests generated by other hosts (up to N) and to which they have to reply.

Memory and computation overhead in the switch / PLC. As a consequence of the higher traffic generated by ArpON, the central switch of the star topology – which often is also the PLC of the industrial network – might become a bottleneck. Moreover, as every message in ArpON is broadcast, the switch replicates it to all its interfaces. In Fig. 8, the length of the queue associated to a switch interface is shown along simulation time, in case of attacks via gratuitous announces with N = 50 hosts and τ = 300 s. In the graph, spikes reach the number of hosts in the network; they are grouped in sets of three due to the renewal of an attack against a certain victim for three times (Section 5.2).

OPEN IN VIEWER

Fig. 8.

Length of the queue associated to a switch interface, along time.

Actually, in the considered schemes the switch never experiences overload. In Fig. 9(a), the amount of traffic either received or sent by the switch, averaged on all its interfaces, is shown in case of attacks perpetrated via gratuitous announces, τ = 300 s, and variable number of hosts. The outbound traffic in the switch interfaces is always less than 20 Kbps also with the largest network and in spite of the re-broadcasting of ArpON messages; it is thus perfectly supported also with a conservative estimate of available bandwidth limited to 100 Mbps. With ARP, the slight increase in outbound messages for larger networks is an effect of the cold start phase when the switch has yet to populate its routing table and initially broadcasts every data till it learns what destination is attached to each interface. For both protocols, the inbound traffic is always very low. The difference between the two protocols accounts for the verification requests sent by ArpON.

OPEN IN VIEWER

Fig. 9.

(a) Amount of traffic in the switch for both ARP and ArpON; (b) End-to-end delay for both ARP and ArpON, with variable number of nodes, τ = 300 s and attacks perpetrated via gratuitous announces.

The queue length and the amount of traffic is almost constant with ARP when varying τ for fixed number of nodes, for both unsolicited replies and gratuitous announces: the average length of the switch queues is always slightly lower than 0.5 with ARP. With the analyzed values of τ, this also holds with ArpON when unsolicited replies are generated, indicating that queues are emptied before the next attack occurs. In case of gratuitous announces, the queues grow but not dramatically, as shown in Table 4 where all results are averaged over all the switch interfaces.

Despite the higher amount of traffic generated by ArpON compared to ARP, message latency is not affected and therefore neither is the timeliness of the industrial network communications. Figure 9(b) shows the end-to-end latency, measured as time elapsed from the generation of a UDP message requiring an address resolution till its transmission when the resolution as been accomplished; results refer to a variable number of hosts in the LAN, τ = 300 s and attacks perpetrated via gratuitous announces. The latency of ArpON is of the order of 20 μs greater than that of ARP for the largest considered LAN.