Dynamic and Application-Aware Provisioning of Chained Virtual Security Network Functions

Abstract

A promising area of application for Network Function Virtualization is in network security, where chains of Virtual Security Network Functions (VSNFs), i.e., security-specific virtual functions such as firewalls or Intrusion Prevention Systems, can be dynamically created and configured to inspect, filter or monitor the network traffic. However, the traffic handled by VSNFs could be sensitive to specific network requirements, such as minimum bandwidth or maximum end-to-end latency. Therefore, the decision on which VSNFs should apply for a given application, where to place them and how to connect them, should take such requirements into consideration. Otherwise, security services could affect the quality of service experienced by customers.In this paper we propose PESS (Progressive Embedding of Security Services), a solution to efficiently deploy chains of virtualised security functions based on the security requirements of individual applications and operators' policies, while optimizing resource utilization. We provide the PESS mathematical model and heuristic solution.Simulation results show that, compared to state-of-the-art application-agnostic VSNF provisioning models, PESS reduces computational resource utilization by up to 50%, in different network scenarios. This result ultimately leads to a higher number of provisioned security services and to up to a 40% reduction in end-to-end latency of application traffic.

Impact of Processing-Resource Sharing on the Placement of Chained Virtual Network Functions

“…[46]) as ratio between the number of adopted CPU cores and of flows supported by the middlebox. Even though this is just a possible and rough estimation for the processing requirement (see [47] for a different strategy based on CPU cycles/s), it allows to TABLE VI PERFORMANCE COMPARISON BETWEEN ILP AND HCA |C| = 3, N user = 300, N iter = 100 |C| = 6, N user = 150, N iter = 100 |C| = 8, N user = 450, N iter = 10 Latency Costs [15] HCA ILP HCA ILP HCA ILP Average number of active NFV nodes ω = 0 ms, κ = 0 ms 2.91 ± 0.057 2.91 ± 0.057 2.95 ± 0.043 2.95 ± 0.043 6.00 ± 0.000 6.00 ± 0.000 ω = 0 ms, κ = 1.75 ms 2.95 ± 0, 052 2.93 ± 0.058 2.99 ± 0.034 2.97 ± 0.034 6.11 ± 0.260 6.00 ± 0.000 ω = 0.4 ms, κ = 0 ms 3.09 ± 0.090 3.07 ± 0.086 3.00 ± 0.028 2.99 ± 0.020 7.86 ± 0.640 6.45 ± 0.410 Results are reported along with 95% confidence intervals understand which are the most processing-hungry VNFs: for example, according to our estimation, a Traffic Monitor is about 15 times more processing-hungry than a Firewall. The six VNFs can be chained in different ways to provide four heterogeneous SFCs, reported in Table V.…”

Designing Security-Aware Service Requests for NFV-Enabled Networks

“…The proposal avoids VNFI resource fragmentation and security service latency. The authors of [14], [15] proposed an Integer Linear Programming (ILP) formulation for placing VNSFs with respect to both the quality of service requirements and the security constraints. They argue that omitting the QoS requirements by forcing all the traffic to traverse the whole VNSFs chain can cause performance degradation to latency-sensitive applications, especially when traversing computationally-demanding security functions such as IDS.…”

Hybrid SDN evolution: A comprehensive survey of the state-of-the-art

“…Nevertheless, the integration of traditional hardware appliances and software-defined functions is not trivial and can be influenced by multiple factors, such as: (i) the hSDN deployment model (cf. Section 2), which might determine how the traffic is routed within the network and where the security functions can be executed [112], [113], (ii) the specific security policies and bestpractices of the operator/enterprise, which define how each class of network traffic should be processed [114], [115], and (iii) the user requirements in terms of QoS (usually maximum end-toend latency and minimum bandwidth), as busy links and devices might create bottlenecks in the network.…”