VADSEC-A LIGHTWEIGHT PROTECTION SCHEME FOR SECURE TOPOLOGY DISCOVERY IN SDN

Software-Defined Networking (SDN) is a model that allows decoupling of control plane traffic from the data plane traffic of a networking device. It promotes centralized management and control of networking devices via programming [1,2]. In traditional networks, the control plane and forwarding plane reside on one networking device i.e., a router or a switch, and network engineers only have to configure the device to perform any desired activity like routing, authentication, authorization, firewalls, NAT, etc. On the contrary, in SDN the control logic is removed from forwarding devices (routers, switches) and resides in a controller which is considered to be the brain of an SDN network. While centralizing control has its advantages, such as easier management, the controller becoming a single point of failure is one of the primary drawbacks. To overcome this issue, researchers have proposed physically distributed controllers [3].

Using a controller to manage devices has not only reduced the cost of traditional network switches and routers but has also resulted in simplified device management. A programmable network offers more flexibility and lets the programmer use his innovation via well-defined APIs to create new services, policies, rules, and applications.

SDN is a three-layered architecture [4] as depicted in Figure 1 illustrating in detail a logical view. The top layer of the SDN architecture is the Application layer. It contains network applications and functions typically used by organizations. SDN applications reside in the application layer and can be developed and used to address specific networking requirements such as traffic engineering, network monitoring, security, and load balancing.

SDN architecture consists of three planes - Application, Control, and Infrastructure. Controller resides in the Control plane and interacts with Applications through APIs and to Infrastructure plane via Southbound Interface. OpenFlow is the most widely used southbound interface.

SDN applications can interact with and control the network through the Northbound Interface (NBI), which is a communication interface exposed by the SDN controller. It acts as a boundary between the application layer and the control plane and specifies the ways in which SDN applications can request network services, retrieve network information, and influence network behavior. NBI supports network programmability by enabling programs to get information from the controller using APIs.

The middle layer is the control layer, which consists of a logically centralized SDN controller. One of the main roles of the controller is to provide and maintain a global view of the network. It also provides an abstraction to the application layer and the possibility to program and enhance underlying SDN infrastructure using Northbound Interfaces (NBIs). Topology discovery which gives a holistic view of the network is a service provided by SDN controller. An accurate topological view is crucial for NBI applications to function correctly and efficiently.

At the bottom is the data plane or infrastructure layer, consisting of a set of interconnected devices, i.e., SDN switches, which provide the forwarding functionality. These switches can be hardware devices or software-based virtual switches, like Open vSwitch [5]. The SDN controller is responsible for managing and configuring individual SDN switches, by installing appropriate forwarding rules. This is achieved through the southbound interface, which connects the control layer and the infrastructure layer. The most popular and de facto standard for the southbound interface is OPENFLOW, managed by the Open Networking Foundation (ONF) [6], and we will use the same in this paper.

To achieve centralized visibility, a controller needs to discover network topology which includes the switches, hosts, and associated links. The discovery and centralized view of network topology is a critical task as many SDN applications and services rely on it. Several topology poisoning attacks have been proposed and implemented to disrupt/poison the controller's view of topology [7]. Compared to conventional networks where topology poisoning attacks are usually confined to a single broadcast domain, topology poisoning attacks on SDN are more dangerous as they affect the entire SDN network. The topology-dependent applications and upper layer services are totally misled owing to a poisoned topology and can result in serious attacks like host hijacking, link fabrication, denial of service, and man in the middle.

The rest of the paper is organized as follows: Section 2 provides background information on LLDP, OFDP link discovery process, and OFDP link spoofing. Section 3 examines related work and previous research about topology discovery attacks and their countermeasures. Section 4 gives details of our proposed design VADSec and its implementation. Section 5 discusses the evaluation of the proposed solution. Section 6 concludes the paper with directions for future work.

Topology discovery is used as a service at the controller end as network switches do not have any capability to discover links and topology. Open Flow Discovery Protocol (OFDP) is the primary mechanism for topology discovery in SDN controllers. Switches are discovered during the initial handshake process, so the focus is on discovering links between switches and hosts.

In conventional networks, Link Layer Discovery Protocol (LLDP) is used to discover links and neighbors (IPv4 networks). The LLDP frame format has been defined in literature as explained in [8]. Ethernet switches send and receive LLDP packets regularly to monitor topology and active status of neighboring devices. LLDP packets are sent via each switch port at a multicast address and only last a single hop, meaning that switches do not forward them further. The LLDP information is stored in Management Information Base (MIB) of each switch. A network management system (NMS) can discover network topology by querying each switch and retrieving MIB information via SNMP.

SDNs use the LLDP frame format as depicted in Figure 2. The LLDP payload is encapsulated in a frame with Ether Type set to 0x88CC. This ether type is an indication that the packet is of LLDP type. The ethernet frame includes LLDP Data Unit (LLDPDU) as shown in Fig. 2 which contains mandatory and optional Time Length Value (TLV) fields [9]. The topology discovery process of conventional networks and SDNs is quite different despite having a common LLDP frame format.

