Tecnologie per il packet filtering

Transcript

1 Tecnologie per il packet filtering Olivier Morandi, Fulvio Risso 1

2 Nota di Copyright Questo insieme di trasparenze (detto nel seguito slides) è protetto dalle leggi sul copyright e dalle disposizioni dei trattati internazionali. Il titolo ed i copyright relativi alle slides (ivi inclusi, ma non limitatamente, ogni immagine, fotografia, animazione, video, audio, musica e testo) sono di proprietà degli autori indicati a pag. 1. Le slides possono essere riprodotte ed utilizzate liberamente dagli istituti di ricerca, scolastici ed universitari afferenti al Ministero della Pubblica Istruzione e al Ministero dell Università e Ricerca Scientifica e Tecnologica, per scopi istituzionali, non a fine di lucro. In tal caso non è richiesta alcuna autorizzazione. Ogni altra utilizzazione o riproduzione (ivi incluse, ma non limitatamente, le riproduzioni su supporti magnetici, su reti di calcolatori e stampate) in toto o in parte è vietata, se non esplicitamente autorizzata per iscritto, a priori, da parte degli autori. L informazione contenuta in queste slides è ritenuta essere accurata alla data della pubblicazione. Essa è fornita per scopi meramente didattici e non per essere utilizzata in progetti di impianti, prodotti, reti, ecc. In ogni caso essa è soggetta a cambiamenti senza preavviso. Gli autori non assumono alcuna responsabilità per il contenuto di queste slides (ivi incluse, ma non limitatamente, la correttezza, completezza, applicabilità, aggiornamento dell informazione). In ogni caso non può essere dichiarata conformità all informazione contenuta in queste slides. In ogni caso questa nota di copyright non deve mai essere rimossa e deve essere riportata anche in utilizzi parziali. 2

3 Outline Layered Demultiplexing dei protocolli Early Demultiplexing, o Packet Filtering Software Packet Filtering Motivazioni storiche Soluzioni Evoluzione Packet Filtering nei sistemi operativi 3

4 Definizioni Packet filter: sistema che applica una funzione booleana a ogni pacchetto in ingresso Packet classifier: sistema che dato un pacchetto in ingresso ed un set di funzioni booleane, ritorna quale/i di queste regole sono state soddisfatte Considerazioni Ambedue i sistemi hanno una base comune Un packet classifier può essere visto come un insieme di più packet filters Packet classifiers sono stati storicamente sviluppati per il protocol/session demultiplexing all interno del kernel del sistema operativo Packet filters sono stati sviluppati per l analisi selettiva del traffico 4

5 Layered Demultiplexing Approccio tradizionalmente utilizzato per l implementazione dei protocolli sugli End-Nodes Process 1 Process 2 Process 3 Application Layer Socket API (e.g. Web-Browser) (e.g. POP3 client) (e.g. SMTP server) Transport Layer TCP Header Payload Internet Layer IP Header Payload Ethernet Driver Ethernet Header Payload FCS 5

6 Layered Demultiplexing (2) Il software di gestione di ogni protocollo sceglie a quale protocol-handler passare il payload corrente valutando un match esatto su uno o più campi dello header Transport Layer UDP TCP 0x11 0x06 Internet Layer ARP IPv6 IP.protocol Ethernet Driver 0x0806 0x86DD Ethernet.type 0x0800 6

7 Layered Demultiplexing (3) L elaborazione dei pacchetti avviene un livello per volta Un modulo software ad un livello decide quale modulo di livello più alto deve procedere con l elaborazione Vantaggi Alta flessibilità data dalla modularità dell approccio Semplicità nella definizione ed implementazione di nuovi protocolli, oppure nella modifica di protocolli esistenti Svantaggi Inefficienza Eleborazione sequenziale: il livello N deve attendere che il livello N-1 termini di elaborare il pacchetto Chiamate tra moduli diversi introducono overhead, anche se minimo 7

