Che cos’è un flusso di traffico di rete?

I flussi di traffico di rete (flussi) sono utili per costruire una comprensione grossolana del traffico su una rete di computer, fornendo un’unità conveniente per la misurazione e/o il trattamento del traffico.

I flussi possono essere misurati per capire quali host stanno parlando sulla rete, con dettagli di indirizzi, volumi e tipi di traffico. Questa visualizzazione della rete può essere utile per la risoluzione dei problemi, il rilevamento di incidenti di sicurezza, la pianificazione e la fatturazione

Ma che cos’è esattamente un flusso e come viene definito?

A questa domanda sembra banale rispondere, tuttavia quando scaviamo più a fondo troviamo sfumature e casi angolari che rendono i flussi interessanti e alla fine difficili da definire.

Background

Per comprendere veramente i flussi, dobbiamo iniziare con alcuni background.

Le reti sono iniziate come a commutazione di circuito. Quando un host voleva comunicare con un altro host ha chiesto alla rete di impostare un circuito. Al termine del flusso di informazioni, il circuito è stato abbattuto.

Figura 1 – Esempio Rete a commutazione di circuito

Le reti a commutazione di circuito hanno il loro patrimonio nelle reti telefoniche. Presentano una serie di inconvenienti, tra cui scarsa scalabilità e basso utilizzo della capacità.

Era necessaria un’alternativa per costruire ciò che alla fine divenne Internet – reti a commutazione di pacchetto. I messaggi vengono tagliati in pezzi di dimensioni variabili che vengono indirizzati individualmente e inviati come pacchetti attraverso la rete.

Figura 2 – Esempio Rete a commutazione di pacchetto

L’host ricevente riassembla il carico utile dai pacchetti nel messaggio. Nota: i pacchetti possono anche contenere informazioni di controllo, come il controllo del flusso e i percorsi non devono essere simmetrici.

Definire i flussi in una rete a commutazione di circuito è facile in quanto il circuito è un flusso e segue un protocollo per stabilire e smantellare (circuit = flow); tuttavia in una rete a commutazione di pacchetto le cose sono meno ovvie.

Immagina per un secondo di essere nel punto di osservazione A nella rete a commutazione di circuito di Figura 1, vedrai:

Figura 3-Zoom sulla rete a commutazione di circuito

Si osserverebbero due flussi-circuiti tra host 3 & 4 e host 5 & 6. Osservare i flussi in una rete a commutazione di circuito è relativamente facile perché la rete è coinvolta nella configurazione dei circuiti, quindi conosce il loro stato e gli endpoint.

Immagina ora di essere nel punto di osservazione A nella rete a commutazione di pacchetto di Figura 2, invece, vedrai:

Figura 4-Zoom sulla rete a commutazione di pacchetto

Improvvisamente le cose sono meno chiare. C’è un pacchetto proveniente dall’Host 5 destinato all’Host 6. Supponendo che osserviamo per un periodo di tempo vediamo più pacchetti arrivano e partono. Osservare i flussi su una rete a commutazione di pacchetto richiede tempo e richiede la registrazione e l’analisi delle informazioni sui pacchetti.

Primo tentativo (ingenuo) di definire un flusso

Usando la nostra conoscenza delle reti a commutazione di pacchetto, un primo tentativo di rispondere a “cos’è un flusso” potrebbe essere:

Un flusso è una sequenza di pacchetti che trasportano informazioni tra due host

Questa definizione sembra:

Figura 5 – Primo Tentativo di Definire un Flusso

C’è tuttavia un problema. Cosa succede se c’è più di un tipo di comunicazione tra gli host, ad esempio A ha una connessione SSH e HTTPS a B? I pacchetti SSH e HTTPS fanno parte dello stesso flusso? Intuitivamente diciamo no, sono sessioni diverse e anche protocolli completamente diversi. Possiamo fare meglio

Secondo tentativo di definire

Che ne dici di utilizzare le informazioni del protocollo dalle intestazioni dei pacchetti come proprietà comuni per identificare i pacchetti nei flussi? Questo separerà diversi tipi di connessione in diversi flussi.

È probabile che una grande percentuale di pacchetti su una rete sia il protocollo IP layer-3, con TCP o UDP come protocollo di trasporto layer-4. È quindi ragionevole considerare l’utilizzo di parametri TCP e UDP come chiavi di flusso dalle intestazioni dei pacchetti.

Useremo un 5 parametri dalle intestazioni dei pacchetti; IP di origine, IP di destinazione, protocollo, porta di origine TCP o UDP e porta di destinazione TCP o UDP come elenco ordinato, comunemente noto come 5-tupla, come le proprietà comuni per mappare i pacchetti ai flussi.

Figura 6 – Esempio 5-tupla

Qui va tentativo 2:

Un flusso è una sequenza di pacchetti che trasportano informazioni tra due host, in cui i pacchetti hanno proprietà comuni:

