VN Isolation Approaches

The original idea of VN was to enhance the Internet with flexible demands such as elasticity, manageability and isolation and use it as a mechanism in the cloud to empower traffic isolation, enhance security and provide lower costs [75].

Traffic isolation network mechanisms might differ from one environment to another, for example, in a Hypervisor cloud environment, it is usual to use virtual bridges as Layer 2 switches to forward traffic based on rules and policies to ensure a secure traffic isolation [15]. A variety of solutions have been proposed with different mechanisms such as isolation via network processor, isolation through logical programming and network processor scheduling [35].

The establishment of VN encouraged several vendors to upgrade and redesign their products, such as Cisco, Juniper and OpenFLow. One of the Cisco products called CRS1/16 was a hardware-based isolation virtual router which implemented firm isolation in the data and control panel and guarantees fault isolation [38].

Gutz et al [22] state that maintaining powerful boundaries between networking portions in a shared environment will enhance security around running applications and that required configuration of inner security criteria would not be needed [22]. For example, a Python daemon, which manages user requests (and exposes the API) is configured with a plugin that implements OpenStack Networking API operations using a specific set of networking mechanisms. A wide choice of plugins are also available; the open vSwitch and Linux bridge plugins utilize native Linux networking mechanisms, while other plugins interface with external devices or SDN controllers [85].

Security isolation methods are not VN isolation but a layer built on top of the network isolated traffic for reasons such as using SSL or HTTPS for authentication purposes [15].

The justifications behind introducing different solutions for network virtualization might differ, for example NRI aimed to solve the issue of the network slices intrusion via “per-slice queuing”, Other projects which developed virtual networks as slices were PlanetLab [87] and GENI [19]. Kanada et al [19] promoted a solution to a straight forward isolation, called a per-link policy, where several slices passed their traffic using a single queue controlled by carefully defined policies.

Introducing network hypervisors such as FlowVisor that are resident between the control and data plane in SDN, overcome some of the isolation mechanisms lacking a programming solution for network isolation such as NOX and NetCore. An SDN hypervisor is designed to provide isolation mechanisms as well as giving developers and researchers the ability to edit, modify or customize any feature or program to fit with the network requirements. Although FlowVisor is a better solution, some research has found several flaws that require better resolutions [22]. The termslicingthe isolation can mean isolating the application communication from another ap- plication or isolating a specific communication type in applications from another communication type in the same application [22].

Another solution is via network slicing for programmable isolation. Moraes et al [17] defined slices as two slices in a shared network not being aware of the other’s existence. Slicing criteria must contain integrity, confidentiality, and isolation throughout the slice. Firmware is another way for slices to filter the non related traffic and hence enhance the slice isolation [22].

Several network isolation solutions have been implemented differently [22]such as:

• VL2: application level isolation using encapsulation and tunnelling for traffic forwarding. • NetLord: virtualization and encapsulation.

• CloudPolice: security imposed on host architecture for customer isolation. • Seawall, SecondNet, and Oktopus.

• SDN:

• Controller modules: Beacon and Maestro, NOX, POX and Nettle. • SDN hypervisor: Onix and FlowVisor.

DCPortalsNg used a traffic rewriting mechanism to isolate tenant VN, which results in protecting traffic from other tenants and better performance as the load on the network hardware device will be lower as the physical addresses of the system VMs will not be processed all at once [17]. HP labs were the first to attempt a VN isolation solution and introduced Trusted Virtual Domains (TVDs)) to develop VN isolation fully handled by VMs. Other solutions use VLANs and EtherIP, while DCPortalsNg used an SDN model without the need of OpenFLow enabled hardware to implement a VN isolation[17].

The use of vRouters in VN will enhance isolation but does not provide complete isolation. Hence, more solutions for VN isolation are still needed [76]. Vrouter abstraction was originally a logical

portion of the physical router [88]. Router virtualization does not mean a full isolation, however, a router can be virtualized but shared by different tenants for a specific resource sharing. A vRouter could have a shared session. The degree of virtualized network elements isolation is controlled based on the requirements and not by the fact they are virtualized [88].

The Juniper approach is to use Router Engines for physical resource isolation between vRouters and implement a broad protection [38].

Several isolation solutions use L2 isolation such as EtherIP and GRE encapsulation protocols, however, those are applied in a private network with low performance isolation and static bandwidth provision. To overcome this an L3 isolation is required [76].

For reliable VN with entirely diverse features to simultaneously run in the same environment, two requirements must be guaranteed; VN isolation and adaptable performance. Ahn et al [76] proposed a platform that guarantees VN definition, efficient QoS bandwidth supervision, VLAN ID network isolation and performance isolation. Performance isolation is a method to supply, dynamically allocate and manage bandwidth between isolated VNs. Ahn et al [76] used “BCN, weight-based bandwidth allocation, and virtual-channel bonding” to ensure the isolation

performance for its proposed solution.