8 Early Demultiplexing: motivazioni Per motivi di efficienza, spesso è preferibile conoscere al più presto l intera sequenza di protocolli contenuta in un pacchetto (i.e. l endpoint di destinazione) per compiere determinate azioni, ad esempio: Scarto di pacchetti (dal semplice filtraggio al firewalling) Scelta di percorsi di elaborazione alternativi Calcolo di statistiche Load balancing Traffic Shaping Quando la velocità di elaborazione è un vincolo determinante, l approccio a livelli sovrapposti è inefficiente Serve un meccanismo che permetta di determinare in anticipo ed in modo semplice e veloce, il percorso dei protocolli seguito da ogni pacchetto ricevuto: Demultiplexing Anticipato 8

9 Early Demultiplexing Varie operazioni di demultiplexing su più livelli vengono compresse in una singola operazione su un unico livello: La sequenza degli header contenuti in un pacchetto viene considerata come un unico header Si confrontano alcuni campi chiave del macro-header risultante L esito dei test determina l accettazione o meno del pacchetto Non sempre è possibile e/o ottimizzato (es. composizione di filtri) Un sistema che implementi un algoritmo di earlydemultiplexing si dice Packet Filter oppure Packet Classifier (a seconda delle implementazioni) 9

10 Implementazione software: traffico web Traffico Web: ip - tcp - porta 80 ethernet ip tcp payload type protocol src port dst port == 2048? == 6? == 80? == 80? and or and Altro no True? yes Traffico Web 10

11 Hardware Packet Filter ethernet ip tcp payload + Efficienza: Un operazione di ad ogni colpo di clock - Flessibità: Wide datapath (e.g 512 bit) Registro Traffico verso server web 0x Completamente hardwired Possibilità di valutare condizioni semplici (tipicamente solo campi ad offset fisso o con condizioni molto semplici) Comparatore (o logica booleana semplice) Risultato Costante 11 Cfr. Douglas Comer Network Systems Design using Network Processors

12 Implementazioni software Vantaggi Elevata flessibilità Svantaggi Minore efficienza rispetto alla soluzione completamente HW 12

13 Requisiti implementazioni software Sicurezza Molti algoritmi di early-demultiplexing sono implementati in kernel o in porzioni critiche dei dispositivi di networking, quindi è indispensabile che ne sia garantito il corretto funzionamento anche a fronte di un input scorretto (sia sotto forma di regole che di pacchetti) da parte di utenti maliziosi (es. pacchetti troncati) Efficienza Gli algoritmi di packet filtering sono spesso impiegati in ambiti in cui le prestazioni rappresentano un vincolo critico, quindi è necessario che siano implementati in modo efficiente Componibilità Se un algoritmo di packet filtering implementa N filtri (generalmente specificati attraverso la composizione booleana di filtri semplici), è preferibile che il filtro composito abbia prestazioni migliori rispetto ad una semplice ricerca lineare Velocità di update Aggiunta / cancellazione / modifica di filtri Es. sessioni TCP (firewall) 13

14 Software Packet Filter: evoluzione CMU/Stanford Packet Filter (1987) Berkeley Packet Filter (1989) WinPcap (~ 2000) PathFinder (1994) Dynamic Packet Filter (1996) BPF+ (1999) FFPF (2004) SWIFT (2008) 14

15 CMU/Stanford Packet Filter (CSPF) [CSPF87] Nato per consentire l implementazione di protocolli in userspace nel sistema operativo Mach ed in seguito integrato nel kernel 4.3BSD Il modello prevede che l applicazione fornisca al kernel un programma in cui è contenuta una descrizione dei pacchetti che desidera ricevere Il kernel simula il programma attraverso una macchina virtuale molto semplice Il programma viene eseguito per ogni pacchetto ricevuto e restituisce il valore true se un pacchetto soddisfa le condizioni imposte dall utente 15

16 CSPF (1) Il programma di filtering è descritto da un espressione booleana, rappresentabile tramite una struttura ad albero La struttura ad albero delle espressioni di filtering è in realtà rappresentata tramite un linguaggio imperativo stack-based a 16 bit Ogni pacchetto è visto come una sequenza di word a 16 bit Il programma viene eseguito da un processore virtuale che simula lo stack Il pacchetto viene visto come un array di bytes La virtual machine non ha alcuna nozione di protocollo Un nuovo protocollo può essere aggiunto senza cambiare la VM 16

