Keywords

1 Introduction

Software-Defined Networking (SDN) changes the traditional network architecture by separating the control plane of switching equipment from the data plane. Nowadays, SDN, particularly its popular realization OpenFlow, has been increasingly employed in academic environments and real-world production networks. Compared with traditional network architecture, SDN implements a unified controller that can support holistic network visibility and flexible programmability. Network applications can make global decisions based on flow conditions provided by the controller. Once the topology information provided by SDN controller is falsified, all operations based on network topology are incorrect.

The fundamental of SDN is the correct topology information. Most security approaches which primarily concentrate on network/rule authorization, conflict resolution or network resource consumption/scalability will be meaningless. Recently, in order to overcome topology attacks, Hong et al. proposed TopoGuard [6], which is the first method to study the network topology visibility exploitation and fix security omissions to detect attacks on topology information. Dhawan et al. proposed SPHINX [4]. They also found several attacks on SDN controllers which violate network topology and data plane forwarding. Although these schemes can defend against most of topology visibility attack, they are vulnerable to complicated attacks constructed by the adversary.

In this paper, we analyze the drawbacks in network topology management of the mainstream OpenFlow networks and propose novel MITM (Man-In-the-Middle) attacks on many security protocols. Besides, we also analyze the existing mainstream patches [4, 14] and figure out some new attacks on network visibility. If an adversary host which links to two different SDN switches relays LLDP packets from one switch to another simultaneously, SDN controller will take this internal link as a normal link according to the existing SDN link discovery method. Compared with the traditional network, it is difficult for SDN controller to find this middle man. According to the original intention of SDN design, OpenFlow controller does not handle the application layer protocols. If these two conditions are satisfied, the adversary can breach most application layer security protocols in SDN by careful design. In this paper, we propose solutions for fake link detection by analyzing the transfer time of LLDP to defend against this MITM attack. Our evaluation shows that it is possible to detect the fake link and prevent such severe MITM attacks.

In short, our paper makes the following contributions:

  • The security analysis is performed on TopoGuard and SPHINX which defend against Network Topology Poisoning Attacks and new MITM attacks on security protocols in SDN architecture are figured out.

  • Security protocols that can be hijacked by our attacks are found out and possible approaches to defend against these MITM attacks are also proposed.

  • Experiments are implemented to validate the proposed solution.

2 Background

2.1 Software Defined Networking

Software Defined Networking is a new paradigm that decouples control plane of network device from its data plane and implements all control plane as a unified software platform, which is called the SDN controller. OpenFlow is a popular realization. The SDN controller can guarantee the topology visibility of whole network and make the best routing decision according to the topology information. Besides, we can easily configure security policies in centralized controller.

2.2 Attacks on Link Discovery Service

Different from legacy network, topology management is unique in SDN networks. SDN controller provides such visibility to upper service/apps. Once this visibility is falsified, upper services will be influenced. In topology management, we focus on link discovery service. Link discovery service is used to find switch-to-switch link in SDN networks, which is an active process. By means of link discovery service, SDN provides controller with secure network topology.

Attacks on internal link discovery are presented due to the lack of integrity detection of LLDP packet in OpenFlow controller. There are two main types of attack on link discovery: fake LLDP injection attack and LLDP relay attack. Due to the open source feature of SDN controller, the adversary can obtain the syntax of LLDP packet. Then he can generate new LLDP packet or modify the content of received LLDP packet (e.g. DPID of switch or the port number field) and forward this packet to the linked switch. Then topo information is polluted. In addition to the fake LLDP injection attack, the adversary can also fabricate internal links in a relay fashion. When receiving LLDP packet from one target switch, the adversary relays it to another target switch without any modification. Then the adversary constructs a fake topology view to the OpenFlow controller that there is an internal link between these two target switches. This relay attack is the basis of launching MITM attack.

2.3 Mainstream Patches

Some methods have been proposed to solve attacks on link discovery service with TopoGuard [6] and SPHINX [4] as representatives. In order to defend against fake LLDP injection, TopoGuard adds a controller-signed TLV into the LLDP packet and checks the signature when the LLDP packets are received. In order to defend against LLDP relay attack, TopoGuard marks the switch ports as SWITCH and HOST according to the types of received packet. If LLDP packet is received from switch port, it will be assigned SWITCH. If host-traffic packet is detected, it will be assigned HOST. Once the port has been marked, this port is suspicious if the traffic received from this port does not match its label. SPHINX maintains flow graphs, which are the graph theoretic representation of traffic flow. In the graph, edges indicate flow metadata and nodes represent the switches. Flow graphs provide a clean mechanism that aids detection of diverse constraint violations for network topology. Once new packet violates flow graphs, SPHINX will raise alerts. In addition, SPHINX also checks the port metadata to ensure that only a single neighbor is permitted per active port at a switch. Besides, links in SPHINX should be bidirectional in flow graphs. However, when adversaries mute all host-generated traffic and relay LLDP packets, these schemes won’t raise an alert.

