BSSN-SDNs: A Blockchain-Based Security Service Negotiation for the SDN Interdomain

Abstract

The security requirements for SDN (Software-Defined Network) cross-domain communication are diverse and dynamically changing; thus, a security service negotiation function is required for the SDN interdomain. However, the SDN interdomain distributed communication environment leads to a lack of trustworthiness and security. Therefore, this paper proposes a blockchain-based SDN interdomain security service negotiation mechanism, BSSN-SDNs, to provide automatic, secure, and trustworthy SDN interdomain security service negotiation. BSSN-SDNs proposes a three-layer reference architecture that enables joint on-chain and off-chain work by extending the security service negotiation module and blockchain client on the controller and deploying security service negotiation smart contracts on the blockchain. It especially adopts non-interactive key exchange and the message authentication code to ensure the confidentiality of the secure service negotiated on-chain. Finally, the timeliness as well as security and trustworthiness of BSSN-SDNs are analyzed, and the FISCO BCOS-based experiment results show that the delay of BSSN-SDNs is acceptable and is positively correlated with the number of policies and the number of SDN domains involved in negotiation.

1. Introduction

Software-defined network (SDN), as one of the most promising future network technologies, has the characteristics of separation of control and forwarding, logical centralization of control, and being open programmable [1]. At present, SDN has been widely deployed on the Internet of Things (IoT), providing a high data transfer rate and efficient network management [2,3,4].

1.1. Motivation

Requirements. With the widespread deployment of IoT, a multi-domain IoT architecture with SDN as the infrastructure has emerged, as shown in Figure 1.

Figure 1. Multi-domain IoT deployed in SDN architecture. Different line types indicate that the data exchange has different security service requirements.

Usually, there is a need for cross-domain data exchange in multi-domain IoT [5]. For example, in the field of smart cities, health data, smart car data, smart meter data, surveillance data, and financial transactions of residents are collected, processed, and exchanged among different organizations. However, these user data are of varying degrees of importance and involve varying user privacy, which requires appropriate security services during cross-organizational data sharing [6]. In the context of smart municipalities, services such as smart water management, smart street lighting, and smart waste treatment are provided for urban management and ensure that these systems operate in a coordinated and effective manner. However, one of the main challenges of smart municipal collaborative services is the security and privacy issues of data sharing faced during interoperability between heterogeneous services [7]. As a further example, in the field of industrial IoT, it is often challenging to have a complete product production process in a single domain. Therefore, it has become a trend to distribute the complete product production process to multiple domains that are closely related. Then, devices distributed in different domains need to share and exchange data using efficient communication mechanisms to collaborate in the production process. However, these data are involved in product parameters, which are usually of some degree of sensitivity, and therefore need to be provided with appropriate security services when shared across domains [8].

As mentioned above, data shared between different organizations is usually of a certain value and high sensitivity. Therefore, different security services are required between organizations depending on the importance and sensitivity of the interactive information. As a result, it is necessary to conduct SDN interdomain security service negotiations.

Challenges. However, SDN interdomain security service negotiation faces the following challenges:

(1)

Compared with SDN intradomain security service negotiation, since there is no unified authoritative center among SDN domains, SDN interdomain security service negotiation lacks trustworthiness; therefore, ensuring the trustworthiness of SDN interdomain security service negotiation is a challenge.

(2)

SDN interdomain environment communication lacks security, so ensuring the security of SDN interdomain security service negotiation is a second challenge.

(3)

Since security requirements are dynamically changing, how to negotiate security services automatically and in a timely manner to adapt to dynamically changing security requirements is a third challenge.

Objectives. In summary, this paper aims to establish automatic, secure, and trustworthy SDN interdomain security service negotiation to protect cross-domain negotiation from unauthorized access (confidentiality), modification (integrity), and falsification (authentication).

1.2. Proposed Solutions

Blockchain technology, with its decentralized, de-trusted, tamper-proof, traceable, and programmable characteristics, can be used to achieve trusted communication in a distributed, untrustworthy environment; in particular, smart contracts provide a method for automatic and transparent business execution [9]. Currently, blockchain technology is widely used in the field of information security to provide security for cross-organizational information sharing and business collaboration [10,11].

Therefore, to address the challenges of SDN interdomain security service negotiation, blockchain technology can be applied to realize automatic, transparent, secure, and traceable interdomain security service negotiation. It should be noted that, since the data on the blockchain chain is publicly accessible, it is important to protect the privacy of secure service negotiations [12,13,14].

In summary, this paper proposes a blockchain-based security service negotiation mechanism for SDN interdomains, BSSN-SDNs, to provide automatic, secure, and trustworthy SDN interdomain security service negotiation.

1.3. Contributions

BSSN-SDNs proposes a three-layer abstract model and enables SDN domains to realize security service negotiation in association with the blockchain by expanding the security service negotiation function and the blockchain client to the SDN controller.

(1)

It utilizes smart contract technology to realize policy publishing, updating, and policy matching to ensure automatic and transparent security service negotiation.

(2)

It adopts a non-interactive key exchange and a message authentication code to ensure the confidentiality of the secure service negotiated on the blockchain.

(3)

It combines the blockchain transaction signature verification mechanism and the simple payment verification function (SPV) for receipt to realize secure and trustworthy security service negotiation in an untrustworthy environment.

(4)

Based on the account state mechanism of blockchain, it realizes automatic updating of policies and ensures the timeliness of policy negotiation; based on the blockchain storage structure, it builds a global and whole-process supervisory view for SDN interdomain security service negotiation.

The rest of this article is organized as follows: Section 2 gives a comprehensive review of related work. Then, Section 3 presents the reference architecture, relevant definitions, theoretical model, functional modules, and workflow of BSSN-SDNs. Section 4 introduces confidentiality protection and smart contracts for secure service negotiation on blockchain. Furthermore, Section 5 analyzes the timeliness and security of BSSN-SDNs and compares them with similar schemes. Finally, the performance evaluation is reported in Section 6, and Section 7 gives the conclusion.

2. Related Work

2.1. SDN-Based IPsec

