# PrECast: An Efficient Crypto-Free Solution for Broadcast-Based Attacks in IPv4 Networks
## 5 Setting up the PrECast Infrastructure
### The PrECast Algorithm
#### 5.1.4 MCAM Table Maintenance  
We now present the MCAM table maintenance process due to the ageing process. The traditional ARP-cache table stored at every host has a time-out value. The time-out value depends on the particular OS running on the host. Having a time-out value has two advantages: Since we are removing any stale ARP cache entries from the memory, having a time-out value can conserve the memory. Time-out also has another important purpose. Within the duration of the time-out, the binding relation between the MAC and IP address of a host might have changed. For example, in a DHCP-based environment, the IP address lease may have expired, and the same IP address is allocated to another host. In a static IP environment, the administrator might have replaced a faulty network adapter that resulted in a change in the binding (this event may be quite rare in a network). Since the MCAM table kept at a switch is similar to the ARP-cache table, it is essential to perform the above maintenance. This is to ensure that the entries kept in the MCAM table are current and valid. In our proposed scheme, we consider two types of time-out values. The first one is the forced-time-out value. The forced-time-out option is used whenever there is a change in the MAC and IP binding relation. The second one is the traditional time-out value that deals with stale entries. We explain them below in detail. Figure 4: Protocol for Eliminating Broadcast (PrECast) ARP-lookup process. The Forced-Time-Out:  
Let \(t\) be the time-out value. Either between [0, \(t\)], or while an <MAC, IP> entry is flagged as dormant, a host may leave the network. Whenever a host leaves the network, we remove its <MAC, IP> binding from every switch in the network. In a dynamic environment, the same IP address is issued to another host with a different MAC address. We give below an example of cases where a forced-time-out is used to remove entries from every switch in the network. Let us assume that Host A is connected to Switch S. There are a number of cases that can trigger a forced-time-out. They are:  
* Host A issue a DHCP-release message after closing its connection. * The DHCP server has issued a lease expiry message to Host A, and Host A has not responded to it. * No L1 or L2 activity from Host A for a period of time (this period of time is a parameter set by the system administrator). * Host A has changed its network card. If one or more of the above cases happen, Switch S will trigger an unsolicited ARP multicast reply with \(<ID_{S},\ MAC_{A},\ ptyset>\) with a zero time-out value. Here, \(ID_{S}\) is the switch ID for S; \(MAC_{A}\) is the MAC address of Host A; and the IP field is empty. All switches that receive this multicast reply will remove the entry for Host A from their MCAM table. The Normal-Time-Out:  
Every entry present in the MCAM table has a time-out value. If the switch detects a new frame with a particular MAC and IP combination, then the timer for the corresponding entry in its MCAM table is reset to the current system time. This means that, whenever a <MAC, IP> binding combination is in use, the corresponding entry remains fresh in the MCAM table. If a <MAC, IP> binding is not in use for the entire duration set in the time-out value, then the corresponding entry in the MCAM table is flagged as dormant. This process is different from the ARP-cache time-out process, wherein any stale entry will be removed from the memory. The main reason for us to propose this is to ensure that, whenever the same <MAC, IP> binding is needed, it is readily available without incurring any load on the network. If a host connected to a switch issues an ARP request to another host for which its binding is flagged as dormant, the switch will change this entry from dormant to active, and a new timer value is set. Rather than removing an unused entry from the MCAM table, flagging them as dormant saves a pair of multicast request and a reply, if the entry is needed at a later point of time.