% Policy Services

Before explaining how the distribution and the optimization modelling is done, it is essential to underline the role of the ``\textit{Policy tool library}'', as it shown in the high level design~\ref{fig:hight-level-design}. In the thesis economy it provides functionalities to manage security policies and filtering rules.

It is integrated to solve all the issues introduced in Section~\ref{sec:use-case}, where it explains that policy inconsistency and rule anomalies represent the reasons why a policy refinement is necessary.
The security problems faced by the design are \textit{intra-policy anomalies}, which means there are misconfiguration in the same security domain, and \textit{inter-policy anomalies} that represents a more complex issue, because conflicting rules between different security domains need to be enforced side by side may be on the same filtering points (e.g the entity A wants to deny all the tcp incoming traffic from 8080 port and the entity B wants to allow that traffic pattern).

For these reasons the steps depicted below represent the process flow of the security policies.
\newline

\begin{figure}[H]
	\resizebox{0.89\textwidth}{!}{
		\centering
		
		% Define block styles
		\tikzstyle{limiter} = [ellipse, draw, text width=5.2em, text badly centered, inner sep=0pt, minimum height=4em]
		\tikzstyle{biglimiter} = [ellipse, draw, text width=6em, text centered, inner sep=0pt, minimum height=4em, minimum width=9em]
		\tikzstyle{block} = [rectangle, draw, text width=6em, text centered, rounded corners, minimum height=3em]
		\tikzstyle{bigblock} = [rectangle, draw, text width=7.5em, text centered, rounded corners, minimum height=3em]
		\tikzstyle{io} = [trapezium, trapezium left angle=70, trapezium right angle=110, text width=4em, minimum height=2.5em, text badly centered, draw=black, fill=blue!30]
		
		\begin{tikzpicture}[node distance = 3cm, auto, >=Stealth]
		% Place nodes	
		
		\node [io] (io) {New policy};
		\node [bigblock, right of=io, node distance = 3.8cm] (char) {Characterization process};
		\node [biglimiter, below of=char] (char-policy) {Characterized policy};
		\node [block, below of=char-policy] (res) {Refinement process};
		\node [limiter, right of=res, node distance = 3.8cm] (isp) {Provider policy};
		\node [limiter, below of=res] (policies) {Reconcilied policy};
		
		\umlnote[x=8,y=0, width=8em]{char}{Entity information}
		\umlnote[x=0,y=-4, width=6em]{res}{Inter-policy conflicts $\;$ analysis}
		\umlnote[x=0,y=-6, width=6em]{res}{Reconciliation}
		\umlnote[x=0,y=-8, width=6em]{res}{Resolution Strategy}
		% arrows
		
		\draw[->] (io) -- (char);
		\draw[->] (char) -- (char-policy);
		\draw[->] (char-policy) -- (res);
		\draw[<-, dashed] (res) -- (isp);
		\draw[->] (res) -- (policies);
		
		\end{tikzpicture}
	}
	\caption{Policy service design.
		\label{fig:policy-model}}
\end{figure}

\begin{itemize}
	\item
	Policy characterization: it solves the ambiguity in rules definition between different security policies. In other words it is fair that a filtering rule, defined by an entity, provides security protection for the entity itself, but in a share infrastructure could interfere with others entities present on it.
	When a new policy is given in input, all the rules that compose the policy it self are analyzed and it is checked if they are well-formed, this means each one is related to the entity that requires it.
	\pagebreak
	
	The possible scenarios to understand if they are well-formed are the following:
	
	\begin{itemize}
		\item 
		no IP address clause, this rule has not relationship with the entity, so it will be\break duplicated and the entity network address will be added as condition clause, one as source IP and the second one as destination IP network;
		
		\item
		one IP address clause, this rule specifies an IP address in its condition clauses, if it is a subset of the entity network the rule is not changed, otherwise the network IP address of the related entity is added;
		
		\item
		two IP address clauses, this rule has both IP source and destination addresses and, at least, one of them has to be a subset of the entity network. If neither the source and the destination IP addresses are related to the own entity, the rule is marked as not well-formed and it is discarded.
	\end{itemize}

	This will not change the semantic of the rule, because the process add informations that are implicitly described in the rule, but it expresses them explicitly, adding the condition clauses.
	
	\item 
	Inter-policy conflicts analysis: it solves all the conflicts between the rules of the same policy, in other words this step analyses the policy, it detects all the anomalies and the conflicts and it deletes them.
	
	\item
	Policy reconciliation: it generates a unique reconciled policy between the ISP security policy and an entity. The former has higher priority then the second one. It will have no effect doing policy reconciliation between entity policies, because there is no conflicts due to the policy characterization.
		
\end{itemize}