# A Tiered Control Plane Model for Service Function Chaining Isolation
### Research Challenges  
Figure 2 shows where end-to-end user traffic can be eavesdropped on in an SFC. NFV is designed to be flexible and simple where most intermediate NFV services are perceived as transparent network services. Hence, the common end-users are unaware of the potential of traffic eavesdropping in an SFC. In multi-operator and multi-tenancy NFV networks, we argue that end-users need to know which operators require access to their traffic. In addition, we assume that the end-users want to apply security policies to their SFCs, which would specify what type of SFC traffic each operator can access. We argue that the end-users require the flexibility of both allowing a subset of the VNFs to have access to all their data traffic, and letting other subsets of the VNFs have access only to a specific type of traffic. Currently, such traffic isolation within an SFC is not possible; end-to-end encryption is also not supported within an SFC.  
This article introduces an architecture that isolates and encrypts SFC traffic between the different VNFs, which requires the automation of the encryption setup. Enforcing the network traffic through encryption services requires a new east-west protocol for network routing and for key derivation.  
Figure 1: Extended east-west communication for Network Function Virtualization.  
Figure 2: The adversary model.  
Hence, this article also suggests a protocol and a procedure that can automate this dynamic routing and encryption setup.  
Figure 3 shows different approaches in routing SFC traffic. This is mainly reflected by plain flow-based routing (Figure 3(1,2)), the use of additional SFC headers (Figure 3(3,4,5)) or by using transport tunnels (Figure 3(6,7)). Running common encryption services on the Internet Protocol (IP) layer introduces an SFC routing problem because the packet encryption hides or changes the meta-data information such as the destination port inside the IP packet (Figure 3(2)). This lack of meta-data makes flow-based routing with i.e., OpenFlow difficult without using additional packet header tagging such as Network Service Headers (NSH) [1] or Multi-protocol Label Switching (MPLS) [2]. Hence, the packets must be classified before they are encrypted and a packet tag must be applied to the IP packet in order be able to route the packet correctly. Our solution to this problem is to put an SFC header in front of the encrypted packet and encapsulate it by a transport tunnel running between the NFV providers (Figure 3(7)).  
Another related problem when not using SFC headers such as NSH or MPLS is how to ensure the state of an SFC packet. Figure 4 shows that an SFC can traverse back and forth between two NFV Service Providers. The example shows how the network device B must know if an incoming packet from the tunnel has its destination to VNF 2 or VNF 4. Since the IP headers of the SFC packet normally do not change, the packet must be tagged by meta-data or be tunnelled.  
Figure 4: Flow identification problem.  
Figure 3: Encryption possibilities.  
This need for SFC packet headers excludes most SFC technologies that are not using additional SFC headers from being applied in combination with IP encryption. This also excludes other methods that do not allow the use of NSH or MPLS. Hence, this article focus on using NSH as both an SFC packet forwarding and a routing mechanism.