% !TEX encoding = IsoLatin

The orchestrator chosen as test-bed for this thesis work is OpenStack cloud tool kit.

\subsection{OpenStack introduction}

OpenStack is a set of software tools for building and managing cloud computing platforms for public and private clouds~\cite{openstack}.
It is used to deploy compute instances, storage devices and\break networking communication in a datacenter, so it can be defined as Infrastructure-as-a-Service (IaaS) discussed in Section~\ref{subsec:cloud_computing}.
All the software tools that compose this open source project can be controlled in different ways, from a command line interface (CLI) or via a web dashboard provided to be the most intuitive mode to interact and control the infrastructure. Both of them lean on the REST API, which provides the best and complete way to access to all the resources.

%The OpenStack suite could be deployed following the scripts in the appendix \ref{cap:openstack-installation} that describes how to provide basic resource services for compute, networking, storage and security.

The ``core'' of OpenStack is made up of seven key components, \textit{Nova} for computation, \textit{Neutron} for the networking, \textit{Horizon} to provide a web dashboard and \textit{Cinder}, \textit{Keyston}, \textit{Glance}, \textit{Heat} that offer additional services for storage and access.

\subsubsection{Security}

OpenStack suite provides a basic security system called \textit{security group} which is a list of stateless filtering rules that could be added to the instance creation process to ensure security protection according to the rules specified in the security group.

This security mechanism is implemented through the Host Iptables tool, the orchestration tool builds table chains from the \code{FORWARD} chain, through the \code{neutron-openvswi-sg-chain} that redirects all the traffic to the specific \code{INPUT}/\code{FORWARD}/\code{OUTPUT} table chain of the instance.

OpenStack creates one Iptables chain for each Virtual Machine that belongs to a security group and injects all the rules into these tables. 

The following section shows how the traffic flows into the network, through the virtual switches and different physical hosts.

\subsection{Filtering points}

From the thesis analysis provided by my colleague Andrea Della Chiesa, OpenStack presents one solution to enforce security on its architecture, but there are many different filtering points already present in this cloud infrastructure over the Host Iptables. He found that Guest instance Iptables could be another point that could provides security operations and, the virtual switches controlled by OpenFlow could behave as well as a firewall.

The OpenStack network architecture and how the packets flows between VMs and hosts are represented in the Figure~\ref{fig:openstack-neutron}.

\begin{figure}[H]
	\centerline{\includegraphics[width=0.9\textwidth]
		{neutron-scheme.png}}
	\caption{OpenStack internal architecture}
	\label{fig:openstack-neutron}
\end{figure}

The following chapter analyizes the performance of the filtering points just mentioned taking into account distinct metrics to undestand the characteristics of each one.

\subsection{Packet flows}

First and foremost it is fundamental to figure out all the possible communication scenarios that could take place to know where are the best filtering points. Understanding all the possible paths, that the traffic pattern can get, allows the security service to be performed efficiently.

The following cases represents all the possible types to exchange traffic.

\begin{itemize}
	\item 
	\textit{Service to service} communication: in this scenario two services inside the same Virtual Machine communicate each other. It does not matter if they are process or containers, but their packets does not leave the network stack of the instance and all the internal traffic is not visible from the outside environment. This involves that the instance itself it is the only filtering point available to enforce security rules.
	
	\item
	\textit{VM to VM} communication: in this case the VM traffic leaves the instance to land in a Linux Bridge called \code{QBR} which is connected, through a virtual interface, to an OpenFlow switch.
	This allows to exploit other two filtering points, one represented by the Linux Bridge which leans on the Host OS Iptables, and the other one is represented by the virtual switch that behaves as a firewall.
	
	\item
	\textit{Subnet to subnet} communication: two VMs on the same subnet can communicate directly, the packets coming from a virtual interface are forwarded to the destination virtual interface. Otherwise  is different the situation in which two VMs have to exchange traffic between them, but they belongs to different virtual L2 networks. The packets cannot reach directly the destination, but the flow is modify by the OVS to reach before a virtual router which is named \code{QROUTER} in the Figure \ref{fig:openstack-neutron}.
	
	\item
	\textit{Host to host} communication: it is frequent that in a multi-node deployment two VMs have to communicate, but they are hosted in different physical machines. In this case OpenStack provides an additional virtual bridge called \code{br-tun} which is an end-point of a tunnel created with the other physical hosts. The packets come from the \code{br-int} switch and they are forwarded to this bridge through \code{path-tun} virtual interface. The packets are enveloped in a VxLAN protocol and they are sent on the physical network. Once they are received, the tunnel header is deleted and the packets are forwarded into the receiver \code{br-int} switch.
	
	\item
	\textit{Internet} communication: this last scenario represents the traffic pattern that covers the communication between the instances running on the cloud infrastructure and the external destinations.
	The packets have to reach the \textit{network node} mentioned before, which is directly connected to the exterior network, than the traffic goes to the virtual router that is the real default gateway. \newline
	The IP header is modified, because it has a private IP address, the \code{QROUTER} sets, as source address, the IP address of the router interface that is exposed outside the cloud deployment or  the ``floating IP'' associated to the VM, if it has one.\newline
	After this operation, the packet is forwarder to \code{br-ext} switch and it is sent outside through the second NIC of the physical machine.
	This last one bridge is another filtering point that could be used to enforce the rules that concern the traffic coming from and the one which goes to the external networks.
	
\end{itemize}

Once understood how packets flows inside and outside the cloud infrastructure, it is now possible to design a distributed firewall that optimizes where the rules have to be enforced, which exploits the filtering points previous described.
