# PrECast: An Efficient Crypto-Free Solution for Broadcast-Based Attacks in IPv4 Networks
## 3 Mitigating the ARP-Poisoning Attack
### Algorithm-Based Solutions
The same functionality of S-ARP is achieved through the use of the digital certificate from the LTA. However, we note that their proposed scheme has the following vulnerabilities:* Like any centralized service, LTA is a single point of failure. Launching a DDoS attack against LTA can bring the entire network down. * There is no mechanism of distributing the public key of LTA to all clients. In the absence of a secure delivery mechanism, any intruder can pretend to be the LTA and distribute his own public key and sign the <MAC, IP >bindings. In S-ARP, this requirement is explicitly mentioned. * TARP in its current state cannot detect rogue DHCP servers. In a multilayered network, there is a latency between the legitimate DHCP server and some clients. This may be exploited by a rogue DHCP server that distributes IP addresses and tickets. * To make the protocol more secure, TARP must provide an efficient ticket revocation mechanism that securely notifies all active clients about which tickets are no longer valid. Any such mechanism will incur severe network overhead in a busy network like a public hotspot or university networks. * Even though TARP solves the ARP-poisoning problem, still the broadcast mechanism is used for the ARP-request. Thus, TARP suffers performance degradation due to the broadcast mechanism. In [PERSON] et al. (2016), [PERSON] et al. proposed an enhanced version of ARP called MR-ARP to prevent the ARP-poisoning attack in Ethernet-based LAN environments through a voting mechanism. MR-ARP determines the owner of the IP address by giving a higher priority to the previous owner in the case of conflict of the MAC address of the owner. If an MR-ARP node observes a conflict for the owner of an IP address that is not registered in its own ARP cache, the MR-ARP triggers voting on the owner of that IP address among the neighbour nodes to make a decision based on the voting results. Since the decision is made through a voting mechanism, MR-ARP must ensure that fairness in the voting mechanism is maintained. In a wired LAN, all nodes have the same transmission rate and thus are likely to send a similar number of voting packets during a particular interval of time. However, this is not possible in a wireless network. This is due to the fact that the transmission rate in a wireless network may be different for different nodes due to the traffic rate adaption based on the signal-to-noise ratio. To resolve this unfairness in a wireless segment, MR-ARP introduces a computational puzzle in the voting procedure. Thus, MR-ARP has a different fairness mechanism for different nodes. In a later paper [PERSON] et al. (2017), one of the authors of [PERSON] et al. (2016) proposed some generalization to MR-ARP and called it the Generalized MR-ARP (GMR-ARP). The fairness in voting was improved in GMR-ARP by dropping reply packets that arrive too early. We noted that both proposals [PERSON] et al. (2016); [PERSON] et al. (2017) have a number of shortfalls:  
* In order to implement MR-ARP or GMR-ARP, the protocol stack at the client-side needs to be redesigned. Any end-host must have the new protocol stack installed before connecting to the network. This is an undesirable requirement in a public environment (like a university, airports or restaurants). * Their voting process consumes a lot of network overhead. This process will also consume resources on every participating host as the broadcasting mechanism is used by the voting process. * Their proposal requires every host to respond to a voting request as early as possible, and each host is expected to send a certain number of voting replies. However, how soon a node sends its voting reply depends on the number of processes running on the host and the queue length of the buffer at every host. An attacker could use this mechanism to launch a DoS against every host in the network. * Both MR-ARP and GMR-ARP require every host to maintain a long-term <MAC, IP >binding table. This consumes memory.