In traditional networks, IPsec is used to provide on-demand security services at the network layer. However, IPsec in traditional networks is implemented in the kernel of routers or hosts and requires end-to-end manual configuration, which is time-consuming, complicated to operate, and prone to security flaws. Since SDN has a hierarchical structure that separates forwarding and control, some scholars have launched innovative research on how to deploy IPsec in SDN in view of the characteristics of SDN. Gabriel Lopez Millan’s team established an SDN-based IPsec management framework and designed two deployment scenarios—with IKE (Internet Key Exchange) negotiation mode and without IKE negotiation mode [15,16]. P4-IPsec implements an IKE-free IPsec based on programmable data plane technology [17,18]. To improve the utilization efficiency of IPsec virtual gateways on the cloud, Protego proposes a distributed IPsec gateway service that separates the control plane and the data plane of IPsec, stores infrequently updated IKE SAs (Security Associations) centrally in the central controller, and the data plane is responsible for datagram encryption and decryption [19]. S-SDS deploys IPsec by extending the OpenFlow message and flow table fields, where the controller manages the Security Policy Depository (SPD) and the gateway is responsible for IKE negotiation [20]. Due to the possible lack of a bidirectional data plane communication channel between VNFs (Virtual Network Functions) in an SFC (Service Function Chaining), the Internet Security Key Exchange protocol (IPsec-IKE) is not applicable inside a VNF (Virtual Network Function); hence, ref. [21] introduces an alternative to IPsec-IKE that is specifically designed for NFV (Network functions virtualization) environments.

The above scenarios have redesigned the IPsec deployment method and workflow within SDN domains but have not yet been specifically explored for the specific issues of SDN interdomain security service negotiation. In particular, SDN interdomain scenarios across organizations face the following challenges: end-to-end inter-domain security service negotiation faces the security risk of denial and lacks supervision; if the security service negotiation and data forwarding are in the same plane, the encryption and authentication during the negotiation and the forwarding of negotiation messages will occupy the computation and bandwidth resources in the data plane, which will affect the forwarding latency and efficiency of the data plane and is inconsistent with the original intent of the SDN data plane for simple and fast forwarding. Therefore, a security service negotiation scheme needs to be proposed specifically for the SDN interdomain.

2.2. SDN Multi-Domain Organization Architecture

Currently, SDN multidomain organization architectures mainly include vertical and horizontal architectures [22]. For security service negotiation among multiple SDN organizations, if a vertical architecture is adopted and a super central controller manages the security service negotiation, the centralized cross-organizational management will face the management transparency problem and the single-point-of-failure problem; if a horizontally distributed architecture is adopted to negotiate the security services through the east-west interfaces of the controllers, it will be difficult to form a global supervisory view, and thus both of them have root cause deficiencies.

Therefore, a new SDN multi-domain organizational architecture needs to be designed for SDN interdomain secure service negotiation.

2.3. Blockchain Applications in SDN

In recent years, blockchain-based SDN security schemes have also been gradually proposed. For example, the scheme for cross-domain forwarding path control has high real-time requirements, so the scheme deploys the blockchain function directly as a controller extension application, deployed locally in the SDN [23]; the scheme for SDN flow table validation deploys the blockchain network between the control layer and the data layer in order to store and validate the flow table [24]; and the scheme for cross-domain access control implements complex authentication algorithms based on the blockchain in order to authenticate endpoint identify or user identity attributes [25,26]. However, the above schemes have not yet proposed a specialized solution for the blockchain-based SDN interdomain security service negotiation problem.

Given the above, it is necessary to design an SDN interdomain secure service negotiation mechanism to ensure a transparent, secure, and trustworthy negotiation process.

3. Overview of BSSN-SDNs

3.1. Threat Models of Security Service Negotiation in the SDN Interdomain

Since SDN interdomain security service negotiation is in a distributed, untrustworthy communication environment, it faces several security threats. To be able to clearly articulate the security threats that can be mitigated by BSSN-SDNs, the SDN inter-domain security service negotiation threat model is therefore described.

Firstly, to facilitate the illustration of security threats, they are categorized into the following three scenarios, depending on the location of the security service negotiation.

3.1.1. Security Service Negotiation Based on Data Plane

If security services are negotiated through end-to-end interactions in the data plane, then it is possible to face attacks from malicious or compromised endpoints or forwarding devices in the data plane. The threat model of security service negotiation based on the data plane is shown in Figure 2.

Figure 2. Threat model of security service negotiation based on data plane.

The threat model is as follows:

(1)

Eavesdropping security services: compromised or malicious forwarding nodes in the intradomain paths or switching nodes in the interdomain paths may eavesdrop on the negotiated security services.

(2)

Tampering security services: the compromised or malicious forwarding nodes in the intradomain paths or switching nodes in the interdomain paths are likely to tamper with the negotiated security services.

(3)

Identity forgery: all three types of adversaries may use a spoofed identity to send forged security service negotiation messages.

(4)

Security service negotiation message replay attack: all three types of adversaries are likely to replay security service messages.

The above is based on the following security assumptions.

(1)

Control plane is safe and secure.

(2)

Control plane to data plane southbound interface communication is secure.

(3)

Data plane packets are forwarded without facing malicious drops or path changes.

3.1.2. Security Service Negotiation Based on Control Plane

If the SDN multi-domain organization uses a horizontal architecture for inter-domain management, where each domain controller negotiates security services through the control plane east-west interfaces, then it may be exposed to attacks from malicious or compromised control plane devices. The threat model of security service negotiation based on the control plane is shown in Figure 3.

Figure 3. Threat model of security service negotiation based on control plane.

The threat model is as follows:

(1)

Eavesdropping security services: the compromised or malicious network nodes on the east-west links may eavesdrop on the negotiated security services.

(2)

Tampering security services: the compromised or malicious network nodes on the east-west links are likely to tamper with the negotiated security services.

(3)

Identity forgery: both types of adversaries may use a spoofed identity to send forged security service negotiation messages.

(4)

Security service negotiation message replay attack: both types of adversaries are likely to replay security service messages.

The above is based on the following security assumptions:

(1)

The control plane for each domain is reliable.

(2)

The communication within the control plane of a single domain is secure and trustworthy.

(3)

Control plane to data plane southbound interface communication is secure.

3.1.3. Security Service Negotiation Based on the Super Control Center

