commit 4dfad7e69195ce8d6265512dfa89a30b6b4ff6a8
Author: meliurwen <meliurwen@gmail.com>
Date:   Mon Jun 22 21:49:14 2020 +0200

    Versione consegnata

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..88583e8
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,14 @@
+*.aux
+*.bbl
+*.blg
+*.fdb_latexmk
+*.fls
+*.log
+*.gz
+*.toc
+*.out
+
+*.tex~
+*.bib~
+
+main.pdf
diff --git a/bibliography.bib b/bibliography.bib
new file mode 100644
index 0000000..cff5d1c
--- /dev/null
+++ b/bibliography.bib
@@ -0,0 +1,63 @@
+@inproceedings{suh2014building,
+  title={Building firewall over the software-defined network controller},
+  author={Suh, Michelle and Park, Sae Hyong and Lee, Byungjoon and Yang, Sunhee},
+  booktitle={16th International Conference on Advanced Communication Technology},
+  pages={744--748},
+  year={2014},
+  organization={IEEE}
+}
+
+
+@article{fundation2012software,
+  title={Software-defined networking: The new norm for networks},
+  author={Fundation, Open Networking},
+  journal={ONF White Paper},
+  volume={2},
+  number={2-6},
+  pages={11},
+  year={2012}
+}
+
+
+@inproceedings{collings2014openflow,
+  title={An OpenFlow-based prototype of SDN-oriented stateful hardware firewalls},
+  author={Collings, Jake and Liu, Jun},
+  booktitle={2014 IEEE 22nd International Conference on Network Protocols},
+  pages={525--528},
+  year={2014},
+  organization={IEEE}
+}
+
+
+@incollection{wang2013towards,
+  title={Towards a security-enhanced firewall application for openflow networks},
+  author={Wang, Juan and Wang, Yong and Hu, Hongxin and Sun, Qingxin and Shi, He and Zeng, Longjie},
+  booktitle={Cyberspace Safety and Security},
+  pages={92--103},
+  year={2013},
+  publisher={Springer}
+}
+
+
+@inproceedings{bakker2016network,
+  title={Network-wide virtual firewall using SDN/OpenFlow},
+  author={Bakker, Jarrod N and Welch, Ian and Seah, Winston KG},
+  booktitle={2016 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN)},
+  pages={62--68},
+  year={2016},
+  organization={IEEE}
+}
+
+
+
+@article{opengroup_erosion,
+  title = {Architecture and Technical FAQs},
+  author = {The Open Group},
+  year={2015},
+  journal = {collaboration.opengroup.org/jericho/faq-at.htm}
+}
+
+
+
+
+
diff --git a/chapters/01_introduzione.tex b/chapters/01_introduzione.tex
new file mode 100644
index 0000000..46ff26d
--- /dev/null
+++ b/chapters/01_introduzione.tex
@@ -0,0 +1,27 @@
+L'attuale infrastruttura di rete si è stabilizzata per oltre un decennio e si è radicata profondamente nel contesto della società umana. Tuttavia, le imprese ed i fornitori di servizi stanno iniziando a realizzare i forti limiti e l'inflessibilità dello stato attuale dell'infrastrutura con le tecnologie di rete in rapida evoluzione e le crescenti richieste da parte degli utenti.
+
+In altre parole si è riconosciuta la necessità di ristrutturare l'attuale architettura con qualcosa di più dinamico e flessibile \cite{suh2014building}.
+
+\section{Software-Defined Network}\label{sdn}
+Come risultato, per superare queste limitazioni intorno al 2005 è stata proposta la \textit{Software-Defined Network} (SDN). SDN è un concetto di rete che sta acquistando tendenza negli ultimi anni, il quale \textit{disaccoppia} il \textit{piano di controllo} e il \textit{piano dati}, \textit{centralizzando} così l'intelligenza di rete in un \textit{controller}.
+
+L'idea di separare il controllo e il piano dati è nata principalmente con l'intenzione di permettere di sviluppare ciascuna parte in modo completamente indipendente l'una dall'altra, in modo che il software non sia vincolato dalla limitazione dell'hardware. Ed eventuali amministratori di rete possano orchestrare la rete per mezzo di applicazioni di alto livello, semplificandone la gestione \cite{fundation2012software}\cite{suh2014building}.
+
+In altre parole si abbandona completamente la concezione verticale e monolitica di apparati di rete "tutto-in-uno", con l'intero stack (sia hardware e software) fornito da un'unica compagnia.
+\newline
+\newline
+In caso di cambiamenti alla rete, anziché dover configurare manualmente ogni singolo switch in conformità di questi cambiamenti, è possibile utilizzare switch programmabili controllati da un'unica applicazione esterna.
+
+\section{OpenFlow}\label{openflow}
+Il componente più importante della SDN è un protocollo di comunicazione \textit{tra il piano di controllo ed il piano dati}. Il \textit{\textbf{protocollo OpenFlow}} è stato introdotto a tale scopo, supportato dalla \textit{Open Networking Foundation} (ONF); allo stato attuale, sono disponibili controller SDN open source che implementano OpenFlow, i più noti sono: \textit{NOX}, \textit{POX}, \textit{Ryu} e \textit{Floodlight} \cite{suh2014building}.
+
+\section{Obiettivo}
+Vista la nativa caratteristica delle SDN di effettuare azioni sul flusso del traffico, in particolare azioni come \textit{scartare} pacchetti (drop) o \textit{permetterne il passaggio} ed il diffuso utilizzo del protocollo OpenFlow, in questa relazione andremo a vedere alcune funzioni di firewall implementate tramite questa relativamente \textit{"nuova"} (2005!) architettura e protocollo ed ai possibili vantaggi e risvolte che è possibile avere sia nella sicurezza che nella gestione di reti.
+
+
+\begin{figure}[H]
+  \centering
+    \includegraphics[width=\linewidth]{img/sdn-arch.png}
+    \caption{Paradigma SDN}
+  \label{fig:coffee}
+\end{figure}
diff --git a/chapters/02_descrizione_generale.tex b/chapters/02_descrizione_generale.tex
new file mode 100644
index 0000000..6df5e0d
--- /dev/null
+++ b/chapters/02_descrizione_generale.tex
@@ -0,0 +1,52 @@
+\onehalfspacing
+\section{Contesto Applicativo}
+
+\subsection{Firewall}\label{firewall_cont}
+Un \textit{\textbf{firewall}} è un componente \textit{software}, \textit{hardware} o una \textit{combinazione dei due} che filtra i flussi di traffico di rete, solitamente posto ai confini di essa. Filtra il traffico consultando una \textit{tabella di regole definite staticamente} che definiscono quale traffico può o non può passarci attraverso.
+\newline
+Le regole sono tradizionalmente espresse in \textit{cinque} tuple: 
+
+\begin{itemize}
+  \item indirizzo IP di origine
+  \item indirizzo di destinazione
+  \item protocollo di trasporto
+  \item numero della porta di origine
+  \item numero della porta di destinazione
+\end{itemize}
+
+I firewall possono utilizzare \textit{due} metodi di filtro contrastanti per applicare una politica di sicurezza della rete. Questi metodi possono essere descritti come \textit{permissivi} o \textit{restrittivi} \cite{collings2014openflow}.
+
+I \textbf{\textit{firewall permissivi}} non eliminano il traffico per impostazione predefinita, a meno che non sia specificato. Al contrario, i \textbf{\textit{firewall restrittivi}} eliminano tutto il traffico per impostazione predefinita. In entrambi i casi, i flussi desiderabili di traffico richiedono precise specifiche, rispettivamente tramite \textit{blacklist} e \textit{whitelist}.
+
+\subsection{Lavori collegati}\label{works}
+I firewall basati su OpenFlow sono stati sviluppati e studiati nella ricerca per vari scopi.
+
+Il lavoro del gruppo di \textit{Suh} \cite{suh2014building} per esempio si concentra sul miglioramento dell'interfaccia uomo-firewall per facilitare agli amministratori di rete l'installazione e l'aggiornamento delle politiche di rete, mentre il gruppo di \textit{Collings} \cite{collings2014openflow} sviluppa un firewall al fine di presentare un quadro di valutazione delle prestazioni di base per misurare l'overhead di comunicazione tra il controller e lo switch.
+
+\textit{Wang} \cite{wang2013towards} si concentra sulle possibili problematiche e sfide per quanto concerne la sicurezza ed implementare firewall robusti basati su SDN.
+
+Infine \textit{Bakker} \cite{bakker2016network} cerca di sfruttare appieno le capacità del paradigma SDN con OpenFlow e di spostare il concetto di firewall da elemento visto come barriera/filtro posto ai confini della rete ad elemento esteso su tutta la rete composto da una od una serie di poliche a seconda del tratto di rete che si va a considerare.
+
+Quest'ultimo lavoro è quello su cui l'autore di questo scritto ha deciso di \textit{focalizzare l'attenzione}.
+
+
+\section{Motivazioni}
+
+I firewall tradizionali si limitano a filtrare il traffico nei loro punti di distribuzione.
+Le ricerche sinteticamente presentate nel paragrafo \ref{works} hanno dimostrato che OpenFlow è una tecnologia adatta per il filtraggio dei pacchetti in una rete, tuttavia, eccetto per il lavoro del gruppo di \textit{Bekker} \cite{bakker2016network} non sembra essersi prestata sufficiente attenzione al modo in cui può essere utilizzata per filtrare in modo flessibile il traffico attraverso una rete che implementa di più di uno switch.
+
+Un altro motivo per cui questo argomento merita più attenzione è che è potenzialmente una \textit{valida alternativa} al dover comprare (e poi integrare e mantenere) costosi firewall esterni dedicati da fornitori come Cisco o Juniper, ognuno con il proprio stack dedicato \cite{suh2014building}; che per giunta non è detto che siano facilmente integrabili tra di loro (tra marche diverse), oltre che mantenibili e scalabili se si guarda anche con un'ottica a lungo termine.
+
+\subsection{Firewall non solo ai confini della rete}\label{firewall_confini}
+Quello che il gruppo di \textit{Bekker} propone è un firewall virtuale basato su OpenFlow in grado di filtrare il traffico di rete attraverso \textit{un'intera rete, non solo ai limiti} \cite{bakker2016network}. Di conseguenza, i dispositivi di rete possono essere protetti indipendentemente dalla loro posizione e il firewall non può essere più un singolo punto di vulnerabilità (SPOF).
+
+La soluzione proposta offre flessibilità grazie alla possibilità di raggruppare le regole del firewall in domini di politiche (policy domains) che possono quindi essere assegnati agli switch OpenFlow; l'applicazione delle regole può essere selettiva in base a criteri diversi ed arbitrari come posizione, ora, tipo di dispositivo, ecc...
+
+\subsection{Nella pratica}
+In pratica se ogni switch ethernet potesse funzionare come un firewall tradizionale, cambierebbe il modo in cui la politica di sicurezza viene implementata in un ambiente di rete. Immaginiamo se ogni switch ethernet fosse un firewall multiporta, quindi i criteri del firewall potrebbero essere implementati in tutta la rete, su ogni porta di ingresso di switch e su ogni collegamento tra switch. Ci sarebbero firewall per ogni server, desktop, ed ogni altro collegamento e la politica del firewall sarebbe implementata da un \textit{controller} che mantiene una visione \textit{\textbf{globale}} del traffico dell'applicazione corrente e potere decisionale su quale traffico dovrebbe essere consentito.
+
+Avere una o più politiche di sicurezza applicata su tutto l'ambiente significherebbe una vera e propria \textit{\textbf{erosione del perimetro}} \cite{opengroup_erosion} di sicurezza della rete stessa.
+
+Questo andrebbe tamponare in maniera non trascurabile il problema nella sicurezza che pone la politica negli ultimi anni di permettere agli utenti di collegare alla rete interna dell'organizzazione i propri dispositivi personali invalidando automaticamente l'oramai obsoleto \textit{"assioma"} che il traffico malevolo può venire solo dall'esterno \cite{bakker2016network}.
+
+Detto questo, avere molte politiche di sicurezza implementate da gestire manualmente sarebbe un vero inconveniente. Tuttavia, come accennato nei paragrafi \ref{sdn} e \ref{openflow} con un'architettura di controller, la politica (policy) verrebbe creata una volta sola e poi trasferita atuomaticamente a tutti i dispositivi di rete associati per essere applicata.
diff --git a/chapters/03_requisiti_specifici.tex b/chapters/03_requisiti_specifici.tex
new file mode 100644
index 0000000..731b984
--- /dev/null
+++ b/chapters/03_requisiti_specifici.tex
@@ -0,0 +1,74 @@
+\onehalfspacing
+
+\section{Capisaldi di Design}
+Sono stati fissati \textit{\textbf{tre punti chiave}} che devono essere rispettati durante l'implementazione del firewall virtuale \cite{bakker2016network}:
+\begin{itemize}
+  \item Un firewall basato su OpenFlow deve essere in grado di \textit{\textbf{filtrare il traffico in modo simile ad un firewall tradizionale}}, tramite la definizione di regole di flusso.
+  \item Dovrebbe essere possibile \textit{\textbf{distribuire le regole su un'intera rete senza la necessità di configurare gli switch uno alla volta}}; ciò affronta il problema di proteggere un'intera infrastruttura di rete da minacce sia interne che esterne.
+  \item Poiché non si può presumere che le reti siano omogenee, dovrebbero essere implementate \textit{\textbf{su una rete politiche di sicurezza eterogenee}}; ciò richiede l'implementazione di un meccanismo che consente a diverse parti di una rete di filtrare diversi flussi di traffico (vedasi nei paragrafi successivi).
+\end{itemize}
+
+\section{Componenti principali}
+
+Per poter implementre le proposte citate nella sezione \ref{firewall_confini}, è stato sviluppato \code{ACLSwitch}\footnote{\url{https://github.com/bakkerjarr/ACLSwitch}}, un'applicazione sviluppata tramite il controller \textit{framework Ryu} che si propone come firewall virtuale distribuito su tutta una determinata rete.
+
+Altri componenti importanti sono le \textit{\textbf{Access Control List}} (ACL) e le \textit{\textbf{Policy Domains}} (Politiche di Dominio). L'implementazione effettuata ad-hoc delle ACL eredita tutti i concetti dei firewall tradizionali; mentre l'inclusione delle Politiche di Dominio \textit{estende} le attuali capacità degli attuali Firewall basati su OpenFlow, fornendo all'amministratore di rete meccanismi di distribuzioni delle regole ACL a gruppi di switch senza la necessità di configurare in maniera separata ognuno di essi. Il metodo di creare regole singole poi distribuirle a dispositivi specifici è tipico sia dei firewall tradizionali che di basati su OpenFlow. Tramite \textit{ACLSwitch} questa funzionalità viene aumentata presentando un meccanismo per raggruppare le regole in \textit{policy domains} che nel pragrafo seguente verranno meglio esplicate.
+
+\section{ACL Estese}
+
+Le capacità delle ACL sono state estese aggiungendo campi extra oltre alle solite 5 tuple (vedasi \ref{firewall_cont}) risultando come segue \cite{bakker2016network}:
+
+\[
+  \text{regola ACL } r = \overbrace{
+    ip\_src, ip\_dst, tp\_proto, port\_src, port\_dst
+   }^\text{Le 5 tuple ACL base},
+   \overbrace{
+    policy, action, time\_start, time\_duration
+   }^\text{Estensioni}
+ \]
+
+I nuovi campi si identificano come segue:
+\begin{itemize}
+  \item \textbf{\textit{policy}}: è il primo campo ed identifica la politica di dominio di cui fa parte la regola.
+  \item \textbf{\textit{action}}: indica, come suggerisce il nome, l'azione da intraprendere, per esempio se un certo traffico che matcha debba essere inoltrato o scartato.
+  \item \textbf{\textit{time\_start}} e \textbf{\textit{time\_duration}}: sono campi facoltativi ed indicano rispettivamente la data di inizio e la durata in cui la regola debba essere in vigore.
+\end{itemize}
+
+\subsection{Policy Domains}
+
+Un policy domain rappresenta una relazione tra le regole ACL e gli switch OpenFlow. Un policy domain può contenere molte regole ACL ma ogni singola regola ACL può essere membro di un solo policy domain. Un policy domain può essere assegnato a molti switch e ad ogni switch possono essere assegnati più policy domain (Fig. \ref{fig:domains}).
+
+L'astrazione fornita dai policy domain consente a un'intera rete di essere protetta da una singola politica e, per estensione, da un singolo meccanismo. Tuttavia, offrono anche la flessibilità di assegnare diversi gruppi di regole a switch separati e, per estensione, a punti diverse della stessa rete.
+
+\begin{figure}[H]
+  \centering
+  \begin{subfigure}[b]{0.46\linewidth}
+    \includegraphics[width=\linewidth]{img/domains.png}
+    \caption{I policy domains (ellissi colorate) possono essere assegnati a switch per proteggere simultaneamente l'intera rete e mettere in vigore altre politiche \cite{bakker2016network}}
+    \label{fig:domains}
+  \end{subfigure}
+  \begin{subfigure}[b]{0.46\linewidth}
+    \includegraphics[width=\linewidth]{img/pipeline.png}
+    \caption{Implementazione della pipeline \cite{bakker2016network}}
+    \label{fig:pipeline}
+  \end{subfigure}
+\end{figure}
+
+\section{Deploy delle Flow Table Entries}
+
+OpenFlow supporta due stili di distribuzione delle FTE: \textit{deploy reattivo} e \textit{deploy proattivo}.
+
+Il \textbf{\textit{deploy reattivo}} viene utilizzato dal controller come risposta a un messaggio \code{packet-in} da uno switch. Quando si creano firewall utilizzando OpenFlow, questa modalità non è adatta a causa del non trascurabile overhead che impone al controller per elaborare decisioni sul traffico.
+
+Questo problema viene risolto \textit{deployando in modalità proattiva} agli switch le FTE nel momento in cui vengono create le regole ACL.
+
+\section{Pipeline}\label{pipeline}
+
+Come mostrato in Fig. \ref{fig:pipeline}, la pipeline è la seguente \cite{bakker2016network}:
+\begin{itemize}
+  \item \code{Table 0} è la prima tabella della pipeline e contiene FTE associate a bloccare flussi di traffico facenti parte di una lista nera; in altre parole i pacchetti che matchano vengono scartati. I pacchetti che corrispondono alla voce \code{table-miss} vengono inoltrati alla \code{Table 1} tramite l'azione \code{Goto-Table}. Pertanto, questa tabella viene utilizzata per fare una prima scrematura, bloccando flussi di traffico \textbf{\textit{indesiderati}}.
+
+  \item \code{Table 1} è la tabella successiva nella pipeline, contiene FTE associate a far passare flussi di traffico facenti parte di una lista bianca; in altre parole i pacchetti che matchano vengono direttamente inoltrati alla \code{Table 2}, il resto, ossia quelli che corrispondono alla \code{Table-miss} vengono scartati.
+
+  \item \code{Table 2} esegue il ruolo di un normale switch ethernet.
+\end{itemize}
diff --git a/chapters/04_conclusioni.tex b/chapters/04_conclusioni.tex
new file mode 100644
index 0000000..a54c0f9
--- /dev/null
+++ b/chapters/04_conclusioni.tex
@@ -0,0 +1,6 @@
+\onehalfspacing
+OpenFlow fornisce tutti i mezzi principali per configurare switch compatibili ed applicare le principali politiche di sicurezza. Come già accennato nel capitolo \ref{works}, gli articoli diversi da quello di \textit{Bakker} che l'autore di questo testo ha consultato sembrano non sfruttare appieno la flessibilità offerta da questa tecnologia; consentendo solo di configurare un solo switch o di farlo singolarmente per ognuno.
+
+La soluzione proposta dal gruppo di \textit{Bakker} presenta un meccanismo che combina questi due approcci in modo che gli host all'interno di una rete possano essere protetti dalle minacce \textbf{\textit{sia interne che esterne}}, facilitando al contempo il settaggio di diverse operazioni di filtraggio tra gruppi di switch diversi.
+
+Oltretutto, \textbf{\textit{come nota personale}}, l'autore di questo testo si sente di aggiungere la concatenzione nella pipeline (cap. \ref{pipeline}) di una tabella con politiche permissive succeduta da una con politiche restrittive permette di semplificare sia la logica che il numero di regole necessarie; questo, oltre a conferire un ovvio vantaggio sulla mantenibilità da parte degli amministratori di rete, permette anche di garantire prestazioni ottimali, visto che come mostra il lavoro del gruppo di \textit{Collings} \cite{collings2014openflow}, sono molto legate (specialmente per quanto riguarda la latenza) al numero di regole applicate.
diff --git a/frontespizio.tex b/frontespizio.tex
new file mode 100644
index 0000000..c8e6d20
--- /dev/null
+++ b/frontespizio.tex
@@ -0,0 +1,49 @@
+\begin{titlepage}
+\begin{onehalfspace}
+	\begin{wrapfigure}[4]{l}[22mm]{0.25\textwidth}
+		\vspace*{-7mm}
+		\centering
+		\includegraphics[width=0.25\textwidth]{img/logo_unimib.pdf}
+	\end{wrapfigure}
+	\par
+	\noindent Università degli Studi di Milano Bicocca \\
+	\textbf{Scuola di Scienze \\
+			Dipartimento di Informatica, Sistemistica e Comunicazione \\
+			Corso di Laurea Magistrale in Informatica}
+\end{onehalfspace}
+
+\vfill
+\par
+
+\begin{doublespace}
+\begin{center}
+	{\Huge \textbf{\\Compito a casa di Sistemi e Servizi di Telecomunicazione}}
+\end{center}
+\begin{center}
+	{\Large \textbf{\\Implementazione di una funzione firewall mediante SDN con architettura OpenFlow}}
+\end{center}
+\end{doublespace}
+
+\vfill
+\par
+
+\begin{onehalfspace}
+
+\vspace{8mm}
+\par
+
+\begin{flushright}
+	{\large \textbf{Autore:} \\
+			\textit{Michele Salanti 793091}
+	}
+\end{flushright}
+\end{onehalfspace}
+
+\vfill
+\par
+
+\begin{center}
+	{\large \textbf{Anno Accademico 2019--2020}}
+\end{center}
+
+\end{titlepage}
diff --git a/img/domains.png b/img/domains.png
new file mode 100644
index 0000000..5a60c3f
Binary files /dev/null and b/img/domains.png differ
diff --git a/img/logo_unimib.pdf b/img/logo_unimib.pdf
new file mode 100644
index 0000000..d576169
Binary files /dev/null and b/img/logo_unimib.pdf differ
diff --git a/img/pipeline.png b/img/pipeline.png
new file mode 100644
index 0000000..4c52d55
Binary files /dev/null and b/img/pipeline.png differ
diff --git a/img/sdn-arch.png b/img/sdn-arch.png
new file mode 100644
index 0000000..fd9c626
Binary files /dev/null and b/img/sdn-arch.png differ
diff --git a/main.tex b/main.tex
new file mode 100644
index 0000000..9b076a4
--- /dev/null
+++ b/main.tex
@@ -0,0 +1,62 @@
+\documentclass{report}
+\usepackage[utf8]{inputenc}
+\usepackage{tocloft}
+\usepackage[italian]{babel}
+
+\usepackage{setspace}
+\usepackage{graphicx}
+\usepackage{geometry}
+\usepackage{wrapfig}
+
+\usepackage{listings}
+\usepackage{subcaption}
+\usepackage{float}
+\usepackage{caption}
+\usepackage{enumerate}
+\usepackage{setspace}
+\usepackage{url}
+\usepackage{amsmath}
+
+\setcounter{secnumdepth}{6}
+
+\def\code#1{\texttt{#1}}
+
+
+% Indice e citazioni linkate
+\usepackage{hyperref}
+\hypersetup{
+    colorlinks,
+    citecolor=black,
+    filecolor=black,
+    linkcolor=black,
+    urlcolor=black
+}
+
+
+\title{Documento dei Requisiti}
+\author{Mattia Busnelli e Salanti Michele}
+
+\begin{document}
+
+\include{frontespizio}
+
+\renewcommand{\cftsecleader}{\cftdotfill{\cftdotsep}}
+\tableofcontents
+
+
+\chapter{Introduzione}
+\input{chapters/01_introduzione}
+
+\chapter{Contesto Applicativo e Motivazioni}
+\input{chapters/02_descrizione_generale}
+
+\chapter{Implementazione}
+\input{chapters/03_requisiti_specifici}
+
+\chapter{Note Finali}
+\input{chapters/04_conclusioni}
+
+\bibliographystyle{unsrt}
+\bibliography{bibliography.bib}
+
+\end{document}