17 CSPF: esempio Pacchetti ARP o IP provenienti da X OR AND AND ARP.SRC=X ETHER.TYPE=ARP IP.SRC=X ETHER.TYPE=IP Campi ad offset fisso Valore costante (0x0806) 17

18 CSPF (2) La struttura ad albero delle espressioni di filtering è in realtà rappresentata tramite un linguaggio imperativo stack-based a 16 bit Ogni pacchetto è visto come una sequenza di word a 16 bit Il programma viene eseguito da un processore virtuale che simula lo stack 18

19 CSPF: esempio di programma e uso dello stack PUSHWORD+6 /*push 6a word del pacchetto */ PUSHLIT EQ /*push prossima instr-word, EQ */ 2054 /*ARP */ PUSHWORD+6 /*push 6a word del pacchetto */ PUSHLIT EQ /*push prossima instr-word, EQ */ 2048 /*IP */ OR ETHER.TYPE==ARP ETHER.TYPE==IP Programma CSPF OR Albero di espressioni == OR == Ether.type Value2 Ether.type Value1 Value1 Result 19

20 CSPF: caratteristiche per la sicurezza (1) Set di istruzioni limitato: Gestione dello stack Load da memoria di pacchetto Operatori logici Operatori booleani e di confronto Assenza di costrutti di controllo del flusso (jump, branch, loop) Non è possibile saltare a porzioni di codice esterne al programma (codice non esistente o appartenente ad un altro programma) Garanzia di terminazione del programma 20

21 CSPF: caratteristiche per la sicurezza (2) Introduce il concetto di Macchina virtuale Idea ripresa da gran parte delle tecniche successive Controlli sulla correttezza dei riferimenti alla memoria di pacchetto e allo stack (bounds checking a runtime) Non è possibile scrivere/leggere in zone di memoria non esistenti Bound checking sui campi (non è possibile accedere ad un campo non esistente nella memoria di pacchetto, es. packet truncation) 21

22 CSPF: limitazioni (1) Non è prevista la composizione di filtri Se N applicazioni impostano N filtri diversi, questi vengono eseguiti in sequenza lineare L architettura a stack si presta poco ad essere implementata efficacemente su macchine a registri Lo stack deve essere simulato tramite un buffer in memoria Ogni accesso allo stack corrisponde ad un accesso a memoria, più l aggiornamento del registro che simula lo stack pointer In teoria, facilita l implementazione di un eventuale JIT 22

23 CSPF: limitazioni (2) Il linguaggio permette di valutare solo campi ad offset fisso Ethernet con/senza VLAN, IP options, IPv6 extension headers,... Non supporta un operatore di indirezione Sono supportati esclusivamente accessi alla memoria di pacchetto allineati ai 16 bit, rendendo più complicati ed inefficienti gli accessi ai campi a 8 e 32 bit (e.g. ip source o destination) Necessario il mascheramento del campo Non possibile se il pacchetto ha lunghezza dispari e si vuole accedere all ultimo byte 23

24 CSPF: limitazioni (3) Il modello basato sull albero delle espressioni è inefficiente In alcuni casi devono essere eseguite più operazioni del necessario (ridondanza) Ogni foglia dell albero viene interpretata indipendentemente dalle altre Non esiste la possibilità di ricordare il risultato dei controlli già effettuati OR Albero di espressioni Esempi di inefficienze - Lo stesso campo (ether.type) viene letto due volte dalla memoria di pacchetto ETHER.TYPE=ARP ETHER.TYPE=IP - Se il pacchetto è ARP, il secondo test è inutile 24

25 Berkeley Packet Filter (BPF) [BPF93] Nato per sopperire alle limitazioni delle soluzioni precedenti (CSPF e discendenti) e per consentire lo sviluppo di tool di monitoring flessibili ed efficienti (e.g. tcpdump) Propone un nuovo e più complesso modello di macchina virtuale per l esecuzione in kernel di programmi di filtraggio Le funzionalità di cattura e filtering dei pacchetti sono fornite alle applicazioni tramite la libreria utente pcap, inizialmente integrata in tcpdump e poi resa indipendente a partire dal