If the SDN multi-domain organization uses a vertical architecture for interdomain management, where the domains negotiate centrally by uploading security service negotiation messages to the super control center, then it may face attacks from the compromised super control center or the malicious devices on their links. The threat model of security service negotiation based on the super control center is shown in Figure 4.

Figure 4. Threat model of security service negotiation based on the super control center.

The threat model is as follows.

(1)

Eavesdropping security services: the network nodes on the links between the super control center and the domains may eavesdrop on the negotiated security services.

(2)

Tampering security services: the network nodes on the links between the super control center and the domains are likely to tamper with the negotiated security services.

(3)

Identity forgery: malicious or compromised domain controllers and network nodes on the links between the center and domain controllers may use a spoofed identity to send forged security service negotiation messages.

(4)

Security service negotiation message replay attack: malicious or compromised domain controllers and network nodes on the links between the center and domain controllers are likely to replay security service messages.

(5)

Management transparency and single points of failure: the compromised control center may confront problems of management transparency and single points of failure.

The above is based on the following security assumptions.

(1)

The control plane for each domain is reliable.

(2)

Communication within the control plane of a single domain is secure and trustworthy.

(3)

Control plane to data plane southbound interface communication is secure.

3.2. Reference Architecture of BSSN-SDNs

In order to address the security threats faced in the above scenarios, BSSN-SDNs were proposed. The theoretical framework of BSSN-SDNs can be represented by a three-layer hierarchical model, which has a blockchain management layer, control logic layer, and data forwarding layer, as shown in Figure 5.

Figure 5. The reference architecture of BSSN-SDNs.

(1)

The blockchain management layer provides the security service negotiation function for the SDN interdomain communication, which mainly includes the security policy publication and update and the security service negotiation. The blockchain management layer is given as a logical schematic of a blockchain whose physical structure is a peer-to-peer network consisting of ledger nodes.

(2)

The control logic layer contains the original SDN controller, the extended security service negotiation functions $\mathit{SSN}$ and the blockchain client $BlockApp$. The SDN controller interacts with the blockchain through the blockchain client, including transaction upload and receipt verification. The WE-bridge is an east-west interface for SDN controllers to interact with interdomain network topology.

(3)

The data-forwarding layer corresponds to the SDN data plane. The controller issues security services to the border switches in the data forwarding layer through the southbound interface. The border switch performs the corresponding security service for data packets based on the negotiated security service database $\mathit{NSSD}$. Then, the data packets with encapsulated security service identifiers are forwarded downstream by matching the OpenFlow flow table.

Regarding how the controller issues security services down to the data plane, reference can be made to the literature [15,16], where the controller configures $\mathit{NSSD}$ the border switches through the YANG model based on the southbound protocol NETCONF. Alternatively, reference can be made to the literature [17,18], using the protocol-independent programmable switches P4 as the border switches and configuring $\mathit{NSSD}$ the P4 switches through Runtime.

(4)

The connections between the blockchain client and the blockchain, as well as among the domain border gateway switches, are via traditional networks.

(5)

Within a single SDN domain, to enhance the resilience of the system and mitigate the single point of failure issue, multiple control nodes can be deployed on the control plane using distributed caches, like Redis, to implement active-standby or even multi-active configurations.

(6)

To guarantee the normal transmission of data within the SDN domain, it is presumed that the interactions within the control plane are secure and trusted and that the communication between the controller plane and the data plane is secure and trusted.

Since the scalability, reliability, consistency, and security of the control plane are important research aspects of SND but not the focus of this paper, further discussion on the control plane can be found in the literature [27,28,29].

3.3. Definitions Related to BSSN-SDNs

Definition 1.

Security Services (SS). It is described using a triple $⟨\mathit{sec}, \mathit{enc}, \mathit{hash}⟩$, where $\mathit{sec}$ denotes a security protocol, $\mathit{enc}$ denotes a cryptographic algorithm, and $\mathit{hash}$ denotes a hashing algorithm. For example, $\mathit{sec}$ can be a security protocol customized within the federation to ensure authentication and confidentiality of communications; $\mathit{enc}$ is the encryption algorithm selected in the protocol, for example, it can be DES, 3DES; and $\mathit{hash}$ is the hashing algorithm selected in the protocol, for example, MD5, SHA-256, etc.

Definition 2.

Security Policy (SP). It is described using $⟨S_{acc}{,D}_{acc},\mathit{Selector}, [{\mathit{SS}}_i{,P}_{S{S}_i}]⟩$, where $S_{acc}$ and $D_{acc}$ denote the blockchain account addresses of the source domain and the destination domain, respectively; $\mathit{Selector}$ describes communication characteristics, such as using $⟨i{p}_S,i{p}_D,transProtocol,por{t}_S,por{t}_D,confLevel⟩$ to specify the source IP address, destination IP address, transport layer protocol, source port number, destination port number, and data sensitivity level of communication data; ${\mathit{SS}}_i$ and $P_{S{S}_i}$ represent the $ith$ optional security service and the corresponding priority accordingly, which have been sorted by priority from highest to lowest by default; and the symbol $[]$ denotes that zero, one, or more contained data units are allowed.

Definition 3.

Secret State Security Service (HSS). Since the data on the chain is publicly available, the security services uploaded to the blockchain should be in a secret state in order to ensure the confidentiality of the negotiated security services. $HSS=HMA{C}_{{\widehat{K}}_{S,D}}(SS,{\widehat{K}}_{S,D})$, where ${\widehat{K}}_{S,D}$ is the shared key of the source domain and destination domain, and $HMAC()$ is the message authentication code function.

Definition 4.

Secret State Security Policy (HSP). It is described using $⟨S_{acc}{, D}_{acc}, \mathit{Selector}, [H{\mathit{SS}}_i{,P}_{S{S}_i}]⟩$. That is, the security services in the security policy are replaced with the secret state security services.

Definition 5.

Negotiated Security Service (NSS). It describes the negotiated plaintext security service. $NSS=⟨S_{acc}{, D}_{acc}, \mathit{Selector}, \mathit{SS}⟩$.

3.4. Theoretical Model of BSSN-SDNs

The theoretical model of BSSN-SDNs can be formalized as a six-tuple, where: $⟨\mathit{SDN}, \mathit{BlockNet}, \mathit{Trans}, \mathit{SC}, \mathit{Receipt}, \mathit{operation}⟩$, where:

(1)

$\mathit{SDN}$ indicates the SDN domains involved in security service negotiation.

(2)

$\mathit{BlockNet}$ denotes the federated blockchain, which is jointly maintained by the SDN domains.

(3)

$\mathit{Trans}$ denotes the transaction, specifically the security service negotiation transaction $\mathit{SSNTrans}$. It contains $⟨{\mathit{id}, \mathit{tp}, S}_{acc}{, \mathit{HSPset}}_S, \mathit{sign}⟩$, where $\mathit{id}$ represents the transaction identifier, $\mathit{tp}$ represents the timestamp, $S_{acc}$ is the blockchain account address of the domain uploading this transaction, the $\mathit{sign}$ is the signature of the account on the transaction, ${\mathit{HSPset}}_S$ represents the secret state security policy set formulated by the source domain $S_{acc}$.

(4)

$\mathit{SC}$ denotes the smart contract, specifically the security service negotiation smart contract $\mathit{SSN}\text{\_}\mathit{SC}$. After the successful deployment of the smart contract, once the system meets the trigger conditions, $\mathit{SSN}\text{\_}\mathit{SC}$ will be automatically executed, which ensures that the security service negotiation process is automatic and transparent.

(5)

$\mathit{Receipt}$. After the security service negotiation smart contract $\mathit{SSN}\text{\_}\mathit{SC}$ achieves the negotiation result, it issues the secret state security service receipt $\mathit{HSSReceipt}$ to the relevant source domain and the destination domain. $\mathit{HSSReceipt}$ contains $⟨S_{acc}{, D}_{acc}, \mathit{Selector}, H\mathit{SS}⟩$.

(6)

$\mathit{operation}$ indicates the operations involved in $\mathit{SDN}$, $\mathit{BlockNet}$ and the interaction between the two. Concretely, this includes uploading the transaction (upload), issuing the receipt (issue), formulating a local security policy (write), encrypting the security policy using a message authentication code (encrypt), publishing the secret state security policy (publish), updating the secret state security policy (update), matching the secret state security policy (match), validating the receipt (which can be conducted using a simple payment verification, SPV), and mapping the secret state security services to plaintext security services (map), etc.

3.5. Functional Module of BSSN-SDNs

BSSN-SDNs extended the functionality of the SDN controller by adding a security service negotiation module $\mathit{SSN}$ and a blockchain client $BlockApp$, and deployed a customized security service negotiation smart contract $\mathit{SSN}\text{\_}\mathit{SC}$ on the blockchain. The functional module is shown in Figure 6. $\mathit{SSN}$ contains a local security policy database and a security service negotiation engine. $BlockApp$, as the blockchain client in the SDN domain contains the smart contract invocation function and the simple payment verification function (SPV) for receipts.

Figure 6. The function model of BSSN-SDNs.

The main functions of each module are as follows:

(1)

$SSN$: Write the security policies formulated by the administrator into the local policy repository through the security service negotiation engine; use the $HMAC()$ to generate that newly formulated security policies into secret state security policies and submit them to the smart contract invocation model; as well as match the ciphertext security policy with the receipt $\mathit{HSSReceipt}$ to obtain the corresponding plaintext security service and issue them to the controller.

(2)

$BlockApp$: The smart contract invocation module encapsulates the secret state security policy into a security service negotiation transaction $\mathit{SSNTrans}$ and uploads it to the blockchain, and performs SPV validation on the secret state security service receipts $\mathit{HSSReceipt}$ which issued by the blockchain.

(3)

$BlockNet$: The blockchain $BlockNet$ receives the security service negotiation transaction $\mathit{SSNTrans}$ and verifies the signature of the transaction; the legitimate transaction will automatically trigger the execution of the security service negotiation smart contract $\mathit{SSN}\text{\_}\mathit{SC}$, realize the policy publishing and updating, and the interdomain secret state policy matching, and write the published and updated policies into the security policy ledger through the consensus mechanism; and it sends the matched secret state security service to the relevant SDN domains through the $\mathit{HSSReceipt}$.

(4)

The controller can send the negotiated security services to the data plane through the southbound interface. In addition, the controller calculates the forwarding path based on the inter-domain topology obtained by the WE-Bridge and the intra-domain topology and sends the forwarding paths down to the data plane.

(5)

The data plane performs encryption and decryption operations for incoming data flow according to the security service parameters in $\mathit{NSSD}$, thus providing on-demand security services for SDN interdomain communication, and forwards the data flow based on the forwarding table.

3.6. Workflow of BSSN-SDNs

The workflow of BSSN-SDNs is shown in Figure 7, where ${\mathit{SDN}}_S$ and ${\mathit{SDN}}_D$ denote a source domain and a destination domain participating in the interdomain security service negotiation in the federation chain, respectively, and $\mathit{BlockNet}$ represent the blockchain network. The overall workflow involves the following three main phases:

Figure 7. The overall workflow of BSSN-SDNs.

(1)

Security Policy Preprocessing Phase. Each SDN domain formulates the security policy from this domain to other domains and encrypts the security policy into a secret state security policy employing $HMAC()$.

(2)

Security Service Negotiation Phase. Firstly, each SDN domain uploads the secret state security policy to the blockchain through the security service negotiation transaction $\mathit{SSNTrans}$, and then triggers the security service negotiation smart contract $\mathit{SSN}\text{\_}\mathit{SC}$ to automatically execute the secret state security policy publishing, updating, and matching, and finally sends the results of the security service negotiation to the relevant SDN domains through the secret state security service receipts $\mathit{HSSReceipt}$.

(3)

Security Service Acquisition Phase. The blockchain clients within the SDN domain use SPV to verify the secret state security service receipts. If the verification is approved, the security service negotiation engine will map the ciphertext security policy in the receipt $\mathit{HSSReceipt}$ to the corresponding plaintext security service, thus acquiring the negotiated security service.

Figure 8 presents a schematic diagram of the transformation of the security service negotiation data during processing.

Figure 8. The transformation of the security service negotiation data.