3 Man-In-The-Middle Attack on Security Protocols

3.1 Threat Model

With the extension of internal network scope, the benefits obtained from direct internal attacks in the network increases. Since our goal is to establish fake internal link and launch MITM attack within SDNs, our threat model exclusively focuses on scenarios where the adversary initiates attacks within the SDN. Thus, we model SDNs as a closed system. We consider an enterprise SDN setup with no traffic across OpenFlow and non-OpenFlow network. We assume a trusted controller and trusted switches, but we do not trust the end hosts. We also assume SDN applications are trusted. In addition, we assume the adversary can establish simple network with the aid of legacy routers and switches.

Fig. 1.
figure 1

Attack scenario

Full size image

3.2 Man-In-The-Middle Attack

In this paper, we will introduce a new MITM attack that is difficult to defend in the mainstream SDN architecture. Our attack is based on the fact that there are no effective means to defend against LLDP relay attack if the adversary mutes its host-generated traffic and only relays LLDP packets. In order to establish middle man in the link successfully, we discuss two ways, i.e. by physical links and by a tunnel. An intuitive relay method is to set up physical links (e.g. cable or wireless) between two switches using middle adversary shown in Fig. 1. In order to increase the scope of this attack, two adversaries can link switch 1 and switch 3 separately and then exchange LLDP packets using another legacy net. This approach may require adversaries to build up a small network. In order to circumvent the detection of protection schemes, the adversary needs to mute all host-generated traffic when relaying LLDP packets. Another way is to make a tunnel by utilizing third-party host. As shown in Fig. 1, compromised host 1 transfers the received LLDP packet to host 2, then host 2 relays it to compromised server. After receiving this packet, the server then transfers it to switch 3. Then controller thought switch 1 connects to switch 3. This method is easy to defend in existing patches because the types of packets in this switch port are different.

After the establishment of fake internal link, the adversary can take MITM. We use the attack on Https as an example. When the compromised user accesses the service of compromised server without protection of https, the middle man can get the user’s network information directly. When communication parties use Https, the middle man can still achieve the login information without being detected by existing patches, which is our main contribution. In our experiment, we test one way SSL authentication. TopoGuard is chosen as the OpenFlow controller. We deploy a linear network topology, as shown in Fig. 1, where we have a compromised host connecting two ingress switches in the network. When the compromised user accesses the compromised server, the server will redirect the access to https. The redirection traffic will pass through the adversary but won’t be changed. After that the compromised host will send SSL request to the server. When the middle adversary receives this request, he will modify the payload using his parameters and send this packet to the server using the compromised host’s packet header. Because the packet header doesn’t change, the traffic will not be transmitted to the controller. Then the server begins to transmit the certificate to the compromised host. The adversary relays this packet to the host and receives the response from this host at this time. After receiving the response, the adversary discards this packet and generates the adversary’s response packet with the compromised host’s address. Then the adversary sends the modified https response packet to the server. At this step there are still no PACKET_IN packets. Then the server and the adversary carry out the key exchange and establish the connection between them. In this procedure, the adversary acts as the role of the client and establishes https connection with the server. After the establishment, the adversary will transmitted the information of server to the client with the normal http packets. From the perspective of the client, he receives what he wants if he does not notice what he reviews has changed from https to http. In this case all useful information from the compromised host are obtained by the adversary, and the adversary even can change the content the server sends. In the whole procedure OpenFlow controller doesn’t recognize the existence of the adversary. TopoGuard could not find the mismatch of the switch port type of the adversary. Because OpenFlow controller almost deals with layer 4 and lower protocols, it can’t recognize the difference between http and https. The whole attack process is similar with SSL strip. In addition, the attack pattern is almost the same when the adversary launches SSLSniff [2] (which attack SSL using forged certificates) except that the adversary needs to forge and replace the certificate of the server. The drawback of SSLSniff is that the client browser will require certificate verification and this will raise the alarm.

Our main contribution is to propose a method that compromises most security protocols using the inherent loopholes of link discovery service in SDN. As to https, if the compromised user pays more attention on the browser address bar and identifies the difference, this attack will fail. But for those users who lack security awareness, it is unpractical for them to notice the difference. In addition, another prerequisite for the attack’s success is that the service provider doesn’t use two-way authentication. In order to improve access speed, most commercial web sites in China use one-way authentication, including taobao.com, jd.com, baidu.com. Different from SSLSniff, our attack doesn’t change the certificate of server. Because the middle man in SDN is difficult to avoid and our attack doesn’t change the certificate in SSL procedure, our attack scheme is universal.