Rathore et al [89] stated that an isolation mechanism is the best solution for complicated continuously growing networks in order to confirm just resource consumption between the shared network tenants. They also established a Virtual Distributed Ethernet (VDE) mechanism software solution to increase isolation performance between cloud users in the Eucalyptus cloud private network.

DCPortal was one of the attempts to provide a physical shared network abstraction with multi- tenancy network logical isolation. To ensure network isolation between tenant traffic and lower the overhead of the physical network structure from processing all the VMs at once, a packet rewriting method was an appealing solution [60]. DCPortals was tested on a DC and was implemented in Openstack clouds with the Quantum module for VN provisioning.

Data Center resource isolation is not sufficient for cloud storage and compute multi-tenancy. The framework needed to be backed up with network isolation, and Brassil [80] proposed a physical layer network isolation.

One of the earliest attempts of VNI is by HP Labs, where the VMs perform and manage network isolation using three methods; VLAN tagging, EtherIP encapsulation, and MAC rewriting. These solutions lack scalability and need more work on the hypervisor reconfiguration [60].

Virtual networks depend on isolation and performance. To ensure that parallel networks are not negatively affected by virtual router misconfiguration or attacks, isolation must be implemented properly. XNetMon proposed to overcome the lack of isolation and performance of VNs in a Xen environment. XNetMon focused its research on virtual routers to provide flexible and secure isolation with high performance network [90].

FNSis a Flash Network Slice which is a concept associated with the CloNe project for Dynamic Virtual Network resource and service provisioning. OpenFlow is used in FNS to ensure the isolation via the controller by determining the flow rules and actions for the NFS traffic by using exclusive packet header fields to match [55].

Neutron Openstack accepts plugins to provide isolation at the virtual link level in order to perform instantly adapted traffic routing [91].

DVNis a solution to ensure cloud VN isolation among tenants, but is more effective in distributed cloud sites. DVN provides isolation on two levels; a link level and a network level. The cloud tenant network is ensured isolation throughout the cloud environment and through the different layers of the network operation at L2 & L3 [92].

Solutions such as DVN proposed to do the same for network service as SDN provision in the cloud. Previous solutions such as NDB [47], OFRewind [77], Anteater[55] and HSA [9] suffered from fundamental deficiencies in exposing critical infrastructure information due to inappropriate implementations. Tunnelling protocols in virtual switches such as VNGRE, VXLAN and STT were proposed as encapsulation methods to strengthen tenant isolation. In DVN the cloud controller schedules and isolates (with tunneling) the bandwidth and tenant traffic to preserve the cloud management data and platform [74].

An L2 isolation solution is by using GRE where each tenant will be designated with its own GRE tunnel and is not sharable with others. L3 isolation is created by configuring the Gateway node to give each tenant their own IP subnet. This would be included in the firewall rules for packet routing and forwarding, and for preventing exchange packages between other isolated networks [92].

A network slicing mechanism not only provides VN isolation but it gives the tenants the flexibility to customize their own network topology. Solutions such as FlowVisor [54], OpenVirtex [55]or VeRTIGO [74] are successful. Rather than open the shared resources for everyone, Jacob et al [52] suggested to group tenants involved into a domain which would then be isolated from all the other tenants. They also suggested that OpenNaas have the ability to create a multi-domain that would group users to use specific shared resources per to their request. They called their

solution Slice Oriented Multi-Domain SDN.

VIOLINis an application-level virtual network architecture, where isolated virtual networks

are created in software on top of an overlay infrastructure (e.g., Planet-Lab). VIOLIN logically isolates the network targeting different sides; administration, address space and protocol, attack and fault impact, and resources [36].

Genesisis a spawning network which allows multiple heterogeneous child virtual networks to

operate on top of subsets of their parent’s resources, and provides isolation among them [36].

FEDERICAaims to provide an agnostic and transparent infrastructure, which supports isolated,

coexisting slices with complete user control to the lowest possible layer [36].

VINIsynthesizes container-based virtualization technologies together with a tunnelling mecha- nism into a coherent platform to achieve design goals of performance, scalability, flexibility and isolation. It allows each virtual network to define its custom topology, routing protocols, and forwarding tables [36].

UCLP developed physical isolations on a optical physical network environment. Physical isolation targets the environment with higher security demands. A resource scheduling algorithm is another isolation methodology some providers use to give the impression of isolation within the networking devices [36].

In cloud environments, in order to insure multi-tenancy applications, controllers must verify the correctness of the performance isolation throughout the cloud infrastructure [61].

textbf FlowVisor is midway-virtualized controller that is responsible for the network slices policy and handles the slices and controller communication to ensure isolation [55]. FlowVisor is a set of language abstraction tools, implemented to create vSDN blocks and create separated flow space after the switch flow tables have been divided. FlowVisor handles many large tasks in SDN topology representation, reducing the burden with vSDN mapping, configuring the tunnelling flow rules while maintaining the flow table isolation [61].

