and Control Element Separation protocol (ForCES) [37], the Control Orchestra-tion Protocol (COP) [98] and the ApplicaOrchestra-tion-Based Network OperaOrchestra-tions (ABNO) [139]. The downside of an abstraction of network control, is that an abstraction can potentially result in a lack of information. Related to the research objectives in the thesis, the current models indicate a lack of a security abstraction, in partic-ular, SFC confidentiality and integrity. This thesis aims to address this problem by investigating the low-level SFC forwarding methods (close to the SBI) in order to identify the attributes needed for making network abstractions.
3.2 SFC forwarding methods (RQ-2)
It was mentioned in the previous section that Munoz et al. [98] have identified dif-ferent SFC technologies and that Hantouti et al. [99] point out that there are many research challenges related to SFC orchestration, such as advanced SFC routing.
Most importantly, there is arguably a need for abstracting metadata about the con-fidentiality and integrity in an SFC. In order to extract this metadata, this research aims to identify the attributes in the existing data plane technologies. Correspond-ingly, this research aims to evaluate the existing SFC technologies towards these research challenges, which in particular includes investigating how secure the cur-rent forwarding mechanisms are and to survey how related research articles aims to solve SFC forwarding on the data plane. This reflects research question 1 and 2, which aim for identifying the security gaps and finding the security requirements.
The related work is split into four categories; (1) SFCs by overlay tunnels, (2) the flow-based approach, (3) stateless segment routing and (4) stateful SFCs.
1 - A full meshed tunnelled overlay network is an "alternative method" of creating an SFC. It is possible to set up all the Virtual Links between every VNF with tunnels (i.e. IPsec [140], LISP [141], GRE [142] or VXLAN [143]). Nakamura et al. [144] suggested such a method by proposing a "Protocol independent FIB architecture for network overlays". However, this approach is not investigated, while it is assumed that the lack of SFC state makes it challenging for the VNFs to choose the correct SFC path. Additionally, the complexity of managing a very high number of tunnels is also assumed to be challenging. However, it is considered as a research opportunity to investigate if the tunnels can be used on an aggregated level, where the tunnels can encapsulate SFC state data [145], such as NSH.
2 - Another method of supporting a data plane SFC is what this thesis refers to as the flow-based approach. This method adopts the principles from SDN OpenFlow and BGP Flowspec [29] and aims to enable SFC forwarding based the attributes of the originating data packet. This implies identifying an SFC-flow based on layer 2, 3 and 4 only. The flow-based approach was clearly represented in the
"STEERING" method by Zang et al. [146]. However, the method lacks attributes to differentiate the SFCs from each other. Blendin et al. [147], Ding et al. [148], Abujoda et al. [149] and Zave et al. [150] aimed to reinterpret existing packet headers and to share SFC information, such as the L2 Ethernet MAC address, the IP option field, the IP Differentiated Services Code Point (DSCP) field or the TCP session field. However, their methods lack the capability of identifying a flow when for example an SF or an SFF change the packet headers (i.e an HTTP proxy). Qazi et al. [151] aimed to solve this problem by the SIMPLE method by processing and correlating the packets in front of the VNF, but the method is complex and the accuracy is questionable. Hence, the need for any additional packet header information about the SFC emerged.
In 2014, Quinn et al. [152] introduced the NSH as a data plane packet header which can contain information about the SFC data path. The protocol is transport independent, meaning that the NSH header can be encapsulated by i.e Ethernet, IP, VXLAN-GPE [39], NVGRE [153] or UDP. In the same year, H. Zhang presented the Service Chain Header [154]. This draft also introduced the roles and com-ponents for the SFC data plane forwarding. These concepts were abstracted by J.Halpern et al. [50] that in 2016 followed up by not adapting the protocol itself, but adopting the concepts of an abstract framework for SFC forwarding, which is the current SFC standard. However, since 2013, there have been many attempts for adapting to the SFC framework [155]. There have historically been two research tracks, namely stateful SFC headers and stateless SFC by segment routing.
3 - Stateless segment routing of SFCs has primarily been driven by the IETF, where they aimed for utilising MPLS [52] and IPv6 [53]. The method does not require any additional underlay network, and it has therefore been attractive for telcos in the 5G domain [156]. Due to its’ lack of state capabilities and the need for a uniform communication protocol across different domains (Chapter: 2.3), it can be challenging to integrate and to achieve flexibility. However, this can be solved by a flexible control plane (Section:3.3). By August 2019, the IETF has endorsed the transport-independent SFC encapsulation scheme of NSH, and they are also encouraging a combination of both segment routing and NSH headers [59].
4 - For stateful SFCs, there have been attempts to overcome the overlay constraint and the overhead in the NSH header. Jacquenet et al. [157] suggested to include an SFC header in the IPv6 extension header. While, in 2018, Hantouti [108] sug-gested to put a compact SFC header encoded in the layer 2 frame. However, most recently, the related research of stateful SFCs involves utilisation of the NSH pro-tocol in different application domains, such as G. Li et al. [158] suggested for optical network. The most related work to the contributions in this thesis, con-cerns multi-domain NFV topologies and packet isolation in SFCs. Here, Kulkarni
3.2. SFC forwarding methods (RQ-2) 47 et al. [159] pointed out scaling issues in NSH in multi-domain topologies. They suggested to scale down NSH, by the use of what they named Neo-NSH. Later, IETF released an RFC in 2018 of hierarchical SFC RFC in 2018 [160] which im-plicitly confirmed the studies from Kulkarni et al. Similarly, in 2019, Hantouti et al. [161] state the benefits of hierarchical SFCs by mentioning scaling, granu-larity and management. Hierarchical SFCs was originally designed to allow the decomposition of network architecture into multiple sub-domains. However, this research in this thesis is aimings to adopt the hierarchical principle into creating granular security domains. Further, from an application domain perspective, this research also aims for creating security function connected to NSH. This is sim-ilar to what Mehmeri et al. [121] suggested in 5G networks. This research in this thesis aims to extend this with security functions in order to support granular isol-ation and encryption. Note: The RFC publicisol-ation of hierarchical NSH [160] was published after research article 3 in this thesis, which also introduced hierarchical NSH. However, the research objective, the content and the application domains in these publications were different to the work in this thesis.
As a reminder of the research challenge; For all these methods it is possible to use one global underlay network, such as an interconnected MPLS EVPN [162] or a Software-Defined Wide Area Network (SD-WAN) with IPsec [163], in order to interconnect the data centre resources into one network domain (Chapter: 2.2.2).
However, it does not solve the SFC forwarding challenge of integrity and isolation.
Openly sharing SFC information in the data packets rises a general security con-cern since this metadata contains sensitive information, which can be modified by intercepting actors. Hence, neither the use of a list of segments nor SFC headers is perceived as secure. This questions the integrity of the NSH packet. The IETF NSH working group has specified an integrity check mechanism [164] to ensure that NSH headers cannot be modified. This NSH header verification was limited to NSH header integrity check only and did not include data encryption. How-ever, the draft is currently expired and the status of the working group [164] is not known. Similarly, Wang et al. [122] have suggested Secure In-Cloud Service Function Chaining (SISC) in order to protect the SFC header by header anonymisa-tion. However, it does not solve the data encryption or integrity problem.
With respect to packet encryption schemes, a very promising research is the Secure EVPN contribution by the IETF [162]. The publication in July 2019 suggests IPsec encryption of layer 2 frames between interconnected data centres. However, the publication does not yet discuss network isolation of the SFCs.