A detailed structure of LLDP frame to understand the format in which packets are sent.

2.1 OFDP LINK DISCOVERY

In SDN, link discovery is initiated by the controller. The controller creates and sends an LLDP packet for each port on each switch via a separate Packet Out message per switch port. The packet out message contains the instruction according to which action will be taken by the switch on corresponding port. LLDP packets once received must be sent to controller via packet-in message as per pre-installed rule. When the controller receives a packet-in message containing LLDP payload and metadata, it can infer the existence of a unidirectional link.

Figure 3 clearly explains this concept.

OFDP link discovery process is illustrated where Switch 2 is in the middle and connected to Switch 1 and Switch 3. How packets flow between ports is shown and later explained.

As illustrated in Figure 3, the SDN controller creates a dedicated LLDP packet for each switch port, which is then sent via Packet-Out message. The corresponding Chassis ID and Port IDs are also initialized accordingly. For instance, the LLDP packet with Chassis ID as SW1 and port ID as Port1 will be sent out via Port1 of Switch SW1. Similarly, LLDP packets with Chassis ID SW2 and port IDs Port1 and Port2 will be sent out via respective ports. When SW2 port2 and SW2 port1 receive LLDP packets, they will send the LLDP packets to the controller encapsulated in a Packet-in message. The Packet-In message contains information like the ingress port on which the packet was received and the Chassis ID of the switch that sent the Packet-In message. This information, combined with the payload information (which includes the Chassis ID and port ID TLVs of the switch from which the LLDP packet originated) helps the controller infer the existence of a link between the switches.

2.2 OFDP LINK SPOOFING

The basic problem with topology discovery via OFDP is lack of any security checks. The controller cannot ascertain the authenticity and integrity of generated LLDP packets. Hosts or switches can generate these packets, and they may also be crafted with incorrect information, causing the controller to believe in non-existent links. If wrong topology information is provided to applications, it may result in incorrect routing, leading to disruption or total disconnection of network services.

As we can see from Figure 4, host host1 attached to switch SW1 on port port2, injects an LLDP packet with Chassis ID set to SW3 and port ID set to port2. Despite coming from a host, switch SW1 will receive the LLDP packet and forward it through a Packet-In message to the controller. As explained earlier, the controller on receiving metadata from SW1 and getting details of LLDP packet payload which were crafted by host1 (Chassis ID SW3 and Port ID port 2), will infer the existence of a link between SW1, Port2, and SW3, Port2. Hence the attack is successfully implemented. It is important to note that a unidirectional link between SW1 and SW3 is established only. To create a bidirectional link, host2 must also be compromised.

Attack scenario is illustrated for the same topology discussed earlier and link spoofing is explained based on this.

In OFDPv2 [10], a modified topology discovery scheme is presented which reduces the number of LLDP packets via packet-out message to one per switch. The switch further forwards it to ports. Upon initial handshake, the switch informs the controller about its ports and associated MAC addresses, allowing the controller to have a one-to-one detail for each port and respective MAC address on each switch. Since the payload of LLDP packet cannot be modified, the ability of SDN switch to modify/rewrite headers is used to update source MAC address of egress packets. Another feature that is used in this approach is the modification of packet-in event handler on the controller so it can look at source MAC address from headers of ethernet frames instead of parsing LLDP packets payload. This technique reduces the controller overhead to a substantial extent. However, this approach is vulnerable to identity spoofing attacks resulting in various security issues like host hijacking, link fabrication, LLDP flooding, Controller fingerprinting, and switch spoofing.

Azzouni, Abdelhadi, et al. proposed sOFTDP [11], a topology discovery protocol that improves the performance of OFDP by making it more secure, reliable, efficient, and error-free. The authors use BPD (Bidirectional Forwarding Detection) technique to verify port liveness and report in case of link failure or port down. For link addition they use OFPT_PORT_STATUS. Just like OFDP, the controller sends LLDP packets to all switches, but these packets are hashed to prevent any switch spoofing attacks. Additionally, the system description field value is also hashed to prevent controller fingerprinting. This approach is more secure and outperforms OFPD and OFDPv2, but it introduces a lot of overhead owing to hashing.

The authors proposed topoguard [12], a solution to counter host hijacking and link fabrication attacks. The host hijacking is prevented by sending probes and verifying pre and post-conditions. The link fabrication is countered by adding an additional TLV of HMAC which contains the hash of the DPID of the switch and port number. Although this technique can protect against link fabrication, it cannot defend against link relay attacks since HMAC is computed only once and cached for future use. As per the authors, link fabrication by relay can be detected by monitoring traffic and making sure that LLDP packets are coming from a SWITCH and not HOST. But this approach isn't practical as a HOST can behave like a switch and make the controller believe so by relaying LLDP packets.

Alharbi and Co [13] in their work analyzed topology discovery and launched link spoofing attacks to verify the vulnerability of OFDP using LLDP packets. They also proposed a protection scheme that uses dynamic keys and HMAC of TLVs to add authentication to LLDP packets. Although this scheme is secure against link spoofing attacks, it adds CPU overhead to the solution.

