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{Firewall}
Un firewall è un dispositivo di rete solitamente interposto tra due reti per filtrare il traffico tra loro secondo una certa politica di sicurezza. Un firewall fornisce protezione eseguendo controlli basati su regole ai pacchetti. I firewall possono essere hardware, software od una combinazione dei due. Un firewall hardware può essere un componente di un dispositivo dedicato od un componente di un router a banda larga:
\begin{itemize}
\item Un \textit{\textbf{firewall hardware}} è in genere implementato sul gateway principale che collega una rete interna protetta e il resto della rete.
\item Un \textit{\textbf{firewall software}} è un software in esecuzione su un computer, che protegge il suddetto computer limitandone i tentativi esterni di accesso.
\end{itemize}
\section{Software-Defined Network}\label{sdn}
I firewall hardware tendono ad offrire una protezione e delle prestazioni migliori rispetto ai firewall software. Essi possono avere funzioni di filtraggio di pacchetti in modalità stateless a vere e proprie applicazioni stateful:
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}.
\begin{itemize}
\item I filtri \textbf{\textit{stateless}} di pacchetti applicano regole di filtro per accettare o rifiutare singoli pacchetti senza esaminare la relazione tra di loro. Il filtraggio dei pacchetti senza stato fornisce un controllo meno efficace ma al contempo mostra prestazioni elevate.
\item Le applicazioni \textbf{\textit{stateful}} applicano meccanismi di sicurezza a specifiche applicazioni tenendone traccia dei vari stati. Il controllo specifico di un'applicazione è piuttosto efficace, al costo però di una sensibile degradazione generale delle prestazioni rispetto ad un filtro stateless.
\end{itemize}
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.
\section{Motivazioni}
\newline
\newline
Nonostante i vantaggi, i firewall hardware presentano tre principali inconvenienti:
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.
\begin{itemize}
\item I firewall hardware sono spesso \textit{costosi}.
\item I costi di manutenzione e aggiornamento dei firewall hardware sono in genere associati a configurazioni complicate e specifiche del fornitore.
\item L'interoperabilità tra i firewall hardware realizzati da diversi fornitori non può sempre essere facilmente raggiunta.
\item I guasti sui firewall hardware possono comportare la sostituzione e la riconfigurazione di più unità hardware al fine di garantire una politica coerente su una rete.
\end{itemize}
\section{OpenFlow}\label{openflow}
Questi inconvenienti potrebbero essere alleviati sostituendo i firewall hardware con alternative flessibili ed a basso costo; il paradigma di rete emergente SDN (Software Defined Networking) è un buon candidato.
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}
I firewall hardware orientati a SDN sono in grado di preservare alte prestazioni sul traffico e consentire un controllo estremamente flessibile sul traffico.
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.
Pertanto, le normative sul traffico possono essere eseguite su un gran numero di switch SDN-oriented senza incorrere in elevati costi di manutenzione.
In questo testo ci baseremo sul prototipo di un firewall hardware SDN-abilitato (con stati) e che fa uso di OpenFlow come protocollo di comunicazione. Ci focalizzeremo dell'impatto che può avere sulle prestazioni il numero di regole applicate su di un firewall e parleremo delle pratiche da adottare (o da evitare) per ridurre il più possibile questo impatto.
\newline
\newline
In sostanza questo lavoro si baserà principalmente sulle ricerche del team di Collings\cite{collings2014openflow} e di Khaled\cite{salah2011performance}.
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.
Sono stati fissati \textit{\textbf{tre punti chiave}} che devono essere rispettati durante l'implementazione del firewall virtuale \cite{bakker2016network}:
Il firewall controller può potenzialmente essere posizionato in un qualsiasi punto della rete. Le regole sono specificate nella tabella di flusso che sono gestite sia dallo switch che dal firewall controller (vedi tabella \ref{fig:flow}). Una voce nella tabella di flusso corrisponde ad una regola che gestisce il flusso del traffico. Lo switch agisce come un banale inoltratore di pacchetti basato sulle regole di sicurezza definite nella sua tabella di flusso. Il firewall controller utilizza la sua tabella di flusso per tenere traccia delle decisioni intraprese sul traffico.
Un canale di comunicazione dedicato viene mantenuto tra lo switch e il controller del firewall. Attraverso questo canale, lo switch invia le informazioni sui flussi di traffico non identificati al controller per l'ispezione e il controller invia le decisioni allo switch.
\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{img/flow.png}
\caption{Esempio di Tabella di Flusso (Flow Table)}
\label{fig:flow}
\end{figure}
\section{Modalità Permissiva e Restrittiva}
Sono state presenti due modalità per specificare le azioni di controllo predefinite in base al traffico:
\begin{itemize}
\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\textbf{\textit{Modalità permissiva:}} rifiuto selettivo dei flussi. Ossia che il traffico viene normalmente inoltrato di default a meno che non venga esplicitamente negato.
\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\textbf{\textit{Modalità restrittiva:}} autorizzazione selettiva dei flussi. Ossia che il traffico viene negato di default a meno che esplicitamente consentito.
\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}
\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.
\section{First Deny Last Allow}
Un controller firewall adotta una metodologia \textit{"first deny last allow"} per determinare un'azione di controllo su un flusso.
Un controller privilegia flusso che "matcha" (corrisponde) ad una regola di rifiuto (deny rule) rispetto a una regola di permissiva (allow rule). La precedenza delle regole di rifiuto sulle regole di consenso allevia il rischio per la sicurezza derivante da regole potenzialmente in conflitto nella tabella di flusso del controller ed anche evita che i pacchetti debbano percorrere un'intero set di regole prima di essere scartati.
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{Posizione delle regole: Valutazione delle performances}
\section{ACL Estese}
In seguito verranno brevemente presentate le prestazioni di un firewall di rete basato su regole. In genere, e come mostrato nella Figura \ref{fig:firewallrulebase}1, i pacchetti in entrata che trasportano richieste arrivano al firewall e vengono messi in coda per l'elaborazione in più fasi:
Le capacità delle ACL sono state estese aggiungendo campi extra oltre alle solite 5 tuple (vedasi \ref{firewall_cont}) risultando come segue \cite{bakker2016network}:
\begin{enumerate}
\item La prima fase prevede l'esecuzione di funzionalità di collegamento dati e livello di rete.
\item Successivamente viene attivato il motore di ricerca delle regole del firewall per elaborare i pacchetti in entrata.
\end{enumerate}
\[
Salah cita da un'altra fonte \cite{salah2011performance} che è stato dimostrato che le regole in fondo alla tabella possono essere scoperte da un aggressore esterno. Un utente malintenzionato può quindi lanciare un attacco che prenda di mira principalmente le regole di in fondo alla tabella e degradi efficacemente e rapidamente le prestazioni di un firewall con una serie di attacchi DoS a basso volume di traffico. Questo tipo di attacco viene chiamato "attacco di complessità algoritmica" (Complexity-algorithmic attacks), è una classe di attacchi DoS a bassa velocità che sfruttano le carenze algoritmiche nella progettazione del software \cite{salah2011performance}.
\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:
Risulta quindi importante capire che impatto possono avere questi attacchi sulle prestazioni dei firewall in modo da trovare modi per mitigare il problema.
\subsection{Misure prese}
Il tema di Salah ha effettuato le misurazioni sottoponendo il firewall a due tipi di traffico: traffico normale e traffico DDoS indirizzato a regole diverse situate in posizioni diverse nell'insieme di regole del firewall.
\newline
\newline
In base all'hardware a disposizione del team è stato misurato che:
\begin{itemize}
\begin{itemize}
\item\textbf{\textit{policy}}: è il primo campo ed identifica la politica di dominio di cui fa parte la regola.
\item Il valore medio era di circa 0,5 ms per l'interrogazione di 10.000 regole, ossia 0,05 microsecondi per singola 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 Il tempo medio di elaborazione del kernel del driver del dispositivo e dell'elaborazione IP ed è stato riscontrato che il valore medio è di circa 2,65 microsecondi.
\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}
\end{itemize}
\subsection{Policy Domains}
\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{img/dos.png}
\caption{L'impatto dei flussi di traffico DoS che colpiscono diverse regole sul firewall}
\label{fig:dos}
\end{figure}
La Figura \ref{fig:dos} mostra l'impatto sulle prestazioni che il firewall subisce quando si lanciano attacchi DoS con velocità diverse che colpiscono posizioni diverse delle regole. L'impatto è stato misurato facendo in modo che venga generato un normale flusso di traffico UDP costante a una velocità di 10 Kpps.
Abbiamo misurato il degrado delle prestazioni in termini di perdita di pacchetti (packet loss), velocità effettiva, utilizzo della CPU e ritardo unidirezionale quando si invia traffico normale e quando si sottopone il firewall a flussi di attacchi DoS di velocità diverse e prendendo di mira regole diverse.
\subsection{Osservazioni}
Dai grafici mostrati in Figura \ref{fig:dos} emerge chiaramente che un leggero degrado si manifesta quando gli attacchi DoS prendono di mira le regole più importanti (quelle in cima), mentre un notevole degrado si manifesta quando gli attacchi DoS colpiscono regole meno importanti (quelle in fondo) come quelle posizionate a 5.000 e 10.000. Più specificamente, quando si prendono di mira le regole meno importanti, si può osservare un degrado grave e evidente con attacchi DoS a velocità relativamente bassa di circa 1 Kpp e 3 Kpp quando si prendono di mira regole posizionate rispettivamente a 10.000 e 5.000. Tuttavia, quando si prende di mira una regola posizionata a 1000, il degrado si manifesta solo con attacchi DoS ad alta velocità di circa 18 Kpps.
Pertanto, si può concludere che le regole di targeting nella parte inferiore del set di regole possono essere gravemente dannose per le prestazioni del firewall. Le prestazioni del firewall sono accettabili quando gli attacchi DoS (fino a una velocità di 18 Kpps) mirano a regole posizionate intorno a 1.000, ma non a regole superiori.
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}).
\section{Conotroller: Valutazione delle performances}
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.
Nella valutazione, il team di Collins fa uso di una configurazione restrittiva con insiemi di regole composte completamente da regole permissive (allow rules). Ciò rappresenta il caso di regole base peggiore perché il controller del firewall è costretto a tentare di accettare ogni flusso di traffico non identificato.
Il numero di regole nelle configurazioni varia da un minimo di 3 a un massimo di 1000.
\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}}
\caption{Implementazione della pipeline \cite{bakker2016network}}
\caption{Schema di interrogazione delle regole del firewall per i pacchetti in arrivo}
\label{fig:pipeline}
\label{fig:firewallrulebase}
\end{subfigure}
\end{subfigure}
\end{figure}
\end{figure}
\section{Deploy delle Flow Table Entries}
Dal grafico \ref{fig:flowlatency} si osserva che la latenza media aumenta linearmente con il tasso di arrivo di nuovi flussi di traffico quando la dimensione del set di regole è 150. Le latenze medie mostrano improvvisi aumenti di latenza con un numero più alto di arrivi di flussi quando le dimensioni del set di regole è a 250 e 500. La latenza media smette di crescere quando il set di regole è a 750 e 1000.
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.
Questa interruzione di crescita, secondo Collins può essere dovuta principalmente a due motivi:
Questo problema viene risolto \textit{deployando in modalità proattiva} agli switch le FTE nel momento in cui vengono create le regole ACL.
\begin{enumerate}
\item Molti nuovi flussi di traffico hanno pattern molto simili, quindi dopo un iniziale processamento da parte del controller le regole per quel pattern vengono applicate allo switch. Questa cosa viene osservata spesso in molti flussi di traffico di un gateway principale dove per esempio, molte connessioni Web tentano di visitare lo stesso insieme di server (per esempio portali di News molto frequentati).
\item Molti flussi vengono scartati (dropped) a causa dello spazio di coda limitato per contenere i pacchetti dei flussi non identificati quando i tassi di arrivo dei flussi sono elevati. La latenza media mostrata in tabella non copre i flussi persi.
\end{enumerate}
\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.
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.
Il team di Salah ha dimostrato che le regole di targeting nella parte inferiore (in basso) di un set di regole relativamente ampio possono essere gravemente dannose per le prestazioni di un firewall. Come buona pratica di progettazione e contromisura vitale contro gli attacchi DoS che prendono di mira le regole in fondo al set, il team consiglia di ridurre al minimo le dimensioni del set di regole del firewall o di riorganizzare dinamicamente le regole in modo che le regole più in basso possano essere spostate nella parte superiore del set di regole, rendendolo così più difficile lanciare attacchi algoritmici di tale complessità che colpiscono le regole inferiori.
Il lavoro del team di Collins, a parere dell'autore di questo testo, sembra in parte inconclusivo su questo fronte, ma mostra chiaramente l'impatto della dimensione del set di regole sulle prestazioni d un firewall ed accenna (o da una breve introduzione) a problematiche nuove introdotte dal paradigma SDN che vengono approfondite da ricerche come quella del team di Shin \cite{shin2013fresco} e dal team di Porras \cite{porras2012security} (in breve: Garbage collection delle regole mandate agli switch ed ottimizzazione e risoluzione di conflitti).
Oltretutto, \textbf{\textit{come nota personale}}, l'autore di questo testo si sente di aggiungere che la metodologia \textit{"first deny last allow"} descritta da Collins ed usata anche dal team di Bakker \cite{bakker2016network} può essere una buona tecnica da tenere in mente quando si progettano set di regole di un firequall, indipendentemente che sia SDN-based o meno. Questo, oltre a conferire un ovvio vantaggio sulla mantenibilità da parte degli amministratori di rete, permette anche di garantire prestazioni ottimali dovuto ad un set ridotto di regole.