26 BPF: caratteristiche (1) La progettazione del BPF si fonda sull eliminazione dei punti critici del CSPF Macchina virtuale a 32 bit a registri Un registro accumulatore (A) Un registro indice (x) Una memoria per dati temporanei Instruction pointer implicito Supporto per campi ad offset variabile Operatori di load indiretto, con offset specificato dal registro indice consentono il decoding di protocolli complessi quali TCP/IP 26

27 BPF: caratteristiche (2) Set di istruzioni Istruzioni semplici Es. le istruzioni operano su una sola area di memoria per volta, per cui possono essere implementate con una switch Permette di creare un interprete efficiente Conversione automatica tra i dati nella memoria di pacchetto (network byte order) e le operazioni elementari (host byte order) Gestione delle eccezioni Non prevista; in caso di errore (es. accesso fuori dal buffer dl pacchetto, divisioni per zero) viene semplicemente ritornato un filtro falso 27

28 BPF: caratteristiche (3) Supporto per accessi alla memoria di pacchetto a 8, 16, 32 bit Operatori per il controllo del flusso Comparazione e branch in un unica istruzione nella forma JUMP_IF_EQUAL ETHERTYPE_IP, T1, T2 I loop sono vietati, sono possibili solo salti in avanti Garanzia di terminazione del programma in un tempo finito Viene ingegnerizzata una libreria user-friendly per la creazione di questi filtri Libpcap (WinPcap in Windows) Traduce un espressione di alto livello in codice BPF Il programma risultante viene quindi interpretato dalla macchina virtuale BPF Implementazione di default: nel kernel del sistema operativo 28

29 BPF: Control Flow Graph Model CSPF è basato su un modello ad albero di espressioni in cui operazioni potenzialmente ridondanti devono essere comunque eseguite Non vi è la possibilità di memorizzare un risultato della computazione per poterlo riutilizzare successivamente (ad es. il doppio controllo sul campo ether.type) BPF è basato su un modello a grafo di controllo del flusso, una macchina a stati in cui Ogni nodo rappresenta un gruppo di istruzioni Le transizioni di stato avvengono in base al risultato delle operazioni di Test&Branch Controlli inutili vengono evitati grazie a transizioni di corto-circuito che determinano immediatamente il risultato finale Transizioni di corto-circuito erano possibili anche con CSPF (con speciali istruzioni che terminavano il programma) ma erano soluzioni più ad-hoc che sistematiche Il CFG permette di ricordare la storia dell elaborazione passata 29

30 Expression Tree vs. Control Flow Graph Filtro pacchetti IP o ARP inviati dalla sorgente X Costo: - 4 confronti - 3 espressioni booleane OR Costo: - 3 confronti (con 2 salti) ETHER.TYPE = ARP F T AND AND ETHER.TYPE = IP ARP.SRC = X T ARP.SRC = X ETHER.TYPE = ARP IP.SRC = X ETHER.TYPE = IP IP.SRC = X Albero di espressioni Macchina a stati 30

31 Stack-based Processing vs. Control Flow Graph Filtro pacchetti IP o ARP Costo di accesso alla memoria: - 2 load (lettura dal pacchetto) - 1 store ( OR ) Costo di accesso alla memoria: - 1 load (lettura dal pacchetto) OR Ogni operazione booleana richiede un memory reference aggiuntivo T ldh [12] jeq #0x806 F jeq #0x800 T F ETHER.TYPE= IP ETHER.TYPE = ARP ret #65536 ret #0 Esecuzione stack-based Esecuzione tramite State Machine 31

32 BPF: esempio di programma Filtro tcp and port 80 (000) ldh [12] ;load ether.type (001) jeq #0x800 jt 2 jf 12 ;ether.type == IP? (002) ldb [23] ;load ip.protocol (003) jeq #0x6 jt 4 jf 12 ;ip.protocol == TCP? (004) ldh [20] ;load flags+frag_offset (005) jset #0x1fff jt 12 jf 6 ;frag_offset > 0? (i.e., c e TCP?) (006) ldxb 4*([14]&0xf) ;load hlen*4 into x (007) ldh [x + 14] ;load tcp.source (008) jeq #0x50 jt 11 jf 9 ;tcp.source == 80? (009) ldh [x + 16] ;load tcp.dest (010) jeq #0x50 jt 11 jf 12 ;tcp.dest == 80? (011) ret #65536 ;return whole frame (012) ret #0 ;discard frame 32

