# FEAROL: Aging Flow Entries Based on Local Staircase Randomized Response for Secure SDN Flow Tables
## 5 Prototype  
Since FEAROL slightly changes the flow-entry management procedure in SDN switches, the software of the SDN switches has to be updated. We are currently implementing FEAROL in OVS, a product-level open-source soft-switch developed by Linux Foundation. As FEAROL is based on a local staircase randomized response, FEAROL does not change the existing protocols and SDN controllers.  
As shown in Figure 5, OVS has a daemon called ovs-vswitchd that continuously manages flows and flow entries. An OVS may have multiple data-paths to receive (1) and forward flow packets. Data-paths reside in the kernel space of an OVS. When a data-path receives a packet, it looks up its flow table to find the matching flow entry. If the matching flow entry is not found, the data-path sends a flow entry request message (2) to its remote controller via the OVS daemon (3). The remote controller generates the flow entry and delivers it to the flow table via OVS daemon along with the flow entry installation module (4) and 5). The data-path retrieves the matching flow entry (5) and forwards the received packet out (7).  
The OVS daemon manages flow entries in the flow table using the flow-entry-management module. FEAROL is implemented in the flow-entry-management module to provide a staircase randomized response for updating the current existence and idle time of each flow entry so that the OVS can protect the true lifespan of each flow entry from sniffing and leakage.  
\begin{table}
\begin{tabular}{c c c c c c c c c} \hline \(p\) & \(\epsilon\) & \(A_{1}\) & \(A_{2}\) & \(A_{3}\) & \(A_{4}\) & \(E(FA_{i})\) & Protection & Aging & Strategy \# \\ \hline \multirow{3}{*}{0.25} & \multirow{3}{*}{\(-1.1\)} & 1 & 0 & 0 & 0 & 0.25 & high & slow & 1 \\  & & 1 & 0 & 2 & 3 & 1.5 & high & fast & 2 \\  & & 1 & 0 & \(-1\) & 2 & 0.5 & high & no & 3 \\ \hline \multirow{3}{*}{0.55} & \multirow{3}{*}{0.2} & 1 & 0 & 0 & 0 & 0.55 & low & slower & 4 \\  & & 1 & 0 & 2 & 3 & 1.3 & low & fast & 5 \\  & & 1 & 0 & \(-1\) & 2 & 0.7 & low & slow & 6 \\ \hline \multirow{3}{*}{0.75} & \multirow{3}{*}{1.1} & 1 & 0 & 0 & 0 & 0.75 & lower & slower & 7 \\  & & 1 & 0 & 2 & 3 & 1.42 & lower & fast & 8 \\ \cline{1-1}  & & 1 & 0 & \(-1\) & 2 & 0.83 & lower & slow & 9 \\ \hline \end{tabular}
\end{table}
Table 4: Strategies used to configure the sets of \(A\) and \(P\).  
The current FEAROL implementation defines nine combinations of \(A\) and \(P\). As listed in Table 4, the update period of \(A\) and \(P\) is set to 60 s by default, based on the maximum flow table space usage \(O\), the total number of packets forwarded to controllers \(F\) and the privacy budget \(\epsilon\) computed in the last period. Note that the total number of packets forwarded to controllers \(F\) must be counted by the modules sending or receiving flow entry requests. In the current implementation, we compute \(F\) in the OVS daemon to leave the software of the controllers unchanged. FEAROL remains the existing flow-entry-management timer in the unchanged OVS. As the timer fires every millisecond, each flow entry ages in milliseconds. FEAROL supports more aging strategies and finer timers.