Vir-tualised Switch (OVS) with OpenFlow support [56] which is placed on each Com-pute Node. The SFF forwards SFC packet to other SFFs or to the VNF connected to the Compute Node. In most NFVIs, the SFFs are usually interconnected by tun-nels between every SFF (i.e. IPsec [20], STT [38], VXLAN-GPE [39], GENEVE [40]). In the SFC specification, these tunnels are referred to as transports tunnels.
Note: In this context, the phrase "transport" is not directly associated with the transport layer in the OSI model. Here, this represents a tunnel which transports the SFC packets between the SFFs.
When interconnecting multiple data centres, the topology of these transport tun-nels represent different interconnection methodologies. They can for example span over multiple data centre sites in a common network or they exist in two different administrative domains interconnected by an intermediate edge router. Running an SFC between two data centres using different SFC technologies is therefore challenging. In order to preserve the SFC state of the packet, the data packet must either maintain the SFC header while it crosses the data centre borders, or the packet must be re-classified. However, when encrypting an SFC packet, reclassi-fication and general SFC routing meet a new challenge.
2.3 The SFC encryption challenge
In NFV, the very fundamental concept is that a network packet, arriving from for example an end-user, has to be processed by intermediate middleboxes (VNFs). In many cases, the original data-content in a packet from the end-user is not changed while the packet traverses from one service to another. In order for the packet to be processed by the VNFs, the packet should preferable be non-encrypted (or by using SSL inspection on VNF ingress)1. Hence, the research problem is based on the assumption that end-user data packets are non-encrypted in the SFC. This makes the packets vulnerable for eavesdropping, manipulation and redirection inside the NFV data plane domain.
The approach to solve the problem in this research, is by introducing packet en-cryption and packet integrity checks inside the SFC domain. This is achieved by enabling packet encryption hop by hop, which is collectively perceived as end-to-end encrypted.
The second research objective is access control, which implies to isolate the VNFs from having access to the end-user data packets. This research aims to solve this by encrypting specific data flows across specific VNF hops. Consequently, the VNFs, which do not have access to the data, are bypassed. Regardless of the SFC
1Standard SSL inspection resolves the issue of encrypted SSL packets [57,58].
routing rules, the access list controls where the encryption keys are distributed and what VNF which potentially can access the data. In the research use case, it is defined that the encrypted data is routed through the VNFs.
Figure 2.7:Hop by hop encryption
Hence, this research aims to ensure that the data traffic is secured from eaves-dropping from all unauthorised parties. Figure2.7exemplifies this concept: VNF A can access the HTTP traffic and not Voice over IP (VOIP) traffic, while VNF B can access HTTP traffic, but not VOIP. VNF C has access to both HTTP and VOIP. Currently, this functionality is not supported in the SFC standard from the IETF [50].
It is mentioned previously that combining packet encryption with segment rout-ing or SFC headers is challengrout-ing. This is because packet encryption can hide packet data which is needed for the intermediate switches and routers to forward the packet. However, this highly depends on the technology which is being used to control the packet forwarding.
This problem is demonstrated by showing 5 examples of packet structures (Figure:
2.8). Note: For simplifying reasons, TCP/UDP is included in the IP header block in the Figure.
1. Figure 2.8-1 gives an example of a plain IP packet which is encrypted and contains no SFC header. If the packet is encrypted by IPsec, the SFFs are not capable of steering the packets based on TCP/UDP port. It is neither capable of looking up any SFC state in the packet.
2. Figure 2.8-2 shows an example of an IP packet containing an SFC header.
2.3. The SFC encryption challenge 31
Figure 2.8:Packet encryption strategies
Encrypting the IP packet then also results in encrypting the SFC header and makes it similar to packet example 1.
3. Figure2.8-3 demonstrates how an SFC header can be placed outside the IP header. Here the packet can be routed based on an SFC header. However, there are currently no standards of mapping Ethernet MAC addresses to SFC addresses (such as ARP). Also, when the packet traverses a layer 3 router, the SFC header is potentially lost.
4. Figure2.8-4 shows an example of an outer IP tunnel that encapsulates both the SFC header and the IP header. This simplified packet structure shows how the outer IP tunnel is transporting the packets between the SFFs. Here, the outer IP tunnel is only valid per SFF hop. In such a packet structure, it is possible to apply encryption and isolation measures. Correspondingly, this research aimed to extend this packet structure by applying encryption and isolation capabilities.
5. Figure 2.8-5 gives a similar example to example 4, but here with segment routing being used as a tunnelling mechanism between the SFFs. This prin-ciple is based on a recent draft from, IETF (June 2019) where they proposed to combine the concepts of stateful and stateless SFCs by introducing NSH-based SFC with SR-NSH-based transport tunnel and SR-NSH-based SFC with Integrated NSH Service Plane [59]. This is a new alternative solution to the problem which have not investigated in this research.
The two last examples demonstrate packet structures which makes it possible to apply encryption and integrity checks. It is possible to apply this to both the inner and the outer IP packet. Applying it to the outer tunnel can ensure confidential-ity between every SFF, while encrypting the inner packet hop-by-hop can ensure
confidentiality for the traffic inside an SFC. However, it does not solve the ac-cess control problem within an SFC. Using different encryption keys on different flows within an SFC requires that the different flows also are identifiable in a for-warding perspective. This is because different encrypted packets must be handled by different encrypting functions. In this research, this is referred to as the flow identification problem of encrypted packets (Chapter: 8). Consequently, this in-formation must be extracted from an attribute in a packet header. This research aimed to solve this by adding this information into the SFC header.
In summary, this section has shown the need for stateful SFCs, which includes attributes for identifying encrypted flows for access control. In the context of in-terconnecting multiple data centres, this raises two additional problems.
First, these SFC identifiers are located in the data packets. Correspondingly, the packet header identifiers have to be coordinated across all SFFs and to any relevant encryption function. There must either be a coordinated mapping (stitching) of the identifiers between different domains or they must exist in one domain (overlay).
Second, it calls for synchronising the network configuration on multiple levels.
This includes both the setup of the underlying SFF tunnels, the setup of encryption parameters and the setup of the SFCs. This coordination of network configuration can either be (1) performed on a top-level orchestration level or (2) by an intercon-nected control plane. Both methods question the need for a vertical provisioning of network resources.
These problems reflect research question one, two and three, where there is a need to identify the interconnection method, the requirements and a solution to this problem. Generally, the need for the distribution of advanced network configura-tion calls for centralised control and programmability, which reflects SDN capab-ilities.