• Tutti i pacchetti del flusso di condividere lo stesso 5-tupla

il Nostro scenario ora assomiglia a questo:

Figura 7-Secondo tentativo di definire un flusso

Perfetto che dici. La vita è bella. Abbiamo una definizione per un flusso, niente di più da vedere qui But Ma aspetta, che dire della direzione dei pacchetti?

Terzo tentativo-Bidirezionale

Una tupla a 5 è unidirezionale (unidirezionale). Per impostazione predefinita, corrisponderà solo ai pacchetti che viaggiano in una direzione, poiché i pacchetti nella direzione inversa hanno trasposto indirizzi IP e numeri di porta, e quindi un diverso hash a 5 tuple.

Ci sono buone ragioni per considerare i flussi come bidirezionali anziché unidirezionali, inclusa la capacità di determinare il comportamento client/server e calcolare i tempi di andata e ritorno, oltre a migliorare il rilevamento di incidenti di sicurezza come la scansione.

Si consideri una semplice connessione TCP in Figura 8 dove i pacchetti rimbalzano avanti e indietro tra Host A & B:

Figura 8-Schema Ladder di un semplice flusso TCP

Vediamo un classico handshake TCP a 3 vie (SYN, SYN+ACK, ACK) seguito da scambio di dati. L’analisi unidirezionale del flusso in un punto di osservazione nella rete vedrebbe due flussi separati, uno per direzione, come da Figura 9:

Figura 9-Scale unidirezionali per un flusso TCP semplice

Il problema con la misurazione del flusso unidirezionale è che perdiamo l’opportunità di acquisire alcuni metadati importanti sul flusso. Certo, ogni flusso unidirezionale può memorizzare metadati direzionali per byte e pacchetti in quella direzione. Ciò può includere la temporizzazione tra pacchetti (vedere i punti etichettati nella Figura 9). Ma perdiamo l’opportunità di raccogliere metadati che richiedono la misurazione dei parametri del traffico in entrambe le direzioni.

Considerare l’osservazione bidirezionale in figura 10:

Figura 10-Ladder of Bidirectional Observations for Simple TCP Flow

Ora possiamo osservare e misurare l’handshake TCP a 3 vie (punti F1, B1, F2) e guardare altre metriche come i tempi di risposta.

Per i flussi bidirezionali, abbiamo bisogno di due 5-tuple, la seconda delle quali inverte l’ordine delle tuple sia degli indirizzi IP che dei numeri di porta. Di seguito è riportato un esempio di flusso SSH avanti e indietro 5-tuple:

Figura 11-Invertire una tupla 5

Giusto, non è stato troppo difficile. Ma aspetta, un piccolo dettaglio si nasconde che richiede ulteriore attenzione. Come facciamo a sapere qual è la direzione in avanti del flusso? Determiniamo la direzione in base al primo pacchetto osservato, che si presume stia viaggiando nella direzione client-server, ma questo non sarà affidabile al 100% in quanto i pacchetti potrebbero essere fuori servizio e/o l’osservazione potrebbe iniziare in parte attraverso un flusso. Useremo con questo metodo, ma dobbiamo ricordare quando guardiamo i risultati che non è perfetto.

Un metodo alternativo sta ispezionando i campi del protocollo di trasporto. In TCP, ad esempio, la presenza del solo flag SYN è un indicatore ragionevole che il pacchetto è il primo nel flusso.

La nostra definizione per un flusso è ora:

Un flusso è una sequenza di pacchetti che trasportano informazioni tra due host in cui i pacchetti hanno proprietà comuni:

• Tutti i pacchetti nel flusso condividono la stessa 5-tupla o 5-tupla trasposta

Quarto tentativo-Incluso il traffico IP non TCP

Fino a questo punto abbiamo ipotizzato che il protocollo di trasporto sia TCP. Che dire di altri protocolli di trasporto IP?

UDP è la scelta più ovvia per il secondo protocollo di trasporto più comune, specialmente con l’aumento del traffico in tempo reale su UDP e nuovi protocolli come QUIC. UDP si adatta facilmente allo stesso modello in cui ha numeri di porta di origine e di destinazione, come nell’esempio QUIC qui sotto:

Figura 12-Invertire un UDP 5-tupla (come TCP)

Stream Control Transmission Protocol (SCTP) è un altro protocollo di trasporto che utilizza i numeri di porta e quindi funziona con un 5-tupla.

Ma per quanto riguarda altri protocolli, IPSec per esempio?

IPSec ESP (Encapsulating Security Payload) è un protocollo che non include i numeri di porta di origine/destinazione, quindi è necessario ricorrere a una tupla 3 poiché è improbabile che comprendere il carico utile del protocollo sia pratico.

Figura 13 – Bidirezionale 3-Tupla

la Nostra definizione di un flusso è ora:

Un flusso è una sequenza di pacchetti che trasportano informazioni tra due host in cui i pacchetti hanno proprietà comuni:

• Per protocolli di trasporto con i numeri di porta (io.e.TCP/UDP/SCTP):

Tutti i pacchetti del flusso di condividere lo stesso 5-tupla o recepite 5-tupla

altro:

Tutti i pacchetti del flusso di condividere lo stesso 3-tupla o recepite 3-tupla

comunque C’è ancora da considerare un altro fattore – tempo.

Quinto tentativo – Scadenza del flusso

Un flusso esiste solo per un certo periodo di tempo. È possibile che la stessa 5-tupla (o 3-tupla) possa essere riutilizzata in un punto diverso nel tempo, per un flusso diverso, tra gli stessi host.

Considera due host in cui uno avvia molte nuove connessioni TCP all’altro. Ogni nuova connessione TCP ottiene una nuova porta di origine, generalmente incrementata di 1 dall’allocazione precedente. IANA assegna l’intervallo da 49152 a 65535 per queste porte effimere, dando 16384 porte. Nel tempo la porta sorgente TCP scorrerà attraverso l’intervallo e la porta sorgente originale verrà riutilizzata, e questo flusso avrà la stessa 5-tupla del flusso originale. Questo presenta un problema, in quanto non è lo stesso flusso!

Per risolvere questo problema abbiamo bisogno che i flussi siano scaduti in cui non vengono visualizzati pacchetti per più di un determinato periodo di tempo. Ci risiamo:

Un flusso è una sequenza di pacchetti che trasportano informazioni tra due host in cui i pacchetti hanno proprietà comuni:

• Per i protocolli di trasporto con numeri di porta (ad esempio TCP / UDP / SCTP):

Tutti i pacchetti del flusso di condividere lo stesso 5-tupla o recepite 5-tupla

altro:

Tutti i pacchetti del flusso di condividere lo stesso 3-tupla o recepite 3-tupla

• Tutti inter-packet volte sono meno arbitrario flusso di scadenza valore di timeout

Sesto Tentativo – Parametri Arbitrari

a Volte hai bisogno di diversi parametri per identificare i flussi di, oppure questi possono essere imposto dal tipo di hardware/software in rete.

In un router Cisco, ad esempio, i flussi sono identificati da una tupla a 7 che aggiunge il tipo di servizio (ToS) e la sub-interfaccia di input alla tupla standard a 5. Ci possono anche essere situazioni in cui i campi layer-2, come l’indirizzo MAC di origine o di destinazione, possono avere senso come chiavi di flusso (anche se si noti che sono solo localmente significativi).

Esistono altri parametri che potrebbero essere utilizzati come proprietà comuni per l’identificazione del flusso; spetta in ultima analisi all’operatore decidere e alle capacità dell’apparecchiatura. Sulla base di questo, perfezioniamo ulteriormente la definizione:

Un flusso è una sequenza di pacchetti che trasportano informazioni tra due host in cui i pacchetti hanno proprietà comuni:

• Per protocolli di trasporto con i numeri di porta (io.e.TCP/UDP/SCTP):

Tutti i pacchetti del flusso di condividere lo stesso 5-tupla o recepite 5-tupla

altro:

Tutti i pacchetti del flusso di condividere lo stesso 3-tupla o recepite 3-tupla

• Tutti inter-packet volte sono meno arbitrario flusso di scadenza valore di timeout
• Possibile utilizzare qualsiasi arbitrario di parametri, come il flusso di chiavi, tra ToS, interfaccia, ecc.

Avvolgendo tutto

Abbiamo dimostrato che produrre una singola definizione di flusso onnicomprensiva è un problema difficile. La definizione del flusso è specifica per l’implementazione, dipende dalle esigenze degli utenti e dalle capacità delle apparecchiature di rete che misurano i flussi.

Nella parte 2 di questo post del blog andremo in ulteriori considerazioni per flussi come etichette di flusso IPv6, frammentazione (problema IPv4 e IPv6..), crittografia, pacchetti non IP e come i flussi vengono misurati e utilizzati in altri sistemi come SDN.

Vedi: https://www.eecs.yorku.ca/course_archive/2015-16/W/3214/CSE3214_01_PacketCircuitSwitching_2016_posted_part2.pdf

Per alcuni documenti correlati, vedere: https://www.researchgate.net/profile/Brian_Trammell/publication/245587221_Bidirectional_Flow_Measurement_IPFIX_and_Security_Analysis/links/0f3175331dd3b49103000000/Bidirectional-Flow-Measurement-IPFIX-and-Security-Analysis.pdf e https://is.muni.cz/th/hilnn/cse2009.pdf

Per RFC rilevanti, vedere: https://tools.ietf.org/html/rfc5103

Per ulteriori informazioni sulla standardizzazione del QUIC, vedere: https://datatracker.ietf.org/wg/quic/about/

Vedi: https://www.cisco.com/en/US/tech/tk812/technologies_white_paper09186a008022bde8.shtml