Firstly, the security service negotiation engine encrypts the plaintext of the security policy $SP=⟨S_{acc}{,D}_{acc},\mathit{Selector}, [{\mathit{SS}}_i{,P}_{S{S}_i}]⟩$ defined by the manager into a secret state security policy $HSP=⟨S_{acc}{, D}_{acc}, \mathit{Selector}, [H{\mathit{SS}}_i{,P}_{S{S}_i}]⟩$.

Then, $HSP$ is encapsulated as $SSNTrans$ and uploaded to the blockchain. After blockchain negotiation, the security service receipt $HSSR\mathit{eceipt}=⟨S_{acc}{, D}_{acc}, \mathit{Selector}, H\mathit{SS}⟩$ is issued.

After the receipt is verified and passed, the security service engine matches the secret state security policy $HSP$ according to the receipt $HSSR\mathit{eceipt}$, thus mapping to the corresponding plaintext security policy $SP$, and obtaining the negotiated security service $NSS=⟨S_{acc}{, D}_{acc}, \mathit{Selector}, \mathit{SS}⟩$.

4. Security Service Negotiation on Blockchain

4.1. Confidentiality Protection for Security Service Negotiation on Blockchain

Since the information on the chain is publicly available but the security service negotiation needs to guarantee the confidentiality of the negotiated content, BSSN-SDNs assigns public-private key pairs $⟨Q_{ID}{,S}_{ID}⟩$ to each domain based on He-IBS (an identity-based signature mechanism). He-IBS generates the master private keys $s$ by the key generation center and discloses the system parameters $⟨G_1{, G}_2, \widehat{e}, P, P_{pub}, H, h⟩$ [30]. Equation (1) and Equation (2) respectively describe the public-private key pairs generated for the source domain $S$ and the destination domain $D$, and the bilinear pair computation shown in Equation (3) is used to realize the non-interactive SDN interdomain key negotiation to obtain the shared key ${\widehat{K}}_{S,D}$ of the source and destination domains.

$$⟨Q_{I{D}_S}{, S}_{I{D}_S}⟩=⟨h(I{D}_S), \mathit{sh}(I{D}_S)⟩$$

(1)

$$⟨Q_{I{D}_D}{, S}_{I{D}_D}⟩=⟨h(I{D}_D), \mathit{sh}(I{D}_D)⟩$$

(2)

$${\widehat{K}}_{S,D}=\widehat{e}\left(S_{I{D}_S}{,Q}_{I{D}_D}\right)=\widehat{e}\left(S_{I{D}_D}{,Q}_{I{D}_S}\right)$$

(3)

Here $Q_{I{D}_S}$ and $S_{I{D}_s}$ are the public and private keys of the source domain, and $Q_{I{D}_D}$ and $S_{I{D}_D}$ are the public and private keys of the destination domain.

The domain administrator formulates security policies from this domain to other domains and writes them to the local policy repository. When the submission of the security policy is confirmed, the security service negotiation engine automatically encrypts the security services in the security policy into the corresponding secret state security services ${HSS}_i$ and reassembles them into a secret state security policy ${HSP}_{S,D}$, and finally submits the set of encrypted security policies set ${HSPset}_S$ to the blockchain client, as shown in Equations (4)–(6).

$$HS{S}_i=HMA{C}_{{\stackrel{⌢}{k}}_{S,D}}(S{S}_i, {\stackrel{⌢}{k}}_{S,D})$$

(4)

$$HS{P}_{S,D}=⟨S_{acc},D_{acc},\underset{j}{\cup }(Selecto{r}_j,[HS{S}_i,P_{S{S}_i}])⟩$$

(5)

$${HSPset}_S=\underset{k}{\cup }HS{P}_{S,D_k}$$

(6)

Here $i$ denotes the serial number of a security service in a security policy and $j$ denotes the serial number of a security policy in the policy set of this domain.

4.2. Smart Contracts for Security Service Negotiation on Blockchain

After the blockchain receives the transaction $\mathit{SSNTrans}$ uploaded by the blockchain client of an SDN domain, it first verifies the transaction signature. And after it passes the verification, it submits the security service policies set $HSP{\mathit{set}}_S$ in the $\mathit{SSNTrans}$ to the security service negotiation smart contract $\mathit{SSN}\text{\_}\mathit{SC}$, to execute the interdomain security service negotiation of SND based on the blockchain.

The customized security service negotiation smart contract $\mathit{SSN}\text{\_}\mathit{SC}$ on the blockchain is shown in Algorithm 1. It is primarily responsible for enforcing the secret state security policies, publishing, updating, and matching. $\mathit{SSN}\text{\_}\mathit{SC}$ receives the set of secret state security policies submitted by each domain as input and outputs the result of security service negotiation. It works in the following main steps.

(1)

For each secret state security policy $HS{P}_i=⟨S_{acc}{, D}_{acc}, \mathit{Selector}, [H{\mathit{SS}}_i{,P}_{S{S}_i}]⟩$ in the security policy set $HSP{\mathit{set}}_S$, obtain its domain identifications $⟨S_{acc},D_{acc}⟩$ in $HS{P}_i$, and obtain its serial number $⟨S_{id},D_{id}⟩$ according to the domain identifications, then write the policy $HS{P}_i$ into ${\mathit{HSPstore}}_S[D_{id}]$ which is the corresponding security policy storage unit of the SDN domain $S_{acc}$ in the blockchain ledger. (steps 2–9).

(2)

Obtain the corresponding secret state security policy formulated by the destination domain $D_{acc}$ from the security policy storage unit ${\mathit{HSPstore}}_D[S_{id}]$, then write it to a temporary variable $HS{P}_{temp}$. (step 10).

(3)

If $HS{P}_{temp}$ is not empty, then the secret state security policies $HS{P}_{temp}$ and $HS{P}_i$ are both sorted in descending order of security service priority (steps 11–13). And a match between $HS{P}_{temp}$ and $HS{P}_i$ will be performed in steps 14–28.

(4)

The temporary variable mark is used to record the existence of a matching security service. (step 14).

(5)

For each security service in $HS{P}_{temp}$, starting from the highest priority, match each security service in $HS{P}_i$ in turn, and if there is a match, write it to the matched set of security policies $HSPse{t}_{match}$ and end the two-layer loop, otherwise, until the two-layer traversal is completed. (steps 15–28).

(6)

