# PrECast: An Efficient Crypto-Free Solution for Broadcast-Based Attacks in IPv4 Networks
## 7 Analysis of PrECast  
In this section, we analyse the strength of our proposed architecture by comparing with the existing solution available in the literature.  
* From Section 2, it is apparent that broadcasting in IPv4 is responsible for several security problems. However, in the literature, every proposal only addresses a particular type of security pitfall like ARP-poison, DHCP-snooping, etc. One type of solution cannot be modified to provide a solution to another type of attack. However, our holistic approach provides a solution to all security pitfalls that are due to IPv4 broadcasting.
* Several proposals that are available in the literature use cryptographic schemes, the key distribution centre and a pre-defined relation between a host and the network, etc. Firstly, the use of cryptographic schemes may not be efficient for a mobile host due to its CPU and power requirements.
* For a solution that uses a key distribution centre (KDC), the KDC will be a single-point attack. Thus, any DoS attack towards KDC can bring the entire network operation down.
* A pre-defined relation between a host and a network (like only the registered MAC addresses' area is allowed to connect to the network) can be imposed on a small private network. However, this relation cannot be extended in a public network like an airport or university network, which encourages the concept of BYOD.  
Our proposed solution does not use cryptographic schemes, thus being power- and CPU-friendly on mobile devices. Since there is no KDC involved in our solution, it is not a single-point failure. Further, pre, since there is no need to establish a predefined relation between a host and a network, our solution not only supports BYOD, but also can scale from a smaller to a larger network.  
* Message overhead: Several proposed solutions in the literature require the use of control messages, thus incurring more overhead. However, our proposed protocol did not incur any extra overhead.
* Transparent implementation: If any implemented solution is known to an end-user/attacker, potentially, the solution may be targeted for attacks. However, our proposed solution may be implemented transparently without end-user's knowledge.
* Our proposed solution requires fewer configurations at the core network, compared with other crypto-based schemes that require and maintain the installation of a KDC.
* Our proposed solution requires zero-configuration at the host side. A host may not be aware of the existence of such a solution. Thus, any hacking attempt exploiting IP broadcasting is recorded by our system, and the network administrator can take immediate action against a host with malicious intention.
* In our paper, we used message complexity and convergence time as our performance parameters. Since, we have not changed the state-diagram of the protocol, the CPU load at the switches, end-devices and the RTT (round-trip time) is the same as without our protocol.  
* Our solution is scalable; since our proposed solution runs as a service inside a switch, it can be implemented on any switch that runs through a network operating system. It can also be implemented using the SDN (software-defined network) architecture.