# A Secure Link-Layer Connectivity Platform for Multi-Site NFV Services
## 3 Description of the L2S Platform  
### Conceptual Design  
After reviewing the advantages and limitations of existing approaches to support data communications in multi-site NFV ecosystems, this section presents the design of L2S, a platform to enable secure link-layer communications among NFV sites. In our solution, we consider an NFV ecosystem where several sites can be used to automatically deploy network services. To keep our discussion concrete, we assume that each site maintains an NFV infrastructure, although the L2S platform can also support scenarios where inter-site communications involve multiple NFVIs at a single site. NFV sites may be owned by different infrastructure providers. Consequently, several MANO platforms may be involved in the lifecycle management of network services. The conceptual design of the L2S platform is outlined in Figure 2. The platform provides the abstraction of a layer-2 switch, supporting link-layer connectivity among VNFs deployed on different NFVIs. This layer-2 switch operates as a multi-site network service, with an L2S VNF on every NFVI. Therefore, the deployment of the L2S platform does not require the installation of additional network equipment at the NFV sites. Instead, it can be automatically provisioned as any other network service over the NFV infrastructures, using their corresponding MANO platforms (deployment and configuration aspects are covered in next subsections). The layer-2 switch implemented by the L2S platform presents several access ports at each NFV infrastructure, which can be assigned to different VLANs. In the example of Figure 2, the switch has 6 ports. Ports 1, 3, and 6 are assigned to a VLAN (with identifier 101), whereas ports 2, 4 and 5 belong to another VLAN (identified as 102). Upon the deployment of NS1, VNF1b and VNF1c are connected to ports 1 and 3 of the layer-2 switch. Figure 2: Conceptual design of the L2S platform. That way, both VNFs are connected to the same VLAN, being able to directly exchange MAC frames through the L2S platform. In this specific example, port 6 remains available for subsequent use, e.g., to instantiate new VNFs or migrate existing VNFs of the network service to site C. VNF1a and VNF1d only need connectivity towards VNFs on the same NFVI. Hence the L2S platform is not needed to support their data communications (these communications are enabled through virtual links provided by the VIMs of their respective NFVIs). Analogously, VNF2b, VNF2c, and VNF2d are interconnected at layer-2 through a separate VLAN of the L2S platform. Internally, an L2S VNF encapsulates the MAC frames that receives on each of its access ports into an IP tunnel, which delivers this traffic to every other L2S VNF that has an access port in the same VLAN. These IP tunnels can be implemented existing standard protocols, such as VXLAN [18] (the solution chosen in our implementation of the L2S platform) or GRE [8]. L2S VNFs behave as aggregation points for VNF traffic entering and leaving NFV infrastructures. Consequently, they represent an appropriate location to enforce security policies and protect inter-site VNF communications. The design of L2S relies on existing security solutions to protect the information transmitted within IP tunnels among L2S VNFs, and provide guarantees on confidentiality, integrity, authentication, and non-repudiation. Security solutions could be used at different layers of the TCP/IP protocol stack, e.g., IPsec [7] (the technology used in our implementation), MACSec [23], or layer-2/layer-3 VPNs [20; 24]. This way, inter-site VNF communications are securely provisioned across any potentially untrusted Internet service provider networks that interconnect the NFV sites. We want to highlight that L2S has specifically been designed to provide secure layer-2 connectivity among remote VNFs. Given that our solution is deployed as a composition of VNFs on distributed NFV infrastructures, the security of the L2S platform itself relies on the security policies and mechanisms of the MANO systems involved in the platform deployment.