NetFlow versione 9

L'ultima versione proposta dalla Cisco è la versione 9 [9], descritta anche in una RFC rilasciata dall'IETF [10]. La particolarità di questa versione è quella di essere basata sull'utilizzo dei template, in modo da poter fornire accesso alle informazioni sui ussi in maniera essibile ed estendibile.

Un template denisce una collezione di campi, con la corrispondente struttura e semantica. Tale approccio ha i seguenti vantaggi:

• _{I nuovi campi possono essere aggiunti ai ow record senza cambiare la struttura} di export dei record2_.

• _{I template che sono inviati ad un NetFlow Collector contengono le informazioni} sulla struttura dei campi del ow record: in questo modo il NetFlow Collector può interpretarne i campi.

• La sua essibilità permette di esportare solo quei campi che sono necessari, o che sono stati richiesti dal NetFlow Collector. Questo permette di ridurre il volume dei dati esportati.

Sulla base delle versione 9 di NetFlow, l'IPFIX Working Group dell'IETF [15] sta sviluppando un nuovo protocollo.

Layout del pacchetto di export

Il formato di export di NetFlow v9 consiste in un header seguito da almeno uno o più template o dati (data FlowSet). Un template fornisce una descrizione dei campi che saranno presenti nei successivi FlowSet. I dati possono seguire immediatamente dopo il template o in pacchetti successivi. In gura 2.7 viene mostrato un esempio di questo pacchetto di export. Dierenti sono le combinazioni di template e dati che è possibile avere.

L'header del pacchetto è rimasto sostanzialmente inalterato rispetto alle versioni precedenti, ed è basato sull'header della versione 5. In gura 2.4 viene mostrata la struttura di tale header. La tabella 2.1 descrive il signicato dei campi.

Il formato del template è mostrato in gura 2.5. La tabella 2.2 ne descrive il signicato dei campi.

packet header

Data Flow Set Template FlowSet

Template FlowSet

Data FlowSet

Figura 2.3: Struttura del pacchetto di export dei dati

32 bit Version Count System Uptime UNIX Seconds Sequence Number Source ID

Figura 2.4: Struttura dell'header del pacchetto di export

Nome campo Valore

Version Rappresenta la versione del record NetFlow esportato in questo pacchetto

Count Numero dei record, sia template che dati, che sono contenuti all'interno del pacchetto

System Uptime Tempo, in millisecondi, da quando il device ha subito il primo boot

UNIX Seconds Tempo in secondi dal 1-1-1970

Sequence Number Numero di sequenza incrementale di tutti i pacchetti che sono inviati da questo device

Source ID Valore usato per garantire l'unicità per tutti i ussi esportati da un particolare device

Template ID 256 Length FlowSet ID = 0 Field Count Field Type 1 Field Length 2 Field Length 1 Field Type 2 Field Type N Field Count Field Length 1 Field Length 2 Field Type 1 Field Type 2 Field Type M Field Length N Field Lenght M Template ID 257

Template ID K Field Count

32 bit

Figura 2.5: Struttura del template del pacchetto di export dei dati

Nome campo Valore

FlowSet ID E' usato per distinguere i template dai dati. Un template ha sempre un FlowSet ID che varia in un range da 0-255. Al momento per i template il valore di questo campo è 0

Length Rappresenta la lunghezza totale di questo FlowSet. Poiché all'interno possiamo avere la denizione di più template, tale valore deve essere utilizzato per determinare la posizione del prossimo FlowSet. E' espressa come somma delle lunghezze del campo FlowSetID, del campo Length stesso e di tutti i campi del template.

Template ID Valore che identica univocamente il template.

L'unicità è garantita rispetto all'entità che esporta il pacchetto Field Count Numero dei campi presenti nel template. Poiché

all'interno è possibile avere più denizioni di template, il valore di questo campo permette di sapere quando un template è terminato

Field Type E' un valore numerico che rappresenta il tipo di campo. I valori sono riportati in [9] e [10]. Field Length E' la lunghezza, espressa in byte, del tipo

di campo corrispondente

I tipi di campi che è possibile specicare all'interno del template non saranno descritti tutti. Per una lista completa si faccia riferimento a [10] e [9]. Nell'appendice A viene presentata una lista dei campi di NetFlow che l'architettura descritta è in grado di riconoscere.

Il formato della parte dati viene invece descritto in gura 2.6 (la tabella 2.3 descrive il signicato dei campi che la compongono).

FlowSetID=TemplateID Length Padding Record 2 − Field 1 Record 2 − Field 3 Record 2 − Field 2 Record 3 − Field 1 Record 1 − Field 2 Record 1 − Field 1 Record 1− Field 3 32 bit

Figura 2.6: Struttura dei dati del pacchetto di export dei dati

Nome campo Valore

FlowSet ID = Template ID Indica il valore del template ID al quale i dati si riferiscono

Length Indica la lunghezza di questo FlowSet. E' la somma delle lunghezze dei campi FlowSet ID, Length stesso e di tutti gli altri campi presenti

Record N - File M Indicano i valori dei campi, il cui tipo

e la cui lunghezza sono stati specicati nel template Padding Serve per un eventuale allineamento della ne

del FlowSet al 32-esimo bit. Tabella 2.3: Descrizione struttura dei dati

Nella gura 2.7 viene mostrato un esempio completo del formato di export della versione 9.

Ricezione del pacchetto di export

Di seguito verrà descritto il modo in cui avviene la ricezione dei pacchetti di export. 2_{Nelle precedenti versioni di NetFlow l'aggiunta di nuovi campi in un usso comportava una}

nuova versione del formato di export e del Collector che doveva supportare il parsing del nuovo formato.

Figura 2.7: Struttura del pacchetto di export dei dati

Un'entità collector riceverà la denizione dei template da un'entità che fa da exporter, normalmente prima di ricevere la parte contenente i dati relativi ai ussi. Tali dati, indicati come Flow Record, possono essere quindi codicati e memorizzati localmente all'interno dei device. Nel caso in cui la denizione dei template non è stata ancora ricevuta al momento della ricezione dei dati, il collector metterà da parte i dati per una successiva codica quando le denizioni dei template saranno - nalmente ricevute. Questo signica che il collector non deve assumere che all'interno di uno stesso pacchetto siano presenti sia il template che i dati ad esso associati.

I template vivono per un certo periodo di tempo. La durata di un template è ricavata dal collector basandosi sul tempo in cui l'ultimo template è stato rice- vuto dall'exporter. Se il collector riceve una nuova denizione di template, questa immediatamente sovrascriverà la denizione esistente.