33 BPF: limitazioni BPF supera molte delle limitazioni insite nel modello CSPF e consente un notevole incremento di prestazioni per un singolo filtro CSPF: Architettura a stack, alberi di espressioni BPF: register-based, control-flow graph Non elimina tutte le ridondanze nel codice (vedi BPF+) Non offre supporto intelligente alla composizione di filtri È possibile attivare 2 filtri contemporaneamente, ma l intera aarchitettura viene duplicata (un secondo BPF in parallelo al primo) Il tempo di elaborazione cresce linearmente con il numero di filtri impostati dalle applicazioni Ogni pacchetto deve essere elaborato da ogni filtro in sequenza 33

34 BPF e componibilità dei filtri (1) Nella maggioranza dei casi, la non componibilità dei filtri BPF non rappresenta un problema E raro avere molte applicazioni di monitoring attive contemporaneamente sulla stessa macchina Nei casi in cui sia necessario discriminare tra un notevole numero di flussi di pacchetti il problema diventa non trascurabile 34

35 BPF e componibilità dei filtri (2) Esempio: N filtri che specificano tutti il path ip tcp, ciascuno con un confronto su una diversa coppia di porte sorgente e destinazione Cioè N filtri sostanzialmente identici, tranne che per un dettaglio Risultato: N confronti sull ethertype (== IP?) N confronti sul next proto IP (== TCP?) N confronti sui campi TCP source e TCP destination N operazioni identiche! Equivale a linear-search con exact match 35

36 Mach Packet Filter [MPF94] Mira a risolvere i seguenti problemi: Demultiplexing efficiente a livello applicativo (il sistema operativo deve smistare un pacchetto all applicativo corretto si base sessione) Gestione efficiente dei frammenti IP Modifica Il set di istruzioni BPF con istruzioni in grado di operare efficacemente in queste condizioni Il compilatore che è in grado di riconoscere il caso in cui due filtri hanno un prologo identico e in questo caso aggiunge solamente un nuovo identificativo di sessione Applicativo1 Prologo (filtro su Ethernet, IP, TCP) Copia chiavi nella scratch memory Identificazione delle sessioni Applicativo2 Applicativo3 36

37 Esempio /* Part (A) Prologo */ ldh P[OFF_ETHERTYPE] jeq #ETHERTYPE_IP, L1, Fail L1: ld P[OFF_DST_IP] jeq #dst_addr, L2, Fail L2: ldb P[OFF_PROTO] jeq #IPPROTO_TCP, L3, Fail L3: ldh P[OFF_FRAG] jset #!Dont_Frag_Bit, Fail, L4 ; A = ethertype ; If not IP, fail. ; A = dst IP address ; If not from dst_addr, fail. ; A = protocol ; If not TCP, fail. ; A = Frag_flags Frag_offset ; If fragmented, fail. L4: /* Part (B) Scrittura delle chiavi in memoria */ ld P[OFF_SRC_IP] ; A = src IP address st M[0] ; M[0] = A ldxb 4 * (P[OFF_IHL] & 0xf) ; X = offset to TCP header ldh P[x + OFF_SRC_PORT] ; A = src TCP port st M[1] ; M[1] = A ldh P[x + OFF_DST_PORT] ; A = dst TCP port st M[2] ; M[2] = A /* Part (C) Filtraggio sulle sessioni */ ret_match_imm #3, #ALL ; Compare keys and M[0..2]. key #src_addr ; If matched, accept the key #src_port ; whole packet. If not, key #dst_port ; reject the packet. Fail: ret #0 37

