A model for the analysis of security policies in service function chains

Two emerging architectural paradigms, i.e., Software Defined Networking (SDN) and Network Function Virtualization (NFV), enable the deployment and management of Service Function Chains (SFCs). A SFC is an ordered sequence of abstract Service Functions (SFs), e.g., firewalls, VPN-gateways,traffic monitors, that packets have to traverse in the route from source to destination. While this appealing solution offers significant advantages in terms of flexibility, it also introduces new challenges such as the correct configuration and ordering of SFs in the chain to satisfy overall security requirements. This paper presents a formal model conceived to enable the verification of correct policy enforcements in SFCs. Software tools based on the model can then be designed to cope with unwanted network behaviors (e.g., security flaws) deriving from incorrect interactions of SFs in the same SFC.

💡 Research Summary

The paper addresses the emerging challenge of ensuring correct security policy enforcement within Service Function Chains (SFCs) that are built on top of Software‑Defined Networking (SDN) and Network Function Virtualization (NFV). While SDN/NFV provide unprecedented flexibility for dynamically composing network services such as firewalls, NATs, VPN gateways, and traffic monitors, the independent configuration of each virtual network function (VNF) can lead to policy conflicts, ordering errors, and unintended security gaps. Existing works mainly focus on isolated firewall or IPSec policy analysis, or on SDN-wide invariant checking that does not consider stateful security functions.

To fill this gap, the authors propose a formal, mathematically grounded model that captures (i) the structure of an SFC as an ordered list of Service Functions (SFs), (ii) the internal state of each SF, (iii) the packet representation as a set of (field, value) pairs, and (iv) the policy of each SF as an ordered set of rules, a conflict‑resolution strategy, and a default action. Each rule consists of a set of conditions (which may involve packet fields or state variables) and a sequence of actions (packet modifications, state updates, or drop). The model defines a deterministic transformation function that, given an input traffic flow, sequentially applies the transformations of the SFs in the chain, producing a final packet set (or the null packet to represent drops).

The verification workflow assumes an OpenFlow‑based deployment. First, OpenFlow flow entries are collected to reconstruct the actual SFCs and their Service Function Paths (SFPs). Second, for each SFC, high‑level security requirements (verification policies) are expressed in the same formal language (e.g., “all traffic to the data centre must be encrypted”, “encrypted outbound traffic must be dropped”). Third, low‑level configuration policies are extracted from each SF implementation (firewall rule tables, VPN encryption settings, etc.). These policies populate the formal model. Fourth, the model computes the effect of each SF on every possible packet in the traffic flow, yielding the post‑chain packet set. Finally, the result is compared against the verification policies; any mismatch signals a configuration error or security flaw.

A concrete example illustrates the approach. In a simple office‑to‑data‑centre scenario, three SFs are chained: a Traffic Monitor (TM), an Application Firewall (AF), and a VPN Gateway (VG). The security goals are: (1) drop any encrypted traffic originating from the office, (2) encrypt all traffic destined for the data centre, and (3) monitor connections to a remote database. When the chain order is TM → AF → VG, the model confirms that all goals are satisfied. If the order is changed to VG → TM → AF, the model detects that VG encrypts the traffic before TM can count connections, and AF subsequently drops the encrypted packets, violating goals (2) and (3).

The authors discuss strengths and limitations. Strengths include the ability to model stateful functions, a unified representation of packet, state, conditions, and actions, and the potential for automated tool support that goes beyond existing SDN verification tools (VeriFlow, ConfigChecker) by incorporating security functions. Limitations involve state‑space explosion for large‑scale networks, the need for abstraction when modeling complex operations such as key exchange, and the reliance on administrators to accurately specify high‑level security requirements.

In conclusion, the paper provides a solid theoretical foundation for SFC security verification and outlines a practical verification pipeline. Future work is suggested on optimizing the model for scalability, extending it to richer function behaviours, and integrating policy authoring assistance to reduce human error. The proposed approach promises to improve the reliability and security of dynamically composed network services in modern SDN/NFV environments.