Towards Secure and dependable software-defined networks

ABSTRACT

• The security and dependability of the SDN is still an open issue.
• Argue for the need to build secure and dependable sdns by design.
• First Step:describe Several threat vectors that may enable the exploit of SDN vulnerabilities.
• Then:sketch the design of a secure and dependable SDN control platform as a materialization of the concept.
• Hope that this paper would trigger discussions and serve as a catalyzer (catalyst) would trigger discussions resilient control PLA Nes.

Keywords

Security, dependability, SDN, Threat Vectors, Controllers

1. INTRODUCTION and motivation

• The traditional network environment is changeable, the implementation of the required strategy is difficult.
• With the SDN NC separation, the switch becomes a simple forwarding device, and the control logic is implemented in the controller. The benefits of controlling a logical set: simplifying the modification of network policies, automatically reacting to spurious changes in network state, and simplifying the development of more complex network functions.
• SDN provides new ways to address long-existing problems in network work, such as routing, while allowing for the introduction of complex network policies, such as security and reliability. such as ethane: A schema that performs fine-grained fine-grained access control policies.
• The main causes of security problems lie in the main benefits of SDN: Network programmability and the centralization of control logic. These open the door to new threats that have not previously existed or are more difficult to exploit.
• The closed (proprietary) nature of the network devices, their static design, the heterogeneity of the software, and the non-centralized nature of the control plane represent a defense against a common threat.
• SDN brings a fascinating dilemma: an extremely promising revolution in the network architecture, but the dangers posed by threat levels are also increasing. We need to confront the dangers to ensure the benefits of SDN.
• This article advocates that security and reliability should be considered as the primary feature in the design of SDN, rather than being put in later.

2. THREAT VECTORS

• SDN has two features that are considered a tempting honeypot for malicious users, and a headache for operators who lack preparation. One is through a variety of software control network, and software will always be affected by a variety of bugs and vulnerabilities. The second is that the brain of the network is concentrated on the controller, and anyone who needs to gain control of the server controlling the software can control the whole network.
• SDN poses a variety of threats and therefore needs to be handled in different ways. It is believed that SDN will make a tremendous leap in network architecture, not only in functionality but also in elasticity.
• SDN Main threat Vector diagram

• Threat Vector One: forged traffic that can be used to attack switches and controllers. Device errors and malicious users can be raised, an attacker can initiate a Dos attack. A simple authentication mechanism can alleviate the problem, but if an attacker controls an application server that stores many user details, it is easy to inject authorized but spoofed traffic into the network using the same authorization port and source MAC address. Possible solutions:the use of intrusion detection systems and support for runtime Root-cause analysis could help identify Abnormal flows.
• Threat Vector Two: attacks on the switch on the vulnerability, the network has a bad impact. Possible solutions:the Use of mechanisms of software attestation, such as autonomic Trust management solutions for Softwar e components./mechanisms to monitor and detect abnormal behavior of network devices.
• Threat Vectors III: Attacks on control plane communications can be used to generate Dos attacks or data theft. [14] For example, many of the SSL implementations that are vulnerable to man-in-the-middle attacks are used in critical systems around the world. In addition, the TLS/SSL model is not sufficient to establish and ensure trust between the controller and the switch. A lack of trust can cause a virtual network black hole to allow data disclosure. Possible solutions:the use of oligarchic (oligarch) trust models with multiple Trust-anchor certication authorities (e.g., one P ER sub-domain or per controller instance) is a possibility.
• Threat Vector four: an attack against a controller vulnerability could be the most serious threat in Sdn. Controller problems can put the entire network at risk, and simply using a common intrusion detection system may not be enough because it may be difficult to find the exact combination of events that trigger a particular behavior, and it is important to label them maliciously. Possible solutions:several techniques can be used, such as replication (to detect, remove or mask abnormal behavior), Empl Oying diversity (of controllers, protocols, programming languages, software images, etc), and recovery (periodically REFR Eshing the system to a, clean, and reliable state). It is also important to secure all the sensitive elements inside the controller (e.g., crypto keys/secrets).
• Threat Vector Five: there is a lack of trust between the controller and the management application. Possible Solutions:mechanisms for Autonomic Trust management could being used to guarantee so the application is trusted du Ring its lifetime.
• Threat Vector Six: A vulnerability that attacks a management site. Possible solutions:the use of protocols requiring double credential verication (e.g., requiring the credentials of both dif Ferent users to access a control server).
• Threat Vector Seven: lack of trusted resources for forensics or remediation. This allows us to understand the causes of the detected problems and to continue the fast and secure mode recovery. Possible solutions:logging and tracing is the common mechanisms in use, and is needed both in the data and control plane S.