38 Vantaggi/svantaggi Molto orientato al problema del demultiplexing nel kernel di un sistema operativo Ottimizzazione molto semplice (ed efficace) ma valida solo in quel particolare ambito applicativo Richiede che tutti i filtri abbiano esattamente lo stesso prologo Solo in quel caso è possibile collassarne la parte finale Ottima scalabilità all aumentare del numero di sessioni Non propone soluzioni di ottimizzazione più generali nel caso di unione di più filtri generici 38

39 PathFinder (1) [PATH94] Introduce un nuovo modello di packet filter che supporta intrinsecamente la composizione di un numero arbitrario di filtri Generalizza il concetto di collassamento proposto da MPF Diversi filtri vengono integrati in un unico filtro composito per minimizzare il numero dei confronti ridondanti (e.g. verifiche su ether.type e ip.proto nell esempio precedente) L idea è quella di sovrapporre i Control Flow Graph di filtri diversi, in modo che tutti i controlli sullo stesso campo si trovino nello stesso nodo del CFG Ogni nodo è implementato da una tabella di hash contenente tutti i valori da confrontare, così da eliminare la ricerca lineare a favore di operazioni di hashing (molto più efficienti quando il numero dei confronti da effettuare è alto) 39

40 PathFinder (2) L elemento basilare sul quale si fonda PathFinder è detto cella Una cella identifica un generico campo di bit all interno del pacchetto ed un valore col quale questo deve essere confrontato per il demultiplexing di un protocollo Ogni cella è descritta tramite una tupla nella forma <offset, length, mask, value> Ad esempio, la cella che permette di controllare se un pacchetto IP contiene un header TCP è definita dalla tupla <9, 1, 0xFF, 6> Il prossimo protocollo è TCP se il decimo byte a partire dall inizio dell header IP, mascherato con 0xFF (i.e. un byte con ogni bit a 1), vale 6 40

41 PathFinder (3) Un filtro è definito da: Celle: esprime una condizione su un campo Linee: definisce più condizioni che devono essere verificate sullo stesso protocollo Header: definisce un protocollo e la lunghezza del suo header Pattern: definisce su quale protocollo (header) dovrà essere soddisfatta una linea Necessario per calcolare gli offset dei vari campi (che sono relativi all inizio del protocollo) Composite pattern: definisce un insieme di pattern che operano su più protocolli Header di lunghezza variabile sono gestiti tramite apposite celle di load che permettono di caricare il valore di un campo in una variabile per un successivo riutilizzo in una cella di confronto 41

42 Esempio: header a lunghezza fissa Pacchetti TCP con ip.src == # Define cells # TCP s protl id (1 byte) ip_cell1 = (9, 1, 0xff, 6) # ip src addr (4 bytes) ip_cell2 = (12, 4, 0xffffffff, 0xc00c4501) # Define line (group of cells that compose the pattern) ip_line1 = (ip_cell1, ip_cell2) # Define the IP header # 20 byte fixed size hdr ip_header = (FIXED, 20, 1) # Define the pattern for TCP packets in which ip.src == # NULL is because we do not define an alternative path for fragmented packets ip_pattern = (ip_header, ip_line1, NULL) 42

43 Esempio: header a lunghezza variabile Pacchetti TCP con ip.src == # Define cells # Get lower 4 bits from offset 0 (ip header length) ip_hdrcell = (0, 1, 0x0f, NULL) # TCP s protl id (1 byte) ip_cell1 = (9, 1, 0xff, 6) # ip src addr (4 bytes) ip_cell2 = (12, 4, 0xffffffff, 0xc00c4501) # Define line (group of cells that compose the pattern) ip_line1 = (ip_cell1, ip_cell2) # Define the IP header # IP is variable length, which is ip.hdrcell multiplied by 4 ip_header = (VARIABLE, ip_hdrcell, 4) # Define the pattern for TCP packets in which ip.src == # NULL is because we do not define an alternative path for fragmented packets ip_pattern = (ip_header, ip_line1, NULL) 43

44 PathFinder: filtro composto (1) Filtri diversi vengono combinati in un unico filtro sovrapponendo i rispettivi pattern, senza ricreare le celle già esistenti Ethernet Cell IP? Sequenze Ethernet Cell IP? Identiche IP Cell Celle IP Cell TCP? Simili TCP? TCP Port 80 TCP Port Cell TCP Port Cell dport = 80? dport = 110? tcp.dport = 80 tcp.dport =

