## 3 Operational Context of Proof-of-Concept Scenarios
### Requirements  
We have in our previous work presented the NFV security requirements [4] for the encryption and the isolation of the VLs. We summarise these requirements in the context of the aforementioned scenario:  
1. **Hop by hop encryption--**In order to prevent eavesdropping of the VLs, the VLs must be encrypted per SFC. 2. **Micro-segmented isolation--**The SFC specification [2] does not allow micro-segmentation within one SFC. However, we state that the end-user requires that they must be able to specify what data traffic the SFs are allowed to handle on a flow-based level. Hence, it is required that the associated data plane components are capable of isolating different packet flows with different encryption keys within one single SFC. 3. **Header visibility--**When encrypting VLs, the SFC packet header must be non-encrypted in order to enable SFC routing of the encrypted packets. We define that a new SFC header extension must be able to both allow and specify when the inner data-content of an SFC packet header is encrypted. Figure 2: Proof-of-Concept scenario. **iv. Control plane flow distribution--**Multiple encryption-flows within one SFC require that the control plane is capable of distributing route information about each of these encrypted flows. These flow-rules must be securely distributed. Hence, secure and trusted intra- and inter-domain communication channels from the virtual network devices to the network controllers must be established. * **Key distribution--**Due to a non-bidirectional data plane between the SFs in an SFC [2], a new hop-by-hop key distribution mechanism is required. The key distribution mechanism must respond to a dynamic SFC behaviour such as an SFC modification. It must also support future encryption standards or protocol extensions. The key distribution mechanism must ensure confidentiality, integrity and availability of the keys. * **Compliance and adoption--**A new SFC header and the corresponding provisioning architecture must be compliant with the current NFV standards. In addition, adding encryption to the VLs should not degrade the end-to-end throughput performance more than traditional end-to-end encrypted channels. Another important factor for the architecture to be adopted is that the end-users do not perceive a significant increase in service provisioning times when they apply VL encryption. * **Resilience and availability--**The architecture must provide resilience towards components failing without reducing the level of security. * **Security integrity--**An attacker should not be able to manipulate the routing tables or to modify the packet headers in order to enforce access to non-encrypted data packets. We aggregated these requirements and defined the following episodes from the aforementioned scenario. **Episode 1: Packet forwarding and provisioning (Req: i, iii, iv, vi)**  
This episode is created from an end-user perspective. An end-user orders a new virtual service according to our scenario. The end-user expects that his broadband service is not affected during service provisioning. A service provisioning demonstration can monitor the provisioning time by measuring network outage. However, demonstrating a full service provisioning also provides evidence of how the architecture provides the setup of the encrypted VLs. In addition, in a fully provisioned SFC, an end-to-end traffic test shows how the encrypted data packets are routed and if the traffic flow is satisfying the security requirement of flow-distribution. **Episode 2: Resilience and availability (Req: v, vii)**  
In this episode, we simulate hardware failure. From an availability and resilience perspective, the architecture must be resilient to components failing without compromising the network encryption policy. During service recovery, this demonstration also shows the dynamic behaviour of the key distribution during failovers.