3.3 Influenced Security Protocols

Besides the attack on Https, we also investigate attacks on other protocols by the means of fake internal link. We mainly focus on application layer protocols. We test many protocols and use the method similar to https attack. In practical application, legal users are always identified by password. By using Https attack mentioned above, we have already got all information about the compromised host and can impersonate him using the password. But we still explore security protocols that can be hijacked. Our test results are shown in Table 1. Many security protocols use certificate to guarantee the legitimacy of public key. If the middle man fails to falsify server’s certificate, we directly use client’s password to login because most login process is protected by https. Our results consider the basic situation. The No stands for impossible in any situation using our scheme.

Table 1. Influenced security protocols
Full size table

3.4 Countermeasures

There are two conditions for MITM attacks. First, SDN controller doesn’t handle application protocols. Only when the switch’s buffer is overflow or the switch is set, the controller can get whole packet instead of packet header. Second, the prerequisite of the MITM attacks is the existence of that middle man. If we can take solutions to break one of these two conditions, the attack can’t be successful.

Full Packet Inspection. The naive way is to set the switch to upload the entire packet to the controller. However, the communication time between the controller and the switch will sharply increase under this case, thereby reducing the communication efficiency of the whole network. In addition, the existing switch rule only matches layer 4, layer 3 and layer 2 packets, it is still useless when the adversary launches the above MITM attacks.

Middleware Inspection. From user’s point of view, our attack is the same as that in legacy network. It is practical to transfer the solution in legacy network to SDN. Because our mentioned attack will change https to http, IDS (Intrusion Detection System) will be useful. In current SDN design, IDS is deployed as a middle box, and it needs OpenFlow controller to transfer packets to both the destination and IDS itself, just as written in [13]. IDS and other defensive measures put additional burden on the controller, and they are hard to deploy ([13]). Shin et al. [15] also proposed a new way to make IDS as an OpenFlow application, but it brought efficiency loss and needed time to prove its usability.

Fake Link Inspection. In order to defend against MITM attacks, the direct method is to find fake link. From the opinion of OpenFlow controller, it is hard to distinguish the difference between the real link and the fake link. But the approach of establishing the fake link provides the possibility. In the procedure of fake link establishment, the adversary needs to relay LLDP packet from one switch to another. Compared with the normal LLDP transmission procedure, the adversary needs to add two times forwarding process of network interface card. This will increase the transmission time. In particular, the transmission time is longer when two hosts conspire to transfer LLDP. If we can distinguish the different latency of link discovery procedure, we will find the fake link.

In order to find the link latency, we can insert timestamp in TLV of LLDP packet. By means of the newest Floodlight version 1.2 which can calculate the LLDP latency, we can directly get the time. Besides, we can also insert timestamp in echo_request. When we receive the echo_reply, we can get the echo_latency by decreasing the timestamp using the current time. Floodlight version 1.2 calculates the LLDP_latency time using the similar method as the echo latency did. When we get the LLDP_latency and echo_latency, we can get the transmission time in the link through LLDP_latency minus echo_latency. Then we can compare the transmission time of different link. In the normal link, the transmission time is basically equal. If the transmission time is too bigger than others, it is questionable. Then we can label this link as questionable and not save this link. Then we need resend LLDP packet to the switch in this link and calculate the transmission time again. If the transmission time is still too longer than other links, we can conclude that this link is fake. Then we can put this link to fake link store and set the survive time. In the whole survive time, we will not resend LLDP packet if we find this fake link again.

This countermeasure is credible in most cases. It may fail only if a link is in paralysis due to congestion. But SDN controller without our countermeasure will evade the paralyzed link because most packets will be discarded if the paralyzed link is selected. Thus our judgement would not affect the data transmission results and the potential false positives of the countermeasure is negligible. If the congestion is relieved, the countermeasure can judge correctly again.

4 Evaluation

4.1 Experimental Setup

In order to test the effectiveness of MITM attack, we implement simple testbed. Our testbed is shown in Fig. 1 (where the controller host does not show up). The controller is TopoGuard in one of these servers. The connections among them are illustrated in Fig. 1. All of our servers are Lenovo Thinkcenter with Intel I5 CPUs and 12 GB of RAM running 64 bit Ubuntu Linux V13.11. The adversary server has two Rtl8139PCI NICs. Our OpenFlow switches are NETGRARWR3800 with 100M bandwidth which run OpenWRT firmware with an OpenFlow extension.

