SDN and NFV
SDN and NFV are technologies from the early 2010s that virtualize network operations. While SDN is a technology that came from the enterprise network and data centers, NFV came from the Network Service Provider (NSP) world. Let's see what they are and the security hazards for networks that implement them.
Software-defined networking (SDN)
SDN separates the data plane from the control plane, creating software-programmable network infrastructure that can be manually and automatically adapted to application requirements.
While in traditional networks, network devices exchange information between them, learn the network topology, and forward packets, in SDN, the switches are simple devices that forward packets according to commands they receive from the network controller.
Let's take, for example, a network of routers. The following happens in traditional networks:
- In the control plane: Routing protocols exchange routing information between them, check restrictions such as Access Control Lists (ACLs) and QoS requirements, and fill in the routing tables.
- In the data plane: From the routing tables, they build the forwarding tables. Then, when a packet enters the router, the router will forward it according to the forwarding tables.
The following diagram shows an example of an SDN network:
Figure 1.13 – SDN
In this network, we have a central controller, which is the network's brain. This controller acts as the control plane for the entire network. When a new session is opened and packets are sent through the network, every switch receiving the first packet will send a request to the controller, asking how to forward it. Upon receiving the response, the switches will store it in their forwarding table. From now on, every packet will be forwarded according to it. This is done through the southbound interface using protocols such as OpenFlow or Netconf. Connections from the controller to the switches are established over the Transport Control Protocol (TCP), preferably with Transport Layer Security (TLS).
On the northbound interface, the controller sends and receives information to and from SDN applications via standard APIs such as RESTful. SDN applications can be applications that implement network functionalities such as routers, firewalls, load balancers, or any other network functionality. An example of an SDN application is a Software-Defined – Wide Area Network (SD-WAN), which provides connectivity between remote sites over private and internet lines.
An SDN domain is all the devices under the same SDN controller. A network orchestrator is used to control multiple SDN domains. For example, when enterprise LANs are connected through a private SD-WAN service, there will be three controllers – two controllers for the two LANs and one controller for the SD-WAN. The orchestrator controls its end-to-end connectivity.
Several security breaches can be used on an SDN network:
- Attacks on the connections between the controller and the SDN switches that are implemented over a standard TCP connection with standard port numbers
- Attacks on network controllers and orchestrators
- Attacks on data plane switches
Later in this book, we will discuss these risks in more detail.
Network function virtualization (NFV)
NFV takes the concept of computing virtualization to the networking world. The concept is that instead of using dedicated hardware for every networking function, we use standard Off The Shelf (OTS) hardware, along with standard Virtual Machines (VMs), when the network functions are software running on these VMs. First, let's have a look at the platforms that host these applications:
Figure 1.14 – VMs and hypervisors
The preceding diagram shows how the networking applications are installed. In the case of Linux containers, the virtual machines are implemented as Linux containers, while the applications are installed on the containers together or separately.
A Type 1 Hypervisor is installed directly over the hardware. Here, we can find the most common Hypervisors, such as VMWare ESX/ESXi, Microsoft Hyper-V, and Citrix XenServer.
A Type 2 Hypervisor is installed over the host operating system. Here, we can find PC-based Hypervisors such as VMWare workstations, Microsoft Virtual PC, and Oracle Virtual Box.
Important Note
A VM is an emulation of a computer system that provides the functionality of a physical computer. A Hypervisor is a piece of software that runs the VMs. There are two types of Hypervisors – Type 1, which runs directly over the system hardware, and Type 2, which runs over the host operating system. The first Hypervisor was developed in the 1960s by IBM, iVMWare ESX (later ESXi) came out in 1999, XEN from Citrix came out in 2003, and a year later, Hyper-V from Microsoft came out. In the Linux world, it started with traditional UNIX platforms such as Sun-Solaris before coming out as Linux KVMs and Dockers. The purpose of all of them is simple – to effectively carry many applications over different OSes that run independently over the same hardware.
Linux containers dominate the networking market in NFV. These can be routers, switches, firewalls, security devices, and other applications in the data center network. They can be also cellular network components that are installed on the same hardware. The NFV model is shown in the following diagram:
Figure 1.15 – NFV
The NFV architecture is comprised of the following:
- Computing hardware, including computing and storage resources
- Virtual resources; that is, the resources that are allocated to the VMs
- VNFs, which are the VMs and the applications installed on them – routers, firewalls, core cellular components, and other network functionalities
- Element Managers (EMs), which manage the network's functionality
- NFV Management and Orchestration (MANO), along with Operations Support Systems (OSSes) and Business Support Systems (BSSes)
When considering NFV application security hazards, we should consider potential attacks on the entire software stack, from the operating system to the Hypervisor, the VMs, and the applications.
SDN and NFV are about taking the transitions from hardware-based areas to virtual networks. Now, let's take this one step forward by going to the cloud and seeing how we can implement the network in it.