One of the earlier approaches to detect topology tampering was by SPHINX [14]. In this approach, an anomaly detection technique is used which monitors network flow graphs to detect any attack that violates the flow graphs.

The authors of Topoguard+ [15] proposed two new attacks called port probing and port amnesia that were successful even in the presence of state-of-the-art defenses like Topoguard and SPHINX. They developed an extension of Topoguard, which is more secure, efficient, and resilient, and thus preventing topology tempering attacks, including port amnesia and port probing.

Samuel et al. [16] presented a technique called SecureBinder, which uses a modified version of the legacy 802.1x authentication protocol to thwart host location hijacking attacks. It is an effective technique and enhances the security of SDN topology discovery mechanism. However, Marin, Eduard et. al. in their work [17] have found two weaknesses that can circumvent the protection of SecureBinder. Since the host is authenticated only once, one of the attacks is to disconnect the host and immediately connect a malicious device without breaching the threshold before which signal of disconnection goes to the controller. Such a scenario is applicable where there are multiple VMs contained by a single host. In another attack, authentication traffic can be intercepted and replayed to a different network location since SecureBinder doesn't bind the authentication traffic to host port.

Secure topology discovery has been a challenging task. If we can somehow secure hosts, topology can be secured as we assume the controller and switches are secure and this assumption is valid. The 802.1x technique has already been used to secure hosts [18] but it causes unnecessary overhead and dependence on the RADIUS server. Conventional methods of security like DHCP snooping, port security, ARP spoofing, etc. cannot be used in SDNs as switch ports can't be configured. Therefore, we need a resource-efficient and effective protection mechanism, that can secure topology discovery.

As we have discussed, securing topology discovery is an ongoing process. Different solutions proposed in the past are either resource-intensive or not fully secure. Moreover, some solutions are yet to be developed and tested for large-scale networks and multivendor platforms. In this paper, we have proposed a simple, yet effective solution called VADSec−VLAN and AD based mechanism for securing the data plane, by making sure that host location hijacking attacks can be prevented resulting in a secure topology discovery process.

We know that VLANs can be used to segregate traffic and isolate certain hosts. In our proposed solution we have made a quarantine VLAN which only allows limited traffic. We know that impersonation occurs when a host wrongly claims to have the MAC ID of the victim's host. If a host is isolated in VLAN, and a broadcast query is generated by the controller, then there should not be any reply pertaining to the MAC ID of the host in quarantine VLAN. If there is any such reply, it would mean the host is being impersonated and traffic will be allowed only after further security checks.

Another layer of security is added by adding an Active Directory account pertaining to the MAC IDs on the domain server. In our solution we have used the “–mac” tag when running topology in mininet to generate simple sequential MAC IDs (00:00: 00:00: 00:01, 00:00: 00:00: 00:02 ……... 00:00: 00:00: 00:NN). The controller will query the Active Directory Controller via LDAP to first check for the existence of an account against the MAC ID before allowing normal traffic. This will not only prevent any flooding attacks but will also make sure that only authorized MAC IDs are allowed to join the network. Once a host is protected, the network can be trusted as we had assumed that switches and links between the switches are secure. Figure 5 depicts in detail our design by illustrating all the components involved.

The concept and design of VADSec illustrated. It includes SDN controller, Infrastructure plane with a simple topology, an Active Directory Server, and a VLAN.

Implementing a quarantine VLAN and utilizing LDAP to query Active Directory for MAC IDs is a highly effective security measure. This process is quite efficient and requires minimal additional effort, as the controllers perform repeated broadcast queries, which is its normal operation. As a result, there is virtually no overhead on the controller when checking for impersonation by broadcasting. When querying an AD server on the same network, there is no noticeable delay in network latency, and network performance remains smooth. In our implementation, the controller and AD server responded quickly and without delay. It is important to note that with a very large network, some delay may occur, but it should still be insignificant. Fortunately, modern hardware can handle the broadcast and LDAP query requests without issue, making this security measure a reliable and practical solution for network protection.

Topology discovery is a crucial feature of the SDN controller as it provides accurate information about the network's layout. This information is necessary for network applications to function properly. However, an attack like host-hijacking and link spoofing can severely affect the entire SDN network. Therefore, it is essential to secure the topology discovery process to obtain an accurate network topology picture. In this paper, a protection technique is proposed that employs quarantine VLAN to isolate host traffic and identify any impersonating host by sending a broadcast excluding the quarantine VLAN. Additionally, MAC ID based accounts have been created in the Active Directory server, allowing traffic and host access only when an account is confirmed from AD via LDAP. This approach makes it difficult to impersonate a host, thereby effectively countering attacks like host hijacking, Man In The Middle (MITM), and MAC flooding. Although currently implemented for a simple network, we intend to apply and test this design for a large-scale network. Furthermore, we plan to include the Context Directory Agent in our design to further secure hosts and user accounts in the future.