4.2 Implementation

In order to implement the adversary host, we use netfilter [1] in Linux to transfer the packet and to realize MITM attack. Netfilter is a subsystem of Linux and provides a set of management mechanism of hook function. We use netfilter to transfer the packet from one NIC (Network Interface Card) to another. We also prohibit the response to external requests. Besides, we change the procedure of SSLStrip [10] so that we can follow the procedure of our MITM attack.

In order to defend against this MITM attack, we use the way of fake link inspection mentioned above. In Floodlight 1.2, we can directly get the LLPD_latency and echo_latency. We only need to change LinkDiscoveryManager in Floodlight to resend LLDP packet and determine whether the link is fake. We can rely on the existing solutions to solve our problem.

4.3 Effectiveness

A successful attack on Https will be shown in this subsection.

We made a one-way SSL verification website in compromised server 10.0.0.3 and visited this website from the compromised host. We can get the page with address of “https://10.0.0.3”. Then we connected relay host to switch 1 and switch 3 respectively. We wrote a script that sended the received LLDP packets to another port in relay host repeatedly. Then we modified SSL-strip [10] from github to follow the processing order as mentioned in Sect. 3. Then we visited this website in the compromised host again. We can get the same page with address of “http://10.0.0.3”. The only difference of web browsing is the protocol.

From the experiment result, we can conclude that the compromised user didn’t recognize the difference if he ignored the difference in browser address bar. We can assure that our attack scheme can bypass the protection of TopoGuard.

4.4 Performance

In this subsection, we use our fake link inspection scheme to test the transmission time of the link in Fig. 1. In the test, a different background flow is also utilized to simulate realistic environment and the background flow exists in every link. We can observe the results in Table 2. The unit of time in the table is millisecond.

The fake link (s1<->s3) can be easily distinguished from the results. We can clearly detect the fake link by the proposed approach, and the MITM attack can not be successful if we turn down this link.

Table 2. LLDP transmission time (ms)
Full size table

5 Discussion

The reason for the existence of topology pollution is due to the lack of verification in SDN architecture. Topology management has never been included in OpenFlow Specification, but most of existing OpenFlow controllers and switch vendors follow a certain convention for handling topology management. This may be a root cause for explaining all controllers expose the similar vulnerabilities. With SDN bringing new security challenges, we should not be superstitious in its design. In order to systematically investigate the potential verification loss, designing a new security fuzzer for SDN will be helpful, which is our future work.

Our attack on the data plane is easy to succeed in existing LAN (e.g. campus network, the company’s internal network). But it has shortcomings. Due to the fact that the host must connect to two different switches, the MITM attack can only launch in small area. This will reduce the damage of the attack even the adversaries conspire to commit crime. Our attack scheme pays more attention to the LAN area. If our host stands nearby the gateway switch, we believe this attack will have a greater threat.

6 Related Work

Many security schemes have been proposed to enhance the security of SDN. OF-RHM [5] proposes OpenFlow Random Host Mutation to dynamically mutate IP addresses of hosts inside an LAN (Local Area Network). POFMTD [9] proposes POF Random Protocol Mutation to dynamically mutate protocols in the communication process. Avant-Guard [12] shows a new attack (which is called data-to-control plane saturation attack) against SDN networks and provides solutions to prevent such attacks. Our attack is ascribed to the deficiency of verification. There are many verification approaches used to check network invariants. VeriFlow [3] provides a set of efficient algorithms to check rule modification events in real time. Header Space Analysis (HSA) [8] leverages static analysis to detect forwarding and configurations errors. NetPlumber [7] introduces a real time policy checking tool using Header Space Analysis. SE-Floodlight [11] proposes security constraint enforcement, role-based authorization, an authentication service and a security audit service to solve rule conflict and multiple applications conflict. All these schemes pay little attention on the formation of topology information. Their schemes can not solve the attacks on topology information.

Several works have noticed the attack on topology information. [6] is the first method to point out the Host Location Hijacking Attack and Link Fabrication Attack, which seriously challenge the core advantage of SDN. Concurrent with [4, 6] unifies detection of attacks on network topology using flow graphs. Based on these methods, we proposes new attacks bypassing their defensive measures.

7 Conclusion

In this paper, we propose new SDN-specific MITM attacks in LAN which can bypass existing defense (e.g. TopoGuard, SPHINX). We demonstrate that the adversary can easily launch MITM attack on security protocols to get host privacy by poisoning the network topology information. The solutions to mitigate the harm of this kind of attack are also proposed. Besides, we investigate the security protocols which will be broken in our MITM attack. With the publication of this paper, we hope that our work will attract more attention to SDN security and contribute to the perfection of SDN specification.