If the destination domain’s secret security policy on $⟨S_{acc},D_{acc},Selector⟩$ is empty, or there is no matching security service in the security policies of the source and destination domains, no operation will be performed on $HSPse{t}_{match}$. (steps 29–30).

(7)

When each policy in the set $HSPse{t}_S$ has completed the above processing, the set of matched security policies $HSPse{t}_{match}$ is returned. (step 31).

$HSPse{t}_{match}$ contains a collection of secret state security services obtained by security policy matching, that is $[⟨S_{acc}{,D}_{acc},\mathit{Selector},H\mathit{SS}⟩]$. The blockchain organizes each secret state security service in $HSPse{t}_{match}$ into a secret security service receipt $\mathit{HSSReceipt}$ and sends them to the relevant source domain $S_{acc}$ and destination domain $D_{acc}$.

Algorithm 1 $\mathit{SSN}\text{\_}\mathit{SC}$

Input: $HSPse{t}_S$;

Output: $HSPse{t}_{match}$;

1: $HS{P}_{temp}=\varnothing$;

2: for $HS{P}_i$ in $HSPse{t}_S$

3:   $⟨S_{acc},D_{acc}⟩\leftarrow HS{P}_{temp}.getAcc()$

4:   $⟨S_{id},D_{id}⟩\leftarrow ⟨S_{acc},D_{acc}⟩.getID()$

5:   if ${\mathit{HSPstore}}_S⟨D_{id},Selector⟩$ is null

6:     publish $HS{P}_i$ in ${\mathit{HSPstore}}_S⟨D_{id},Selector⟩$

7:   else

8:     update ${\mathit{HSPstore}}_S⟨D_{id},Selector⟩$ by $HS{P}_i$

9:   end if

10:   $HS{P}_{temp}\leftarrow {\mathit{HSPstore}}_D.\mathit{getHSP} (S_{id},Selector)$

11:   if $HS{P}_{temp}!=\varnothing$

12:     $HS{P}_{temp}.rank(Priority)$

13:     $HS{P}_i.rank(Priority)$

14:     mark = 0

15:     for $HS{S}_j$ in $HS{P}_{temp}$

16:       for $HS{S}_k$ in $HS{P}_i$

17:         if $HS{S}_j$==$HS{S}_k$

18:           $HSPse{t}_{match}[⟨S_{acc},D_{acc}, \mathit{Selector}⟩]\leftarrow {\mathit{HSS}}_k$

19:           mark++

20:           break

21:         else

22:           continue

23:         end if

24:       end for

25:       if mark !=0

26:         break

27:       end if

28:     end for

29:   end if

30: end for

31: return $HSPse{t}_{match}$

5. Discussions

5.1. Timeliness of Security Service Negotiation for BSSN-SDNs

BSSN-SDNs can realize automatic updating of policies and ensure the timeliness of security service negotiation. According to the account state mechanism of blockchain, there are ${\delta }_{t+1}=\gamma \left({\delta }_t,T\right)$, where ${\delta }_t$ is the account state of a smart contract at time $t$, $T$ is a transaction that has been consensus of the blockchain nodes, and $\gamma$ is the state transition function triggered by the transaction $T$, thus the account state mechanism makes a transaction update the account state of its related smart contract [31]. Similarly, in BSSN-SDNs, assuming ${\eta }_t$ is the security policy set of domain $acc$ stored in the $\mathit{SSN}\text{\_}\mathit{SC}$ account at the moment $t$. When domain $acc$ uploads a new security service negotiation transaction $SSNTran{s}_{acc}$ to update its policies, $\mathit{SSN}\text{\_}\mathit{SC}$ executes $SSNTran{s}_{acc}$ and consensus confirms it, the security policy set of domain $acc$ in the $\mathit{SSN}\text{\_}\mathit{SC}$ account is automatically updated to the current newest policy set ${\eta }_{t+1}$, that is ${\eta }_{t+1}=\gamma \left({\eta }_t,SPNTran{s}_{acc}\right)$. By analogy, BSSN-SDNs ensure that the set of security policies of each SDN domain on the chain is always kept current and up-to-date. Also, since the security service receipts are based on the most up-to-date security policy matching results, the BSSN-SDNs guarantee the timeliness of the security service negotiation results.

5.2. Security and Trustworthiness of Security Service Negotiation for BSSN-SDNs

To discuss the security and trustworthiness of BSSN-SDNs, we can review the threat model described in Section 3.1. And assumes that the BSSN-SDNs are deployed in open, untrusted, and decentralized SDN interdomain environments. The control plane in each domain is reliable, the interactions within the control plane are secure and trusted, and the southbound communication between the controller plane and the data plane is secure and trusted.

Figure 9 gives the security measures taken by the BSSN-SDNs during the security service negotiation process. Then we consider the following threats.

Figure 9. The security measures taken by the BSSN-SDNs.

(1)

Eavesdropping attack.

In the process of (a)–(e), the security service is uploaded, matched, and issued completely in ciphertext so that eavesdropping attacks can be prevented during the negotiation process.

(2)

Tampering attack.

As shown in step (b), the uploading process can detect tampering because the transaction containing the secret state security policy is signed when it is uploaded to the blockchain, and the blockchain verifies the signature after receiving the transaction. As shown in step (c), since the consensus mechanism is used in the on-chain negotiation process, the on-chain negotiation process can detect tampering. As shown in step (d), the blockchain sends down the negotiated secret security service in the form of receipts to the $BlockApp$ within the SDN domain. The $BlockApp$ uses the SPV to verify the receipt, so the issuing process can detect tampering. In summary, BSSN-SDNs have the ability to detect tampering.

(3)

Identity forgery.

As shown in step (b), it is necessary to sign the uploaded transactions with the domain’s private key, so BSSN-SDNs prevent malicious or compromised controllers from uploading false transactions with forged identities.

(4)

Replay attacks.

As shown in step (b), since the signature mechanism includes timestamps when uploading the blockchain, it is possible to detect malicious or compromised controllers launching replay message attacks to the blockchain.

(5)

Management transparency and single point of failure.

Since security services are negotiated using the consortium blockchain co-managed by the SDN domains, the negotiation process mitigates the single point of failure and management transparency issues.

