Mitigating ARP poisoning-based man-in-the-middle attacks in wired or wireless LAN
- 6.8k Downloads
In this article, an enhanced version of address resolution protocol (ARP) is proposed to prevent ARP poisoning-based man-in-the-middle (MITM) attacks in wired or wireless LAN environments. The proposed mechanism is based on the idea that when a node knows the correct MAC address for a given IP address, if it does not delete the mapping while the machine is alive, then MITM attack is not possible for that IP address. In order to prevent MITM attack even for a new IP address, we propose a new IP/MAC mapping conflict resolution mechanism based on computational puzzle and voting. Our proposed scheme can efficiently mitigate ARP poisoning-based MITM attacks, even in Wi-Fi hot-spots where wireless machines can easily come and leave, since the proposed mechanism does not require manual configuration if the proposed ARP is deployed through operating system (OS) upgrade. The proposed scheme is backward compatible with the existing ARP protocol and incrementally deployable with benefits to the upgraded machines.
KeywordsMedium Access Control Wireless Local Area Network Malicious Node Medium Access Control Address Address Resolution Protocol
The address resolution protocol (ARP) is used to find the media access control (MAC) address of a node corresponding to a given IP address in the same subnet [1, 2]. The resolved addresses are temporarily kept in the ARP cache to reduce the resolution time and avoid additional ARP traffic overhead for recently resolved IP addresses .
The ARP poisoning attack refers to the behavior of registering a false (IP, MAC) address mapping in the ARP cache of another node for malicious purposes. As an example, when there are three different nodes A, B, and C in the same subnet, if Node A registers the (IPC, MACA) mapping in the ARP cache of Node B, then it is an ARP poisoning attack of Node A. If the above attack is successfully made, Node A can receive all the packets from B to C because B considers that MACA is the MAC address of Node C and sends all the traffic for C to MACA. Thus, ARP poisoning enables the attacker to eavesdrop the communication between other nodes, modify the content of the packets, and hijack the connection. This ARP poisoning can also be used to launch a denial-of-service (DoS) attack . For example, if an attacker replaces the MAC address of a particular host with another value in the ARP cache of a remote machine, then the victim will experience DoS since it cannot access the original host due to the wrong MAC address. Furthermore, ARP poisoning can be used to mount man-in-the-middle (MITM) attack . In the above example, if Node A registers the (IPB, MACA) mapping in the ARP cache of node C additionally, then Node A can see all the packets that are exchanged between Nodes B and C. If this attack occurs, the adversary may eavesdrop, insert, or modify the messages between the victims of the MITM attack, without being detected.
If an operating system accepts any ARP reply message even though it did not send any ARP request messages, then just one transmission of the ARP reply packet will be enough to register a false (IP, MAC) mapping in the node running that operating system. Even for operating systems that do not accept unsolicited ARP reply packets, it is possible to induce an ARP request message for a specific IP address by sending a spoofed ICMP echo request packet and to register a false (IP, MAC) mapping for that IP address .
The ARP spoofing issue was first investigated in the environment of wired local area network (LAN), i.e., Ethernet. However, it is becoming easier to access Internet via wireless LAN, i.e., 802.11 network, due to the widespread deployment of access points (APs) by many Internet service providers (ISPs). Thus, ARP spoofing can also be an important issue in the wireless LAN environment. According to , there can be many scenarios whereby a wireless attacker poisons the ARP caches of other wireless nodes, connected through the same AP or different APs, or it poisons the ARP caches of other wired nodes in the same subnet. Although there have been several attempts to resolve the ARP cache poisoning problem in the wired LAN environment, some of those approaches may not be effective in a different environment of wireless LAN.
Conventional approaches can be classified into two categories depending on whether the ethernet switch upgrade is required or not. dynamic ARP inspection (DAI)  requires the support from the ethernet switches. DAI usually requires manual configuration by network managers and cannot prevent ARP poisoning occurring between wireless nodes connected through the same AP. The methods that do not require support from Ethernet switches usually use cryptographic techniques [9, 10]. Since most of these methods use public key cryptography, there should be a central server to distribute the public key of each node reliably. However, this central server could be subject to a single point of failure problem.
Furthermore, the public key of the central server itself and the MAC address of the server need to be delivered to each node reliably. This step usually requires manual setting by the network manager, and it may not be appropriate for the environment of Wi-Fi hot-spots where wireless machines can easily come and leave.
Thus, we investigate a new mechanism to prevent ARP spoofing-based MITM attacks in wired or wireless LAN environments, while overcoming the limitations of existing approaches. The proposed scheme makes the upgraded normal nodes protect each other through collaboration based on voting and computational puzzles. Since the public key cryptography is not required, the manual setup or configuration is not required for the newly arriving wireless nodes and it is free from a single point of failure problem due to the absence of any central server. The remainder of the article is organized as follows. We first discuss related study in Section 2. Section 3 describes the proposed enhanced version of ARP. In Section 4, the performance of the proposed mechanism is verified through experiments in a testbed environment. Finally, conclusions are presented in Section 5.
2 Related study
As explained in Section 1, neglecting unsolicited ARP replies cannot prevent ARP cache poisoning, since ARP requests can be easily induced by source address-spoofed ICMP echo request messages. If the member nodes of a given subnet do not change frequently, then the ARP cache poisoning might be avoided by employing static ARP. However, this approach may be infeasible in an environment where the IP addresses are allocated to mobile nodes dynamically through Dynamic Host Configuration Protocol (DHCP). DAI corresponds to the approach that requires the support of ethernet switches . In the DAI, the ethernet switch checks the validity of the received ARP packet based on the trusted IP-to-MAC mapping database. However, this database is either manually managed or dynamically managed through DHCP snooping . In order to perform DHCP snooping, the port on which the network DHCP server is connected needs to be configured as a trusted interface, and other ports need to be configured as untrusted interfaces. However, this approach may not be effective, if the ARP cache poisoning occurs among the wireless nodes connected via the same AP. In this article, we attempt to devise a method to prevent ARP poisoning-based MITM attacks with minimal overhead of manual configuration by the network administrator or by the user, and with minimal infrastructure upgrade cost.
The approaches that do not require the upgrade of ethernet switches can be classified into two sub-categories based on the use of cryptography. Antidote  is a non-cryptographic approach. If a new ARP reply, which is insisting on a new MAC address for an existing IP address, arrives, the new (IP, MAC) mapping is accepted, only when the node corresponding to the previous MAC address is not alive. However, there is a problem in Antidote. When a normal machine sends an ARP request for an IP address which is not in the ARP cache currently, if a malicious ARP reply arrives first, then the victim caches the wrong reply and discards the later ones. Thus, MITM attack can be successful under this race condition. The proposed scheme shares the basic concept, preservation of (IP, MAC) mapping while the node corresponding to the original MAC address is alive, with the Antidote, but resolves the race condition in a different way using computational puzzle-based voting.
S-ARP  is a popular cryptography-based approach. Although S-ARP requests operate in the same way as normal ARP requests, S-ARP replies need to be signed by the sender's private key and the signature needs to be verified using the sender's public key at the receiver side. Since S-ARP is based on asymmetric cryptography, it requires a central server called authoritative key distributor (AKD) to manage the mapping between the IP address and the corresponding public key. If the AKD fails, the whole system may not work, i.e., S-ARP has a single point of failure problem. In addition, S-ARP usually requires the upgrade of the DHCP server and incremental deployment is not easy, since the S-ARP-enabled machine may not accept ARP replies from non-S-ARP nodes.
Goyal and Tripathy proposed a modified version of ARP  to lower the computational cost of S-ARP. This avoids the calculation of digital signature for each ARP reply by allowing the use of the same digital signature several times over multiple ARP replies during a pre-defined time period, while ensuring the recency of the mapping in the digital signature through one time passwords. Although the computational cost is relieved, it has the same limitation as S-ARP: a single point of failure problem due to AKD, and the cost of manual configuration to disseminate the public key and the MAC address of AKD to all newly arriving hosts.
Ticket-based ARP (TARP)  is another approach to reduce the computational cost of S-ARP by employing the concept of ticket, centrally generated IP/MAC address mapping attestation. However, TARP also requires manual dissemination of Local Ticket Agent (LTA)'s public key, and LTA might be subject to a single point of failure problem.
Philip  proposed an approach to prevent ARP cache poisoning in wireless LAN by implementing the defense mechanism in the AP. The basic idea is as follows. The AP constructs the list of correct IP-to-MAC address mapping by monitoring DHCP ACK messages or referring to the DHCP leases file, and blocks all the ARP packets with a false mapping based on the constructed list. However, this approach can be applied only to the dynamic IP addresses allocated through DHCP, and cannot prevent ARP cache poisoning occurring inside the wired LAN. We attempt to protect the upgraded nodes from ARP poisoning-based MITM attacks, whether those nodes are connected to LAN through wire or wireless medium.
Recently, Nam et al.  proposed an enhanced version of ARP, called MR-ARP, to prevent ARP poisoning-based MITM attacks in the ethernet by employing the concept of voting. If an ARP request or reply message arrives declaring a new MAC address for an IP address registered in the ARP cache, MR-ARP queries the node corresponding to the current MAC address to check if that IP address is still used by that node in a similar way to Antidote. If an MR-ARP node receives an ARP request or reply declaring an (IP, MAC) mapping for a new IP address, it requests that the neighbor nodes vote for the new IP address to make the correct decision for the corresponding MAC address. For this mechanism, the voting can be fair only when the voting traffic rates of the responding nodes are almost the same. This condition can be satisfied in the Ethernet, but may not be valid in the 802.11 network due to the traffic rate adaptation based on the signal-to-noise ratio (SNR), i.e., auto rate fallback (ARF) [14, 15]. Thus, we attempt to overcome the limitation of MR-ARP by improving the voting procedure through the incorporation of computational puzzles, while achieving the following goals: mitigation of ARP poisoning-based MITM attacks in wired or wireless LAN, backward compatibility with existing ARP, minimal infrastructure upgrade cost (e.g., no upgrade of LAN switches or modification of DHCP), incremental deployability, and no manual configuration for newly joining nodes.
3 Computational puzzle-based enhanced ARP
We improve the voting procedure of MR-ARP by incorporating computational puzzles [16, 17, 18] to mitigate ARP poisoning-based MITM attacks in wired or wireless LAN, while overcoming the limitation of MR-ARP . As explained at the end of Section 2, the transmission rates of wireless nodes may not be uniform, and thus, the fair voting may not be guaranteed by the voting mechanism of existing MR-ARP. The key idea of the new voting mechanism to resolve the fairness issue in the wireless LAN can described as follows. If the CPU processing power of different nodes is not significantly different, then they might spend a similar amount of time solving the puzzles of the same difficulty. Thus, if we accept the votes only from the nodes that solved the puzzle correctly, then fair voting might be realized in the wireless environment, too. Furthermore, voting reply traffic can be reduced compared to the original MR-ARP scheme since we no longer need to receive multiple votes from each neighbor node. In addition to the fairness issue, MR-ARP could be vulnerable to ARP cache-poisoning problem, although not the MITM problem, especially when a new machine with a new IP address is added. We also explain how this issue is resolved through the new initialization stage after the detailed description of the new voting mechanism. The proposed enhanced version of MR-ARP, which is called EMR-ARP, follows a similar approach to the original MR-ARP, except in the voting and initialization procedures. Thus, EMR-ARP is also based on the following idea . When Node A knows the correct IP/MAC address mapping for Node B, if Node A retains the mapping while Node B is alive, then ARP poisoning and the MITM attack between A and B are not possible.
EMR-ARP retains the long-term (IP, MAC) mapping table, in addition to the normal ARP cache, which is also referred to as the short-term table in this article, to manage the (IP, MAC) mapping for all alive machines in the subnet. Three fields, IP, MAC, and Timer T L , are allocated for each IP address registered in the long-term table. The default value of the timer in the long-term table is 60 minutes. In order to avoid losing the mapping of (IPa, MACa) for an alive host after 60 minutes, the EMR-ARP node sends new ARP request messages for IPa only to MACa through unicasting and checks whether MACa is alive and is still using IPa just before the timer expires. In this case, 10 ARP messages are sent at the random intervals of 50~100 ms. If at least one ARP reply returns, then the mapping is registered in the short-term ARP cache and the corresponding long-term table timer is set to 60 min again. If there is no ARP reply, then the mapping between IPa and MACa is considered invalid and the corresponding entry is deleted from the long-term table. Thus, the (IP, MAC) mapping can be retained in the long-term table until the binding is released.
In case (B) of Figure 1, MAC conflict occurs, because the newly received MAC address MACa for IPa differs from that is already associated with IPa. This conflict is resolved by giving a priority to only if it is alive. As shown in Figure 1, the activity of a host is examined by sending 10 ARP request packets and counting the ARP replies. Multiple ARP requests are sent to cope with unexpected packet losses, including the case of DoS attack on . Even though the packet loss probability is as high as 80% by DoS attack, at least one ARP reply will be returned with a probability of 89%(= 1 - 0.810). Let us consider the case where the mapping of (IPa, MACz) expires, and the IP address IPa is allocated to a new machine with the MAC address of MACa through DHCP. In this case, the new mapping between IPa and MACa can be chosen by the rule corresponding to the case (B) in Figure 1, even though the mapping (IPa, MACz) exists in the long-term table. When a first ARP request from MACa arrives, there would be conflict on IPa in the long-term table, and the node which observes the conflict will send ten ARP requests to MACz. However, the machine MACz would not reply and the new mapping can be registered, since the previous mapping has expired.
3.1 Computational puzzle-based voting scheme
Thus far, we investigated how to prevent MITM attacks for the IP addresses whose corresponding MAC addresses are known already. However, if Node A receives an ARP request from a new IP address, then Node A cannot easily know the correctness of the source IP/MAC mapping contained in the ARP request. For example, when a new machine is added into a LAN with empty short-term cache and long-term table and the machine sends an ARP request for the gateway router, if an adversary's ARP reply advertising a fake MAC address arrives first, then this wrong MAC address may be registered and the late true MAC address may be dropped. We use computational puzzle-based voting, which corresponds to the case (C) in Figure 1, to solve the poisoning problem for this particular case.
Preserving the fairness among different nodes is one of the most important issues in the voting scheme. In the previous version of the voting scheme used in MR-ARP , the fairness was provided by having all the neighbor MR-ARP nodes send multiple voting reply packets at the maximum speed of link rate in the Ethernet. This idea works, because the LAN cards usually have sufficient capability to send traffic at the link rate regardless of the vendor. However, the maximum transmission rates of different nodes may not be the same in the wireless LAN if the transmission rate changes by ARF depending on SNR. Thus, the voting scheme needs to be refined to provide the fairness under any combination of wireless and wired nodes. We attempt to provide the fairness by having the wired or wireless nodes spend a similar amount of time solving the computational puzzles  of the same difficulty and making the address resolution decision only based on the votes from the nodes that solved the puzzle correctly. Thus, the puzzle used in the proposed ARP scheme needs to satisfy the following requirements.
The puzzle must be easy to make.
The puzzle must be difficult to solve, but it should be easier to verify the puzzle solution.
Puzzle receiver nodes cannot predict the puzzle easily.
Different nodes should solve different problems to avoid the case whereby a malicious node pretends to be many other nodes by sending multiple replies with a spoofed MAC address after solving only one problem.
The complexity of the different puzzles should be similar to provide fairness between different nodes.
where H' is a uniform random hash function, r is a positive integer, y is an integer given by the puzzle presenter, and [z] r means the least significant r bits of z. Then, the number of iterations required to find a solution of the above puzzle can be modeled as a random variable X that has a geometric distribution with a success probability p, where p = 1/(2 r ). The mean (μ) and the standard deviation (σ) of X are 1/p and , respectively. Thus, σ can be large, even close to μ for small values of p. When this type of puzzle is used, if the attacker can luckily solve many puzzles, even for different MAC addresses, while most other normal machines solve only one puzzle, then the attacker might win the voting by increasing the ratio of votes supporting the fake MAC address and spoof the ARP cache of the voting request node. The variance in the puzzle solving time needs to be minimized to avoid such a problem.
In order to satisfy the above requirements, while minimizing the variance in the puzzle-solving time, we design the puzzle based on the public key cryptography, especially RSA algorithm [19, 20], so that the number of arithmetic operations required to solve the puzzle cannot differ depending on the machines. The proposed puzzle can be described as follows. We first consider two keys e and d that are usually termed the public key and the private key in the public key cryptography. In the proposed scheme, the value of e is fixed to 3, a popular value for the public key . We calculate the value of d in the following way. We choose two different large primes p and q, that are 128 bits long and satisfy the condition that (p - 1) and (q-1) are relatively prime to e. Then, d is an integer that satisfies the condition:
If f i is simply defined as modular exponentiation, e.g., as the decryption operation in the public key cryptography, without any additional operations of addition and subtraction, then the multiple encryption required to evaluate F m (x) can be simplified into a single exponentiation by Euler's theorem . In order to avoid such a simplification, we incorporated the additional operations of addition and subtraction in the definition of the message transformation functions as shown above.
Thus, if the values of e, d, N, and m are fixed, then the puzzle complexity in terms of the number of operations is also fixed. In the proposed scheme, the values of e, d, and N are fixed as described below, and the complexity of the puzzle is controlled only by m.
In EMR-ARP, we use two types of puzzles. The first type of puzzle should be solved by the voting request node itself to prevent a DoS attack that attempts to exhaust the processing power of neighbor EMR-ARP nodes by inducing continuous puzzle computation through too frequent transmission of voting request packets. The second type of puzzle needs to be solved by the EMR-ARP nodes receiving the voting request packets. This puzzle is used to provide the fairness among different nodes in voting.
In the first-type puzzle, the voting request node first makes a message m s by concatenating its own MAC address (MACA) and the local time T s measured in seconds when the voting request node starts to calculate the puzzle, i.e., m s = MACA||T s , and transform m s into c s by the message transformation function F m . Then, the voting request node sends T s , m, and the transformed message c s to the neighbor nodes. e, d, and N need not be delivered since they are fixed and known to EMR-ARP nodes in advance. The neighbor nodes apply the message recovery function G m to the received message c s . If the recovered message agrees with MACA||T s , then it confirms that the sender solved the first-type puzzle correctly and the receiver proceeds to solve the second-type puzzle to send a valid vote in return.
Thus, by comparing G m (c r ) and m r , we can verify the correctness of each answer. We can easily find that the second-type puzzle reflects all the requirements stated above.
Each EMR-ARP node maintains a table of (MAC address of voting request node, T s ) pairs, called puzzle history table, to prevent the flooding of the identical puzzles. T s is the puzzle generation time at the sender node as described above. If an EMR-ARP machine receives a voting request packet, then it first examines the value of the T s field. If the value of received T s is less than or equal to the value stored in the puzzle history table, then the received voting request message is neglected since the puzzle is highly likely to be a repetition of an old one. After verifying the validity of T s to avoid the flooding of identical puzzles, the EMR-ARP node investigates the correctness of the solution contained in the field of c s . If the solution is correct, the received voting request is considered valid, and the received timestamp T s is registered in the puzzle history table, i.e., in the entry corresponding to the MAC address of the current voting request node. Then, the EMR-ARP node proceeds to solve the second-type puzzle to provide a feedback for the voting request.
After solving the second-type puzzle as described above, the EMR-ARP node sends the MAC address corresponding to the queried IP address and the puzzle solution to the voting request node through the fields of target hardware address and c r , respectively, in the voting reply packet of Figure 3b.
Then, the voting request node receives and buffers the incoming voting reply packets up to 1 s from the voting request transmission time. The voting request node finds the earliest voting reply packet, calculates the response time t1, i.e., the period from the voting request transmission time to the arrival time of the earliest voting reply packet, and discards the voting reply packets that arrive later than 2t1 since those late replies might come from the malicious nodes actively solving the puzzles multiple times even for different nodes to increase the ratio of the votes supporting the fake IP/MAC mapping. Then, the voting request node verifies the correctness of the puzzle solution only for the not-too-late replies and accepts the received IP/MAC mapping only when the solution for the second-type puzzle is correct. The voting request node calculates the polling score for each candidate MAC address. If a MAC exists that received over 50% of valid votes, then that MAC address is accepted for the queried IP address.
3.2 Initialization stage
The original MR-ARP scheme might be vulnerable especially when a new MR-ARP node is attached to a LAN where an attacker resides. The detailed problem is described with an example below. In this section, we introduce an initialization stage for the proposed EMR-ARP to overcome the shortcoming of the original MR-ARP scheme especially for this case.
In this scenario, existing MR-ARP nodes do not know the IP address of Node F, and thus, each of them will try to find the correct MAC address of Node F through voting after waiting a random time between 0 and 100 ms . If we assume Node D is the first node that queries the MAC address of Node F, Node D will send a voting request for the IP address of Node F, IPF. There are one attacker node, i.e., Node E, and only one MR-ARP node that knows the MAC address for IPF, i.e., Node F itself. If those two nodes receive the voting request for IPF, then Node F will reply with 50 voting reply packets containing the correct MAC address for IPF. The attacking node needs not follow the original MR-ARP protocol, and it can send more than 50 voting reply packets with a false IP/MAC mapping. Thus, the attacker can win the voting in this case.
MITM attack cannot be successful between Nodes D and F even in this case since the ARP cache and the long term table of Node F are protected with the help of other MR-ARP nodes. However, we further investigate how to prevent ARP cache poisoning-based one-way eavesdropping by Node E for the packets going from the router Node D to the new Node F.
We employ additional initialization steps for EMR-ARP, which are described hereafter, to resolve this problem. The initialization procedure is performed only once during the lifetime of a given machine. The lifetime means the time interval from the time when the machine is turned on to the time when the machine is turned off. If a given EMR-ARP machine receives a new IP address through DHCP, then it performs the initialization steps, immediately after the IP address is configured. If the IP address is manually configured for a given EMR-ARP machine, then the initialization steps are performed just after the network card is activated. We need to note that all the ARP packets irrelevant to the initialization steps are discarded until the initialization steps are completed.
The second step starts after waiting 1 s from the transmission of the gratuitous ARP request packet. In the second step, the rebooted or newly attached node sends a special voting request packet for its own IP address to know if its current IP address is used by other machines. If there is no voting reply packet, or the MAC address of voting node polls over 50% of votes, then the new node can use the current IP address without any problem. If there is at least one reply packet and the MAC address of voting request node polls less than 50%, then the node gives up the use of the current IP address and requests a new IP address through DHCP or manual configuration with the help of a network administrator.
If other existing EMR-ARP nodes retain an entry corresponding to the IP address of the voting request node in the long term table, then they first verify the correctness of the solution to the first-type puzzle and send voting reply packets after solving the second-type puzzle, only if the first puzzle solution is correct. Although the voting reply packets for a normal voting request message are sent only to the voting request node through unicasting, the voting reply packets for a special voting request message are broadcasted, so that other neighbor EMR-ARP nodes can sniff those responses.
Thus, according to the initialization procedure described above, when an EMR-ARP node sends the first special voting request packet after reboot or initial deployment, if an attacker replies with a false MAC address for the queried IP address, then the new node will try to avoid the use of the IP address in conflict. Thus, the voting replies from the attackers advertising false IP/MAC mapping cannot help one-way eavesdropping for the packets going to the new EMR-ARP node. Conversely, if there is no reply for the first special voting request, then all the normal EMR-ARP nodes will accept the mapping between the sender protocol address and the sender hardware address of the special voting request packet by the algorithm in Figure 6. Thus, the proposed initialization procedure can effectively prevent one-way eavesdropping of the packets destined to the newly attached nodes.
4 Numerical results
In this section, we evaluate the performance of the proposed ARP in terms of the voting traffic overhead, the reliability in the presence of attackers, and address conflict resolution delay.
4.1 Analysis of traffic overhead
We first compare the traffic overhead of EMR-ARP with that of MR-ARP. The traffic overhead of EMR-ARP or MR-ARP is due to the exchange of voting request and reply packets in the voting procedure. Thus, we investigate the traffic rate of voting request and reply packets.
where the first term on the right hand side of the first equality describes the rate of the voting reply packets triggered by Node A itself, the second term describes the traffic rate of voting request packets received by Node A, and the third term is the rate of the voting reply packets triggered by the special voting request messages of other EMR-ARP nodes.
By comparing (5) and (6), we can find that the voting traffic overhead of EMR-ARP is lower than that of MR-ARP if L ≥ 2. If L ≥ 10, then the voting traffic overhead of EMR-ARP is lower than that of MR-ARP by a factor of more than six since the EMR-ARP does not require multiple transmission of the same voting reply packets. When L = M = 255, and T D is one day, . Thus, the voting traffic overhead is not significant for a small subnet.
4.2 Analysis of reliability of the proposed scheme
Before investigating the reliability of the proposed scheme in the presence of attackers in detail, we first investigate whether the fairness can be maintained even when the performance of the CPUs is not the same among different machines.
We also determine the value of m based on the result shown in Figure 7. The message transformation time, i.e., puzzle solving time, should be sufficiently longer than the MAC layer access delay of 802.11 wireless LAN so that the different transmission rate on the wired and wireless medium cannot impair the fairness in voting among the wired and wireless nodes . Thus, we select a sufficiently large value, i.e., 4000, for m to maintain the message transformation time over 450 ms. However, since the optimal value of m can differ depending on the machine, the value of m can be determined according to the above rule by each machine whenever it is rebooted.
As an example, let us consider a case where the processors of all the machines belonging to the given subnet are one of the above three types of CPUs. Let us assume that the puzzle solving times of different machines do not differ by a factor of two, as shown in Figure 8. Then, even though an attacker uses the quad-core processor and tries to send multiple voting replies after solving many puzzles for other MAC addresses, so as to pretend to be multiple other machines, the first voting replies from other normal EMR-ARP nodes will arrive earlier than the second voting reply of the malicious node if all the nodes experience a similar level of MAC layer access delay. If t1 denotes the response time of the earliest voting reply packet, then the voting request node does not accept the voting reply packets that do not arrive within 2t1 from the voting request transmission time as explained in Section 3.1. Thus, the fairness can be guaranteed if the puzzle solving times of different machines do not differ by a factor of two. Figure 8 implies that this condition is likely to be valid in a real environment since the performance of the CPUs used in recent desktop and laptop computers is usually not much different from that of the three types of CPUs considered in this article.
We briefly discuss the compatibility of EMR-ARP with the existing ARP. EMR-ARP Node A responds to a normal ARP request destined to itself by sending an ARP reply message as the current ARP. Even though Node A is the only EMR-ARP-enabled node in the subnet, Node A can accept the received IP/MAC mapping for a new IP address using the rule for (C) in Figure 1. Thus, EMR-ARP is backward compatible with the existing ARP.
4.3 Analysis of conflict resolution delay
In this section, we investigate how long it takes to resolve the conflict on IP/MAC address mapping especially in the cases (B) and (C) of Figure 1. In case (B) of Figure 1, the conflict is resolved by sending 10 ARP request packets to the previous owner of the IP address in question and receiving an ARP response packet from that node. Since the puzzle computation is not involved in this step and the packets are hardly dropped in the normal situation without any DoS attack, it usually takes only one round-trip time (RTT) between the querying node and the previous owner node to resolve the conflict in this case. Since the querying node waits up to 1 s, the conflict resolution time does not exceed 1 s even though there is no response from the previous owner node.
5 Conclusions and future work
An enhanced version ARP, EMR-ARP, is proposed to prevent ARP cache poisoning-based MITM attacks in wired or wireless LAN environments. The proposed scheme is based on two key concepts: long-term IP/MAC mapping table and computational puzzle-based voting. The long-term table protects the IP/MAC address mappings for all alive machines in the subnet from the ARP cache poisoning attack. The computational puzzle-based voting prevents ARP poisoning-based MITM attack whenever a machine is rebooted or a new machine is added. It is very important to maintain the fairness between different machines when the MAC addresses are resolved based on voting. We designed a new puzzle based on the RSA algorithm to provide fairness, even when the link rates differ between wireless and wired nodes, while minimizing the variance in puzzle solving time.
The experiment results show that the ARP poisoning-based MITM attacks are well mitigated, as long as the number of EMR-ARP nodes is larger than that of adversary nodes. Since the proposed mechanism is not based on public-key cryptography, the manual configuration, such as distribution of the public key and the MAC address of the centralized key management server, is not required, and thus, the proposed scheme can efficiently mitigate ARP poisoning-based MITM attacks, even in public Wi-Fi hot-spots. The proposed scheme is backward compatible with existing ARP protocol and incrementally deployable, with benefits to the upgraded machines.
The proposed computational puzzle-based voting scheme can provide fairness among different nodes only when the computation power of the CPUs of those machines is not significantly different. The proposed scheme will be extended further, so that the fairness can be maintained, even when the computation power of the machines is more diverse in future study.
This research was supported by the Yeungnam University research grants in 2010.
- 1.Plummer DC: An ethernet address resolution protocol. RFC 1982., 826:Google Scholar
- 3.Benvenuti C: Understanding Linux Network Internals. O'Reilly, California; 2006.Google Scholar
- 4.Hacking UNIX 2003: A tutorial for performing various attacks including ARP poisoning attack on UNIX systems.[http://duho.cjb.net]
- 5.Whalen S: An introduction to arp spoofing.[http://packetstormsecurity.org/papers/protocols/intro_to_arp_spoofing.pdf]
- 7.Fleck B, Dimov J: Wireless access points and arp poisoning.[http://bandwidthco.com/whitepapers/netforensics/arp-rarp/Wireless%20Access%20Points%20and%20ARP%20Poisoning.pdf]
- 8.Bhaiji Y: Network Security Technologies and Solutions. Cisco Press, New York; 2008.Google Scholar
- 9.Bruschi D, Ornaghi A, Rosti E: S-ARP: a Secure address resolution protocol. In Proc of Annual Computer Security Applications Conference (ACSAC). Volume 1. Las Vegas, Nevada, USA; 2003:66-74.Google Scholar
- 11.Teterin I: Antidote.[http://online.securityfocus.com/archive/1/299929]
- 12.Philip R: Securing Wireless Networks from ARP Cache Poisoning. Master's Thesis, San Jose State University; 2007.Google Scholar
- 15.Lacage M, Manshaei MH, Turletti T: IEEE 802.11 rate adaptation: a practical approach. In Proc of ACM International Symposium on Modeling, analysis and simulation of wireless and mobile systems (MSWiM'04). Volume 1. Venice, Italy; 2004:126-134.Google Scholar
- 16.Dwork C, Naor M: Pricing via processing or combatting junk mail. In Proc of CRYPTO. Volume 1. Santa Barbara, California, USA; 1992:139-147.Google Scholar
- 17.Borisov N: Computational puzzles as sybil defenses. In Proc of IEEE International Conference on Peer-to-Peer Computing. Volume 1. Cambridge, UK; 2006:171-176.Google Scholar
- 18.Parno B, Wendlandt D, Shi E, Perrig A, Maggs B, Hu YC: Portcullis: protecting connection setup from denial-of-capability attacks. In Proc of SIGCOMM. Volume 1. Kyoto, Japan; 2007:289-300.Google Scholar
- 20.Kaufman C, Perlman R, Speciner M: Network Security-Private Communication in a Public World. 2nd edition. Prentice Hall, Upper Saddle River; 2002.Google Scholar
- 21.Gratuitous ARP - The Wireshark Wiki[http://wiki.wireshark.org/Gratuitous_ARP]
- 22.Chatzimisios P, Boucouvalas AC, Vitsas V: IEEE 802.11 packet delay-a finite retry limit analysis. In Proc of IEEE Globecom. Volume 2. San Francisco, USA; 2003:950-954.Google Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.