45 PathFinder: filtro composto (2) Modello basato su longest prefix match Due filtri vengono esaminati per verificare se hanno un prefisso iniziale comune In questo caso, le celle uguali vengono eseguite una sola volta Il DAG del filtro viene aumentato di un nuovo arco in OR per la parte relativa al suffisso divergente Celle diverse che descrivono lo stesso campo, ma valori di confronto diversi vengono condensati utilizzando una tabella di hash Ethernet (type) 0x0800 IP (protocol) 0x06 TCP (dport) IP (src) IP src La struttura di un filtro composito non deve essere necessariamente un albero, ma può essere un DAG (Directed Acyclic Graph) TCP dport 80 TCP dport

46 PathFinder: celle e tabelle di hash L array di puntatori alle celle di livello inferiore è implementato come una tabella di hash Array: lookup in tempo costante, ma, enorme spreco di memoria (l insieme dei puntatori ai nodi successivi è sparso, i.e. tanti spazi vuoti) Lista di valori: più compatto, ma ricerca lineare Hash: giusto compromesso tra velocità di ricerca e spazio occupato PathFinder gestisce anche il caso di confronto su intervalli (es. valore < 100) Array Lista Hash Ptr trie 1 Ptr trie 2 Ptr trie 3 Ptr trie 4 Ptr trie Ptr trie Ptr trie 80 Ptr trie 110 Valore Hash Ptr trie 80 Ptr trie

47 PathFinder: Trie-Search Un filtro composito è molto simile ad una struttura trie : Una macchina a stati con struttura ad albero, in cui ciascun nodo contiene un array di puntatori ad altri sub-trie Ogni array contiene un puntatore per ogni possibile carattere di un alfabeto fisso Per ricercare una parola chiave (e.g. un pattern) all interno della struttura, questa viene scomposta nei caratteri che la compongono Il carattere i-esimo viene utilizzato come indice nell array dell i-esimo nodo a partire dalla radice, per ottenere il puntatore ad un nodo al livello i+1 La ricerca procede ricorsivamente fino all ultimo carattere della parola 47

48 Trie-Search: esempio Alfabeto: abc Parole da ricercare: ab, ac, bc (ossia i filtri) Input1: abccca Input2: bcaab a b c a b c a b c a b c Ø ab ac Ø Ø bc Ø Ø Ø 48

49 PathFinder e Trie-Search: esempio 5 filtri: 1. ETH - IP - ICMP 2. ETH - IP - UDP 3. ETH - VLAN - IP - ICMP 4. ETH - IP - TCP - dport ETH - IP - TCP - dport 110 Ethernet (type) 0x0800 0x8100 VLAN (type) 0x0800 IP (protocol) 0x06 0x11 0x01 [1][3] La struttura generale di un filtro Pathfinder è un DAG composto dall unione dei pattern di tutti i filtri specificati TCP (dport) [2] UDP ICMP [4] [5] TCP dport 80 TCP dport

50 Esecuzione del codice di Pathfinder Cella Pathfinder: Cell <offset, length, mask, value> Esempio del codice necessario per interpretare una cella: LOAD A, Cell->offset; LOAD B, Cell->length; LOAD C, Packet[A:B]; LOAD A, Cell->mask; AND C, A; LOAD B, Cell->Value IF (C!= B) GOTO NO_MATCH 4 load aggiuntive per ogni cella, senza considerare bounds checking e controlli accessori 50

51 PathFinder: vantaggi e svantaggi Vantaggi Semplicità nell aggiunta di filtri (composizione) Gestisce frammentazione Ottimo nel caso di demultiplexing Svantaggi La struttura trie, se molto profonda, può portare a limitazioni delle performance Per ogni pacchetto, la macchina a stati deve essere simulata attraverso un parsing a runtime dell intera struttura in memoria Il numero di accessi a memoria necessari prima di ottenere un match può essere elevato Ciò porta ad una degradazione delle prestazioni Approccio poco generale per la composizione di filtri Gestisce headers con lunghezza variabile, ma non campi variabili Non consente predicati del tipo ip.src == ip.dst 51