FlowVisor implemented slice isolation by configuring the traffic header with a part that is only defined for the corresponding slice path flow.FlowNis a Cloud solution for resource isolation with logically customized controllers for each tenant. FlowN used another isolation mechanism on the address space by encapsulating the client packet headers with VLAN information [93]. Although network virtualization is a standard definition, the strategies differ depending on the approach the developers selected. OpenFlow and FlowVisor are well known, though they were not flawless for manageability, isolation, flexibility and QoS. Flowviser controls only the data

plane, which means the control and network planes are out of its responsibility, and hence the platform user must find a solution for this gap. OpenFlow also suffers from standard management tool support [61].

Hu et al [61] stated that FlowVisor creates slice based ports on switches, IP address schemes, physical addresses, etc. The slices are administered and assigned to different controllers dynamically and physical infrastructure multi-tenancy is provided via sharing network hardware in a form of VN.

FlowVisor offers full isolation with VN slices and is considered to be a middle layer between the data and control planes. An OpenFlow switch and a controller are connected at an intermediate layer, the network hypervisor. A slice here is defined as a set of flows running on a topology of switches, which are isolated but may overlap if this is desired [58]. FlowVisor applied virtualization technology to create software switches to be part of VNs and implemented isolation as well as physical traffic forwarding. Moreover, this solution did not require dedicated switching hardware, specific programming tools or network CPUs [73].

Flowspaceis a header that defines slices. Sherwood et al [73] state that “The set of flows that make up a slice can be thought of constituting a well-defined subspace of the entire geometric space of possible packet headers.” Moreover, “ FlowVisor defines a slice as a set of flows, thought of as being defined by a set of (possibly non-contiguous) regions, and called the slice’s flowspace. FlowVisor ensures that network controllers are not aware of the virtualization system, slices must be solidly isolated, and slices are characterized by well configured rules. FlowVisor invented dynamic active mechanisms for monitoring, modifying and setting regulation on the transferred messages in order to confirm the slice’s isolation and transparency. As FlowVisor aimed for deployment standardization, its design led to different isolation mechanisms being adapted such as Bandwidth Isolation, Topology isolation, Switch CPU Isolation, FlowSpace Isolation, Flow Entries Isolation and OpenFLow Control Isolation [73].

FlowVisor implements Bandwidth Isolation through the use of VLAN and edited forwarding tables with flow rules entries to process priorities as set in the VLAN priority bit and executed accordingly. However, despite the effort and the improvement in bandwidth isolation, it can not be claimed as a full QoS achievement [73].

As FlowVisor is built on OpenFlow technology and each slice used its own controller, OpenFlow control isolation was a necessity through abstracting the control path and isolating it [73]. ADVisor is similar to FlowVisor, as it is also a software solution. No control plane isolation mechanisms were proposed by this work. VeRTIGO adds more flexibility in provisioning

vSDNs, and also increases the hypervisor complexity. However, it does not address the Control plane isolation limitations of the previous solutions. Auto-slice is a solution targeting software deployment via a partial control plane offloading and could be offered by distributing the hypervisor over multiple proxies. However, within each SDN domain, the control plane isolation problem still persists. In OpenVirteX the full flowspace could be provided to each tenant. The hypervisor layer is still software and extended by edge switches. However, no isolation schemes were discussed in these schemes [84].

AutoSlice aimed to create network resource slices, such as a topology forwarding table,

bandwidth, etc, with variable controller delegation for isolation confirmation [94].

Once traffic or a specific category of traffic has been dedicated to a certain VN, this is a traffic isolation implementation. In vSwitches, flow tables contain lists of forwarding policies, which must be isolated between slices otherwise the traffic forwarding will fail [73].

SDN controllers such as Beacon and Maestro (based on Java), NOX and POX (based on Python), and Nettle (based on Haskell), were implemented for SDN networks but they did not solve the issue of isolation virtualization. FlowVisor and Onix were better but they lacked accuracy and security [22]. SDN technologies and any protocols and programs are still maturing and considered to be on going work. Security aspects, and isolation in particular, are not as well developed or refined as cloud QoS or flexibility and hence is an area requiring more research. Hence, the security aspects are not even stable enough and require further research.

For VM isolation in the cloud, a best practice recommendation is to use a combination of mechanisms such as VLAN, firewall, IDS/IPS as well as data classification and policy-based management [32]. Further, the cloud provider should create an evidential report in case of an isolation break.

Bouayad et al [39] declared that multi-tenancy and isolation is one of the “open research problems” in cloud computing, alongside with “vender-lock-in, data management and cloud security". Isolation and multi-tenancy are not issues to be taken lightly as they extend throughout the cloud layers (SaaS, PaaS, IaaS) and such challenges require a solution throughout the three layers in a cloud [39].

One of the overarching questions in VN is how isolation is confirmed and specified in a network abstraction. Gutz et al [22] have attempted to resolve this on a software level via programing slices but are still developing semantics for confidentiality and integrity.

Maintaining a virtual network isolation on a traditional physical layer is a challenge by itself, yet configuring the same on a wireless environment for mobility and unbroken connection

adds another level of challenges [91]. Hence, for this thesis a decision was taken to focus on non-wireless environments.