As mentioned above, BSSN-SDNs help to ensure confidentiality, integrity, authenticity, and anti-replay attacks and mitigate single points of failure and management transparency problems. Therefore, BSSN-SDNs is an SDN interdomain security service negotiation scheme with security and trustworthiness.

When SDN inter-domain security service negotiation has higher security requirements, further security measures are required. For example, in addition to protecting the confidentiality of the negotiated content, the privacy of the negotiating party’s identity needs to be protected. Especially when a more serious security threat, a global adversary, is encountered, the communication needs to be guaranteed to be anonymous to protect true privacy. For example, [32] is an enhanced anonymous communication scheme that has the advantage over Tor [33] of protecting sender anonymity and relationship anonymity and can be applied to traditional IPsec, data-plane-based, or control-layer-based inter-domain secure service negotiation for the SDN interdomain. For the blockchain-based SDN inter-domain secure service negotiation proposed in this paper, to provide privacy protection, techniques such as zero-knowledge proofs, homomorphic encryption, ring signatures, and attribute cryptosystems can be used to protect the anonymity of the negotiating parties.

5.3. Comparison of BSSN-SDNs with Similar Schemes

Compare BSSN-SDNs with the following security service negotiation schemes, as shown in Table 1.

Table 1. Comparison of BSSN-SDNs with similar schemes.

Scheme	IPsec	Open vSwitch	[15,16]		[19]	[21]	BSSN-SDNs
Application Scenarios	legacy network	SDN	SDN intradomain		between legacy network and SDN	SDN with NVF	SDN interdomain
Deployment Locations	host or router	host or OVS switch	SDN controller and SDN border switch		SDN controller and data plane	SDN controller and VNF nodes	SDN and blockchain
IKE SA negotiation	✓ 1	✓	✓	✗ 2	✓	✗	✗
IPsec SA negotiation	✓	✓	✓	✗	✓	✗	✓
where to negotiate?	host or router	host or OVS switch	host or switch	SDN controller issue	SDN controller with host in legacy network	SDN controller issue to peer VNFs	smart contract on blockchain

¹ The symbol “✓” indicates that the scheme conducts the corresponding negotiations. ² The symbol “✗” indicates that the scheme does not conduct the corresponding negotiations.

Firstly, it can be found that most of the schemes are applied in traditional networks (such as IPsec) or within SDN domains (such as [15,16]), while BSSN-SDNs are applied in SDN multi-domains.

Secondly, the end-to-end manual configuration of security parameters used by IPsec and OVS is an error-prone and non-scalable task, especially for SDN inter-domain cross-organization scenarios.

Thirdly, to ensure the security of security service negotiation, the following schemes either require two-phase negotiation, such as using IKE SA negotiation to ensure the security of IPsec SA negotiation, or the IPsec SA is directly issued by the controller, which sacrifices the personalized security service negotiation among endpoints. However, in BSSN-SDNs, blockchain naturally guarantees the security and trustworthiness of SDN interdomain security services negotiation, which avoids an additional round of negotiation specifically to ensure the security of security service negotiation. At the same time, BSSN-SDNs provide personalized negotiations based on the security requirements of the negotiators.

Finally, in a multi-domain environment, combining SDN with blockchain to solve cross-domain problems is advantageous. Because SDN is logically centralized compared to traditional networks, the SDN controllers in each domain have a global view and global control capability. Interaction with blockchain nodes through SDN controllers can facilitate the implementation of required functions, such as the SDN interdomain security service negotiation in this scheme.

6. Experiments and Evaluation

The experiments evaluate the performance of BSSN-SDNs in two aspects: the performance of blockchain-based security service negotiation and the performance of secure service negotiation for the SDN interdomain.

6.1. Simulation Setup

In order to verify the performance of BSSN-SDNs, we utilized Mininet to build the simulated SDN multi-domain environment. Then we adopt Floodlight as the controller and develop the secure service negotiation function and the $BlockApp$ function as the controller applications. In addition, we deploy the FISCO BCOS [34] as the blockchain node function. FISCO BCOS is an open-source consortium blockchain platform, which fits well with the BSSN-SDNs. The secure service policies are transmitted and stored in JSON file format. The experiments are conducted on an Ubuntu 18.04 system on a VMware Workstation 15 Pro virtual machine. The host is configured with an Intel Core i7-10750H 2.6 GHz CPU and 32 GB of RAM.

The topology is built as shown in Figure 10. Six SDN domains are connected sequentially, with four switches in the data plane of each domain.

Figure 10. The experimental topology for BSSN-SDNs.

6.2. Experimental Results

6.2.1. Performance Evaluation of Blockchain-Based Security Service Negotiations

• Task 1: Time overhead of blockchain-based security service negotiation

This experiment tested the time consumed by the blockchain to execute secure service negotiation when uploading different numbers of secure service policies in batches. Each transaction in the experiment contains 10 policies, and the block timeout is set to 1 s. Moreover, BPFC-SDNs implement cross-domain forwarding control policy sharing based on blockchain. It solves the problems of cross-domain policy agnosticism and policy conflict for SDN inter-domain forwarding control by issuing the global shared policy to each SDN domain and achieving cross-domain policy collaboration by each domain controller. Meanwhile, blockchain-based technology ensures the security and trustworthiness of the policy collaboration process [23]. Because the performance of block-chain-based forwarding control policy sharing was tested in BPFC-SDNs, BPFC-SDNs is used as a comparison scheme for BSSN-SDNs to compare and analyze the time overhead of blockchain-based task execution between the two. The experimental results are shown in Figure 11.

Figure 11. The time overhead of blockchain-based secure service negotiation.

The experimental results in Figure 11 show that as the number of security service policies uploaded in batches goes from 500 to 2000, the time for the blockchain to complete the security service negotiation in BSSN-SDNs rises slowly from about 1.2 s to about 1.83 s, and when the number of policies uploaded in batches reaches 2500, the negotiation time rises steeply to about 3 s. This is because, compared to batch up-loading 2000 policies, batch uploading 2500 policies requires the generation of a new block, at which point the waiting time for generating a new block brings a significant increase in the negotiation time.