52 Problemi nella composizione di filtri A fronte di più filtri, ne viene ritornato uno solo, che è quello con il percorso più lungo Facile da determinare se si seguono i percorsi AND (che hanno la precedenza) Non chiaro come viene determinato nel caso in cui vada scelto un percorso in OR (quando una cella ha due uscite) I filtri sono ottimizzati solamente se condividono un prefisso comune (ip.src == X and ip.dst == Y) or (ip.src == Y and ip.dst == X) : OK (tcp.sport == X and tcp.dport == W) or (ip.src == K and tcp.sport == Y): controllo ridondato su tcp.sport anche nel caso in cui sia giù stato verificato che valga X Risolto da Redundant Predicate Elimination in BPF+ 52

53 Dynamic Packet Filter (DPF) [DPF96] Ripropone lo stesso modello di PathFinder, basato su trie-search Ne supera le limitazioni prestazionali eliminando le load indirette nel codice di elaborazione di ogni cella Ogni volta che viene aggiunto un filtro (pattern), l intero classificatore viene tradotto in codice nativo ottimizzato, tramite tecniche di Dynamic Code Generation Il codice di packet processing viene viene quindi generato a runtime Le celle (qui chiamate atoms) vengono preventivamente ordinate in modo da accedere ad offset crescenti nel pacchetto Può essere un vantaggio o uno svantaggio Svantaggio: (ip.proto == TCP and ip.src = ) Vantaggio: (ip.src == X and ip.dst == Y) or (ip.dst == X and ip.src == Y) Non chiaro dall articolo se PathFinder possa fare la stessa cosa 53

54 DPF vs. PathFinder (1) Eliminazione degli overhead di interpretazione I parametri di ogni cella sono noti all atto della sua creazione (e normalmente pari a valori costanti) Le operazioni di load da memoria di tali valori possono essere sostituiti dall utilizzo di costanti Utilizzo della modalità di indirizzamento immediate Un valore costante è inglobato all interno dell opcode di alcune istruzioni LOAD A, Cell->offset; LOAD B, Cell->length; LOAD C, Packet[A:B]; LOAD A, Cell->mask; AND C, A; LOAD B, Cell->Value IF (C!= B) GOTO NO_MATCH LOAD C, Packet[offs:len]; AND C, mask; IF (C!= value) GOTO NO_MATCH Codice per l interpretazione di una cella Codice nativo corrispondente con l utilizzo di valori immediate 54

55 DPF vs. PathFinder (2) Altre ottimizzazioni Capacità di ottimizzare l operazione di switch su una cella Hash table, jump table, IF annidati Atom coalescing Es. tcp.sport == 0x80 and tcp.dport == 0x90 tcp.port == 0x8090 Bound check aggregation Se possibile, una volta per protocollo JIT non particolarmente evoluto 55

56 DPF: tempo di update Ogni volta che viene aggiunto un pattern al classificatore, questo deve essere interamente ricompilato Ciò implica che il tempo di update risultante sia dato da Tup_dpf = Tup_pathf + Tcodegen Dove Tup_dpf è il tempo di update del filtro DPF Tup_pathf è il tempo di update del filtro PathFinder Tcodegen è il tempo di compilazione Il tempo di update il più delle volte non è determinante, tuttavia deve rimanere limitato Il tempo di update dipende dalla quantità di passi di ottimizzazione nella fase di generazione del codice nativo 56

57 DPF vs. PathFinder: prestazioni Il confronto tra i due modelli, effettuato su macchine con prestazioni tra loro comparabili, porta ai seguenti risultati*: Un classificatore DPF è dalle 13 alle 26 volte più veloce dell equivalente PathFinder Conferma i risultati per cui il codice nativo è di un ordine di grandezza più lento rispetto al codice di una macchina virtuale Il tempo di update di DPF è solo tre volte superiore al tempo di update di PathFinder Le prestazioni di un classificatore DPF sono comparabili a quelle dello stesso classificatore codificato a mano, con l enorme vantaggio dato dalla flessibilità dell approccio 57