3. SECURITY & dependability in SDN3.1 Background

• To date, no SDN controller has proposed the use of simple authentication communication channels and data replication between controller instances to address security and reliability issues. There is no mechanism to ensure that trusted switch controllers are associated (to avoid malicious devices in the network) or to detect, correct, or mask the failure of system components. No technology is used to ensure data integrity and consistency within or between controllers.
• From the point of view of security and reliability, one of the key factors to ensure high system robustness is fault tolerance and intrusion tolerance.
• A secure and reliable control plane helps to improve the overall elasticity of the network, which is our goal. An elastic system is a dynamically changing system that adapts itself to environmental conditions, such as a system that performs self-healing in the face of persistent threats, and a system that protects parameters (such as number of copies, key lengths, etc.) that can be automatically added in the event of a serious attack.

3.2 Secure and dependable Control Platform

• One of the most important techniques for improving system reliability is replication . Replication makes it possible to mask faults and isolate malicious or faulty applications and/or controllers. is a replication instance.

• Another relevant technology for improving the robustness of a secure and reliable system is diversity . You can use a different controller for replication. The diversity concept can refer to the diversity of PC operating systems to limit the impact of hackers on public vulnerability attacks.
• self-recovery capability . In a persistent hostile environment, active and passive recovery can restore the system to a healthy state. We need to explore the diversity of the recovery process.
• Dynamic device affinity . A switch should be able to dynamically correlate with multiple controllers in a secure way to automatically tolerate failures. Adding data plane programmability is also helpful in this regard.
• Trust between the device and the controller. an easy way is to add certified trusted devices to the whitelist of the controller, but this approach does not meet the flexibility requirements of SDN . Another approach is to trust all switches, and when a switch's credibility is challenged / below the threshold, the cancellation of trust isolates it from the system. Based on an exception or fault detection algorithm, other switches or controllers can report malicious or unusual behavior.
• trust between the application and the Controller software . Software components may be aged, exhausted, faulted, or attacked, so a dynamic trust model is required. In this paper, we can evaluate the credibility by observing the behavior and attributes.
• security Domain. in the OS analogy to the pc ,user -level applications cannot access Root/administrator -level files. You can use technologies such as sandbox and virtualization to explore security domains in the SDN control platform.
• security components. such as Trusted computing bases(TCB), a tamper-resistant device that can be used to store sensitive security data, such as encrypted private keys. This way, even if the system is compromised, sensitive data is still guaranteed.
• Fast, reliable software updates and patching. There is no software to ensure that there are no bugs and vulnerabilities, the control plane needs to adopt a reliable and secure mechanism to complete the software update. A reference solution is available to read [+].
• The above mentioned a variety of safe and reliable solutions, corresponding to the threat vector resolved to participate in the following table.

• Building a secure and reliable control platform can still benefit from the help of traditional technologies such as firewalls, intrusion detection systems, and so on.

3.3 Security and dependability by Design

• The author gives an example of the application of three technologies, such as replication replication, diversity diversity, Dynamic Switch Association, association and so on to the system design, which can improve the security and reliability of the system.

3.4 Related work

• The security and reliability of SDN continues to be an almost untapped area, presenting many challenges and opportunities. Only a few closely related work, namely [5] and [6].
• Temporary work related to the security of SDN itself is not enhanced, which is the goal being pursued.

4. Concluding REMARKS

• The point of this article is that security and reliability should be taken into account when designing Sdn. Lists the existing threat vectors and briefly discusses the mechanisms we use to build a secure and reliable SDN control platform.

Towards Secure and dependable software-defined networks