In addition, it can be seen in Figure 11 that for batch uploading the same number of policies, the blockchain execution time of BSSN-SDNs is longer than that of BPFC-SDNs. This is because in BPFC-SDNs, the blockchain policy management smart contract only performs policy publishing, and its smart contract has a time complexity of O(n), whereas the security service negotiation smart contract in BSSN-SDNs needs to perform policy matching in addition to performing policy publishing, and its smart contract has a time complexity of O(Cn) (1 ≤ C ≤ 2). Therefore, when the same number of policies are uploaded, the blockchain-based execution time in BSSN-SDNs is longer than that in BPFC-SDNs. But it can be found that the core of BPFC-SDNs is forwarding control, whose main function is to control data forwarding based on policies by the controller when the data flow arrives, while the core of BSSN-SDNs is security service negotiation, whose main function is to complete the security service negotiation by the blockchain before the data flow arrives. Therefore, the time spent on blockchain-based security service negotiation in BSSN-SDNs hardly affects data forwarding, so although the overhead of BSSN-SDNs is longer than that of BPFC-SDNs, it is acceptable.

• Task 2: the throughput and average time overhead of blockchain-based secure service negotiation

Figure 12 and Figure 13 show the average time overhead for blockchain to complete a security service negotiation and the throughput of performing a security service negotiation when different numbers of policies are uploaded in a bath during the above experiments. It can be found that when the batch uploading of security service policies reaches about an integer multiple of 2000 policies, the average time overhead of security service negotiation is the smallest, which is about 0.92 ms, and the throughput is the largest in test, which is about 1093 completed negotiations per second. This is because when the number of policies received by the blockchain in a batch is about an integer multiple of 2000, every block generated is filled, and this is when the blockchain performance, that is, the number of transactions that can be processed per second, is near its peak in this experimental setting. Compared to BPFC-SDNs, BSSN-SDNs have a larger average latency and a smaller throughput, which is because the contract complexity of BSSN-SDNs is slightly higher than that of BPFC-SDNs.

Figure 12. The average time overhead of blockchain-based secure service negotiation.

Figure 13. The throughput of blockchain-based secure service negotiation.

6.2.2. Performance Evaluation of Security Service Negotiation for SDN Interdomain

In BSSN-SDNs, SDN interdomain security service negotiation is triggered when an SDN domain formulates and submits a set of new security service policies. In this experiment, the total latency of SDN interdomain security service negotiation includes the time overhead of the following six processes: (1) SDN controller application SSN encrypts the security policy; (2) $BlockApp$ generates the security service negotiation transaction; (3) $BlockApp$ submits the transaction $\mathit{SSNTrans}$ to the blockchain, and the blockchain validates the transaction; (4) the blockchain executes the security service negotiation and generates the block by consensus; (5) issues the negotiation result to the relevant SDN domain controllers; (6) the controllers map the security service receipt to $NSS$ and write it to the local security service repository.

• Task 3: Total latency for two domains with different distances to complete a security service negotiation

The experiments tested the total delay for BSSN-SDNs to perform SDN interdomain security service negotiation and the time for the blockchain to perform security service negotiation (the 4th phase mentioned above) when a domain performs one security service negotiation with a domain at a different distance. The distance here refers to the number of hops at the domain level. The experiment tested the total delay for BSSN-SDNs to complete one SDN interdomain security service negotiation and the time for the blockchain to complete one security service negotiation in the case that domain A negotiates security services with five other domains B\C\D\E\F, respectively. The negotiation experiments for different distances are repeated 30 times individually, and the averages are taken for the test times. The experimental results are shown in Figure 14 and Figure 15.

Figure 14. The total latency of secure service negotiation between SDN interdomains.

Figure 15. The latency of secure service negotiation on blockchain.

From the experimental results in Figure 14 and Figure 15, it can be seen that although the distance (distance here refers to the number of hops at the domain level, not the physical distance) between the two domains participating in the negotiation is different, the blockchain-based interdomain security service negotiation latency of SDN is similar, and the total interdomain SDN latency and the on-blockchain latency in this experimental environment are about 1.5 s and 1 s, respectively. Therefore, in the SDN multidomain environment, the blockchain-based security service negotiation delay of BSSN-SDNs is weakly correlated with the number of hops between SDN domains.

• Task 4: Total latency for multiple domains to complete security service negotiation

The experiments measured the total delay of BSSN-SDNs to complete SDN interdomain security service negotiation and the latency of blockchain to complete security service negotiation when different numbers of SDN domains request security service negotiation at the same time, respectively. The security service negotiation policy in the experiment is configured so that one successful security service negotiation can be completed between every two domains. Each experiment is repeated 30 times, and the test time is averaged. The experimental results are shown in Figure 16.

Figure 16. The latency of secure service negotiation among different numbers of domains.

The experimental results show that, firstly, for different numbers (2–6) of domains re-requesting security service negotiation at the same time, the latency of the blockchain to execute security service negotiation is growing slowly and takes similar time, all slightly more than 1 s. This is due to the fact that when there are few negotiation policies, the blockchain takes a large percentage of the time to generate the block. Secondly, the total delay of the SDN interdomain security service negotiation increases gradually with the number of domains involved in the negotiation and shows a quadratic tendency, as shown in Figure 17. This is because when there are n (2 ≤ n ≤ 6) domains performing security service negotiation at the same time and the policy is configured to allow every two domains to be able to complete a successful security service negotiation, the number of times SDN interdomain performs security service negotiation is about n(n − 1).

Figure 17. The order 2-regression for the total latency of SSN among SDN interdomains.

In summary, the security service negotiation latency of BSSN-SDNs positively correlates with the number of policies to be negotiated as well as the number of domains participating in the negotiation, and it is weakly correlated with the hop distance between the participating domains.

7. Conclusions

In this paper, BSSN-SDNs, a blockchain-based SDN interdomain security service negotiation scheme, is proposed. It can automatically perform security service negotiation to meet the demand for dynamic security service negotiation between SDN domains as well as to solve the problem of the lack of security and trustworthiness of SDN interdomain security service negotiation. It is discussed that BSSN-SDNs can guarantee the timeliness, security, and trustworthiness of security service negotiation within the SDN interdomain. The experimental results show that the delay in blockchain-based security service negotiation is within an acceptable range and positively correlates with the number of policies and domains involved in the negotiation. In the future, it is expected that the application can be extended into the field of multi-domain IoT.