Virtual Machines

The virtualization software is the main distinguishing factor for network simulators available on the market. The program used by the simulator has particularities that result in various types of VM and types of network simulators. In general, we can divide the VMs into two main types: the system VMs and the process VMs. These two types of VMs were defined by James E. Smith and Ravi Nair as follows:

"A process VM is a virtual platform that executes an individual process. This type of VM exists solely to support the process; it is created when the process is created and terminates when the process terminates. In contrast, a sys-tem VM provides a complete, persistent syssys-tem environment that supports an operating system along with its many user processes. It provides the guest operating system with access to virtual hardware resources, including net-working, I/O, and perhaps a graphical user interface along with a processor and memory."[Smith and Nair 2005]

Figure 2.4 – Description of process VM and system VM from [Smith and Nair 2005]

Figure 2.4 illustrates several differences between process VM and system VM. A system VM virtualization software virtualizes the hardware of a machine and lets the user install an OS on that virtualized hardware. An example of system VM virtualiza-tion software is VirtualBox. In a process VM virtualizavirtualiza-tion software, the user can only run processes on the virtualized OS forced on by the virtualization software. The im-posed virtualized OS is dependent on the method used by the virtualization software.

An example of process VM virtualization software is Wine. Containers are also process VMs.

A user using a system VM virtualization software can choose the OS to install, but the user needs to configure it himself in most cases. Moreover, the process can be lengthy and the launch of dozens of system VMs at the same time costs a lot in term of computational resources. A process VM is designed to start quickly and does not need much configuration effort. Moreover, the resources required for a process VM are a lot cheaper. Scalability is also one of the main features of process VMs, making them interesting for building significant virtual networks. The drawback of process VMs is that virtualization softwares use different methods to simulate the OS (clonable kernel, bundles of commonly used libraries, etc.) and those methods limit the capabilities of the process VM.

The method employed by the virtualization software to create a VM can further divide the process VMs and system VMs into more types of process VMs and system VMs. Each of these methods has a different approach to tackle the virtualization chal-lenge peculiar to either system VMs – intercept the system call of guest OS – or process VMs – virtualizing the guest OS. Different methods create different results, and net-work simulators then choose different virtualizing software according to the features those methods provide. It leads to various network simulators that do not have the same purpose.

For example, Hynesim handles system VMs and relies on virtualizing softwares such as VirtualBox, QEMU/KVM, LXC, and VMware. Meanwhile, IMUNES creates virtual networks with process VMs using the method described in[Zec 2003]. Another example of process VM network simulator is Mininet. Mininet uses namespaces to create different VMs and can easily create more than a hundred VMs in a virtual network in under a minute on an average computer. However, because Mininet uses namespaces, all the created VMs use a Linux kernel, and they share the same file system. Not only is there no isolation between the namespaces but it also creates problems for services as all services share the same configuration files.

Overall, network simulators using system VMs can create very realistic virtual net-works with a large variety of virtual hosts that are not dependent on the OS of the host machine. However, that virtual network consumes many resources, and each vir-tual host needs a specific configuration. Network simulators using process VMs can create a massive number of lightweight VMs rapidly with different topologies. The virtual hosts do not require an individual configuration. They can use the programs installed on the host system and possess a file system where any change is discarded at the end of the simulation. However, on the downside, the virtual host OS depends on

the network simulator, and the virtual machines can do limited actions on the virtual networks.

In a nutshell, a system VM virtual network allows diversity but is resource expen-sive, while a process VM virtual network is easy to create and less costly, but the virtual hosts’ capacities are limited. Table2.8 presents a classification of a few existing network simulators:

System network simulator Process network simulator Cloonix[Peach et al. 2016] Marionnet[Loddo and Saiu 2008]

Hynesim[Prigent et al. 2005] Mininet[De Oliveira et al. 2014]

GNS3[Welsh 2013] MLN[Begnum 2006]

Unified Networking Lab[Vlasyuk et al. 2016] Netkit[Rimondini 2007]

IMUNES[Puljiz and Mikuc 2006]

CORE[Ahrenholz et al. 2008]

Table 2.8 – Examples of network simulators

At this point, choosing a network simulator requires selecting the proper trade-off: either simulating a complete network capable of diversity, but at a high cost, or simulating a network quickly and at a larger scale, but with restrictions on what the virtual hosts can do. Most virtual networks used in the evaluation of security products and services, like testbed environments, are built by network simulator using system VMs or an overlay network connected to system VMs. Both solutions are expensive in resources but necessary to execute the workload drivers or script that generate the evaluation data.

2.4 Conclusion

The evaluation of services and security products consists in the verification of sev-eral heterogenous properties (compliance with the specifications, processing capacity, resilience, policy accuracy, etc.). Those properties are verified with different methods and tools. The role of the evaluator is to select compatible tools together, compose them on a network infrastructure and orchestrate them to work together to obtain a reliable evaluation of the target. Such tasks consume time and resources, especially to evaluate all properties of services and security products.

So far, only testbed environments can test all properties of services and security products. They can deploy at a large scale homegrown scripts or involve a large number of evaluator to manually generate activity. Contrary to real-world traces, the evaluator has full knowledge of the data produced. However, the resource and time needed to set up and maintain such an environment are high, especially when the scale is significant.

One of the reasons for that cost is the virtual infrastructure of testbed environments.

Testbed environments generally relies on system VMs. Such VMs properly support the application and programs generating data.

Other virtual networks that relies on process VMs cannot support those programs.

Those virtual networks are a lot more cost efficient at a large scale. The only thing limiting their use is the lack of method to generate reliable evaluation data with the available resources. The goal of this thesis is to propose an alternative method to effectively reduce the effective costs of virtual networks in an evaluation context. We aim to propose a new method of generation of data that is independent of the virtual infrastructure and can function on less expensive infrastructure like a virtual network using process VMs.

3 Formal Model of