## 5 Proof of Concept
### AG Cuts
Consequently, the \(N_{h}\) hosts in the network are split into two sets, the \(V\) vulnerable hosts and the \(S\) non-vulnerable ones:  
\[N_{h}=V+S \tag{4}\]  
The switch will compute security metrics just for the traffic flows that have a vulnerable host as an endpoint. The metrics computation is performed over the switch and will increase the overall Packet Processing Time (PPT). The absolute computation time will obviously depend on the capacity of the available hardware so, to keep the discussion as general as possible, here we assume it is a multiple of a constant time unit \(U_{c}\). The security metric is computed using Equation (3). Packet Processing Times (PPTs) (The PPT is calculated as follows: we used Wireshark ([[https://www.wireshark.org/](https://www.wireshark.org/)]([https://www.wireshark.org/](https://www.wireshark.org/)), accessed on 1 October 2023) to capture a packet timestamp \(t_{int}\) at the ingress interface of the switch and the timestamp \(t_{out}\) at the egress interface when the same packet is forwarded to the destination host. The packet processing time is then calculated by \(t_{out}-t_{int}\).) are plotted in Figure 8. The blue color is used to plot the PPT of normal packets, i.e., not requiring metric computation because they cannot be part of the attack; the orange color is used to plot the PPT of packets used to calculate the security metric. The test is always performed by forwarding a series of 10,000 packets through the switch between the source and destination. The red lines correspond to the respective averages of the two sets of PPTs. We plotted five sample cases, ranging from no packets undergoing security metric calculation up to security metric calculation for all packets, with intermediate cases of 12.5%, 25%, and 50% of packets triggering the security metric calculation. We believe this figure provides some important information and insight into the problem we are considering:  
1. The PPT is indeed quite variable but shows statistical stability when comparing single values with the average; therefore, we assume we are facing a stationary and ergodic stochastic process;
2. The average PPT for the two cases is almost independent of the number of packets involved in security metric calculation, and because of this, we assume that we can make some general statement not depending on the actual shape of the AGs but just on the number of hosts identified as vulnerable;
3. The overall processing burden in the switch is a linear function of the number of traffic flows considered suspicious (i.e., the number of suspicious hosts), and therefore, we are interested in the security metric calculation. On average, the overall processing burden in the switch is a multiple of the number of flows according to the average packet processing time. Based on the aforementioned considerations, we are now interested in understanding how much the data plane of the network is loaded by the additional task of security metric calculation in the switches. Let us call the total computation time consumed in the switch, \(T_{c}\) in the following, as an indication of such overall load. Based on the discussion above, we assume \(T_{c}\) is the product of the number of flows to monitor, which is the same as the number of vulnerable hosts \(N_{h}\), for the average processing time of the involved packets that we estimated in Figure 8. This estimation on a single switch is in line with the demonstration of [8] [PERSON] et al., leaving the multi-switches case for future works. As a result, we can extrapolate the following:  
1. The overhead generated in a single switch by the process of metric elaboration will be linearly influenced by the number \(V\) of hosts identified as possibly vulnerable;
2. The total overhead generated in the network by the entire metric calculation processes will have a directly proportional relationship with the number of switches that compute the metric.