Metodologie di autocongurazione,integrazione e testing di sistemi in

Transcript

Università degli Studi di Firenze
Dipartimento di Elettronica e Telecomunicazioni
Dottorato di Ricerca in
Ingegneria Informatica, Multimedialità e Telecomunicazioni
XXIII Ciclo
Metodologie di
autoconfigurazione,
integrazione e testing di sistemi
in reti wireless per applicazioni
critiche
Tesi di
Ing. Matteo Rosi
Coordinatore:
Prof. Giacomo Bucci
Tutori:
Prof. Romano Fantacci
Ing. Laura Pierucci
Anno Accademico 2009/2010
Indice
Elenco delle figure
v
Elenco delle tabelle
ix
Pubblicazioni
xi
Introduzione
I
xiii
Rete MANET autoformante ed integrazione con
lo standard TETRA-DMO
1
1 CADAE: Channel Assignment DAEmon
3
1.1
La generazione automatica della rete MANET . . . . . . . . .
4
1.2
Il problema del interference detection . . . . . . . . . . . . . .
7
1.2.1
8
1.3
Assegnazione dei canali basato su una topologia ad albero
Sviluppo demone CADAE . . . . . . . . . . . . . . . . . . . . 21
1.3.1
Macchina a stati . . . . . . . . . . . . . . . . . . . . . 23
1.3.2
Risultati prestazionali . . . . . . . . . . . . . . . . . . 24
2 TWNET: Tetra Wireless NETwork
2.1
27
Lo standard Tetra . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.1
Architettura DMO . . . . . . . . . . . . . . . . . . . . 31
i
ii
Indice
2.2
2.1.2
Canale a trama temporale . . . . . . . . . . . . . . . . 34
2.1.3
Indirizzi ed identità . . . . . . . . . . . . . . . . . . . . 35
2.1.4
Scenari di servizio TETRA DMO . . . . . . . . . . . . 37
2.1.5
La sicurezza nel Tetra DMO . . . . . . . . . . . . . . . 75
Integrazione rete Tetra DMO con rete wireless mesh . . . . . . 80
2.2.1
Elementi costitutivi la rete TWNET . . . . . . . . . . 82
2.2.2
Soluzione integrata Tetra/IP . . . . . . . . . . . . . . . 84
2.2.3
Nodo TWNET . . . . . . . . . . . . . . . . . . . . . . 86
2.2.4
Sviluppo software di intercomunicazione Pe2Ne: Pei to
Network . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.3
II
Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Testing funzionale per la sicurezza dell’implemen-
tazione di protocolli di rete
3 S.T.R.E.S.S.
3.1
3.2
3.3
125
Black-Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . 126
3.1.1
Concetti di base . . . . . . . . . . . . . . . . . . . . . . 128
3.1.2
Testing per la sicurezza del software . . . . . . . . . . . 132
3.1.3
Tecnologie di Black-box testing e stato dell’arte . . . . 134
3.1.4
Stato dell’arte degli strumenti esistenti . . . . . . . . . 143
Sviluppo piattaforma S.T.R.E.S.S. . . . . . . . . . . . . . . . . 149
3.2.1
Generalità dei protocolli utilizzabili . . . . . . . . . . . 151
3.2.2
Componenti principali . . . . . . . . . . . . . . . . . . 164
Utilizzo della piattaforma . . . . . . . . . . . . . . . . . . . . 188
3.3.1
3.4
123
CLI: command line interface . . . . . . . . . . . . . . . 193
Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Indice
3.5
iii
3.4.1
SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
3.4.2
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
3.4.3
XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Sviluppi Futuri . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Conclusioni
205
Appendices
209
Definizione di ABNF in ABNF
211
Bibliografia
215
iv
Indice
Elenco delle figure
1.1
Primo grafo di esempio . . . . . . . . . . . . . . . . . . . . . . 10
1.2
Secondo grafo di esempio . . . . . . . . . . . . . . . . . . . . . 11
1.3
Terzo grafo di esempio . . . . . . . . . . . . . . . . . . . . . . 11
1.4
Profondità media dell’albero per blocchi di 200 simulazioni con
numero di nodi variabili in area 300x300 . . . . . . . . . . . . 18
1.5
Profondità media dell’albero per blocchi di 200 simulazioni con
numero di nodi variabili in area 400x400 . . . . . . . . . . . . 18
1.6
Numero di ripetizioni di canali, con scenario 300x300 al variare
del numero di nodi. . . . . . . . . . . . . . . . . . . . . . . . . 19
1.7
Numero di ripetizioni di canali, con scenario 400x400 al variare
del numero di nodi. . . . . . . . . . . . . . . . . . . . . . . . . 19
1.8
Metri quadri della zona di interferenza in un’area 300x300. . . 20
1.9
Metri quadri della zona di interferenza in un’area 400x400. . . 20
1.10 State machine dell’algoritmo implementato . . . . . . . . . . . 22
1.11 Caso di ricostruzione dell’albero . . . . . . . . . . . . . . . . . 26
2.1
Struttura della trama temporale nel set-up di una chiamata
senza presence check tramite repeater . . . . . . . . . . . . . . 41
2.2
Call setup senza presence check . . . . . . . . . . . . . . . . . 43
v
vi
ELENCO DELLE FIGURE
2.3
Struttura della trama temporale nel set-up di una chiamata
con presence check tramite repeater . . . . . . . . . . . . . . . 45
2.4
Call setup con presence check . . . . . . . . . . . . . . . . . . 47
2.5
Struttura temporale set-up chiamata di gruppo tramite DMGATEway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.6
Sequenza degli scambi di PDU nel set-up della chiamata . . . 50
2.7
Diagramma temporale della segnalazione di set-up di chiamata
con DM-GATE . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.8
Struttura temporale set-up chiamata di gruppo tramite DMGATEway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.9
Occupazione slot durante una chiamata in DMO . . . . . . . . 54
2.10 Occupazione trama temporale durante pre-emption con la presenza di DM-Repeater . . . . . . . . . . . . . . . . . . . . . . 55
2.11 Occupazione trama temporale durante la richiesta di pre-emption
con DM-GATEway . . . . . . . . . . . . . . . . . . . . . . . . 58
2.12 Scambio di messaggi durante la pre-emption al livello DMCC . 59
2.13 Scambio di messaggi durante la pre-emption al livello DMCC
in presenza di DM-GATEway . . . . . . . . . . . . . . . . . . 60
2.14 Occupazione trama temporale durante una richiesta di changeover 61
2.15 Occupazione trama temporale durante una richiesta di changeover
in chiamate di gruppo . . . . . . . . . . . . . . . . . . . . . . 63
in presenza di DM-REPeater . . . . . . . . . . . . . . . . . . . 63
in presenza di DM-GATEway . . . . . . . . . . . . . . . . . . 66
2.18 Scambio di messaggi durante changeover al livello DMCC . . . 67
ELENCO DELLE FIGURE
vii
2.19 Scambio di messaggi durante changeover al livello DMCC in
presenza di DM-GATEway . . . . . . . . . . . . . . . . . . . . 68
2.20 Occupazione della trama per l’invio di un SDS . . . . . . . . . 71
2.21 Occupazione della trama per l’invio di un SDS in presenza di
DM-REPeater . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.22 Scambio di messaggi a livello DMCC durante l’invio di SDS . 73
2.23 Diagramma funzionale dei meccanismi di encryption e decryption
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.24 Schema dello scenario TWNET . . . . . . . . . . . . . . . . . 82
2.25 Interfacce e PDU presenti nello scenario integrato . . . . . . . 92
2.26 Macchina a stati finiti del Mobile Node sull’isola origine . . . . 97
2.27 Macchina a stati finiti del Mobile Node sull’isola destinataria . 97
2.28 TWNET Call Setup . . . . . . . . . . . . . . . . . . . . . . . 99
2.29 Sequenza dei messaggi scambiati durante una chiamata senza
presence check . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
2.30 Diagramma delle classi . . . . . . . . . . . . . . . . . . . . . . 114
2.31 Diagramma sequenziale . . . . . . . . . . . . . . . . . . . . . . 115
2.32 Passaggio dei dati in ingresso lato rete multihop . . . . . . . . 120
3.1
Modello a V del processo di sviluppo software . . . . . . . . . 131
3.2
Schema del funzionamento della piattaforma S.T.R.E.S.S. . . . 151
3.3
Creazione dei messaggi utilizzando l’albero ABNF . . . . . . . 155
3.4
Modello ABNF del protocollo POP3: creazione di traffico valido156
3.5
Esempio di inserimento di anomalie all’interno del modello
ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3.6
Esempio di pacchetto di login inviato durante una sessione
valida del protocollo POP3 . . . . . . . . . . . . . . . . . . . . 159
3.7
Diagramma delle classi del modello ABNF . . . . . . . . . . . 165
viii
ELENCO DELLE FIGURE
3.8
Rappresentazione della definizione ABNF del messaggio di
login del POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.9
Diagramma delle classi della componente Parser . . . . . . . . 166
3.10 Diagramma sequenziale della procedura di parsing . . . . . . . 167
3.11 La classe Symbol . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.12 Diagramma delle classi previsto secondo il pattern Strategy . . 171
3.13 Esempio: come vengono associate le classi del pattern Strategy 172
3.14 La classe ActionFactory . . . . . . . . . . . . . . . . . . . . . 173
3.15 Diagramma delle classi del sistema di inserimento automatico
di anomalie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
3.16 Schema di funzionamento del monitor e scambio di messaggi
con le componenti . . . . . . . . . . . . . . . . . . . . . . . . . 177
3.17 Diagramma delle classi del sistema di analisi del comportamento178
3.18 Diagramma delle classi delle risposte alle azioni dei test . . . . 182
3.19 Esempio di State risultanti dall’invio del pacchetto di login del
POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
3.20 Diagramma delle classi della parte di scrittura dell’output
. . 185
3.21 Schema generale del funzionamento del dissector . . . . . . . . 186
3.22 Diagramma delle classi del Dissector . . . . . . . . . . . . . . 188
3.23 Diagramma di sequenza del Dissector . . . . . . . . . . . . . . 189
3.24 Diagramma delle classi della componente di gestione dei test
case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Elenco delle tabelle
1.1
Risultati delle simulazioni per un numero di nodi crescente . . 13
1.2
Numero di canali riutilizzati, per un numero di nodi crescente,
con possibilità di marcare canali occupati . . . . . . . . . . . . 14
1.3
Profondità media dell’albero . . . . . . . . . . . . . . . . . . . 14
2.1
Struttura degli indirizzi Tetra . . . . . . . . . . . . . . . . . . 37
2.2
Occupazione di frame e slot nella chiamata diretta senza presence check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.3
Occupazione di frame e slot nella chiamata con presence check 44
2.4
Schema del Header delle PDU TWNET . . . . . . . . . . . . . 90
2.5
Struttura dei pacchetti TWNET . . . . . . . . . . . . . . . . . 91
2.6
Campi del PDU CALL SETUP . . . . . . . . . . . . . . . . . 100
2.7
Valori dei campi del PDU CALL SETUP . . . . . . . . . . . . 103
2.8
Valori degli attributi di TwnetCallData . . . . . . . . . . . . . 104
2.9
Campi del TRAFFIC PDU . . . . . . . . . . . . . . . . . . . . 107
2.10 Valori dei campi del TRAFFIC PDU . . . . . . . . . . . . . . 108
2.11 Campi del CALL TERMIANTED PDU
. . . . . . . . . . . . 109
2.12 Valori degli attributi del TERMINATED CALL PDU . . . . . 112
ix
x
ELENCO DELLE TABELLE
Pubblicazioni
1. Rosi, M, Maccari, L, and Fantacci, R, S.T.R.E.S.S. : Stress Testing and Reverse Engineering for System Security, IEEE International
Conference on Communications, Glasgow, 2007
2. Leonardo Maccari, Matteo Rosi , Romano Fantacci, Luca Maria Aiello, Marco Milanesio, Security analysis and improvement for Kademlia
DHT, IEEE 2009 Internation conference on communications, Dresda,
2009
3. Luca Maria Aiello, Leonardo Maccari, Marco Milanesio, Matteo Rosi,
Eclipse attacks in Kad networks, Italian Networking Workshop, Cortina, 2009
4. Luca Adamo, Romano Fantacci, Matteo Rosi, Daniele Tarchi, Federico
Frosali, Analysis and Design of a TETRA-DMO and IEEE 802.11 integrated network, Emergency Management-Communication and Computing Platforms Workshop 2010
5. Documentazione per il software C.A.Dae. Implementazione dell’algoritmo di Network Auto-Forming
6. Report per Selex-Comms sullo studio di un algoritmo di Network AutoForming e risultati di simulazioni
xi
xii
Pubblicazioni
7. Maccari, L, Mando’, G, Piccinocchi, L, and Rosi, M, EPO Patent Request PCT/IT/2008/000359: Modified Ad-Hoc On-Demand DistanceVector Routing Protocol (2008)
8. Richiesta di brevetto Nodo TWNET
9. Richiesta di brevetto Trasmissione su seriale del traffico TETRA DMO
10. Richiesta di brevetto Estensione delle funzionalità Changeover e Preemption tipiche dello standard DMO allo scenario multi isola TWNET
11. Richiesta di brevetto Soluzione di sicurezza per la negoziazione di chiavi
crittografiche per applicazioni Tetra DMO su reti etorgenee
12. N.3 Report per la Convenzione con Selex-Comms su: Design ed implementazione di un sistema di AAA e provisioning convergente per reti
multifunzione Tetra WiMAX basato su RADIUS
13. Report per progetto europeo N I 2 S 3 D1.1: NEC/SOA state of the art
14. Report per progetto europeo N I 2 S 3 D4.1: Analysis and classification
of software insecurities
15. Report per progetto europeo N I 2 S 3 D4.2: Definition of a suitable
grammar to express networking protocols and design of the testing platform
Introduzione
Il lavoro di ricerca svolto in questi anni si può suddividere in due filoni, il
primo, in collaborazione con Selex-Communications, è incentrato sulla realizzazione di un’infrastruttura di rete sicura e dinamica in grado di configurarsi
autonomamente, al fine di fornire supporto a sistemi di comunicazioni professionali. Il secondo filone di ricerca invece è incentrato sulla realizzazione
di una piattaforma di testing per la verifica della sicurezza in applicativi di
rete.
Nel contesto delle reti professionali i moderni sistemi di telecomunicazioni
hanno riportato importanti risultati per quanto riguarda affidabilità, copertura ed ampiezza di banda, permettendone l’uso in un ampia varietà di
applicazioni e servizi. Tra le opzioni disponibili all’interno nel mercato professionale il sistema Tetra ed in particolare modo la sua opzione DMO (modalità
che permette la comunicazione diretta half duplex fra utenti senza il supporto di alcuna infrastruttura) ricopre un ruolo di rilevo. Questa modalità di
comunicazione è stata oggetto di una collaborazione fra Università di Firenze e Selex-Comms per individuare una soluzione ai limiti tecnici e di design
che da cui è limitata, il Tetra-DMO infatti non supporta comunicazioni multi hop, con vincoli sia sulla copertura che sulla scalabilità dell’intera rete.
L’obiettivo di fondo raggiunto durante la tesi è stato quindi quella di integrare il Tetra-DMO con un sistema di comunicazioni wireless più flessibile
xiii
xiv
Introduzione
(per esempio basato su IEEE 802.11), dove la tecnologia DMO costituisse
l’accesso al servizio e che quindi permettesse l’interoperabilità con gli altri
terminali Tetra-DMO, mentre la tecnologia IEEE 802.11 potesse essere utilizzata per fornire una flessibile e scalabile rete di backbone multi hop per
interconnettere diverse isole Tetra-DMO. Uno scenario applicativo preso in
considerazione è quello di situazioni di emergenza in caso di disastro naturale
per fornire supporto alle unità di soccorso. In questi scenari gli operatori devono agire in situazioni ambientali critiche, come per esempio all’interno di
una metropolitana, dove le comunicazioni giocano un ruolo chiave per permettere soccorsi ed interventi tempestivi. Spesso però per fornire tali servizi
non è possibile disporre, per impedimenti ambientali, di infrastrutture presenti. La rete integrata oggetto della tesi andrebbe a fornire quel supporto
alle telecomunicazioni fondamentale per le procedure di emergenza. Il deployment di una rete multi hop permetterebbe quindi la creazione di un
backbone di comunicazione per coprire luoghi difficilmente raggiungibili, in
modo da fornire copertura wireless a banda larga per trasmissioni video e permettendo, tramite l’integrazione con il Tetra-DMO, la comunicazione con un
isola DMO all’interno del luogo delle operazioni con le isole all’esterno e con il
centro operativo. Vedremo quindi il lavoro svolto in collaborazione con SelexComms che vedrà per prima cosa lo sviluppo di una rete wireless multi hop
auto configurante, che ne permette il dispiegamento e l’attivazione facilitata
e completamente automatica, con particolare attenzione all’ottimizzazione
della banda dati e alla minimizzazione delle interferenze elettromagnetiche
tipiche delle reti MANET. Successivamente verrà presentata la soluzione di
integrazione TWNET (Tetra Wireless NETwork) per permettere il collegamento fra isole DMO differenti tramite la backbone multi hop.
Il secondo filone di ricerca, sviluppato all’interno del progetto europeo N I 2 S 3 ,
xv
è stato incentrato sullo sviluppo di una metodologia di testing funzionale per
implementazioni di protocolli di rete e sulla creazione di una piattaforma per
l’esecuzione di testing di robustezza. Informatica e telecomunicazioni stanno
sempre più diffondendosi nella società moderna, diventando parte integrante
di un gran numero di attività, molto comuni sia in quelle commerciali sia
nella pubblica amministrazione, Certamente questo ha portato moltissimi
vantaggi, sia da un punto di vista economico, per esempio aumentando la
produttività dei lavoratori, sia da un punto di vista dei servizi forniti, aumentandone l’accessibilità e la fruibilità. Il numero di utenti di tipologie diverse,
dal professionista al ragazzo delle scuole medie che usufruiscono di sistemi
di comunicazione ed accedono alla rete aumentano sempre di più. I mezzi
con cui ci si connette cambiano, prima si utilizzavano prevalentemente PC,
oggi si utilizzano smartphone, notebook, netbook, tablet pc, ebook reader ed
addirittura le televisioni; anche gli elettrodomestici sono dotati di schede di
rete wireless o ethernet per poter essere integrati in un sistema di domotica.
Quindi è logico aspettarsi che nel portare l’utilizzo della rete al centro di ogni
aspetto della società moderna ci siano molti aspetti che richiedono particolare attenzione soprattutto dal punto di vista della sicurezza. A conferma di
questo è sufficientepensare ad applicazioni di home banking, ma anche più
semplicemente ai database centralizzati a livello regionale contenenti tutti i
dati sensibili sanitari di tutti i cittadini italiani. Fondamentale diventa una
corretta gestione della sicurezza dei sistemi e delle informazioni in essi contenuti, con un attenta configurazione ed analisi delle componenti coinvolte.
Per compromettere la sicurezza dei sistemi infatti basta un dettaglio, un solo
anello debole per rendere inutili tutte le precauzione prese. Si rende quindi
necessario assicurarsi che gli applicativi utilizzati non presentino alcun tipo
di vulnerabilità che possa essere sfruttata de un eventuale attaccante. Quindi
xvi
Introduzione
si rende fondamentale la necessità di eseguire dei test per assicurare che non
vi siano errori nei componenti software e soprattutto in quei programmi che
vanno ad implementare delle funzionalità di comunicazione via rete. Errori
che se si manifestano, possono venir sfruttati da attaccanti e quindi produrre
quelle vulnerabilità dei sistemi che causano danni sia economici che lesivi dei
diritti personali (per esempio violazione della privacy). Durante l’attività
di ricerca svolta in questi anni è stata ideata una metodologia per svolgere
attività di testing di robustezza su varie implementazioni di protocollo e che
potesse essere utilizzata con standard differenti ed in differenti layer della
pila ISO/OSI, inoltre illustreremo lo sviluppo di una piattaforma per permettere l’esecuzione dei test, introducendo elementi di automazione ed analisi
del comportamento delle componenti sotto test per agevolare il processo.
Parte I
Rete MANET autoformante ed
integrazione con lo standard
TETRA-DMO
Capitolo 1
CADAE: Channel Assignment
DAEmon
La prima parte del progetto di collaborazione prevede la creazione di un
sistema per il deploy facilitato di una rete mesh in grado di ovviare a problemi
di interferenze elettromagnetiche sia con altre reti wireless già presenti sia con
rami della medesima rete di backbone; verrà quindi presentato sia l’algoritmo
ideato per l’auto forming di tale rete che il prototipo di software che andrà ad
implementare tale algoritmo e che girerà sui nodi della rete mesh di backbone.
La rete auto formante sarà costituita da router dotati di 4 interfacce wireless, 3 di queste saranno dedicate alla costruzione della rete di backbone e
saranno interfacce wi-fi di tipo IEEE 802.11a quindi con portante a 5 Ghz
mentre la quarta sarà un’interfaccia wi-fi di tipo IEEE 802.11g per la fornitura del servizio di connettività dati. I router saranno dotati di una particolare
versione sistema operativo GNU/Linux specifica dei dispositivi embedded,
per l’esattezza OpenWRT Kamikaze 8.09 [1]. Questi device necessitano di
una alimentazione Power over Ethernet e saranno dotati di sistema di alimentazione a batteria in modo da poter essere facilmente dislocati senza
3
4
Capitolo 1. CADAE: Channel Assignment DAEmon
alcun problema. Le schede di rete wireless sono tutte basate su chipset
atheros ed il loro funzionamento sarà gestito dai driver presenti nel kernel
linux MadWIFI [2]
1.1
La generazione automatica della rete MANET
L’assegnazione dei canali su una rete mesh, con lo scopo di minimizzare il
grado di interferenza tra due link della stessa rete è un tema su cui si sta
sviluppando un filone di ricerca nuovo ed attivo. Il problema del channelassignment, da un punto di vista teorico rimane un problema irrisolto, se non
con soluzioni parziali o che fanno leva su euristiche non applicabili a tutti i
contesti, visto che le implicazioni teoriche del problema stesso sono particolarmente difficili da affrontare. Da un punto di vista generale, il problema
di scegliere i canali su una rete mesh è assimilabile ad una delle varianti del
problema teorico di colorazione di un grafo. Tale problema è ben noto in
letteratura, e può essere descritto come segue: dato un grafo, e un insieme
finito di colori, associare ad ogni arco del grafo un colore preso dall’insieme
a disposizione in modo che non esista un nodo della rete collegato a due
archi dello stesso colore. Calato nella pratica delle reti mesh, ogni arco è un
link, ogni colore è un canale, in questo modo si garantisce che ogni nodo non
possieda due link sulla stessa frequenza, e quindi che si fanno interferenza.
Alcune precisazioni sono necessarie:
• il miglior algoritmo per la risoluzione del problema della colorazione del
grafo è dimostrato essere NP-completo, quindi non esiste un algoritmo
efficiente per trovare una soluzione. Inoltre, non sempre esiste una
soluzione al problema;
1.1. La generazione automatica della rete MANET
5
• il modello della colorazione del grafo non descrive efficacemente il problema in tutti i suoi lati. Un nodo può provocare interferenza anche verso
un altro nodo con cui non condivide nessun link, per il noto problema
del nodo nascosto;
• gli algoritmi di colorazione del grafo, presuppongono la conoscenza a
priori di tutto il grafo ed agiscono come un’entità centralizzata. In una
rete mesh non si può fare un’assunzione di questo tipo, ma l’algoritmo
dovrebbe funzionare in modo distribuito e cooperativo tra i nodi;
• una volta trovata una soluzione, l’assegnazione dei colori agli archi non
è indipendente, ma cambiare il colore di un solo arco può implicare
una riconfigurazione di altri archi del grafo. In altre parole, una volta
trovata una soluzione per un dato grafo, non è detto che trovare una
soluzione per lo stesso grafo leggermente modificato (ad esempio per
la caduta di un link) sia più facile che trovare una partendo da zero.
Inoltre, la riassegnazione di un canale non può essere effettuata in modo efficiente utilizzando le informazioni posseduta da un singolo nodo,
perché si rischia sempre di produrre l’effetto del nodo nascosto.
Da queste basi, esistono articoli in letteratura che presentano soluzioni
particolari, applicabili in contesti limitati, o che prevedono grossi interventi
sullo strato MAC. Ad esempio , Raniwala [3] introduce un algoritmo centralizzato per la channel-assignment in reti mesh. In un successivo articolo
si introduce anche la possibilità di realizzarne una variante distribuita, ma
con un notevole aumento di complessità. Altre tecniche si concentrano sull’assegnazione di un set di canali in cui ogni scheda di rete viene collegata
sempre allo stesso canale, ed all’utilizzo di tecniche per la decisione del link
da utilizzare per ogni pacchetto [4], o ad euristiche basate sui dati di una
6
parte limitata della rete [5] . Dovendo realizzare una soluzione attuabile nella pratica sugli apparati mesh forniti, si è scelto un algoritmo che non prevede
cambiamenti ai livelli MAC (condizione necessaria per poter essere applicato), e che pur rappresentando una soluzione sub ottima nel contesto generale,
fornisce buone prestazioni nel contesto di rete identificato dalla convenzione.
Tale contesto è il seguente:
• rete di piccole dimensioni (5 nodi fissi più un gateway) ma estendibile
ad un numero di nodi superiore
• nodi equipaggiati con 3 schede di rete per la formazione del backbone
• assenza di mobilità
• necessità di riconfigurazione solo temporanea.
L’ultimo punto deriva da quanto detto in precedenza sulla riorganizzazione di una rete già formata. Una volta stabilita una configurazione iniziale ottima, questa non viene rimessa in discussione se un link si rende
indisponibile. Quello che succede è che un nodo che si ritrova momentaneamente isolato si appoggerà su un canale già occupato da altri nodi, almeno
fino a quando il link iniziale non viene ripristinato. L’algoritmo descritto
nella sezione successiva è stato realizzato su un simulatore, con lo scopo
di verificare la bontà dello schema di allocazione dei canali scelto. Lo scenario simulato è un’astrazione di una rete mesh reale, quindi serve a giudicare la distribuzione dei canali, nella fase implementativa si verificheranno le
prestazioni e le modifiche necessarie perché sia funzionante sulle piattaforme
hardware scelta per lo sviluppo del prototipo.
1.2. Il problema del interference detection
1.2
7
Il problema del interference detection
Algoritmi avanzati di interference detection esistono in letteratura, ma possono essere utilizzati avendo il controllo dei parametri di basso livello della
comunicazione. Il driver madwifi maschera il comportamento dei componenti
di basso livello della scheda di rete e si interfaccia con un modulo proprietario
chiamato hal, che include tutta la parte di elaborazione del segnale. Le uniche
informazioni che vengono restituite allo spazio utente sono i risultati delle
scansioni prodotte dalla scheda di rete. Le scansioni restituiscono il numero
di altre reti trovate nel raggio di copertura dell’apparato, insieme al rapporto segnale/rumore per ciascuna di esse. Avendo a disposizione solo questi
dati, l’algoritmo di interference detection si riduce ad un semplice ranking
dei canali a disposizione, escludendo quelli già occupati da altri access point
ordinati per la potenza del segnale ricevuto. La funzione di scan fornita dal
driver madwifi infatti restituisce una lista degli AP il cui segnale è ricevuto
dalla stazione client, insieme al valore dell’intensità del segnale ricevuto. Con
questi strumenti a disposizione, dopo la scansione si dà un giudizio sul grado
di interferenza relativo al canale prescelto, tale valore può essere calcolato
come la somma delle potenze ricevute dagli AP circostanti. Considerato che
il traffico all’interno di una rete wifi può essere molto variabile nel tempo,
a seconda del numero di utenti e del tipo di traffico che essi generano, non
sembra plausibile introdurre una fase di scansione temporale limitata, in cui
su ogni canale il nodo prescelto ascolta in modalità monitor per un periodo
prolungato, con lo scopo di stimare il carico della rete con cui si fa interferenza. Con una strategia simile, infatti, un nodo potrebbe spenderebbe alcuni
secondi per ogni canale prescelto, ascoltare tutto il traffico su quel canale e
stimare con più precisione il livello di interferenza che incontrerebbe su quella frequenza. Tale stima deve essere ripetuta nel tempo, altrimenti perde di
8
significato, ma per poterla realizzare è necessario cambiare la modalità usata
dalla scheda (che viene spostata in modalità monitor), interrompendo cosı̀
il suo normale funzionamento. Durante la fase di scansione, che può essere
effettuata anche in background, ovvero senza che la scheda cambi modalità
o si disconnetta dal proprio access point (se viene utilizzata in modalità
client), la scheda non rimane un tempo sufficiente sullo stesso canale per
poter ricevere sufficiente traffico e poter realizzare una stima del carico sulla
rete. L’unica soluzione rimane quella di basare il ranking delle frequenze su
due parametri, il numero di AP che vengono individuati su un determinato
canale, e la potenza del segnale ricevuto da quegli AP. La potenza è un valore
in db che viene esportato dalle schede di rete attraverso le interfacce standard wireless extension del kernel di linux, quindi una somma normalizzata
del valore di potenza riportato per ogni AP su quel canale sembra essere la
stima migliore per definire il livello di occupazione del canale.
1.2.1
Assegnazione dei canali basato su una topologia
ad albero
Il tipico scenario di rete associabile all’utilizzo degli apparati mesh è quello di
una rete in cui un gateway, equipaggiato con una o due schede di rete fornisce
connettività verso l’esterno, e gli altri nodi vengono utilizzati per costruire
una “magliatura” che copra la maggiore superficie possibile. Più che di una
vera rete mesh, si può parlare di una topologia ad albero, in cui il nodo
gateway divide la rete in due tronconi. Si immagina anche che la maggior
parte del traffico sia diretto da e verso i nodi della rete all’esterno, e che
venga comunque instradato dal gateway stesso. L’algoritmo sfrutta questa
naturale gerarchia della rete suddividendo l’insieme dei canali utilizzabili in
9
due sottoinsiemi e introducendo delle politiche di fail-over in caso di problemi
di connessione. L’algoritmo può essere descritto brevemente come segue:
• ogni nodo, gateway escluso, utilizzerà una scheda di rete in modalità
managed, con cui si lega al suo padre, e due schede di rete in modalità
master a cui si legheranno i suoi figli. Ogni scheda in modalità master
accetta un unico figlio come client, l’albero che si crea è binario.
• Il nodo gateway, se equipaggiato con due schede di rete, le utilizza
entrambe in modalità master, e nel pacchetto di beacon specifica due
parametri: il primo indica la sua profondità nell’albero (che sarà ovviamente 0), il secondo è il sotto albero a cui è associata la scheda di
rete (destro o sinistro). Da notare che se il gateway è equipaggiato con
una sola scheda di rete, lo stesso principio può essere applicato usando
due sotto reti virtuali appoggiate sulla stessa scheda. Il gateway quindi
divide la rete in due tronconi, sulla sotto rete destra si useranno i canali
pari, su quella sinistra si useranno i canali dispari.
• I nodi che non sono gateway, inizieranno una scansione con la scheda in
modalità client. In questo modo riceveranno la presenza dei beacon del
gateway e tenteranno di connettersi ad una delle sue schede, ma solo
uno per scheda di rete (reale o virtuale) sarà in grado di autenticarsi.
Inoltre la scansione serve a capire se ci sono altri nodi che utilizzano altri
canali nella stessa zona. Un nodo associato al gateway sponsorizzerà
nei propri beacon una profondità pari a 1.
• se un nodo non riesce a collegarsi al gateway perché non riceve i suoi
beacon o perché non viene autenticato, ripeterà la procedura di scan
per cercare dei nodi a profondità 1, e tentare di connettersi. Una volta
trovato un padre, il risultato della ultima scansione viene utilizzato
10
anche per scegliere i canali più liberi su cui impostare le schede master
a cui si connettono i propri figli. Preferibilmente, il nodo sceglierà
un canale libero, superiore a quello usato dal padre. In questo modo
scendendo nell’albero si scelgono canali con indice più alto, e si evita il
fenomeno del nodo nascosto. Una volta arrivati in fondo alla lista dei
canali utilizzabili si riparte dal primo.
Figura 1.1: Primo grafo di esempio
La suddivisione dei canali in pari e dispari fa sı̀ che avvenga una distribuzione migliore delle frequenze. Due nodi che sono in range di trasmissione infatti si accorgono della presenza reciproca e possono evitare di scegliere
lo stesso canale. Se i due nodi non sono in range invece non possono accordarsi, quindi potrebbero produrre interferenza su un terzo nodo che è nel range di
entrambi, per il problema del nodo nascosto. L’impatto di tale problema può
essere limitato se nodi in posizioni geografiche diverse utilizzano canali diversi. Questo viene garantito nella profondità dell’albero utilizzando i canali in
modo incrementale, e viene reso più efficace anche discriminando i canali tra
la metà destra e sinistra dell’albero. Lo schema cosı̀ descritto realizza in mo-
Figura 1.2: Secondo grafo di esempio
Figura 1.3: Terzo grafo di esempio
11
12
do molto semplice un’allocazione dei canali che per reti di piccole dimensioni
si rivela, secondo le simulazioni effettuate molto efficiente. In reti di piccole
dimensioni basate su IEEE 802.11a [6] (in cui esistono 12 canali separati in
frequenza) il problema della colorazione del grafo si riduce di complessità
visto che aumentando i canali a disposizione in relazione al grado del grafo
(il numero massimo di vicini di ogni nodo) si alleggeriscono i vincoli. Le
modifiche necessarie al MAC per realizzare l’algoritmo sono minime, le informazioni aggiuntive nel beacon possono essere inserite in un campo ad-hoc se
il driver lo permette, o più semplicemente direttamente nel nome della rete
(essid). Il fail-over viene gestito utilizzando una scheda virtuale di backup
per ogni nodo. Può succedere infatti che se un link diviene inutilizzabile un
nodo si trovi isolato dalla rete. Ad esempio, se il suo unico vicino ha già due
figli e quindi non accetta più connessioni. Questa situazione, che si genera
molto raramente nella fase di deployment (le simulazioni mostrano che per
1000 topologie differenti con 5 nodi più un gateway solo 9 nodi rimangono
isolati) può avvenire in presenza di cambi di topologia (per qualche motivo un link diventa inutilizzabile). La situazione viene risolta aggiungendo
per ogni scheda di rete in modalità master un essid virtuale, di backup. Su
questo essid non c’è limite di client connessi contemporaneamente, quindi se
un client rimane orfano in un dato istante, può connettersi ad un essid di
backup che riesce a trovare. L’essid di backup condivide il canale con una
scheda in modalità master, quindi la banda a disposizione è condivisa tra
due client, due osservazioni sono necessarie:
• In un contesto di rete ad albero, la condivisione dello stesso link non
implica automaticamente limitazione di banda. Per comprendere questa affermazione si osservino le figure 1.1, 1.2 e 1.3. Il link tra il nodo
gateway e il nodo 1 rappresenta comunque un collo di bottiglia per
13
Nodi
Nodi orfani
Altezza media
5
0
0.27
6
0
3
7
1
3.2
Tabella 1.1: Risultati delle simulazioni per un numero di nodi crescente
il traffico da e verso la rete, quindi la disposizione dei nodi nel sotto
albero sinistro non influisce realmente sulle prestazioni della rete nel
traffico di ingresso e uscita. Chiaramente però aumentare il numero
di nodi sullo stesso link può rendere il MAC più inefficiente, quindi è
consigliabile tornare, quando possibile alla configurazione iniziale.
• Per questo motivo, il client può produrre delle scansioni in background
alla ricerca del suo vecchio link e ricollegarcisi nel caso in cui il link
ritorni disponibile.
Risultati delle simulazioni
L’algoritmo è stato valutato utilizzando il framework Omnet++ su piattaforma GNU/Linux. Le simulazioni hanno dimostrato che in reti fino a 7 nodi
di backbone più un gateway l’algoritmo è molto efficiente.
In tabella 1.1 si riportano alcuni risultati prodotti su 100 simulazioni
con topologie random. Dalla tabella si evidenzia che all’aumentare dei nodi
di backbone il numero di nodi orfani (nella seconda colonna della tabella è
riportata la somma totale su tutte e 100 le simulazioni) non è rilevante, i
nodi avrebbero comunque la possibilità di connettersi ad una interfaccia di
backup (possibilità che nella simulazione non è stata implementata). La terza
colonna riporta l’altezza media dell’albero nelle simulazioni effettuate. Una
ulteriore valutazione è stata effettuata permettendo ai nodi della backbone di
14
0
1
2
3
5 1.03 0.85
0.8
0.71
6 1.56
1.35 1.22
1.4
7 2.28 2.07
1.9
1.78
Tabella 1.2: Numero di canali riutilizzati, per un numero di nodi crescente, con
possibilità di marcare canali occupati
0
1
2
5 2.62 2.59 2.61
3
2.6
6 2.97 2.91 2.93 2.97
7 3.21 3.18 3.19 3.19
Tabella 1.3: Profondità media dell’albero
scegliere, in modo casuale fino a tre canali che non possono essere utilizzati.
In questo modo si simula la possibilità di un nodo di non poter utilizzare un
dato canale per l’interferenza generata da parte di reti terze. Nel momento in
cui deve scegliere i canali da assegnare alle proprie schede di rete master, oltre
ai risultati della scansione si scelgono anche fino a tre canali marcati come
occupati. Il numero di nodi orfani che si misurano dopo 1000 simulazioni di
questo tipo è inferiore allo 0.5% del totale dei nodi utilizzati.
In tabella 1.2 si riporta il numero di volte che un canale viene riutilizzato
(in media) per ogni simulazione, all’aumentare (sulle colonne) del numero
massimo di canali marcati occupati da un nodo. Si vede che le interferenze
anche dovute al nodo nascosto, con un tasso di riutilizzo delle frequenze cosı̀
basso non producono un danno rilevante, in ogni caso, ci si aspetta che la
scelta incrementale del numero di canale minimizzi l’effetto del nodo nascosto.
Aumentando il numero di nodi, si aumenta anche la profondità media
dell’albero, come riportato nella tabella 1.3.
15
Sono poi stati valutati degli scenari più generali, in particolare sono
state considerate situazioni con un numero maggiore di nodi e una area geografica maggiore. Lo scopo delle simulazioni era verificare la scalabilità
dell’algoritmo.
Utilizzando un numero di nodi maggiore il numero di volte che lo stesso canale viene riutilizzato aumenta, ma aumenta anche la superficie totale
coperta dalla rete quindi usare più volte lo stesso canale non significa automaticamente generare interferenze. Per valutare l’ampiezza delle zone di
sovrapposizione quindi è stato necessario modificare il codice delle simulazioni
per produrre un’analisi più dettagliata sul numero di metri quadri in cui c’è
sovrapposizione, piuttosto che sul numero di riutilizzi del canale stesso. Sono
state effettuate prove con un numero di nodi da 5 a 15, in aree di quadrate
di lato 300m e 400m. Per ogni nodo si considera una zona di copertura
circolare di raggio 150m, secondo le stime effettuate con il simulatore. Per
ogni scenario sono state effettuate 200 simulazioni, ognuna con topologia casuale. Dai risultati sono state eliminate le simulazioni che rappresentavano
un caso irrisolvibile, ovvero quelle simulazioni in cui un nodo, per via della
disposizione casuale, cascava all’esterno della zona di copertura di ogni altro
nodo, rimanendo isolato. Le grandezze misurate sono:
• i metri quadrati dell’area di copertura ovvero la somma delle aree
coperte da ogni AP, senza contare più volte le intersezioni;
• l’area totale della zona di interferenza, ovvero la somma delle aree di
intersezione in cui gli AP che si sovrappongono usano lo stesso canale.
Questa grandezza ci dà una stima della percentuale della superficie
totale in cui possono avvenire collisioni;
• la profondità media dell’albero che si viene a creare;
16
• il numero di ripetizioni nell’utilizzo di un determinato canale, per tutti
i canali;
• il numero di nodi orfani, ovvero nodi che hanno come unico punto di
attacco alla rete un altro nodo che ha già le sue interfacce occupate con
altri, quindi non accetta più connessioni.
Il primo valore significativo è quello che riguarda i nodi orfani che è minore
dello 1% in ogni simulazione effettuata. Nello scenario 400x400, per un blocco
di 200 simulazioni con una media di 10 nodi per simulazione, si ha una media
di 11 nodi orfani, quindi immaginando di avere 200 deployment diversi della
stessa rete contenente mediamente 10 nodi, solo 11 non riescono a collegarsi,
con una percentuale dello 0.55%. Nello scenario 300x300 la percentuale è
ancora inferiore. Per quello che riguarda la profondità dell’albero, il grafico
1.4 mostra la distribuzione delle profondità al variare del numero dei nodi
della simulazione. La profondità massima è di 5 hop, e la maggioranza delle
simulazioni producono una profondità tra 3 e 4 hop, con la simulazione con 9
nodi a fare da elemento intermedio. In figura 1.5 si riporta lo stesso grafico per
la superficie 400x400, in cui i risultati sono molto simili, si nota però un lieve
spostamento verso sinistra del grafico, aumenta il numero di simulazioni con
profondità 5 e la simulazione con 9 nodi ha una maggioranza di risultati con
profondità 4. Lo spostamento è dovuto all’incremento dell’area, che dispone
i nodi mediamente più lontani, quindi non sempre è possibile costruire un
albero bilanciato. La figura 1.6 mostra il numero di volte che nella stessa
rete viene riutilizzato un canale per la topologia 300x300. Ogni volta che
un canale viene riutilizzato, anche in zone diverse della rete si incrementa
questo valore di uno. Non vengono considerati i canali scelti dalle foglie
dell’albero per le schede in modalità master, perché pur occupando un canale,
17
non producono traffico non avendo figli. Avendo a disposizione molti canali
(12) il numero di ripetizioni rimane molto basso.
Per la topologia 400x400 l’effetto è lo stesso che per la profondità dell’albero, aumentando la profondità c’è anche un maggiore riuso dei canali.
Infine, nella figura 1.8 viene riportata l’area totale coperta dagli AP, e l’area
totale di sovrapposizione dei canali. Si osservi che su una superficie totale di
90.000 MQ, già con 10 nodi si ha una copertura quasi totale della zona ed aumentando il numero di nodi, l’unico effetto è quello di aumentare la superficie
in cui avvengono collisioni. Nella figura 1.9 lo stesso grafico viene riportato
per un’area di 160.000 MQ. Anche in questo caso aumentando il numero di
nodi si aumenta il numero totale di MQ di copertura ma si aumenta anche
il numero di MQ di interferenza, anche se le distanze mediamente maggiori
allontanano i nodi tra loro e quindi diminuisce l’area di sovrapposizione.
Conclusioni Le simulazioni dimostrano che l’area di interferenza su superfici di 300x300 e 400x400 metri rimane comunque limitata specialmente
nel caso della superficie maggiore. Questo ha come conseguenza l’aumento
della profondità dell’albero, quindi l’aumento del numero di hop medi di un
pacchetto verso il gateway. Da notare anche come l’aumento della profondità dell’albero comporta anche maggiore spesa di riconfigurazione nel caso
di cambio di topologia, ma una maggiore densità di AP nella stessa area
permette collegamenti migliori tra gli AP stessi. Dalle simulazioni non è
possibile stimare le prestazioni in termini di traffico. Appare chiaro che deve
essere trovato un trade-off sul numero di nodi utilizzati, visto che aumentalo significa garantire maggiore copertura e migliori collegamenti, ma anche
maggiore delay e maggiore interferenza.
18
Figura 1.4: Profondità media dell’albero per blocchi di 200 simulazioni con numero
di nodi variabili in area 300x300
Figura 1.5: Profondità media dell’albero per blocchi di 200 simulazioni con numero
di nodi variabili in area 400x400
19
Figura 1.6: Numero di ripetizioni di canali, con scenario 300x300 al variare del
numero di nodi.
Figura 1.7: Numero di ripetizioni di canali, con scenario 400x400 al variare del
numero di nodi.
20
Figura 1.8: Metri quadri della zona di interferenza in un’area 300x300.
Figura 1.9: Metri quadri della zona di interferenza in un’area 400x400.
1.3. Sviluppo demone CADAE
1.3
21
Sviluppo demone CADAE
Una prima implementazione dell’algoritmo è stata sviluppata in ruby e implementata sulle macchine costituenti la rete mesh, in un testbed composto
da un nodo fisso con una sola interfaccia (il gateway) e tre nodi equipaggiati
con 4 interfacce di rete, di cui tre per il backbone e una per la copertura.
Inoltre iè stato scelto di utilizzare per comunicare e pilotare le schede wireless
solamente strumenti di sistema presenti in tutte le distribuzioni linux, in modo da assicurarci un funzionamento delle schede omogeneo anche su macchine
diverse. Per la precisione sono stati usati i seguenti pacchetti software:
• wireless-tools: una serie di tool per configurare la modalità di configurazione delle schede, il canale di ascolto e tutte le configurazioni base
della scheda;
• wpa-supplicant: tool per lo scanning dei canali e per l’autenticazione
verso access point utilizzando i vari algoritmi di comunicazione previsti
dallo standard;
• hostapd: software di emulazione di access point e autenticator, implementa funzionalità avanzate che non vengono fornite da una scheda in
modalità master, come ad esempio il numero massimo di client associati
e autenticazioni WPA.
L’implementazione dell’algoritmo è quella descritta nella macchina a stati
di figura 1.10, nella fase attuale non sono state implementate le procedure di
backup.
22
SEARCH_PARENT
scan
found_ap
connect_timeout retry_max go_search
CONNECTING
ENABLE_BK
connect to best AP
enable_bk_ssid
found_parent
found_bk
CONNECTED
BK
set_params
set no_params_bk
reconnect_timeout
go_watch go_watch
WATCH_CONNECTION
watch_loop
lost reconnected
LOST
retry_and_check
Figura 1.10: State machine dell’algoritmo implementato
1.3.1
23
Macchina a stati
L’applicazione se avviata con il parametro gateway si aspetta di trovare una
sola scheda di rete, fa una scansione dei canali liberi, una volta effettuato il
ranking basandosi sul numero e sulla potenza degli AP presenti in ogni canale,
sceglie un canale e fissa tre essid virtuali, 0 L, 0 R, backup. Per ogni essid si
fa partire un’istanza di hostapd, impostando il parametro max num sta ad
1 in modo che ad ogni ssid non si possa collegare più di una stazione. Se
avviato senza tale parametro, una scheda di rete viene avviata in modalità
managed e si inizializza una macchina a stati composta da 7 stati:
• SEARCH PARENT: In questo stato si richiamano le funzioni di scan,
utilizzando l’applicativo wpa cli.
Si fa il ranking delle risposte, e
si configura wpa supplicant attraverso wpa cli rendendo enabled le
reti migliori e rispettando il ranking realizzato nella scansione, tra le
risposte ricevute si eliminano gli essid backup. A quel punto si va nello
stato CONNECTING. Se non si trovano essid validi dopo un numero
parametrizzabile di tentativi ci si sposta nello stato ENABLE BK
• ENABLE BK Questo stato è uno stato fittizio, realizzato solo per
chiarezza e per esigenze di logging. In questo stato vengono abilitati
anche gli ssid backup e si torna allo stato SEARCH PARENT.
• CONNECTING: attraverso wpa cli si iniziano i tentativi di connessione
alle reti identificate nella fase di scan. Se dopo 5 secondi la scheda non è
ancora connessa, si setta a disable l’essid scelto e si passa al successivo.
Se tutta la lista fallisce si torna a SEARCH PARENT, se si ottiene una
connessione si passa a CONNECTED, se la connessione ottenuta è su
un essid backup si passa a BK.
24
• CONNECTED: si impostano le 2 interfacce master su due canali liberi,
dopo aver effettuato una nuova scansione, e gli si assegnano degli essid
del tipo X L, X R dove X è la profondità del padre aumentata di uno.
Si passa in WATCH CONNECTION.
• BK: senza impostare le schede in modalità master si passa allo stato WATCH CONNECTION. Un nodo collegato ad un’interfaccia di
backup infatti è il terzo nodo collegato al genitore, altrimenti avrebbe
trovato libero uno degli altri due essid. Si vuole evitare che altri nodi
scelgano questo nodo come genitore a loro volta, sovraccaricando quel
ramo. Dalle simulazioni effettuate risulta comunque che il caso in cui
un nodo abbia bisogno di un’interfaccia di backup è molto raro.
• WATCH CONNECTION: in questo stato, periodicamente si controlla
lo stato della connessione verso il padre, se la connessione viene persa,
si passa nello stato LOST
• LOST: per tre tentativi intervallati da un secondo si controlla se la
connessione è stata recuperata, alternativamente, si abbattono le schede
in modalità master, si aspetta un secondo per dare il tempo ai propri
figli di scollegarsi e si ritorna nello stato SEARCH PARENT
1.3.2
Risultati prestazionali
Sono state effettuate dieci prove in sequenza per validare l’approccio e le
prestazioni del codice, che è tuttora sperimentale. L’instabilità delle macchine utilizzate nel testbed ha reso più difficile lo svolgimento dei test stessi.
Durante le prove effettuate l’albero viene sempre costruito correttamente,
a differenza delle simulazioni però le scansioni sono più imprevedibili, non
sempre dopo una scansione un nodo riesce a riconoscere tutti i suoi vicini,
25
il numero di scansioni è quindi stato aumentato a 3 consecutive prima di
passare nello stato connecting. Inoltre, il figlio destro di un nodo aspetta
sempre un secondo, per permettere all’eventuale figlio sinistro di collegarsi
per primo. Altrimenti i due nodi faranno scansioni contemporaneamente e
non si troveranno a vicenda. Su 10 test effettuati il primo nodo a connettersi
alla rete impiega mediamente circa 12 secondi, il secondo nodo intorno ai
40, perché generalmente prova a connettersi allo stesso ssid già occupato dal
primo fallendo. Il terzo, fallisce due volte di seguito, perché prova prima gli
ssid a livello 0 che sono già occupati, quindi cercherà di connettersi ad un
nodo di livello 1, mediamente impiega un minuto per connettersi. I fallimenti sono dovuti al fatto che altri nodi potrebbero già essere collegati all’AP
scelto, quindi l’AP non permetterà altre connessioni per mantenere l’albero
al più in forma binaria. Durante le prove sono stati effettuati dei tentativi
di disconnessione e riconnessione di un nodo intermedio nell’albero, come
descritto in figura 1.11. Come ci si attendeva, dalla situazione iniziale (1)
per un evento di disconnessione (spegnimento della macchina) la macchina
L2 diventa la L1 ovvero il secondo figlio del GW (2), nel momento in cui
la macchina viene riaccesa non trovando più libere le interfacce del GW che
vengono scelte con preferenza sulle altre, il nodo diventa figlio di uno dei due
nodi già connessi all’albero (3).
26
Figura 1.11: Caso di ricostruzione dell’albero
Capitolo 2
TWNET: Tetra Wireless
NETwork
La seconda parte della collaborazione con Selex-comms prevede l’utilizzo
della rete mesh auto configurata dal software CADAE per estendere il sistema
di comunicazione Tetra DMO. Il protocollo Tetra [7] fornisce un sistema
di telecomunicazioni in gradi di garantire sia sicurezza che affidabilità delle
comunicazioni, a testimonianza di ciò questi sistemi sono in dotazione alle
principali forze dell’ordine e militari italiane ed estere. La sicurezza delle
trasmissioni viene garantita da due livelli di sicurezza implementati in due
livelli protocollari distinti; il grado di affidabilità invece viene determinato
principalmente da quanta copertura del segnale viene data ad i vari terminali,
per questo il Tetra fornisce due tipi diversi di funzionamento:
• Trunked Mode (TMO): modalità infrastrutturale dove il servizio viene
garantito sotto la copertura di una Base Station Tetra,
• Direct Mode (DMO): modalità non infrastrutturale dove i vari terminali
comunicano direttamente l’uno con l’altro senza l’ausilio di una BS.
27
28
Capitolo 2. TWNET: Tetra Wireless NETwork
L’obbiettivo del progetto TWNET è quindi quello di superare alcuni
limiti della modalità di comunicazione DMO per poter ampliare ulteriormente la possibilità di copertura per riuscire a garantire affidabilità delle
comunicazioni anche in situazioni ambientali difficili o in scenari di emergenza. Per far questo si è pensato di ampliare il funzionamento dei terminali DMO con l’adattabilità e la facilita di deploy delle reti mesh presentate
precedentemente, in modo da fornire una backbone di supporto alle normali
comunicazioni Tetra.
L’idea è quindi quella di dotare i nodi mesh di un’interfaccia Tetra per
poter esportare e importare segnalazioni e traffico voce fra i due mezzi di
telecomunicazioni, da una parte una rete mesh basata su IP e dall’altra isole
Tetra DMO. Per far questo è necessario avere un’interfaccia in grado di accedere in ricezione ed invio al mezzo Tetra per poi riuscire a tradurre queste
informazioni in traffico IP e viceversa. Presenteremo quindi i servizi che
saranno interessati dal nostro sistema, la nuova struttura dei nodi mesh con
l’interfaccia Tetra/IP scelta ed eventuali estensioni che dovranno essere implementate per garantirne la corretta funzionalità, ed infine il software che
è stato sviluppato per permettere lo sviluppo del prototipo di questa rete
mista.
2.1
Lo standard Tetra
Nell’ambito dei sistemi radio professionale l’ETSI ha sviluppato il protocollo
di comunicazione TETRA (TErrestrial Trunked RAdio), protocollo che per
completezza e funzionalità può essere paragonato al più famoso GSM utilizzato per i sistemi pubblici di radiocomunicazione mobile. A differenza delle
reti pubbliche, TETRA va a soddisfare esigenze più specifiche e prevede fun-
2.1. Lo standard Tetra
29
zionalità avanzate andando cosı̀ a coprire il settore di mercato delle utenze
professionali. Infatti va a soddisfare specifiche esigenze di sicurezza, privacy,
flessibilità e soprattutto affidabilità tanto da essere considerato protocollo di
riferimento per le telecomunicazione da parte degli enti governativi europei.
I sistemi TETRA sono in grado di inviare simultaneamente sia dati che
traffico voce, il collegamento radio è dotato di 4 canali indipendenti in grado di garantire la trasmissione contemporanea delle due tipologie di traffico.
Un’altra caratteristica che permette questa trasmissione simultanea è la separazione in slot temporali di una singola portante e la possibilità, da parte
di un device , di farsi allocare più slot temporali per l’invio dei dati. Secondo lo standard ETSI, si prevede l’uso di una tecnologia digitale in grado di
garantire una buona qualità audio paragonabile al GSM ed un basso rate di
errori per le trasmissioni dati.
Queste caratteristiche sono abbinate ad alti livelli di sicurezza paragonabili ai sistemi di telefonia fissa, grazie a diversi livelli di autenticazione:
• l’utente con la radio;
• la radio con la rete;
• la rete con la radio;
• fra reti diverse;
• fra gli utenti;
Queste feature rendono questa tecnologia il principale punto di riferimento
nelle comunicazioni radio professionali.
TETRA è in gradi di lavorare in 3 principali modalità:
1. DMO (Direct Mode Operation): che permette la comunicazione fra i
terminali quando si è fuori copertura della rete;
30
2. V+D (Voice + Data): in modalità trunked permette l’invio simultaneo
dei due tipi di traffico;
3. PDO (Packet Data Optimized): permette di raggiungere le massime
velocità di trasmissione dati.
Vi sono alcuni ruoli fondamentali ed alcuni concetti base indispensabili
per la corretta comprensione dello standard:
• Master : ruolo ricoperto dal terminale che è in possesso del canale
• Slave: tutti gli altri terminali presenti sul canale;
• le modalità operative di utilizzo del canale sono due:
1. normal mode: solamente una chiamata può essere eseguita su una
certa frequenza, indipendentemente dal tipo di chiamata se di
gruppo o individuale;
2. frequency efficient mode: in questa modalità si possono attivare
al massimo due chiamate su una stessa frequenza;
• in modalità DMO sono premesse solo chiamate simplex sia che siano
di gruppo o individuali;
• nel DMO non vi è alcuna correlazione fra indirizzi e frequenze di trasmissione, per esempio possono essere attivate chiamate ad uno stesso destinatario ma su frequenze diverse;
• in modalità DMO un terminale può ricevere una chiamata solo se ha
selezionato la frequenza sulla quale viene effettuata tale chiamata;
31
• gli indirizzi identificano un terminale o un gruppo di terminali, un
indirizzo è costituito da una prima parte chiamata MNI (Mobile Network Identity) che rappresenta l’identificativo di rete a cui appartiene
il terminale e da una seconda parte univoca che identifica il device;
• su un terminale sono configurati vari indirizzi:
1. un ITSI Address;
2. due Open Group GTSI: indirizzi di gruppo che consentono di identificare tutti i terminali presenti su di una frequenza o tutti quelli
aventi uno stesso MNI;
oltre a questi tre indirizzi possono essere configurati altri indirizzi di
tipo GTSI;
• un terminale può ricevere una chiamata solo se questa è indirizzata ad
uno degli indirizzi in esso configurati.
2.1.1
Architettura DMO
Lo stack protocollare DMO ha tre layer che implementano varie funzionalità a basso livello, andremo adesso a presentarle in modo da chiarire le
varie entità che vengono coinvolte durante il funzionamento del sistema di
telecomunicazione.
Air interface layer 1
Il primo e il più basso layer nello stack protocollare si occupa della comunicazione del mezzo fisico ed in particolar modo gestisce la definizione della
modulazione, sincronizzazione radio del TDMA, codifica del canale e multiplexing dello stesso. Il progetto TWNET prevede la conservazione della
32
struttura di comunicazione del DMO originale, sorvoliamo quindi su approfondimenti tecnici poiché non è stato argomento di studio al fine del
progetto.
Il secondo livello dello stack è paragonabile al livello data link della pila
ISO/OSI, si occupa cioè della parte di accesso al canale; questo layer può
essere suddiviso in due parti principali: la prima, definita user plane adibita
al trasporto delle informazioni, sia dati che voce, utilizzate dalle applicazioni
utente, la seconda, control plane a cui viene delegata la gestione del traffico
per la segnalazione. L’obbiettivo di questo livello di protocollo è quello di
gestire le connessione logiche delle comunicazioni fornendo un’interfaccia agli
strati superiori per un accesso semplificato al mezzo fisico.
• Codifica di canale e schemi di scrambling/de-scrambling interleaving/deinterleaving;
• Controllo di accesso al canale:
– sincronizzazione dei frame tenendo traccia del Frame Number e
dello Slot Number
– controllo di accesso al canale DM con rilevazione dello stato dello
stesso (libero occupato o riservato)
– rilevamento di collisione con i terminali slave durante gli stati del
canale riservati o occupati tramite un sistema di accesso casuale
– frammentazione di un SDU in più PDU e la successiva ricomposizione
– multiplexing dei canali logici all’interno di un burst di livello 2
33
– creazione e sincronizzazione della struttura multiframe. Ogni frame
viene numerato in modo ciclico ed ogni blocco di sincronizzazione
deve indicare i numeri di frame di time slot.
• Gestione della radio:
– gestione indirizzi per le chiamate
– controllo di potenza
– creazione del collegamento radio
– gestione di un buffer per il traffico dell’utente e di controllo fino a
quando non avviene l’effettiva trasmissione
– interfacciare le applicazioni a commutazione di circuito con lo
strato fisico
– scambiare le informazioni con lo strato superiore
• Crittografia: il DMO è in grado di garantire la sicurezza delle comunicazioni tramite un sistema di cifratura basato sull’utilizzo di chiavi
crittografiche statiche (SCKs) e l’uso di una sincronizzazione di un
parametro dipendente dal tempo (TVP) contro gli attacchi di replica
dei pacchetti cifrati.
In questo livello protocollare sono previste soltanto le funzionalità riferite
al control plane, quindi gestione del traffico e la segnalazione. La componente principale di questo layer è il Direct Mode Call Control (DMCC) che
implementa le seguenti funzionalità:
• Inizializzazione, mantenimento e rilascio dei servizi di base per le chiamate
34
• Indirizzamento delle chiamate (destinazione, repeater e gateway)
• Short Data Service (SDS): brevi messaggi di testo simili agli SMS del
GSM
• Supporto per servizi correlati alle chiamate: livello di priorità dell’utente, identificazione pre-emption e late entry.
Un altro aspetto che viene gestito dal control plane è la Security Management che si occupa di:
• Identity Management e le procedure di autenticazione, anche se nel
DMO non esistono vere e proprie procedure di autenticazione perché
l’autenticità del chiamante viene garantita dalla conoscenza di un segreto condiviso, cioè la chiave SCK usata per la cifratura della chiamata;
• Enable/Disable Mechanism: un terminale autorizzato può abilitare o
disabilitare l’accesso al canale radio di un secondo terminale.
Inoltre se un terminale deve poter comunicare anche con una rete Tetra
TMO tramite un DM-GATEway, dobbiamo aggiungere alle funzionalità di
questo layer anche la componente che implementa le procedure di registrazione verso la rete infrastrutturale, componente denominata Direct Mode
Mobility Management (DMMM).
2.1.2
Canale a trama temporale
Il sistema Tetra DMO utilizza due diversi metodi di suddivisione ed accesso
al canale, il primo metodo è un Time Division Multiplexing (TDM) come
anche il secondo, più nuovo, che però utilizza due frequenze portanti. Al fine
di garantire la massima compatibilità possibile, anche con terminali Tetra di
35
vecchia fattura, il progetto TWNET si appoggerà al primo metodo e quindi
verrà utilizzata solo una frequenza portante. Il canale non viene scelto automaticamente ma viene impostato sul terminale che si vuole utilizzare, una
volta attivo sulla frequenza questo verrà utilizzato per trasmettere tutte le
tipologie di dato: segnalazione, voce, messaggi e dati. Lo standard DMO
utilizza per ogni banda una struttura fissa di allocazione del canale suddivisa
in tre sotto trame:
1. la separazione più grande è organizzata in multi frame,
2. ciascuno dei quali e suddiviso in 18 frame,
3. ogni frame è ulteriormente suddiviso in 4 frame slot
2.1.3
Indirizzi ed identità
I terminali e i gruppi di device Tetra vengono identificati all’interno della rete
tramite indirizzi di diverso tipo. Tali indirizzi di suddividono in categorie
differenti in base alla lunghezza ed all’utilizzo:
MCC : Mobile Country Code di 10 bit identifica la nazione di appartenenza
dell’operatore Tetra
MNC : Mobile Network Code di 14 bit identifica l’operatore stesso
MNI : Mobile Network Identity di 24 bit è formato da MCC+MNC
SSI : Short Subscriber Identity di 24 bit identifica un terminale e deve
essere univoco all’interno di una sotto rete Tetra
TSI : Tetra Subscriber Identity di 48 bit è formato da MNI+SSI identificando univocamente il terminale
36
TEI : Tetra Equipment Identity si 15 bit
• Indirizzi di device Tetra tipo repeater e gateway sono di 10 bit
Gli indirizzi di gruppo hanno la stessa lunghezza e struttura di quelli individuali e vengono utilizzati nello stesso modo e negli stessi campi del protocollo durante le comunicazioni, per chiarire potremmo paragonare questo
tipo di indirizzamento a quello IP, in questo caso ci riferiremmo all’indirizzamento unicast nel caso di indirizzi di terminale o a quello multicast nel
caso di quelli di gruppo. Si distingue quindi l’ITSI ed il GTSI come indirizzi
individuali o di gruppo, e conseguentemente possiamo parlare dell’ISSI o nel
secondo caso del GSSI.
Ogni terminale Tetra ha assegnato un TSI individuale ed un numero
variabile di TSI di gruppo, l’insieme di questi indirizzi costituiscono la TSI
Family. Fra tutti i gruppi disponibili ve ne è uno che è associato a tutti i
terminali, chiamato open group; i device che trasmettono a questo gruppo
comunicano con tutte le stazioni presenti su quel canale. L’indirizzo di questo
gruppo è identificato dal SSI con i bit settati tutti a 1, se invece vogliamo
chiamare in broadcast tutte le stazioni anche all’esterno della sotto-rete Tetra
anche i bit del MNI devono essere settati a 1. Il sistema di indirizzamento
viene utilizzato sia dal livello 2 che dal livello 3, la destinazione può essere
sia un indirizzo Unicast che uno di gruppo, mentre quello di mittente può
essere solamente un indirizzo ISSI.
Un caso particolare sono gli indirizzi associati a differenti device Tetra:
repeater e gateway hanno degli address lunghi 10 bit che però non hanno il
vincolo dell’univocità all’interno di una rete Tetra ma solamente all’interno
della stessa isola DMO. Un terminale DMO riconosce la presenza di questi
device tramite la segnalazione periodica che questi trasmettono sul canale su
cui sono attivi. In questo caso tali indirizzi di 10 bit non vengono utilizzati
37
Tetra Subscriber Identity
(TSI) 48 bit
Mobile Network Identity
(MNI) 24 bit
Mobile Country Code
Mobile Network Code
(MCC) 10 bit
(MNC) 14 bit
Short Subscriber Identity
(SSI) 24 bit
Tabella 2.1: Struttura degli indirizzi Tetra
per destinare il traffico ma bensı̀ solo per indicare il tramite cui veicolare tali
dati, per fare un esempio possiamo paragonare tale sistema al funzionamento
nelle reti IP dei gateway e il differente uso di indirizzi IPv4 e ARP.
2.1.4
Scenari di servizio TETRA DMO
Il Tetra DMO è in grado di trasmettere due tipologie di informazioni: traffico
dati e traffico voce. Entrambe vengono fornite dei servizi di sicurezza tramite
cifratura del canale di trasmissione utilizzando i due principali sistemi previsti
dallo standard:
• AIE: Air Interface Encryption
• E2EE: End-to-End Encryption
La modalità DMO rappresenta una delle caratteristiche più importanti
del TETRA ed è anche l’oggetto del progetto TWNET, in questa modalità
sono previsti due tipi principali di servizi:
• bearer : questo tipo di servizio per l’invio di informazioni fra le interfacce
di rete interessa i livelli più bassi della pila protocollare, per esattezza
i 3 livelli inferiori. L’utente utilizza per accedere alle funzionalità del
38
device radio un protocollo di livello superiore il quale utilizza i servizi
bearer per trasmettere sulla rete le informazioni, sia dati che voce;
• teleservice: il servizio che fornisce la capacità di comunicazione fra
gli utenti tramite lo standard TETRA, si tratta dei servizi che vengono forniti all’utilizzatore tramite le varie applicazioni del device che
si appoggiano ai servizi bearer per il trasposto dei dati sulla rete.
Come accennato precedentemente, il progetto TWNET prevede l’utilizzo
del canale fisico con modalità normale quindi con la possibilità di attivare
una sola chiamata simplex su un canale e tale chiamata può essere stabilita
soltanto fra terminali operanti su quella frequenza. Andiamo quindi a analizzare i meccanismi di funzionamento dei vari servizi Tetra DMO che dovranno
essere supportati dalla rete TWNET.
Chiamata diretta senza presence check
In modalità normale ogni MS può operare su di un solo canale configurato
dall’utente, tale portante viene utilizzata per tutte le tipologia di trasferimento: dati, voce o segnalazione. Nel Tetra DMO il mezzo di comunicazione
viene suddiviso in una struttura fissa descritta nel capitolo 2.1.2 che prevede
4 time slot per frame e 18 frame costituiscono un hyperframe. Il canale può
risultare libero (quando cioè non viene rilevata alcuna attività), occupato,
riservato o in uno stato sconosciuto. Durante una chiamata vengono utilizzati gli slot 1 e 3 all’interno del frame. Quando una radio vuole effettuare
una chiamata su un canale libero, ne prenota l’utilizzo ed inizia la procedura
per attivare la chiamata voce: Il master trasmette i burst di sincronizzazione
(DSBs: Direct Mode Synchronization Bursts) nei frame numero 6, 12 e 18
mentre viene allocato il traffico (DNBs: Direct Mode Normal Bursts) nei
39
frame dal 1 al 17. Nella fase di prenotazione del canale il master usa i frame
per:
• indicare che il canale è riservato;
• indicare per quale gruppo o terminale è riservato;
• segnalare la durata della prenotazione.
L’occupazione del canale da parte del master risulta conclusa dopo il termine
della chiamata, dopo un changeover (procedura che cambia il ruolo del master
quindi il canale risulterà occupato da un altro terminale) o dopo che il timer
della prenotazione è scaduto. Quando un canale è occupato, vengono usati
per la chiamata i seguenti frame:
• il frame 18 è usato per la sincronizzazione con un DSB negli slot 1 e 3
• i frame 6 e 12 hanno un DSB nello slot 3 e possono trasportare traffico
con un DNB nello slot 1
• nei frame 6 e 12 vengono anche allocate anche informazioni sulla prenotazione del canale con un DSB negli slot 1 e 3
• la segnalazione di pre-emption si trova negli slot 3 dei frame 2, 5, 8, 11,
14 e 17
• durante una chiamata i frame dal 1 al 17 trasportano il traffico DNB
nello slot 1
Un terminale che vuole effettuare una chiamata, per prima cosa effettua
un monitoraggio sul canale per verificarne lo stato: nel caso la frequenza
sia libera, la radio diventa il master della chiamata e inizia a sincronizzare
40
Frame #
17
18
1
Slot #
1
2
3
4
1
2
3
4
1
Channel
su
su
su
su
su
su
su
su
tc
Frame #
5
Slot #
1
Channel
tc
2
2
p?
4
1
tc
2
4
1
2
occ
4
1
tc
2
4
p?
7
3
3
3
tc
6
3
2
3
1
2
tc
4
1
tc
2
4
ich
8
3
4
3
1
2
p?
4
1
tc
2
4
3
4
tc
9
3
3
10
3
4
1
2
tc
Tabella 2.2: Occupazione di frame e slot nella chiamata diretta senza presence
check
il canale inviando burst DSP (su nella tabella 2.2) che informano i terminali slave su quale numero di frame sta avvenendo la chiamata cosı̀ da poter
allineare le strutture multi frame. Successivamente nel primo frame libero
il master inizia a trasmettere il traffico (tc nella tabella 2.2). Nella trama
temporale vengono rilasciati alcuni slot liberi per eventuali richieste di preemption sul canale (p? nella tabella 2.2) e vengono trasmessi burst di sincronia sullo slot 3 dei frame 6, 12 e 18 per indicare che il canale è attualmente
occupato (occ nella tabella 2.2). Ogni scambio di dati in una comunicazione
in DMO consiste in una trasmissione indipendente con un master e vari slave
coinvolti.
In questo esempio, le opportunità di pre-emption sono nello slot 3 dei
frame 2, 5 e 8 del link slave. Una richiesta di questo tipo fatta nello slot
3 del frame 2 sul link slave sarebbe ritrasmessa 5 slot dopo nello slot 3 del
frame 4 del link master. La figura mostra inoltre la trasmissione del segnale
di presenza da parte del DM-REP nello slot 3 del frame 7 sul master link
(questo slot potrebbe venir utilizzato per la ritrasmissione di una richiesta di
pre-emption eventualmente ricevuta nello slot 3 del frame 5 del link slave).
La procedura per passare da una trasmissione della chiamata ad un’altra
prende il nome di Changeover. Per prima cosa il chiamante, che vuole rilas-
41
ciare il ruolo di master, invia una segnalazione “transmit ceased message”
nello stesso formato del traffico DNB nello slot 1 in almeno due frame consecutivi indicando cosı̀ che sta per concludere la comunicazione. Una radio
slave che vuole eleggersi nuovo master della nuova transazione di chiamata,
invia un “changeover request message” in uno slot 3 riservato. Nell’eventualità di collisioni di richieste di changeover o pre-emption, queste vengono
risolte tramite un meccanismo di ritrasmissione con intervallo casuale. Una
volta che una richiesta viene ricevuta con successo, il master rilascia il canale
tramite un “changeover acknowledgement” al termine del quale diviene a
tutti gli effetti uno slave per la successiva transazione.
In caso si utilizzi il protocollo MS-REP la procedura di call set-up senza
presence check è modificata come in figura 2.1
Figura 2.1: Struttura della trama temporale nel set-up di una chiamata senza
presence check tramite repeater
Dopo essersi assicurato che lo stato del canale è libero, il terminale DMMS può linearizzare il trasmettitore. Quindi stabilisce la sincronizzazione al
canale e il suo ruolo di master trasmettendo una sequenza di messaggi di call
set-up sul master link inviati su un numero appropriato di frame. I burst
di sincronizzazione contengono le informazioni sul conteggio del frame (in
42
figura 2.1 i 17 e 18 del master-link) e dello slot di appartenenza (in figura
2.1 da 1 a 4). Il terminale DM-MS master quindi si mette in ascolto dei
burst di sincronizzazione ritrasmessi dal DM-REP sul link slave a conferma
che la sua segnalazione è stata ricevuta e gestita con successo dal dispositivo.
Il DM-REP può variare il numero di frame ritrasmessi sul link slave, in
questo esempio invia i burst di sincronizzazione in 2 frame per un totale di
8 burst. Il terminale DM-MS master quindi trasmette il traffico (tc in figura
2.1) nel successivo frame disponibile che nell’esempio è il frame 3 del master
link. La figura illustra inoltre la posizione degli slot allocati alle richieste
di pre-emption (p? in figura 2.1 vedi anche capitolo 2.1.4), gli slot per la
linearizzazione (lch in figura 2.1) e i burst di sincronizzazione che indicano
l’occupazione del canale (occ in figura 2.1) inviati nello slot 3 dei frame 6 e
12, e negli slot 1 e 3 del frame 18.
Ai livelli più alti della pila, la chiamata inizia con l’invocazione della primitiva DMCC-SETUP request da parte dell’applicazione utente. Se il canale
risulta libero il Direct Mode Call Control (DMCC) inizia la procedura di
attivazione della chiamata creando ed inviando al livello MAC un messaggio
di DM-SETUP. Se i livelli inferiori riescono con successo a stabilire la chiamata questa informazione viene comunicata all’applicazione utente con un
messaggio di conferma e con l’avvio del timer DT311 (300ms) in modo che la
comunicazione non superi il tempo della prenotazione del canale. Nel caso le
procedure di attivazione della chiamata non vadano a buon fine per la presenza di una chiamata già attiva sul canale, la procedura può essere interrotta
tramite l’invio di un messaggio di DMCC-RELEASE o può essere invocata
la procedura per il pre-emption. Nel caso in cui il canale risulti libero, il
DMCC degli altri terminali viene allertato della presenza di una chiamata
entrante con la ricezione del DM-SETUP PDU, questi reagisce inviando al-
43
l’applicazione utente una segnalazione tramite il messaggio DMCC-SETUP
e si mette in attesa di una risposta. Se l’applicazione è in grado di ricevere
la chiamata invia come replica un messaggio di DMCC-SETUP response, il
quale configura il livello MAC per la ricezione del traffico e quindi assume il
ruolo di slave. In caso contrario l’applicazione segnala la sua impossibilità di
ricevere la chiamata inviando un DMCC-RELEASE request, in questo caso
il DMCC configura lo stato del MAC come idle ed abbandona la procedura
di set-up.
Figura 2.2: Call setup senza presence check
In presenza di un DM-REP intermedio la messaggistica scambiata a livello di processi è analoga; il DM-REP si limita infatti a re-inoltrare quanto
ricevuto seguendo lo schema aria visto in precedenza.
44
Frame #
16
2
17
3
4
1
2
18
3
4
1
2
1
Slot #
1
3
Master
sup sup sup sup sup sup sup sup sup sup sup
4
1
2
lch
4
Slot #
1
Master
tc
2
5
3
4
1
tc
2
cn
6
3
p?
4
1
tc
2
4
1
2
cn
4
1
2
3
4
occ
1
2
tc
cnk
8
3
4
1
tc
4
cn
7
3
3
3
cnk
Slave
Frame #
2
3
2
9
3
p?
4
1
2
3
4
tc
Slave
Tabella 2.3: Occupazione di frame e slot nella chiamata con presence check
Chiamata individuale con presence check
Le chiamate di gruppo possono essere stabilite soltanto tramite la modalità
descritta precedentemente mentre, per le chiamate dirette ad un destinatario
singolo, esiste la possibilità di attivare la comunicazione voce solo con terminali che riscontrino la propria presenza.
La procedura per stabilire una chiamata con il presence check è simile
a quella senza il riscontro ma successivamente al burst di frame dedicati al
set-up della chiamata (sup in figura 2.3) il master attende una risposta da
parte del destinatario per poter trasmettere i primi dati di traffico. Il destinatario della chiamata, che assumerà inizialmente il ruolo di slave, risponde
trasmettendo un messaggio di connect (cn in figura 2.3) su più frame per segnalare la propria presenza sul canale di trasmissione. Dopo la segnalazione il
master risponde inviando un messaggio di ack (cnk in figura 2.3) per convalidare la creazione effettiva della connessione fra i due terminali. L’opzione
del presence check a fronte di un ritardo nei tempi di setup della chiamata permette di ottimizzare l’utilizzo del canale e il risparmio energetico dei
terminali impedendo di iniziare chiamate senza la presenza del destinatario.
Analizziamo adesso il comportamento della procedura in caso di presenza
di un repeater considerando la trama in aria.
45
Figura 2.3: Struttura della trama temporale nel set-up di una chiamata con
presence check tramite repeater
La procedura inizia in maniera simile al caso di set-up senza presence
check, ma il messaggio di set-up nel burst di sincronizzazione (sup in figura
2.3, con 7 inviati in questo esempio) ora richiede una risposta indicante la
presenza della DM-MS che è destinatario della chiamata. Lo slave per la
comunicazione risponde sul link slave con il messaggio connect (cn in figura
2.3) che indica la sua disponibilità a ricevere la trasmissione. In questo esempio, lo slave linearizza il trasmettitore nello slot 1 del frame 2 del link slave,
inviando un messaggio di connect nello slot 3 di questo frame e ripetendo
poi il messaggio di connect nel frame seguente. Tale messaggio è ritrasmesso dal DM-REP alla master DM-MS nel frame apposito sul link master (in
questo caso i frame 4 e 5). Al ricevimento del connect il master risponde con
un messaggio di riscontro della connessione (cnk in figura 2.3) inviandolo in
almeno un frame e quindi inizia la trasmissione del traffico nel frame 7 del
link master.
La procedura di call set-up con presence check al livello superiore viene
avviata se il DMCC-SETUP request indica che è richiesto il controllo di
presenza. Il DMCC converte la richiesta di set-up in un messaggio DM-
46
SETUP PRES PDU, lo invia ed entra nello stato CALL SETUP PRESCHECK ORIGINATING. Dopo la trasmissione aspetta un DMAREPORT
indication dal livello 2 che lo informa del progresso della procedura. Se il DMSETUP PRES PDU è stato trasmesso correttamente il DMCC avvia il timer
DT303 (250ms) ed aspetta una risposta. Se infine riceve una DM-CONNECT
PDU, accetta la richiesta di servizio e:
• invia come risposta un DM-CONNECT ACK PDU;
• entra nello stato CALL ACTIVE TX OCCUPATION;
• invia all’applicazione utente DMCC-SETUP confirm;
• crea un DMC-CONFIGURE request;
• interrompe il timer DT303 (250ms);
• avvia il DT311 (300ms).
Quando invece si riceve un DM-DISCONNECT PDU viene inviato un DMRELEASE PDU e si ritorna in uno stato IDLE. Anche nel caso che termini il timer DT303 il DMCC invia un DM-RELEASE PDU; successivamente potrà inviare di nuovo un DM-SETUP PRES PDU oppure notificare
all’applicazione utente un DMCC-RELEASE indication.
La notifica di una chiamata in entrata ad un DMCC sarà fatta dalla
ricezione di un DM-SETUP PRES PDU. Se l’applicazione utente non può
ricevere la chiamata sarà immediatamente inviato un DMCC-RELEASE request: il DMCC invierà un DM-DISCONNECT PDU indicando la causa del
rifiuto e ritornerà nello stato IDLE. Altrimenti se il DMCC desidera ricevere
la chiamata:
• risponderà con un DMCC-SETUP response;
47
• invia un DM-CONNECT PDU contenente le informazioni del servizio
offerto;
• avvia il timer DT307 (350ms)
e aspetta la risposta dal DM-MS chiamante.
Se entro il tempo fissato
dal timer riceve un DM-CONNECT ACK PDU allora notifica un DMCCCOMPLETE indication ed entra nel nuovo stato CALL ACTIVE RX OCCUPATION. Altrimenti il timer DT307 termina, il DMCC notifica un DMCCRELEASE indication e ritorna allo stato IDLE.
Figura 2.4: Call setup con presence check
Anche in questo caso, in presenza di repeater, la procedura è sostanzialmente identica; si noti però che i timer hanno un valore (consigliato) maggiore: 550 ms per il DT303 e 450 ms per il DT 307.
48
Chiamata tramite DM-GATEway
Nel caso sia presente un DM-GATE la procedura di set-up si differenzia
nel caso di chiamata individuale o di gruppo e se generata lato TMO o
DMO. Se generata dal lato TMO è con presence check, se individuale, e senza
presence check, se di gruppo; non considereremo in seguito tali procedure
poiché non coinvolte nel progetto oggetto di questa tesi. Ci soffermeremo
invece sulle procedure di set-up di chiamata sia di gruppo che individuale
generate lato DMO: in tal caso le chiamate sono senza presence check anche
se una procedura implicita fra DM-MS e DM-GATE è presente come sarà
più chiaro in seguito.
Chiamata di gruppo da DM-MS attraverso il DM-GATE Il diagramma temporale in figura 2.5 mostra la call set-up da un DM-MS attraverso
il DM-GATE. Il disallineamento iniziale tra lo slot 1 della trama DMO e lo
slot 1 del down link TMO è supposto essere di 3 slot.
Dopo aver seguito le procedure per la verifica dello stato del canale, e
supposto che sia stato trovato libero, il terminale DM-MS chiamante può linearizzare il trasmettitore. Fatto ciò, invia il messaggio di richiesta di set-up
gsu sul canale DMO indirizzandolo al gateway. In questo esempio il gateway
invia il messaggio USETUP usu sull’uplink TMO, 3 slot dopo aver decodificato con successo il primo burst di set-up dalla DM-MS. E’ una scelta del
gateway se inviare o no delle DM-GACK intermedie alla DM-MS chiamante
durante la gestione del set-up di chiamata lato TMO (usu + dscn).
La SwMI ha immediatamente risorse disponibili e risponde inviando la
D-SETUP e la D-CONNECT ai membri del gruppo TMO e al gateway,
rispettivamente, nello stesso slot (dscn). Al tempo stesso richiede anche un
riscontro di livello 2 (l2a) dal gateway in un sub slot riservato sul canale di
49
Figura 2.5: Struttura temporale set-up chiamata di gruppo tramite DM-GATEway
traffico allocato (slot 3). Se la SwMI risponde velocemente non c’è necessità
di un riscontro intermedio alla DM-MS e quindi il gateway può rispondere
alla DM-MS chiamante con il messaggio DM-GCONNECT. Il messaggio è
anche usato per riallineare lo slot e la numerazione dei frame sul canale
DMO. Nel frattempo, in assenza di traffico reale, il gateway genera PDU
nulle nell’uplink TMO. La DM-MS, dopo aver ricevuto il DM-GCONNECT
dal gateway, assume il ruolo di master, applica la nuova temporizzazione
stabilita dal gateway e genera i messaggi di DM-SETUP sul canale DMO
per avvertire i membri del gruppo chiamato; infine procede ad inviare il suo
traffico che è trasmesso dal gateway sul canale TM uplink 3 slot dopo e dalla
SwMI sul canale TM downlink dopo altri 2 slot. La figura 2.5 illustra, lato
DMO, la posizione degli slot allocati alle richieste di pre-emption (p? in
figura 2.5) ed ai burst di sincronizzazione che denotano l’occupazione del
canale (occ in figura 2.5) che sono gli slot 3 del frame 6 e 12 e gli slot 1
50
e 3 del frame 18. E’ mostrato anche, nello slot 3 del frame 1 sul canale
DMO, il segnale di presenza che viene trasmesso dal gateway nello slot 3
dei frame 1, 7 e 13 durante l’occupazione da parte di una DM-MS come
master. In generale, una chiamata di gruppo iniziata da una DM-MS verso
membri presenti sia sul canale DMO che nel sistema TMO deve tenere conto
del tempo di risposta del sistema TMO, poiché può impiegare anche molto
tempo per rispondere ad un set-up di chiamata: lato DMO il DM-GATE deve
mantenere aperta la procedura di set-up mediante l’invio delle DM-GACK
e abilitare la conclusione del set-up stesso (invio su) solo quando l’apertura
della chiamata lato TMO gli viene confermata. La figura 2.6 mostra le PDU
inviate in aria lato DMO e TMO durante un set-up di chiamata via DMGATE.
Figura 2.6: Sequenza degli scambi di PDU nel set-up della chiamata
51
L’approccio di base della sequenza dei messaggi per una richiesta di chiamata (individuale o di gruppo) originata da una DM-MS prevede la richiesta
iniziale, un riscontro intermedio opzionale ed un riscontro positivo o negativo
finale. Durante la call set-up il gateway è il master del canale, la DM-MS
chiamante inizia la procedura con il messaggio DM-GSETUP che è inviato
sul canale DMO verso il gateway. Questo inoltra una U-SETUP al SwMI
e aspetta per un D-CONNECT in risposta che contiene l’allocazione del
canale, in attesa del messaggio può essere inviato un riscontro alla DM-MS
chiamante (DM-GACK) per prevenire il ripetersi delle richieste di call set-up
e quindi la generazione della segnalazione di prenotazione. Alla ricezione del
D-CONNECT il gateway invia un DM-GCONNECT alla DM-MS chiamante
che quindi assume il ruolo di master e inizia la chiamata seguita dal traffico.
I messaggi di DM-SETUP e il traffico sono ricevuti sia dal gateway che dai
membri DMO del gruppo.
Chiamata individuale da DM-MS attraverso il DM-GATE Il diagramma temporale in figura 2.7 mostra la segnalazione per il set-up di una
chiamata individuale da una DM-MS ad una MS nel sistema TMO.
Il processo inizia quando la DM-MS invia la richiesta di chiamata DMGSETUP (gsu in figura 2.8) dopo aver determinato la numerazione di frame
e di slot sul link stabilito dal segnale di presenza del gateway. La richiesta di
set-up viene inoltrata alla SwMI che a sua volta contatta la TM-MS (è una
scelta del gateway se, durante la procedura, inviare un riscontro intermedio
alla DM-MS chiamante prima di inviare la call set-up alla SwMI). In questo
esempio, la richiesta è inviata al sistema TMO (usu) prima che il riscontro
intermedio del gateway (gak ) sia inviato alla DM-MS. Alla ricezione di un
U-CONNECT dalla TM-MS contattata, la SwMI invia un D-CONNECT e
52
Figura 2.7: Diagramma temporale della segnalazione di set-up di chiamata con
DM-GATE
53
un D-CONNECT ACKNOWLEDGE (dcnk in figura 2.8) al gateway ed alla TM-MS rispettivamente inviando cosı̀ l’allocazione di canale nello slot 3
della stessa portante (in questo esempio). Il gateway quindi invia il riscontro finale, DM-GCONNECT (gcn), alla DM-MS chiamante ridefinendo la
numerazione di slot se necessario per l’allineamento con il canale TM. In
questo caso, il messaggio ritarda la numerazione di slot di due, mantenendo
la differenza di tre slot fra canali DM e TM. Il gateway invia anche PDU
nulle alla SwMI finché la DM-MS chiamante non è pronta ad inviare traffico.
Dopo la ricezione del riscontro finale, il terminale chiamante diventa master
del canale DM, e quindi segue lo standard DM per le procedure di call set-up
inviando i messaggi di DM-SETUP seguiti dal traffico.
Figura 2.8: Struttura temporale set-up chiamata di gruppo tramite DM-GATEway
54
Chiamata di emergenza
L’interfaccia aria DM supporta le chiamate di emergenza: un terminale DMMS che inizia una chiamata di emergenza può usare un canale DM e, se
necessario, fare la pre-emption di qualunque comunicazione a più bassa priorità eventualmente presente sul canale. Il servizio DMO permette ad una
comunicazione DM di essere inibita per supportare il servizio di chiamate di
emergenza.
Pre-emption
Durante una chiamata DM un terminale DM-MS, che può o non può essere
implicato nella chiamata corrente, potrebbe voler accedere al canale per una
ragione di priorità come una chiamata di emergenza. In questo caso esiste un
meccanismo di pre-emption del canale già occupato come illustrato in figura
2.9.
Figura 2.9: Occupazione slot durante una chiamata in DMO
La prima sequenza master mostra il normale progresso di una chiamata
con burst di traffico nello slot 1. Un terminale DM-MS che vuole usare il
canale deve, se non partecipante alla chiamata, aver prima determinato il suo
stato scoprendo cosı̀ la chiamata in corso. Successivamente deve sincronizzarsi con il terminale DM-MS master e determinarne poi lo stato temporale,
incluso i numeri di frame e di slot. Quindi per eseguire la pre-emption, il ter-
55
minale DM-MS trasmette un messaggio di richiesta (prq in figura 2.9) in uno
degli slot allocati per questo scopo (durante l’occupazione, la pre-emption è
permessa nello slot 3 dei frame 2, 5, 8, 11, 14, e 17). Quando il master decodifica con successo la richiesta, assunto che sia una richiesta valida, annuncia
la sua accettazione e la conseguente chiusura della chiamata in corso sia al
terminale DM-MS che ne ha fatto richiesta sia agli altri terminali coinvolti
nella chiamata. Questo annuncio è fatto per mezzo del messaggio di riscontro specifico della procedura (par e pa in figura 2.9), successivamente al suo
invio il master cede il proprio ruolo e rilascia il canale. Il terminale che ha
richiesto la pre-emption con successo trasmette i messaggi di set-up per la
nuova chiamata, con un nuovo indirizzo di gruppo o individuale, e ne diventa
il master.
In figura 2.10 è illustrata tale procedura in presenza di DM-REP.
Figura 2.10: Occupazione trama temporale durante pre-emption con la presenza
di DM-Repeater
La prima sequenza master mostra il normale progresso di una chiamata
attraverso un DM-REP con burst di traffic nello slot 1 di ogni frame (dal
1 al 17) sul link master ritrasmessi poi dal DM-REP sul link slave. Una
56
DM-MS che vuole usare il canale deve, se non partecipante alla chiamata,
per prima cosa determinare lo stato del canale e in questo caso identificare
che è presente una chiamata in corso attraverso un DM-REP. La DM-MS che
fa pre-emption si deve quindi sincronizzare con la trasmissione del DM-REP
sul link slave e determinare lo stato temporale del canale, incluso il numero
di frame e di slot del link slave. Per effettuare la pre-emption, la DM-MS
trasmette un messaggio di richiesta (prq in figura 2.10) in una posizione
appropriata della struttura a frame nel link slave (durante l’occupazione, la
procedura è permessa solo nello slot 3 nei frame 2, 5, 8, 11, 14 e 17). Quando
la stazione master decodifica con successo la richiesta di pre-emption ripetuta
dal DM-REP sul link master, assumendo sia una richiesta valida, informa che
il canale è stato prenotato sia alla DM-MS che esegue la richiesta che alle
altre DM-MS, che erano parte della chiamata in corso. Questa informazione
è inviata attraverso il messaggio di riscontro (par e pa in figura 2.10) inviati
sul link master e quindi ripetuti sul link slave, una volta inviati i messaggi
di riscontro il master cessa il suo ruolo e rilascia il canale. La DM-MS che
ha avviato la procedura con successo trasmette i messaggi di set-up al DMREP usando il link master per la nuova chiamata, con un nuovo indirizzo
di gruppo o individuale, e diventa master per la sua transazione iniziale. In
questo esempio la trasmissione del traffico inizia allo slot 1 del frame 15 del
link master. Si noti che in questo esempio la DM-MS che fa pre-emption
non include un aggiustamento temporale all’interno della richiesta e quindi,
nella nuova set-up, mantiene lo stesso riferimento temporale e numerazione
dei frame usati dalla vecchia DM-MS master.
Durante la chiamata attraverso un gateway una DM-MS, indipendentemente dal fatto che stia o no partecipando alla chiamata in corso, può voler
accedere al canale DMO per ragioni di priorità come un’emergenza. Anche
57
in questo caso esiste un meccanismo di pre-emption per il canale attualmente
occupato. E’ illustrato in figura mostrando il caso in cui una TM-MS stia
trasmettendo attraverso il gateway e una DM-MS debba fare pre-emption.
Analizzando il comportamento in aria, per effettuare la pre-emption la
DM-MS invia un messaggio di richiesta (gprq in figura 2.11) in una posizione
apposita della struttura a frame DM (durante l’occupazione la procedura è
permessa solo nello slot 3 dei frame 2, 5, 8, 11, 14 e 17). Al ricevimento della richiesta il gateway invia il messaggio U-TX DEMAND alla SwMI nello
slot 3 del frame 7 sul TM uplink, questo è il primo frame possibile poiché
lo slot 3 del frame 6 non avrebbe avuto un tempo sufficiente per decodificare la richiesta di pre-emption ricevuta nello slot precedente. In questo
esempio la SwMI ordina alla TM-MS trasmittente di fermare la trasmissione
e contemporaneamente assegna il permesso di trasmettere al gateway (dtgi
in figura 2.11), chiedendo un riscontro di livello 2 da ambedue le parti. Il
gateway quindi informa la DM-MS che fa pre-emption di questo usando il
messaggio DM-GPRE ACCEPT che viene inviato negli slot di traffico (slot
1) dei frame 8 e 9 sul canale DM insieme con il messaggio DM-TX CEASED
(gpac). Il messaggio DM-GPRE ACCEPT è ripetuto nello slot 3 di ambedue
i frame per incrementarne l’affidabilità (gpa). Alla ricezione di questi frame
di riscontro la DM-MS richiedente trasmette una sequenza di messaggi di
set-up come master (su in figura 2.11). Si noti che, dopo l’assegnazione della
trasmissione da parte della SwMI, il gateway invia PDU nulle fino a che non
viene ricevuto traffico dalla DM-MS.
Analizzando il diagramma temporale di scambio dei messaggi di livello
superiore, la pre-emption viene usata quando un terminale C vuole interrompere o subentrare ad una chiamata fra un terminale A e un terminale
B. La chiamata con pre-emption può essere fatta unicamente se la chiama-
58
Figura 2.11: Occupazione trama temporale durante la richiesta di pre-emption con
DM-GATEway
59
ta in corso è ad una priorità minore o non ha la priorità settata. Nel caso
in cui la pre-emption sia valida, il DMCC invia un DM-PREEMPT alla
stazione master ed entra nello stato PRE-EMPTION attendendo la risposta. Se riceve un DM-PRES ACCEPT PDU, il terminale C procede con una
call setup in maniera analoga a quanto visto precedentemente. Se invece
riceve un DM-REJECT PDU il DMCC informa l’applicazione utente con un
DMCC-RELEASE indication e ritorna allo stato IDLE.
Figura 2.12: Scambio di messaggi durante la pre-emption al livello DMCC
In presenza di un repeater la sequenza temporale di scambio dei messaggi sostanzialmente non varia, limitandosi il repeater a re-inoltrare in aria i
messaggi ricevuti.
In presenza di gateway una DM-MS può sempre fare pre-emption ad
un’altra DM-MS. Si noti comunque che, tranne il caso in cui un’altra DMMS stia parlando, in presenza di gateway quest’ultimo è sempre il master.
In questo caso, infatti, la DM-MS dovrà inviare una PDU particolare, la
60
DM-GPREEMPT PDU. Il gateway risponde la DM-GACK PDU indicando
che la richiesta è stata ricevuta e quindi la DM-MS si mette in attesa per
DT308 (30 s). Entro tale tempo deve ricevere una DM-GPRE ACCEPT
PDU o una DM-GREJECT PDU che indicano l’accettazione o meno della
richiesta. Diverso il caso in cui sia il gateway a fare pre-emption: in questo
caso la DM-MS master deve sempre rispettare la richiesta di pre-emption del
gateway indipendentemente dalla sua priorità.
Figura 2.13: Scambio di messaggi durante la pre-emption al livello DMCC in
presenza di DM-GATEway
In questo esempio una TM-MS sta inviando traffico che è poi trasmesso dal gateway sul canale DM, il quale agisce come master. Per fare la
pre-emption, la DM-MS invia un messaggio DM-GPREEMPT. Quando il
61
gateway decodifica con successo la richiesta, assumendo sia una richiesta
valida, invia una richiesta di trasmissione alla SwMI usando un’U-TX DEMAND PDU con la priorità fissata in modo appropriato. E’ una scelta
del gateway se riscontrate il ricevimento della richiesta di pre-emption usando un messaggio intermedio di riscontro (DM-GACK) prima di inviare la
U-TX DEMAND alla SwMI. La SwMI ordina alla TM-MS trasmittente di
fermarsi usando il messaggio D-TX INTERRUPT e, in questo esempio, contemporaneamente assegna il permesso di trasmettere al gateway usando il
messaggio D-TX GRANTED. Alla ricezione di questo messaggio il gateway
consegna il canale alla DM-MS usando il messaggio DM-GPRE ACCEPT e
inviando anche il messaggio DM-TX CEASED. La DM-MS richiedente quindi invia un DM-SETUP come master seguito dal traffico. In figura 2.13 è
illustrata la temporizzazione della procedura di pre-emption.
Changeover
Una chiamata DM è costituita da una o più call transaction ognuna delle quali
avente un suo master (che può anche rimanere lo stesso) e uno o più slave.
La procedura che consente di effettuare un cambio di ruoli, che permette
cioè ad uno slave di diventare il nuovo master, è denominata changeover ed
è illustrata in figura 2.14.
Figura 2.14: Occupazione trama temporale durante una richiesta di changeover
62
Giunti al termine del periodo di trasmissione del traffico voce, il master
DM-MS indica che la sua call transaction è arrivata alla fine, inviando un
messaggio di cessazione della fase di trasmissione (txc in figura 2.14). Questo
messaggio è inviato almeno due volte nello slot 1 in frame consecutivi e usando lo stesso formato di burst del traffico normale. I riceventi della chiamata
sono quindi a conoscenza della terminazione della chiamata e che il master
DM-MS sta riservando il canale DM per la stessa chiamata per un certo
periodo di tempo. Durante questo periodo, uno qualunque degli slave della
chiamata può richiedere di diventare il nuovo master mediante l’invio del
messaggio di richiesta di changeover (txr in figura 2.14) che è inviato in uno
degli slot 3 allocati dal protocollo a questo tipo di richieste. Le collisioni fra
messaggi di richiesta di changeover e di pre-emption può talvolta avvenire,
ma il protocollo è progettato per controllare tale contesa con un meccanismo
di ritrasmissione con accesso casuale. Alla ricezione di una richiesta valida
di changeover, il master rilascia il canale al richiedente usando una serie di
messaggi di riscontro di changeover (txa in figura 2.14). Al termine della
trasmissione dei messaggi di riscontro, il richiedente trasmette una sequenza
di messaggi di set-up in burst di sincronizzazione (su in figura 2.14), il cui
effetto è di far diventare il terminale il nuovo master della chiamata e dare
inizio ad una nuova call transaction. La figura 2.14 si applica sia a chiamate
di gruppo che a quelle individuali ma, nelle chiamate di gruppo, ci potrebbe
essere una collisione fra più terminali DM-MS che richiedono contemporaneamente di effettuare questo procedimento. In questo caso una procedura di
riprova casuale del controllo a contesa è effettuata come illustrato nella figura
2.15.
In questo esempio due slave DM-MS trasmettono una richiesta di changeover
contemporaneamente. Queste richieste possono interferire e produrre un
63
Figura 2.15: Occupazione trama temporale durante una richiesta di changeover in
chiamate di gruppo
risultato illeggibile. Il master pertanto non riceve nessuna richiesta chiara
e mantiene il canale nella modalità riservata, trasmettendo il segnale apposito (rsv in figura 2.15), fino a che un’altra richiesta di changeover viene
ricevuta con successo o il timer di prenotazione scade e il canale è rilasciato totalmente. Nell’esempio lo slave 1 trasmette una seconda richiesta di
changeover, che in questo caso ha successo e diventa quindi il nuovo master.
Analizziamo adesso il caso in cui sia presente un terminale DM-REP. In
figura 2.16 è illustrata la procedura di changeover in questo caso.
presenza di DM-REPeater
64
Per cambiare il mittente di una chiamata, il master indica prima che la
sua chiamata è terminata, usando un messaggio di cessazione chiamata (txc
in figura 2.16). Questo messaggio è inviato almeno due volte nello slot 1 di
frame consecutivi sul link master e usando lo stesso formato dei burst del
traffico normale, questi messaggi vengono quindi ritrasmessi dal DM-REP
sul link slave (tcx’ ). I destinatari della chiamata che sono in ascolto sul link
slave sono quindi a conoscenza del termine della chiamata e possono quindi
richiedere al master, attraverso il DM-REP di continuare con una nuova
chiamata. Il messaggio di richiesta di changeover (txr in figura 2.16) in questo
esempio è inviato dalla DM-MS richiedente nel prossimo slot 3 disponibile sul
link slave seguente la ricezione del txc’. Questa richiesta viene ritrasmessa
dal DM-REP nel frame appropriato sul link master. Alla ricezione di una
richiesta di changeover valida (txr’ ), il master consegna il canale al richiedente
usando una serie di messaggi di riscontro (txa in figura 2.16), trasmessi i
riscontro sul link master, il master diventa slave e non ha più responsabilità
sul canale. Alla ricezione del messaggio di riscontro di changeover ripetuto
(txa’ ), il richiedente trasmette una sequenza di messaggi di set-up nei burst
di sincronizzazione (su in figura 2.16) sul link master usando in questo caso la
stessa temporizzazione di frame e di slot del precedente master. L’azione di
inviare la sequenza di set-up mette in atto il changeover con il richiedente che
diventa il nuovo master della prossima chiamata. La numerazione di frame
in figura 2.16 è stata scelta arbitrariamente come esempio ma, in questa
figura, il primo burst di traffico nel nuovo master deve essere nel frame 5
(non mostrato in figura 2.16) sul link master. Si noti che la procedura di
changeover quando operante con un DM-REP impiega più tempo che nel
caso di link diretto MS-MS.
Consideriamo adesso la procedura in presenza di gateway. In figura 2.17
65
è illustrata la temporizzazione del processo di changeover. La TM-MS indica
che la sua chiamata è arrivata a fine, usando il messaggio U-TX CEASED
(utxc in figura 2.17). La SwMI informa il gateway e riscontra la TM-MS
usando i messaggi D-TX CEASED e richiede un riscontro di livello 2 ad
ambedue, il gateway a turno informa la DM-MS usando il messaggio DMTX CEASED (txc in figura 2.17). Il messaggio di richiesta di changeover
(gtxr in figura 2.17) in questo esempio è inviato da un terminale richiedente
nel prossimo slot 3 disponibile sul canale DM seguente la ricezione del txc,
assumendo che il gateway renda lo slot 3 del frame 7 disponibile per l’accesso
random del DM-TX CEASED.
Il gateway quindi effettua la richiesta di trasmissione alla SwMI (utxd )
prima di aver riscontrato la ricezione del messaggio di richiesta di changeover
sul canale DM (gak in figura 2.17). Successivamente la SwMI dà il permesso
di trasmettere e ricevere al gateway e alla TM-MS rispettivamente usando i
messaggi D-TX GRANTED e chiedendo un riscontro di livello 2 ad ambedue.
Alla ricezione di questo permesso dalla SwMI, il gateway quindi rilascia il
canale alla DM-MS usando una serie di messaggi finali di riscontro (gtxa in
figura 2.17), alla ricezione dei messaggi di riscontro, la DM-MS richiedente
trasmette una sequenza di messaggi di set-up come master. Si noti che dopo
la trasmissione concessa dalla SwMI, il gateway invia PDU nulle fino a che
non riceve traffico dalla DM-MS.
Analizziamo adesso la procedura dallo scambio di messaggi a livello più
alto. Quando un terminale DM-MS ha finito una comunicazione invia una
DM-TX CEASED PDU in broadcast per avvertire della fine della comunicazione. Tale PDU viene ricevuta dagli altri terminali DM-MS coinvolti
nella chiamata. Un altro terminale DM-MS, che si suppone voglia richiedere
il changeover, una volta ricevuta la PDU, invia una DM-TX REQUEST al-
66
presenza di DM-GATEway
l’attuale master che, nel caso in cui il primo terminale accetti la richiesta
di changeover, invierà un DM-TX ACCEPT verso lo slave. La procedura
continua quindi con la procedura di call set-up discussa precedentemente.
In presenza di un DM-REP la procedura rimane sostanzialmente analoga.
Nel caso di gateway, per la procedura di changeover sono necessarie le
seguenti precisazioni. Innanzitutto c’è da dire che a termine di una chiamata
il gateway assume sempre il ruolo di master, pertanto non sarà possibile
avere una DM-MS master. Analizziamo adesso il caso di una procedura di
changeover richiesta da un DM-MS slave in presenza di gateway. Questi deve
inviare una DM-GTX REQUEST PDU diretta al gateway che risponderà con
una DM-GACK PDU, a questo punto la DM-MS setterà il timer DT309 (10
s) entro il quale deve ricevere una DM-GTX ACCEPT PDU o una DMGREJECT PDU. Nel caso in cui il change-over venga accettato il terminale
Figura 2.18: Scambio di messaggi durante changeover al livello DMCC
67
68
potrà inviare una DM-SETUP PDU come master. In presenza di gateway, in
una chiamata DM, ognuna costituisce una chiamata separata, con un certo
master e uno o più slave, analogamente, in TMO, ogni chiamata comprende
trasmissioni separate.
Figura 2.19: Scambio di messaggi durante changeover al livello DMCC in presenza
di DM-GATEway
In questo esempio, il traffico è inviato come una chiamata individuale di
una MS nel sistema TMO. Per fare il changeover il chiamante prima indica
69
che la sua chiamata è terminata, usando un messaggio U-TX CEASED, la
SwMI informa il gateway usando in messaggio D-TX CEASED e successivamente il gateway a turno informa la DM-MS usando il messaggio DM-TX
CEASED. In questo esempio la DM-MS vuole trasmettere e richiede il permesso dal gateway inviando il messaggio DM-GTX REQUEST, la ricezione di
questo messaggio di richiesta di changeover può opzionalmente essere riscontrato dal gateway con il messaggio DM-GACK. Il gateway inoltra la richiesta
alla SwMI usando il messaggio U-TX DEMAND, La SwMI quindi dà il permesso di trasmettere al gateway e riceve allo stesso tempo il permesso dalla
TM-MS usando i messaggi D-TX GRANTED. Alla ricezione di questo permesso dalla SwMI, il gateway come master rilascia il canale alla DM-MS
usando il messaggio DM-GTX ACCEPT, la DM-MS richiedente ora diventa
il master, inviando il messaggio DM-SETUP seguito dal traffico.
Servizi dati narrowband
Il TETRA DM SDS supporta sia servizi punto-punto che punto-multipunto.
L’SDS punto-punto offre l’opzione dei riscontri mentre il punto-multipunto
è solo senza riscontri. L’SDS è essenzialmente un servizio di messaggistica
ottimizzato al fine di garantire un servizio veloce per lo scambio di brevi
messaggi di testo o di un breve messaggio predefinito come un messaggio di
emergenza. Il messaggio è veicolato all’interno del canale di segnalazione e
può essere inviato o ricevuto in parallelo con una chiamata voce o dati in corso. L’SDS può essere anche utilizzato per applicazioni come la localizzazione
automatica dei veicoli (LIP) o per il supporto della sicurezza (OTAR). L’SDS in DM supporta l’invio di messaggi la cui lunghezza in bit non superi i
2047. I messaggi possono essere inviati su canale libero oppure tramite stealing (solo STATUS) o call transaction all’interno di una chiamata. Possono
70
essere inviati attraverso un DM-REP ed essere diretti verso o ricevuti dal
sistema V+D tramite un DM-GATE. Un messaggio breve punto-punto è inviato da una MS mittente ad una MS ricevente utilizzando la frequenza radio
portante DM selezionata. La MS destinataria è indirizzata attraverso il suo
ITSI usando lo schema di indirizzamento standard, la ricevente riscontra la
ricezione del messaggio, se è stato richiesto, e la MS mittente può riprovare
l’invio un certo numero di volte se il riscontro è atteso e non viene ricevuto.
Un messaggio breve punto-multipunto è inviato da una MS mittente a un
gruppo di una o più MS riceventi usando la frequenza radio portante DM
selezionata. Il gruppo è indirizzato attraverso il suo GTSI utilizzando lo
schema di indirizzamento standard. Non ci sarà riscontro dalle MS riceventi
in questo caso, ma la MS mittente potrà ritrasmettere il messaggio un certo
numero di volte per aumentare il livello di affidabilità dell’invio.
Una DM-MS che vuole inviare un messaggio breve senza riscontro segue
le procedure per accertarsi dello stato del canale, se il canale è nello stato free, la DM-MS può linearizzare il suo trasmettitore. Quindi stabilisce
la sincronizzazione con il canale e contemporaneamente si pone come master trasmettendo una sequenza di intestazioni DM-SDS UDATA usando la
struttura DSB (sdu in figura 2.20, dove sono 8 i messaggi inviati in questo esempio). Il messaggio intestazione DM-SDS UDATA contiene le informazioni
sul conteggio del frame che, in questo esempio, definisce la loro posizione nella struttura temporale nei frame 17 e 18 della struttura multi frame ciclica a
18 frame. La stazione master DM-MS trasmette quindi le parti rimanenti del
messaggio breve (sd in figura 2.20), senza la ripetizione e usando la struttura
DNB, nello slot 1 dei frame successivi. In questo esempio le parti rimanenti del messaggio occupano tre slot e sono inviate nei frame da 1 a 3. Per
affidabilità, la stazione DM-MS può ripetere l’invio del messaggio completo
71
immediatamente, senza ricontrollare che il canale sia libero, e iniziando di
nuovo con le DSB. In esempio c’è la ripetizione completa di un messaggio,
con le DSB inviate nei frame 4 e 5, e le tre DNB inviate nei frame 6 e 8.
La figura 2.20 illustra inoltre dove la segnalazione di pre-emption è permessa
durante la trasmissione di un SDS. Brevi DSB di occupazione sono inviati
nello slot 3 dei frame 6, 12 e 18 durante la trasmissione dei DNB.
Figura 2.20: Occupazione della trama per l’invio di un SDS
Si considera adesso il caso di un SDS inviato attraverso un DM-REP.
Una DM-MS che vuole inviare un SDS senza riscontro attraverso un DMREP segue le procedure per accertarsi dello stato del canale, a condizione
che il canale sia trovato libero la DM-MS può linearizzare il trasmettitore.
Quindi stabilisce la sincronizzazione con il canale e contemporaneamente il
suo ruolo a master inviando una sequenza di intestazioni DM-SDS UDATA
sul link master, in un appropriato numero di frame. Le intestazioni DMSDS UDATA contengono informazioni sul conteggio dei frame, che definisce
la loro posizione nella struttura temporale ciclica multi frame a 18 frame,
nell’esempio mostrato in figura 2.21, sono inviati 7 burst di sincronizzazione
(sdu in figura 2.21) contenenti informazioni sul conteggio di frame e definendo
la loro posizione nei frame 17 e 18.
Il master DM-MS quindi rimane in ascolto di DM-SDS UDATA ritrasmesso dal DM-REP sul link slave come conferma che la sua segnalazione al DMREP è avvenuta con successo. Il DM-REP può trasmettere in un numero
72
diverso di frame dal numero usato dal master DM-MS. Comunque, in questo
esempio, invia i burst di sincronizzazione in 2 frame per un totale di 8 burst.
Il master DM-MS quindi trasmette la parte rimanente dell’SDS (sd in figura
2.21), senza ripetizione nello slot 1 del seguente frame. In questo esempio le
parti rimanenti del messaggio occupano due slot e sono inviate nel frame 3 e
4. Per affidabilità, la master DM-MS può ripetere il messaggio completo immediatamente (senza verificare di nuovo che il canale sia libero), in esempio
c’è una ripetizione del messaggio, inviato nei frame 5 e 6. La figura 2.21 illustra anche dove il segnale di pre-emption è permesso durante la trasmissione
di un SDS.
Figura 2.21: Occupazione della trama per l’invio di un SDS in presenza di DMREPeater
Il protocollo per l’invio di DM SDS in presenza di un gateway è simile
a quello base, in presenza di sole DM-MS. Gli SDS possono essere inviati
in tutti i modi consentiti e le PDU sono le stesse. Esistono però alcune
differenze infatti gli SDS sono riscontrati solo a livello 2 sul sistema TMO.
Per coerenza quando una DM-MS invia un SDS attraverso un gateway usando
il servizio con riscontro, il riscontro è generato dal gateway come equivalente
del riscontro a livello 2 del TMO. I gateway quindi inoltrano gli SDS alla
73
SwMI usando le procedure appropriate definite per il caso base. Gli SDS
possono essere inviati anche da utenti TMO a una o più DM-MS attraverso
il gateway: questo riceve l’SDS dalla SwMI e genera un riscontro di livello 2
se richiesto, quindi inoltra l’SDS sul canale DM verso la o le DM-MS.
Analizziamo adesso la procedura di invio di SDS senza riscontro dal punto
di vista dello scambio di messaggi ad alto livello. Tale procedura può essere
avviata solo in caso di canale libero e prevede l’invio di un certo numero di
DM-SDS UDATA consecutivi. Poiché tale procedura è senza riscontro, maggiore è il numero di DM-SDS UDATA PDU che vengono inviate e maggiore
è l’affidabilità della procedura.
Figura 2.22: Scambio di messaggi a livello DMCC durante l’invio di SDS
Status messages Gli status messages sono inviati dai terminali al fine
di comunicare in automatico lo stato del nodo. Gli status messages sono
caratterizzati da:
• i dati sono inviati come valori numerici a 16 bit;
• 32768 valori sono liberi mentre il resto sono riservati al sistema;
• sono convertiti in testo al terminale e workstation ricevente;
74
• veloci ed efficienti;
• facili da usare.
Text messages I messaggi di testo sono invece messaggi inviati dagli
operatori che utilizzano i terminali. Sono caratterizzati da:
• ne esistono 4 tipi diversi: SDS-1, SDS-2, SDS-3 and SDS-4;
• SDS-1, -2 e -3 sono a lunghezza fissa (16, 32, 64 bits);
• SDS-4 è a lunghezza variabile (massimo 2047 bits). L’identificatore di
protocollo definisce come SDS-4 è usato; l’uso più comune e messaggio
di testo (140/160 caratteri) e Authomatic Vehicle Location;
• il testo è inserito attraverso la tastiera del telefono, dispositivo unico
per voce e dati.
Servizi dati a circuito Una connessione bearer è una comunicazione dati
punto-punto o punto-multipunto fra una MS chiamante e una o più MS chiamate. Può essere effettuata solo fra MS che hanno selezionato la stessa frequenza portante radio DM con modo di operazione simplex. TETRA DMO
offre tre tipi di connessioni dati a circuito dipendentemente dal fatto che i
dati siano meno protetti, dal livello di protezione desiderato. La differenza
fra servizi bearer protetti e non protetti è che il servizio bearer protetto fornisce la protezione di errore come definito nella clause 8 di [8]. Il risultato
è un canale più affidabile e robusto a spesa di una riduzione del data rate
effettivo di utente.
75
Servizi a circuito non protetti I servizi a circuito non protetti supportano connessioni punto-punto (chiamate individuali) e punto-multipunto
(chiamate di gruppo). Il throughput dati all’interfaccia utente è 7,2 kbit/s.
Servizi a circuito protetti I servizi a circuito protetti supportano
connessioni punto-punto e punto-multi punto. Sono definiti sei tipi di servizi
protetti in TETRA DMO offrendo due livelli differenti di protezione contro
gli errori usando una protezione di tipo forward nello stream di dati trasmessi.
La protezione agli errori è come definita in [8] e i sei servizi offrono throughput
dati all’interfaccia utente con 4,8 kbit/s o 2,4 kbit/s con rate di protezione
agli errori di approssimativamente 2/3 e 1/3, rispettivamente. Per avere una
protezione ulteriore contro gli errori, interleaving con profondità 1, 4 o 8
possono essere usati insieme ai due livelli di protezione dell’errore, risultando
cosı̀ sei opzioni di servizio. La trasmissione della voce attraverso connessioni
a circuito protette non è standardizzata ma il suo uso non è specificatamente
escluso.
2.1.5
La sicurezza nel Tetra DMO
La modalità DMO permette agli utenti Tetra di parlare e scambiare dati
sfruttando il collegamento radio diretto senza la gestione delle BS Tetra. Le
stazioni vengono organizzate in gruppi, all’interno dei quali ogni utente è
implicitamente autenticato attraverso la conoscenza dei parametri di cifratura comuni al gruppo. Esistono due ulteriori modalità di utilizzo del Tetra
DMO: la modalità Repeater e Gateway. La prima modalità viene utilizzata
per connettere all’interno del gruppo un device Tetra con un altro sfruttando un nodo intermedio (il repeater), qualora la copertura radio del singolo
dispositivo non dovesse essere sufficiente a raggiungere il destinatario. La
76
seconda invece viene utilizzata per interfacciare la rete Tetra TMO con un
gruppo DMO che potrebbe non trovarsi sotto copertura delle BS.
Air interface encription Nella modalità DMO, Tetra offre quattro possibili livelli di sicurezza:
• DM-1: E’ il livello base, in cui non vengono implementate primitive
crittografiche e tutto il contenuti informativo viene fatto passare in
chiaro sulla rete.
• DM-2-A: Viene criptato il traffico utente e segnalazione. La parte del
pacchetto contenente gli indirizzi è in chiaro. Questa classe permette
di usare un repeater con address check indipendentemente che questo
sia in possesso delle chiavi crittografiche.
• DM-2-B: Viene criptato anche la parte dell’indirizzo di destinazione
(SSI) e tutto il traffico SDU. La funzione di repeater non è compromessa (il repeater non deve possedere le chiavi) ma non viene verificato
l’indirizzo di destinazione. La sorgente del messaggio è in chiaro, quindi
un eventuale terzo terminale può effettuare pre-emption.
• DM-2-C: Viene criptato tutto il pacchetto di sincronismo e tutto il traffico SDU e PDU, in particolare tutti gli indirizzi. Eventuali dispositivi
intermedi devono essere a conoscenza delle chiavi.
Il primo compito dei terminali Tetra quando vogliono iniziare una chiamata è quello di stabilire e concordare il livello di sicurezza da usare. La
classe di sicurezza usata dovrà essere mantenuta per tutta la durata della
comunicazione. Ogni MS deve mantenere un profilo di sicurezza associato a
ciascun indirizzo destinatario.
Ogni singolo profilo di sicurezza consta di:
77
• Un Identificativo del KSG usato per la cifratura (KSG-Identifier)
• L’identificativo della chiave (Static Cipher Key) SCK usata per la
trasmissione (SCKN)
• L’identificativo della chiave SCK in ricezione
• La classe sicurezza di preferenza e quella minima usata per la trasmissione
• La minima classe accettata per la ricezione
• La classe minima accettata da parte del master della chiamata per le
operazioni di pre-emption.
Nella fase di set-up della chiamata vengono comunicati, da parte del
master, i parametri di sicurezza contenuti nel frame DMAC-SYNC. Il destinatario della chiamata confronta tali parametri di sicurezza con quelli propri
predefiniti per la comunicazione con quell’indirizzo chiamante: se risultano
essere identici i KSG usati, le chiavi appartenenti allo stesso Key Association
Group (KAG) e il livello di sicurezza uguale o superiore a quello minimo, la
chiamata viene accettata. In caso contrario viene inviato un messaggio di
“security parameter mismatch” se si sta usando la modalità presence-check,
altrimenti viene semplicemente ignorata la richiesta. Lo stesso procedimento
viene usato anche da parte del master qualora gli venga fatta una richiesta
di pre-emption da parte dello slave. In modalità DMO una procedura di
autenticazione esplicita non è prevista, la conoscenza delle chiavi SCK per
un determinato gruppo DMO prova implicitamente l’autenticità della MS.
Le chiavi SCK possono essere installate, fino ad un massimo di 30, direttamente sui singoli terminali con procedure off-line o alternativamente possono
78
essere distribuite utilizzando l’infrastruttura Tetra TMO attraverso il protocollo OTAR. Ogni MS dispone di 30 Static Cipher Keys utilizzabili, per far si
che la comunicazione possa avvenire, tra due dispositivi deve esistere almeno
una chiave in comune da poter usare per la cifratura. Lo stesso vale nel caso
in cui per la comunicazione venga usato un repeater con address check o un
gateway. Ogni chiave ha un durata di utilizzo, al termine del quale viene
sostituita da un’altra chiave scelta all’interno del set di chiavi di quel gruppo
DMO. Per facilitare tali procedure di gestione delle chiavi durante una chiamata, è previsto un ulteriore sotto-raggruppamento delle chiavi, associando
uno o più identificativi SCKN con un Group Short Subscriber Identity GSSI.
Ogni sottogruppo di chiavi SCK associati ad un GSSI, prende il nome di
Key Association Group KAG, ogni MS individua una chiave di default in un
KAG per la trasmissione, mentre potrà utilizzare le altre per la ricezione.
Ogni GSSI associato ad un SCKN avrà tante corrispondenti chiavi associate
quante sono i subset, cioè uno per ogni subset, per esempio, se vengono
creati tre subset, ciascuno sarà formato da 10 chiavi e se un determinato
GSSI era associato al numero SCKN 3, dopo la suddivisione, sarà associato
alla chiave 3 di ciascun subset ovvero la SCKN 13 e la SCKN 23. Oltre alla
suddivisione statica delle chiavi in sottogruppi esiste anche una procedura
dinamica. Il meccanismo OTAR può essere utilizzato se il terminale ha un
accesso TMO per associare una determinata chiave di cifratura ad un certo
indirizzo destinatario.
E2E encryption Questo meccanismo di cifratura viene applicato solo al
traffico e alla segnalazione proveniente dallo strato dell’utente (U-plane). Lo
standard ETSI non si occupa di descrivere gli algoritmi di cifratura da usare
o come gestire le chiavi cifratura, ma definisce un meccanismo di sincronia
79
quando vengono usati degli stream cipher per criptare il traffico. La cifratura
end-to-end ha i seguenti requisiti:
• lo stesso meccanismo deve essere usato in entrambe le direzioni
• i processi di sincronizzazione nelle due tratte devono risultare indipendenti
• la cifratura E2E fa parte dell’user plane (è quindi indipendente dall’AIE)
• il trasporto dell’informazione in chiaro e cifrata devono mantenere la
struttura temporale
Assumiamo che il processo di cifratura avvenga attraverso un KSG che in
questo caso prenderà il nome di End-to-End KSG (EKSG). Il KSG ha due
input: una chiave di cifratura (CK) ed un vettore di inizializzazione (IV).
Il blocco funzionale F1 cifra il testo in chiaro con il bit stream in uscita dall’EKSS (un generatore di numeri pseudo random), generando il testo cifrato.
Dall’altro lato la funzione F1 inversa decifra il testo in chiaro utilizzando il
bit stream sincronizzato. La funzione F2 introduce delle informazioni di sincronia che al ricevitore verranno estratte dalla funzione F3 per sincronizzare
l’EKSS.
Collegato al blocco funzionale per le cifratura/decifratura, sarà presente
un interfaccia di controllo che avrà i compiti di:
• selezione della chiave CK
• selezione dell’algoritmo KSG
• gestire l’encryption state (on/off)
80
Figura 2.23: Diagramma funzionale dei meccanismi di encryption e decryption
Per evitare la ripetizione nella generazione dello streaming del KSG, il parametro
IV può essere reso variabile in base al tempo. Nell’architettura TETRA il
blocco funzionale dell’E2EE trova posto nell’User Plain allo strato superiore
dell’AIE, che svolge le sue funzionalità in modo indipendente. Non esistono
quindi requisiti sugli strati inferiori, se non il trasporto del bit di informazione
negli header necessario a segnalare che il traffico è cifrato con cifratura E2E.
2.2
Integrazione rete Tetra DMO con rete
wireless mesh
L’obbiettivo prefissato del progetto TWNET è quello di creare una rete di
accesso wireless basata sullo standard Tetra DMO per applicazioni di enti
istituzionali in ambiti di emergenza. La rete sfrutta la modalità di comunicazione diretta dello standard e viene estesa utilizzando una rete wireless di
2.2. Integrazione rete Tetra DMO con rete wireless mesh
81
tipo ad-hoc, creando cosı̀ un’infrastruttura con i requisiti:
• auto instradante;
• non gerarchica;
• facilmente collocabile;
• adatta per applicazioni di emergenza.
Inoltre la rete ad-hoc deve essere in grado di supportare connessioni multihop, aumentando la copertura della rete DMO che da standard non supporta questa funzionalità. Per garantire tali feature abbiamo selezionato una
soluzione che prevede l’integrazione, nel sistema di telecomunicazione Tetra,
di una rete MANET: Mesh Ad-hoc NETwork. Questo tipo di reti hanno la caratteristica di essere costituite da terminali dotati delle medesime
funzionalità, in grado di auto organizzarsi rendendo superflua una qualsiasi
infrastruttura fissa per fornire supporto alle comunicazioni.
Il sistema risulterà quindi autonomo con sia i terminali utente Tetra che
i nodi di accesso della rete MANET liberi di muoversi ed in grado di auto
configurarsi dinamicamente per la creazione della rete TWNET. Gli scenari
di rete che sono stati presi in considerazione sono principalmente due:
• scenario isolato;
• scenario interconnesso tramite gateway.
La rete di supporto MANET viene fornita tramite il sistema di autoforming CADAE presentato nel capitolo 1 che garantirà una rete di supporto
il più efficiente possibile, in grado di ridurre al minimo le interferenze elettromagnetiche per ottimizzare le comunicazioni wireless; quindi sarà garantita
82
una estensione dei servizi Tetra su tale infrastruttura affrontando problematiche con complessità crescente col numero di terminali mobili che andranno
ad utilizzare tale rete.
2.2.1
Elementi costitutivi la rete TWNET
Lo scenario preso in considerazione per questo progetto, presentato in figura
2.24, costituisce l’obbiettivo ultimo del lavoro.
Figura 2.24: Schema dello scenario TWNET
Nella figura 2.24 si possono distinguere i tre agenti principali presenti
nella rete TWNET:
1. Mobile Node
2. Terminale Tetra
3. Gateway Mobile Node
Il Mobile Node è l’elemento costituente la rete ad-hoc ed ha il compito
di interconnettere le varie isole Tetra DMO con la rete MANET, per far
83
questo deve essere in grado di trasportare la segnalazione DMO da e verso la
rete di backbone. Quindi il fulcro dell’integrazione Tetra/Wi-fi risiede nelle
caratteristiche eterogenee del nodo, che sarà, inoltre, in grado di svolgere sia
il ruolo del comune terminale Tetra che di router mesh IP. Il Mobile Node
deve quindi essere in grado di connettersi all’isola DMO come terminale ed
implementare le funzionalità di controllo dei servizi di telefonia, deve avere
funzionalità di routing cosı̀ da poter gestire l’instradamento dei pacchetti
nella rete mesh ed infine essere in grado di connettersi sia con gli altri nodi
mobili che con device IP, come per esempio un telefono VoIP o un Laptop.
Inoltre devono essere implementate funzionalità per permettere ai nodi mobili di gestire la sicurezza delle comunicazioni, con particolare attenzione al
supporto dei sistemi di cifratura forniti dallo standard Tetra DMO.
Il Gateway Mobile Node è in tutti gli effetti un Mobile Node, dal quale
eredita tutte le funzionalità, ma con alcune particolarità aggiuntive: infatti
deve essere in grado di connettersi ad una rete integrata Tetra e comunicare
con una Base Station.
Infine il Terminale Tetra costituito da un device Tetra DMO standard che
senza alcuna modifica deve essere in grado di comunicare con gli altri elementi
della rete in maniera completamente trasparente, senza cioè accorgersi della
presenza dell’infrastruttura TWNET.
Quindi i macro-requisiti che il sistema TWNET deve rispettare sono:
• L’interfaccia aria fra TETRA Terminal e Mobile Node deve essere conforme allo standard TETRA DMO al fine di rendere interoperabile il
nodo mobile con TETRA Terminal di altri produttori.
• Deve supportare la presenza di eventuali DM-REP (repeater secondo
lo standard TETRA DMO) nelle isole.
84
• Deve supportare la presenza di eventuali DM-GATE (gateway fra reti
TETRA DMO e reti TETRA TMO) all’interno della rete.
• La rete TwNET dovrà essere non gerarchica di tipo ad-hoc, fast-deployable,
self-Forming and self-Configuring.
• La rete TwNET deve sfruttare la modalità di comunicazione diretta
(DMO) dello standard TETRA, interoperante con tecnologie Wireless
LAN.
• La rete TwNET dovrà esporre un’interfaccia di gestione per le funzioni
di: Fault, Configuration, Accounting, Performance and Security.
• La rete TwNET deve essere costituita da Nodi Mobili trasportabili su
veicoli attrezzati (nodi di accesso trasportabili), pertanto facilmente
dispiegabili nel territorio in condizioni di emergenza.
• I Nodi Mobili trasportabili devono supportare modalità di comunicazione diretta Single hop e Multihop.
• La rete TwNET deve prevedere l’utilizzo di Nodi Mobili Gateways
trasportabili su veicoli attrezzati (nodi gateway trasportabili), pertanto
facilmente dispiegabili nel territorio in condizioni di emergenza.
• I Nodi Gateway devono supportare modalità di comunicazione verso
infrastrutture GPRS/GSM, WiFi, WiMAX.
2.2.2
Soluzione integrata Tetra/IP
Una delle possibili soluzione per l’integrazione fra due sistemi cosı̀ diversi
come il Tetra DMO e una rete IP è quella di adottare una rete eterogenea.
Infatti un sistema DMO non permette comunicazioni multihop ma soltanto
85
singlehop, l’unica estensione prevista da standard è costituita dall’adozione
di DM-REP (Repeater) che permettono di estendere il raggio di copertura
ma che non costituisce un nodo attivo della rete. Quindi la nostra soluzione
permette di separare la rete di accesso che supporta lo standard DMO mentre la parte di trasporto dati e segnalazione (backbone) viene implementata
su protocollo IP che risulterà però completamente trasparente alla rete di
accesso. In questo modo riusciremo ad ottenere una rete ad-hoc multihop a
banda larga sul lato di backbone, e una rete di accesso in grado di fornire
gli stessi servizi implementati dalle reti Tetra DMO (chiamata, changeover,
pre-emption, SDS).
La scelta, lato backbone, di appoggiarci ad una rete WiFi permette l’utilizzo di una tecnologia molto diffusa ed a basso costo che però permette
l’estensione dei servizi di rete DMO in ambienti dove fino ad ora non era
possibile. Le caratteristiche delle reti WiFI sono principalmente:
• basso costo di realizzazione;
• la possibilità di creare reti mesh costituite da nodi multi-interfaccia;
• alta diffusione;
• interfacce con protocolli di routing: in ambito IEEE 802.11 sono state
sviluppate metriche ed interfacce che permettono una gestione efficiente
delle politiche di instradamento [9];
• ampiezza di banda diversi ordini di grandezza superiore rispetto a quella fornita dal Tetra DMO 50kbps contro 54Mbps dello standard IEEE
802.11 variante a o g;
• il supporto a meccanismi di sicurezza avanzati forniti dallo standard
IEEE802.11i;
86
• la Quality of service fornita tramite il supporto a code di pacchetti
differenziate per tipologia di servizio per supportare differenti priorità
di traffico secondo lo standard IEEE 802.11e.
2.2.3
Nodo TWNET
Il nodo mobile risulta essere l’elemento base di tutto il sistema TWNET,
come abbiamo visto deve integrare sia le funzionalità di un terminale Tetra
che quelle di un router mesh. Le funzionalità che devono essere implementate
sono derivate dall’implementazione DM-MS, inoltre non può essere introdotta
alcuna modifica nell’interfaccia aria prevista dallo standard ETSI. Quindi per
rendere possibile l’interfacciamento con la rete MANET si rende necessaria
un’estensione dell’implementazione DMO sui terminali DM-MS che permetta
lo scambio delle informazioni legate al progetto TWNET. Il Mobile Node può
essere visto come costituito da due componenti fondamentali:
1. Mobile Terminal (MT): si sviluppa dal DM-MS standard che gestisce i
servizi lato DMO
2. Terminal Equipment (TE): che realizza la connessione fra DM-MS e la
rete TWNET
Ogni nodo mobile può ricoprire tre macro stati:
• Idle: il nodo non è coinvolto nel routing di una chiamata o di un sds,
quindi nell’isola DMO di appartenenza non è attiva alcuna chiamata.
• Master: il nodo mobile è attivo nel routing di una chiamata TWNET
dove l’isola di appartenenza è destinataria.
87
• Slave: il nodo mobile è attivo nel routing di una chiamata TWNET, in
questo caso la sorgente della chiamata proviene dall’isola di appartenenza.
Il nodo mobile è attivo nel indirizzamento della chiamata ma non è in
grado di parteciparvi come destinatario, ne di attivarne una; i suoi compiti si
limitano alla gestione del traffico ed alla sua esportazione/importazione verso/dalla rete TWNET. I suoi compiti dipendono strettamente dallo stato in
cui si trova il nodo: quando questi è il Master della chiamata, il suo compito
è quello di memorizzare le informazioni contenute nelle PDU ricevute dalla
rete multihop per ricostruire i dati da inviare sull’isola DMO; inoltre deve
accertare la presenza nella propria isola di competenza di device Tetra, come
repeater o gateway, per poter stabilire correttamente il protocollo da utilizzare. Nel caso in cui il nodo mobile sia Slave deve elaborare le informazioni
esportate dall’isola DMO, prelevare i campi delle PDU, creare il pacchetto
di comunicazione TWNET per inviarlo all’interno della rete IP.
Il protocollo TWNET
Per permettere il corretto invio e ricezione delle informazioni prelevate da
un isola DMO e per renderne possibile il re-invio all’interno delle isole destinatarie si è reso necessario la definizione di un protocollo di trasmissione
per coordinare i vari cambiamenti di stato dei nodi mobili all’interno della
nostra rete. La comunicazione delle segnalazioni e dei dati (voice + data)
tipici del DMO verranno cosı̀ incapsulati in pacchetti IP/UDP composti a
livello applicativo da due sezioni: header TWNET e payload TWNET.
Header TWNET Sono stati definiti vari tipi di pacchetti TWNET, per
poter distinguere le segnalazione dal traffico voce e per meglio gestire le fasi
88
di start-up di una chiamata. L’header (Tabella 2.4) risulta essere uguale per
tutti i vari tipi di frame ed è costituito da vari campi:
• PDU Type: lunghezza 8 bit, distingue le varie tipologie di PDU.
• AIE settings: lunghezza 40 bit, contiene i campi necessari per ricostruire la cifratura AIE nell’isola di destinazione; è costituito da 4 sotto
campi:
1. Air interface encryption state (2 bit);
2. Time variant parameter (29 bit);
3. KSG number (4 bit);
4. Encryption key number (5 bit).
• Unique ID: lunghezza 8 bit, identifica in maniera univoca la PDU all’interno della rete TWNET per evitare ambiguità e risolvere problemi
generati da eventuale replicazione dei messaggi a livello della rete IP.
Tale campo è costruito nel seguente modo: se è possibile ricavare il
numero del frame contenuto nella PDU proveniente dall’isola DMO
(numero compreso fra 1 e 18) il campo sarà costituito da:
1. 3 bit impostati a 0;
2. 5 bit contenenti il Frame Number esportato dal DMO.
Se il numero non permette un’identificazione univoca (nel caso degli
SDS la stessa PDU viene ripetuta su più frame non rendendo univoco
il Frame Number), tale campo sarà del tipo:
1. 1 bit impostato a 1;
89
2. 7 bit generati a partire dal frame number e da altre informazioni
presenti in modo da generare un numero che possa essere associato
univocamente con la PDU.
In questo modo associando lo Unique ID insieme ai campo Called party
TSI e Calling party TSI è possibile identificare in modo quasi univoco
la PDU. Resta l’ambiguità in cui venga inviata una stessa PDU dallo
stesso mittente, allo stesso destinatario, nello stesso Frame Number ma
in un superframe diverso.
• Destination address type: lunghezza 4 bit, identifica il tipo di indirizzo
del destinatario e viene utilizzato a livello 2. Indica se l’SSI è o true o
pseudo.
• Called party TSI: contiene il GTSI o l’ITSI del destinatario della chiamata o del SDS. Si tratta, rispettivamente, o di indirizzo di gruppo o
individuale.
• Source address type: identifica il tipo dell’indirizzo del mittente.
• Calling party TSI: contiene l’indirizzo del mittente.
• Area selection area master: lunghezza 48 bit, identifica l’isola chiamante, potrebbe corrispondere all’ITSI del Mobile Node dell’isola chiamante.
• Area selection isola slave flag: lunghezza 8 bit, indica se il campo Area
selection isola slave: è inserito.
• Area selection isola slave: lunghezza 48 bit, identifica il Mobile Node
dell’isola destinataria della chiamata. Questo è un campo opzionale
non è sempre presente in tutte le PDU.
90
Information Elements
Lenght Type
PDU type
8
M
AIE settings
40
M
Unique ID
8
M
Destination address type
4
M
Called party TSI
48
M
Source address type
4
M
Calling party TSI
48
M
Area selection isola master
48
M
Area selection isola slave flag
4
M
Area selection isola slave
48
C
Reserved
16
M
Header TWNET
280
M
Tabella 2.4: Schema del Header delle PDU TWNET
• Reserved: lunghezza 16 bit, e destinato ad usi futuri.
Struttura dei pacchetti TWNET Abbiamo visto che vi sono due tipi di
pacchetti che vengono generati dai sistemi Tetra DMO, e si distinguono dalla
componente che li ha generati (Capitolo 2.1.1): i pacchetti di segnalazione
vengono creati dal control plane, mentre i pacchetti traffico voce e dati sono
generati a livello utente dallo user plane. Nel sistema integrato TWNET i
pacchetti a livello 1 e 2 lato DM-MS vengono definiti dallo standard Tetra,
mentre i pacchetti a livello superiore possono essere costituiti da un header
TWNET a livello di rete e protocollo UDP a livello trasporto. In tabella 2.5
sono rappresentati gli schemi di incapsulamento dei pacchetti TWNET.
Call Control Tetra voice
91
SDS
UDP
IP
Tabella 2.5: Struttura dei pacchetti TWNET
Struttura Hardware
La soluzione TWNET prevede quindi l’integrazione di un terminale Tetra
DMO con un router wireless mesh per creare il Mobile Node. Questi due
elementi devono essere in grado di scambiarsi dati e informazioni di controllo
tramite un’interfaccia interna al nodo secondo un protocollo di segnalazione.
Quasi tutti i terminali Tetra in commercio implementano lo standard ETSI
PEI(Peripherical Equipment Interface) [10], che fornisce un interfaccia di
comunicazione che può essere collegata a diversi connettori fra cui una porta
seriale RS-232 o USB; solitamente lo standard PEI viene utilizzato per inviare
e ricevere comandi AT, abbiamo quindi scelto di usare questa interfaccia
per connettere il Terminal Equipment al Mobile Terminal. Nello sviluppo
del nostro prototipo è stata usata una connessione seriale RS-232 per poter
utilizzare anche terminale Tetra più datati e non dotati di connettore USB.
2.2.4
Sviluppo software di intercomunicazione Pe2Ne:
Pei to Network
Si è reso indispensabile lo sviluppo lato TE di un software per ricevere ed
inviare dati da e verso l’interfaccia PEI, tradurre i comandi AT ed incapsularli
in pacchetti UDP per inviarli nella backbone multihop. I requisiti di tale
software sono:
92
Figura 2.25: Interfacce e PDU presenti nello scenario integrato
• Portabilità: deve poter girare sia su router mesh wireless equipaggiati
con processore ARM big-endian, sia su workstation x86 little-endian.
• Real Time: il software deve essere in grado di gestire sia la segnalazione
su seriale, sia il traffico di rete con vincoli temporali stringenti, in modo
da poter garantire un servizio di comunicazione di tipo voce molto
sensibile ai ritardi di trasmissione.
• Efficienza: le piattaforme su cui girerà il software saranno, fra le altre,
dei router mesh embedded caratterizzati dai bassi consumi, alimentate
Power over Ethernet, ma dotate di scarse capacità di calcolo e con
poche risorse di memoria. Particolare attenzione è stata quindi posta
per sviluppare un software leggero, in grado di utilizzare il minor quantitativo possibile di risorse di sistema, garantendo però le funzionalità
necessarie allo scopo.
• Affidabilità: si è prestato attenzione in fase di design e sviluppo per
garantire la disponibilità del servizio, sia tramite un attento processo
di testing del codice sia nella creazione della macchina a stati che deve
93
essere dotata di procedure di recovery per evitare blocchi del servizio e
monitorare il funzionamento del Mobile Terminal.
La scelta quindi è ricaduta sullo sviluppo di un software C++, denominato pe2ne (PEI to NEtwork), utilizzando solo librerie standard, disponibili per
entrambe le architetture in oggetto, e sviluppato con particolare attenzione
verso la portabilità del codice. Il software girerà come demone sulle macchine
che andranno a costituire il nostro prototipo di rete, queste saranno dotate di
sistema operativo GNU/Linux ed in particolar modo di distribuzione OpenWRT [1] e Ubuntu [11]: la prima una distribuzione specifica per piattaforme
embedded, che fornisce una completa toolchain per lo sviluppo di applicativi
e la loro integrazione con il sistema operativo; la seconda è una delle più
diffuse distribuzioni linux per desktop.
L’obiettivo principale del progetto è quindi quello di creare un estensione
per il Tetra DMO: questa modalità di funzionamento, come visto nel capitolo 2.1.1, prevede una sola comunicazione contemporanea che quindi coinvolge anche i terminali non direttamente interessati dalla chiamata (saranno
impossibilitati ad effettuare chiamate poiché il canale di trasmissione risulterà occupato). Tutte le segnalazioni e i dati che verranno quindi esportati
da un’isola DMO verso la rete devono essere propagati verso tutti i Mobile
Node presenti nella rete multihop, per preservare il corretto comportamento
dei servizi di una rete DMO. Per questo motivo i pacchetti entro la rete mesh
saranno inviati con indirizzo di destinazione di Broadcast, le problematiche
di loop nelle trasmissioni di frame e ricezioni multiple sono risolte sia da
politiche di rilevamento loop che da controlli implementati nel software per
il riconoscimento di pacchetti replicati; inoltre la particolare struttura ad albero binario creata dal sistema CADAE (presentata nel capitolo 1) permette
una maggiore resistenza a problemi del genere.
94
Lato rete IP il demone deve agire come un modem software fra il Tetra e
la rete multihop, affrontando tutte le problematiche di sistemi di questo tipo,
deve cioè essere in grado di esportare correttamente tutte le informazioni da
un dominio DMO, inviarle nella rete correttamente incapsulate in un frame
IP/UDP ed infine riuscire ad importare tali informazioni nelle altre aree
DMO. Deve quindi comportarsi come un interfaccia in grado di:
• leggere e scrivere i campi dei pacchetti Tetra sulla porta seriale;
• leggere e scrivere i campi dei pacchetti Tetra nei datagrammi UDP che
verranno usati nella rete di backbone;
• leggere e scrivere gli appropriati comandi AT sull’interfaccia PEI.
Le interfacce che sono coinvolte nelle comunicazioni fra due isole tramite
l’infrastruttura TWNET sono schematizzate in figura 2.25. Come abbiamo
già visto i terminali Tetra sono in grado di esportare informazione e segnali
di controllo attraverso l’interfaccia PEI: tale standard definisce sia la sintassi
di comandi AT per inviare istruzioni finalizzate alla lettura e scrittura di dati
sul terminale, ma definisce anche la sintassi di alcuni messaggi non sollecitati
inviati dal terminale al manifestarsi di un certo evento lato radio (per esempio
una chiamata entrante o un SDS). Permette inoltre la generazione di chiamate, trasmissione di SDS o la richiesta di changeover senza coinvolgere la
componente MMI del terminale (Man Machine Interface). Il software Pe2ne,
girando come demone sul TE, legge le notifiche AT non sollecitate da un lato e
utilizzerà i comandi AT di set e read per riprodurre lo stesso evento negli altri
punti della rete multihop. Anche i dati voce vengono trasportati nello stesso modo, infatti le informazioni sulle chiamate vengono esportate sulla PEI
come comandi AT e formattate secondo lo standard ISI [12]. In questo modo
il Mobile Node che gestisce l’isola DMO originante la chiamata preleva i dati,
95
tramite i messaggi non sollecitati sulla seriale, questi vengono incapsulati ed
inviati sulla backbone; dall’altra parte i pacchetti, decapsulati, permettono la
creazione di comandi AT che vengono inviati sulla seriale all’interfaccia PEI
degli altri Mobile Node coinvolti nella chiamata. Eventuali problematiche di
questa soluzione derivano esclusivamente dalla banda disponibile per la connessione verso la PEI: infatti la connessione scelta per i prototipi, una seriale
RS-232, ha come transfer rate massimo 112500 bit/s che rappresenta un collo
di bottiglia nel flusso di dati scambiati fra due isole (il percorso del flusso
dati è sintetizzato in figura 2.25). Nonostante i terminali Tetra forniti per
la creazione del prototipo di rete TWNET implementino la libreria standard
ETSI AT, questa presenta delle lacune di funzionalità per gli obiettivi del
progetto. Infatti pe2ne necessita l’accesso ad un ampio numero di parametri,
sia sotto forma di messaggi non sollecitati che tramite l’uso di comandi di set
e read, rendendo cosı̀ necessaria un’estensione alla libreria per implementare
dei nuovi tipi di comandi e segnalazioni. Per esempio un nodo mobile in un
isola destinataria di una chiamata deve essere in grado di cambiare l’indirizzo
del terminale chiamante che deve infatti risultare quello del mittente che ha
iniziato la procedura all’interno di un’altra isola; mentre, utilizzando le librerie fornite, la chiamata nell’isola destinatario risulterebbe come originata
dal suo nodo mobile master. Un’ulteriore estensione ai comandi AT è l’implementazione dei messaggi per l’estrazione e l’inserimento dei frame di voce
da e verso il Mobile Terminal. Quindi molte modifiche sono state eseguite anche su firmware e software del Tetra MT all’interno del Mobile Node,
che dovranno gestire quindi comandi ed esportare notifiche non sollecitate
non standard, mantenendo contemporaneamente la retro compatibilità con
la libreria standard ETSI AT.
96
Finite State Machine
Uno dei principali problemi è mantenere la macchina a stati finiti del software
sul TE sincronizzata con quella interna del MT, infatti non è in grado di prelevare, tramite PEI, lo stato attuale del terminale Tetra; conseguentemente
la macchina a stati di pe2ne deve essere rigidamente vincolata ai messaggi
inviati ed alle risposte ricevute dall’interfaccia PEI. Ogni volta che viene inviato un comando, viene ricevuto un messaggio di risposta, OK, se il messaggio
è sintatticamente corretto, o un messaggio ERROR se non corretto o incompleto. Inoltre i passaggi di stato saranno vincolati non solo dalle risposte di
verifica sintattica ma anche da messaggi di risposta alle read o dalle notifiche non sollecitate, quindi la macchina a stati deve prevedere ogni tipo di
trasmissione effettuate nei passaggi da uno stato all’altro. In figura 2.26 e in
figura 2.27 vengono presentate le macchine a stati di una chiamata senza presence check sia dal lato dell’isola originante la chiamata, sia dal lato dell’isola
destinataria; si può notare lo scambio di comandi sulla seriale e le rispettive
risposte che vincolano i vari passaggi di stato. Le procedure schematizzate in
queste FSM verranno presentate ed illustrate successivamente al paragrafo
2.2.4.
Il software inoltre gestisce l’esportazione real time dei frame voce inviati
dal MT sulla PEI in modo asincrono per soddisfare i requisiti tipici di questa
tipologia di traffico: tali dati devono essere forniti ed inviati secondo stretti
requisiti in termine di latenza, jitter e error rate. In particolar modo il jitter è
il parametro più importante per garantire una buona qualità del servizio [13];
solitamente una buona soluzione per ridurre il jitter è implementare un buffer
per i frame voce, ma visto anche i particolari vincoli sulle risorse di sistema il
buffer non deve superare una certa dimensione per evitare l’esaurimento delle
risorse sul TE. Per ovviare a ciò abbiamo optato per una soluzione con due
97
+CTICN
IDLE
WAIT_SLAVE_CTCC
+CTCR/SEND_UDP_RELEASE
TIMEOUT
SLAVE_RESERVED
+CTCC
ERROR
+CTCR/SEND_UDP_RELEASE
TIMEOUT
TIMEOUT
TIMEOUT
+TWNCSD
+CDTXG
WAIT_TWNCSD
SLAVE
WAIT_TWNCALL
+TWNCALL/SEND_UDP_CALL
+CDTXC
+TWNBLK/SEND_UDP_DATA
Figura 2.26: Macchina a stati finiti del Mobile Node sull’isola origine
READ_UDP_CALL/AT+TWNCALL
+OK/AT+CTSDC
IDLE
SENT_TWNCALL
SENT_CTSDC
TIMEOUT
+CTCR
TIMEOUT
READ_UDP_CALL_DROP/ATH
MASTER_RESERVED
ERROR
WAIT_ACK_RELEASE
TIMEOUT
+OK/ATD
READ_UDP_CALL_DROP/ATH
READ_PTT_PRESS/AT+CUTXD
TIMEOUT
+OK/AT+CUTXC
TIMEOUT
+OK
READ_PTT_REL/AT+TWNCSD
SENT_TWNCSD
TIMEOUT
MASTER
WAIT_ACK_DATA
READ_UDP_DATA/AT+TWNBLK
SENT_ATD
+CTCC
TIMEOUT
+CTOCP
WAIT_MASTER_CTCC
+OK
WAIT_CTOCP
Figura 2.27: Macchina a stati finiti del Mobile Node sull’isola destinataria
98
buffer di dimensioni dell’ordine dei 10 frame, uno implementato dal software
pe2ne sul TE ed il secondo quello già presente all’interno del software del MT.
La soluzione del doppio buffer si è resa necessaria, nonostante la presenza di
una struttura analoga all’interno dei terminali Tetra, vista l’impossibilità di
avere informazioni lato TE sullo stato di riempimento dello stesso e quindi
l’impossibilità di controllare il flusso dei dati voce verso il MT.
Chiamata voce senza presence check In questo contesto operativo il
Mobile Node deve fornire le seguenti funzionalità:
• il MT deve essere in grado di ricevere tutte le chiamate dell’isola, includendo chiamate di gruppo e chiamate singole con identificativo TETRA
destinatario diverso dal proprio
• il MT deve essere in grado di processare il traffico aria ed esportare
sulla PEI i comandi AT in forma di Unsolicited Read Codes (comandi
di lettura informazioni asincroni)
• il MT deve essere in grado, una volta instaurata la chiamata, di esportare la voce sulla seriale PEI secondo il formato descritto dalla
definizione ISI [12]
• il MT deve essere in grado di processare i comandi AT provenienti dal
TE e tradurli in segnalazione aria al fine di realizzare il setup e la
successiva gestione della chiamata secondo lo standard DMO
• il MT deve essere in grado di variare la propria TETRA Identity
• il TE deve essere in grado di inviare verso il MT i comandi AT (standard
ed aggiuntivi) necessari a trasmettere in aria la giusta segnalazione
DMO
99
• il TE deve essere in grado di leggere il flusso voce dalla PEI e tradurlo
in stream di pacchetti UDP da inviare sul backbone Wi-Fi
• il TE deve essere in grado di rilevare segnalazione duplicata e gestirla
evitando loop
• il TE deve essere in grado di gestire la segnalazione in banda trasmessa
durante l’invio del flusso voce
Call Setup La prima fase analizzata è quella di Call Setup. In questa
fase sull’isola sorgente il MN deve ricevere la segnalazione aria ed esportare
sulla PEI i comandi AT necessari a veicolare tutti i parametri che serviranno
a valorizzare i campi delle PDU backbone.
La procedura TWNET per segnalare la presenza di una Call Setup prevede
l’invio di un pacchetto dal MN dell’isola mittente ai MN delle isole di destinazione (vedi figura 2.28); tale pacchetto del tipo PDU CALL SETUP è
formato dall’header TWNET più alcuni campi specifici (schematizzati nella
tabella 2.6).
Figura 2.28: TWNET Call Setup
Tale PDU, in relazione alla Figura 2.28, dovrà essere composta a partire
dai dati inoltrati sulla PEI all’interno del MN sull’isola sorgente e, dopo
aver attraversato la rete multihop, sarà utilizzata dal TE del MN dell’isola
100
Lenght Type
PDU type
8
M
AIE settings
40
M
Unique ID
8
M
4
M
Called party TSI
48
M
Source address type
4
M
Calling party TSI
48
M
48
M
4
M
48
C
Reserved
16
M
Pre-emption flag
1
M
Circuit mode type
4
M
Priority level
2
M
End to end encryption flag
1
M
Call type flag
1
M
Tabella 2.6: Campi del PDU CALL SETUP
101
destinazione per valorizzare i parametri dei comandi AT necessari ad eseguire
il setup della chiamata.
Dal lato dell’isola sorgente il MN riceve segnalazione aria indicante che
uno dei terminali attivi nella propria zona di copertura intende effettuare
una chiamata voce. Si assume che nessuna altra chiamata sia in corso e che
non ci sia nessun terminale nello stato di master reservation (caso in cui la
procedura corretta non è la call-setup ma la preemption od il changeover).
Il MT all’interno del TWNET MN dovrà quindi essere in grado di ricevere
segnalazione aria proveniente dal terminale TETRA dell’utente e provvedere
a creare la CALL SETUP PDU i cui campi sono stati forniti in tabella 2.6.
In corrispondenza della ricezione di una chiamata entrante, sia essa di
gruppo che individuale, il MT esporterà in modo non sollecitato sulla PEI i
comandi elencati sotto.
<CR><LF>
+CTICN: <CC instance>,<call status>,<AI service>
<calling party identity type>,<calling party identity>,
<priority level>
<CR><LF>
<CR><LF>
+CTCC: <CC instance>,<hook>,<simplex>,<AI service>,
<e to encryption>,<comms type>,<slots/codec>,
<proprietary>,<Tx Grant>
<CR><LF>
<CR><LF>
+TWNCALL: <called party identity type>,<called party identity>,
<call frame number>
<CR><LF>
102
Originariamente nelle librerie standard vengono esportati solamente i primi due comandi +CTICN e +CTCC di cui il primo con soltanto i primi tre
campi obbligatori e i restanti facoltativi; nella nostra soluzione forzeremo
l’esportazione di tutti i parametri facoltativi rendendoli di fatto mandatori.
Il valore assunto dal campo <CC instance>, che solitamente in DMO è
sempre uguale a 0, per l’utilizzo in TWNET è modificato per assumere i
seguenti possibili valori:
• 10000000 (binario) = 128 (decimale): per notificare la comunicazione
tramite gateway;
• 01000000 (binario) = 64 (decimale): per notificare la comunicazione
con repeater;
• 00000000 (binario) = 0 (decimale): per notificare la comunicazione con
protocollo MS-MS.
Il comando +TWNCALL invece è completamente nuovo alle librerie standard e permette, in fase di setup, di esportare l’indirizzo destinatario, elemento fondamentale per l’instaurarsi della chiamata ma che da librerie non
poteva essere ottenuto via PEI.
Il PDU CALL SETUP viene valorizzato come descritto in tabella 2.7
Per settare il valore del campo Call type flag si osserva il parametro
<comms type>. Nel mondo DMO esso può assumere tre soli valori:
• 0 chiamata punto-punto senza presence check
• 1 chiamata di gruppo
• 3 chiamata punto-punto con presence check
103
Lenght
Details
PDU type
8
2
AIE settings
40
0(non usato)
Unique ID
8
<call frame number> da +TWNCALL
4
<called party identity type> da +TWNCALL
Called party TSI
48
<called party identity> da +TWNCALL
Source address type
4
<calling party identity type> da +CTICN
Calling party TSI
48
<calling party identity> da +CTICN
48
autogenerato
4
0
48
0 (non utilizzato)
Reserved
16
0
Pre-emption flag
1
1
Circuit mode type
4
0 (fonia)
Priority level
2
<priority level> da +CTICN
1
<e to encryption> da +CTCC
Call type flag
1
<comms type> da +CTCC
Tabella 2.7: Valori dei campi del PDU CALL SETUP
104
Lenght
Details
CC Instance
8
da +CTCC
4
da +TWNCALL
Called party TSI
48
da +TWNCALL
Source address type
4
da +CTICN
Calling party TSI
48
da +CTICN
Isola partner
48
NULL
Pre-emption flag
1
1
Circuit mode type
4
0 (fonia)
Priority level
2
da +CTICN
1
da +CTCC
Call type flag
1
da +CTCC
Tabella 2.8: Valori degli attributi di TwnetCallData
Per questo motivo si opera come segue: <comms type> = 1 o 3 → Call
type flag = 0 altrimenti → Call type flag = 1
Al termine dell’invio della CALL SETUP PSU il software pe2ne provvederà ad immagazzinare in una struttura dati apposita i dettagli sulla chiamata
di cui sta facendo il routing verso la rete in modo da evitare di dover ricevere nuovamente via PEI le informazioni già esportate durante la setup e
necessarie per la trasmissione delle successive segnalazioni e del traffico voce.
Dato che per design il Mobile Node può gestire solo una chiamata per volta, la struttura in oggetto viene re-inizializzata ad ogni procedura di CALL
SETUP. Questa struttura dati nominata TwnetCallData viene definita come
una classe C++ con gli attributi privati presenti in tabella 2.8 e i rispettivi
metodi di set e get.
Sull’isola destinataria la CALL SETUP PDU ricevuta viene tradotta nei
105
seguenti comandi AT:
AT+TWNCALL=<Calling address type>, <Calling party identity>
<CR><LF>
AT+CTSDC=<AI Service>,<Called party identity type>,
<Area>, <Hook>, <Simplex>, <e-to-e encryption>, <Comms type>,
<Slot/Codec>, <RqTx>, <Priority>
<CR><LF>
ATD<called party identity>
<CR><LF>
Anche in questo caso è stato necessario proporre un’estensione alle librerie standard, il comando AT+TWNET permette di settare nell’isola di
destinazione il corretto mittente della chiamata. Successivamente all’invio del
comando ATD il TE che origina la chiamata sull’isola destinazione riceve due
comandi non sollecitati tramite i quali vengono ricavati i parametri necessari
alla successiva gestione della chiamata
<CR><LF>
+CTOCP: <CC instance >,<call status>,<AI service>,<hook>,<simplex>
<CR><LF>
<CR><LF>
+CTCC: <CC instance>,<hook>,<simplex>,<AI service>,<e to encryption>
<comms type>,<slots/codec>,<proprietary>,<Tx Grant>
<CR><LF>
Se il parametro <Tx Grant> ha valore 0 significa che il MN ha il permesso di trasmettere traffico nell’ambito della chiamata half duplex appena
106
instaurata e che quindi può iniziare ad inviare in aria le trame voce. Il processing della CALL SETUP PDU include anche la creazione di una struttura
dati TwnetCallData con contenuto uguale a quella creata sull’isola sorgente,
per mantenere in memoria tutti i parametri necessari per la creazione successiva di altri comandi AT. In riferimento a tale struttura dati il campo
Isola Partner dovrà però in questo caso essere settato facendo riferimento al
campo Area Isola Master ricevuto con la CALL SETUP PDU.
Gestione del traffico voci A valle di una CALL SETUP il terminale
TETRA inizia immediatamente ad inviare trame voce verso il MT del MN
della propria isola. In realtà il terminale TETRA dell’utente invierà traffico
voce in aria con destinatario il nodo od il gruppo con il quale desidera parlare,
sarà il MT a dover intercettare il traffico voce diretto a qualunque terminale
e, nel caso che sia destinato ad un terminale TETRA non in diretta copertura
del chiamante, esportare sulla PEI i frame voce codificati secondo lo standard
ISI.
Per trasportare i dati voce sulla rete TWNET viene definita la TRAFFIC
PDU, il cui contenuto viene descritto in tabella 2.9
La dimensione del payload ISI è variabile e dipendente dalla PDU ISI
trasmessa in aria, comunque da standard la lunghezza non può superare i
336 bit.
Sull’isola sorgente il traffico voce viene inviato in aria dal terminale utente
che riveste il ruolo di master e viene intercettato dal MN che afferisce a
quell’isola DMO. In questo contesto il MN, che svolge il ruolo di slave, dovrà
esportare sulla PEI un messaggio non sollecitato contente una serie di trame
voce formattate secondo lo standard ISI:
<CR><LF>
Lenght Type
PDU type
8
M
AIE settings
40
M
Unique ID
8
M
4
M
Called party TSI
48
M
Source address type
4
M
Calling party TSI
48
M
48
M
4
M
48
C
Reserved
16
M
< 336
M
Payload ISI
Tabella 2.9: Campi del TRAFFIC PDU
107
108
Lenght
Details
PDU type
8
3
AIE settings
40
0
Unique ID
8
Autogenerato
4
da TwnetCallData
Called party TSI
48
da TwnetCallData
Source address type
4
da TwnetCallData
Calling party TSI
48
da TwnetCallData
48
Autogenerato
4
0
48
0
Reserved
16
0
< 336
da +TWNBLK
Payload ISI
Tabella 2.10: Valori dei campi del TRAFFIC PDU
+TWNBLK: <stringa ASCII del pacchetto ISI in formato HEX>
<CR><LF>
Questo tipo di messaggio è stato aggiunto alle librerie standard poiché
non era prevista la possibilità di esportare i dati voce durante una chiamata.
Sull’isola di destinazione il MN avrà completato la procedura di CALL
SETUP e andrà a ricoprire il ruolo di master della chiamata instaurata,
quindi alla ricezione del TRAFFIC PDU andrà ad estrarre il payload ISI ed
utilizzerà i dati per alimentare il MT in modo che questo possa tradurre tali
dati in PDU di traffico voce in aria. Per alimentare il MT il demone pe2ne
dovrà inviare verso la PEI il messaggio AT:
AT+TWNBLK= <stringa ASCII del pacchetto ISI in formato HEX>
109
Lenght Type
PDU type
8
M
AIE settings
40
M
Unique ID
8
M
4
M
Called party TSI
48
M
Source address type
4
M
Calling party TSI
48
M
48
M
4
M
48
C
Reserved
16
M
Reservation time remaning
6
M
Request flag
1
M
Changheover request flag
1
M
Cease cause
4
M
Tabella 2.11: Campi del CALL TERMIANTED PDU
<CR><LF>
Call Termination Al termine della chiamata, il terminale originante
invia in aria una DM-TX CEASED PDU, ovvero un frame che indica che
il traffico voce è terminato e notifica quanto a lungo il canale resterà nello
stato reservation.
A livello di rete TWNET alla ricezione della DM-TX CEASED PDU per
la chiamata, il MN creerà una CALL TERMINATED PDU i cui campi sono
elencati nella tabella 2.11.
110
Figura 2.29: Sequenza dei messaggi scambiati durante una chiamata senza presence
check
111
La CALL TERMINATED PDU, in relazione alla figura 2.29, dovrà essere
composta a partire dai dati inoltrati sulla PEI e, dopo aver attraversato
la rete multihop, sarà utilizzata dal TE del MN dell’isola destinazione per
valorizzare i parametri dei comandi AT necessari ad eseguire la terminazione
della chiamata.
Sull’isola sorgente l’invio della CALL TERMINATED PDU dovrà essere
eseguito appena si riceva dal lato aria la segnalazione che il terminale di
origine ha cessato di inviare la trama voce, cioè quando è stato rilasciato
il tasto PTT (Press To Talk) del device fisico. La segnalazione aria viene
intercettata dal MN che invia sull’interfaccia PEI i messaggi non sollecitati:
<CR><LF>
+CDTXC: <CC instance>,<TxRqPrmsn>
<CR><LF>
<CR><LF>
+TWNCSD: <CC instance>,<Rsv time remaining>,<Request Flag>
<Chgvr Request Flag>,<Cease cause>,<call frame number>
<CR><LF>
Il MN una volta ricevuta in aria questa segnalazione dovrà provvedere
ad inviare verso la rete TWNET la CALL TERMINATED PDU assegnando
ai campi previsti i valori secondo quanto indicato nella tabella 2.12. Per
alcuni dei campi è necessario che il MN acceda ai valori della struttura dati
TwnetCallData che aveva creato durante la fase di Call Setup.
Sull’isola di destinazione il MN che riceverà la CALL TERMINATED
PDU, confronterà i campi con quelli della struttura dati TwnetCallData che
ha istanziato alla ricezione della CALL SETUP PDU e, in caso ci sia un
match invierà dal TE verso il MT i seguenti due comandi AT:
112
Lenght
Details
PDU type
8
4
AIE settings
40
0
Unique ID
8
<call frame number> da +TWNCSD
4
da TwnetCallData
Called party TSI
48
da TwnetCallData
Source address type
4
da TwnetCallData
Calling party TSI
48
da TwnetCallData
48
autogenerato
4
0
48
0 (non utilizzato)
Reserved
16
0
Reservation time remaning
6
<Rsv time remaing> da +TWNCSD
Request flag
1
<Request Flag> da +TWNCSD
Changheover request flag
1
<Chgvr request flag> da +TWNCSD
Cease cause
4
<Cease cause> da +TWNCSD
Tabella 2.12: Valori degli attributi del TERMINATED CALL PDU
113
AT+TWNCSD=<CC instance>,<Rsv time remaining>,<Request Flag>
<Chgvr Request Flag>,<Cease cause><Chgvr Request Flag>,
<Cease cause>
<CR><LF>
AT+CUTXC=<CC Instance>
<CR><LF>
I valori dei parametri dovranno essere estratti dalla CALL TERMINATED PDU eccezion fatta per il campo <CC Instance> che sarà invece estratto
dalla struttura dati TwnetCallData. Il secondo comando era già previsto dalla libreria standard mentre si è reso necessario definire il primo per andare a
settare quei parametri che devono essere trasposti dall’isola sorgente a quella
destinataria.
Design software
Come precedentemente accennato, abbiamo sviluppato il software pe2ne utilizzando il linguaggio ad oggetti C++ ed utilizzando solamente le librerie
standard libstdc++ fornite sia per le comuni distribuzioni linux per desktop
che per le distribuzioni per piattaforme embedded. Il programma è stato
sviluppato per girare su sistema operativo GNU/Linux e progettato per essere un demone che, una volta caricato all’avvio del servizio, resta in memoria
in background in attesa di reagire al manifestarsi di un evento (per esempio la
ricezione di dati su rete o su seriale). Andiamo ora a presentare le componenti
principali:
• class IOMultiplex: gestione eventi concorrenti e accesso ai socket;
• class Session e class State: implementazione macchina a stati finiti;
114
• class UdpBuffer: buffer dati provenienti dalla rete multihop.
Figura 2.30: Diagramma delle classi
class IOMultiplex Il principale problema da risolvere in software che
forniscono servizi di rete è come riuscire a gestire gli eventi concorrenti quali:
• comunicazione in lettura e scrittura sulla seriale
• comunicazione in lettura e scrittura sulla socket UDP
• timer della macchina a stati
Figura 2.31: Diagramma sequenziale
115
116
Tali funzionalità sono state delegate alla classe IOMulitplex con un approccio
sincrono al problema utilizzando la funzione select(): su un sistema Linux
quando viene aperto un file o una socket, questa viene resa disponibile tramite
un file descriptor, che ne permette l’utilizzo sia in scrittura che in lettura; le
operazioni sui file descriptor di default sono bloccanti, cioè quando vi si accede per eseguire una certa operazione, se questi non è pronto si interrompe
l’esecuzione del programma fino a quando il descrittore di file non diventa
nuovamente in grado di essere utilizzato. Il nostro software deve poter contemporaneamente stare in ascolto di due socket in ricezione, uno lato rete
IP/UDP e l’altro verso la connessione seriale PEI, in questo caso l’utilizzo della chiamataread() di una delle due socket bloccherebbe l’esecuzione del
programma impedendo di fatto la ricezione Real Time sull’altra socket, la cui
invocazione avverrebbe solo a lettura avvenuta dal primo socket. Per risolvere
questo problema si utilizza la funzione select() che prende in input la lista
dei file descriptor aperti che vogliamo utilizzare e, quando viene richiamata,
blocca l’esecuzione del programma fino al verificarsi di due condizioni:
1. uno o più di un file descriptor è pronto per ricevere dati e vi sono dati
da leggere (nel nostro caso o è arrivato un pacchetto UDP o è stato
ricevuto un messaggio dalla PEI);
2. è scaduto il timeout della select().
In questo modo ci assicuriamo di poter ricevere ed elaborare i dati quando
raggiungono il TE permettendoci di garantire le tempistiche richieste.
Per abilitare il controllo sui socket e contemporaneamente avviare il timer
viene richiamato il metodo pubblico wait() che invoca la select e che ritorna
un intero contenente quanti file descriptor sono attivi con dati pronti per
essere letti, in caso ritorni 0 allora significa che il timer è scaduto. Succes-
117
sivamente la classe chiamante potrà notificare l’evento alla macchina a stati
che eseguirà le azioni dipendenti dallo stato in cui si trova in quel momento
il TE (si può vedere la sequenza delle chiamate in figura 2.31).
Un’altra funzionalità delegata a IOMultiplex è fornire l’accesso alle classi
che gestiscono a basso livello le socket Linux per prelevare o inviare i dati sia
verso la rete che verso la PEI. Le operazioni di trasmissione e ricezione vengono pilotate dagli stati della FSM e quindi devono poter essere richiamate
da un grande numero di classi diverse; è importante avere un’interfaccia comune a tutte le classi che implementano i vari stati ed è necessario che questa
venga implementata dalla medesima istanza della classe IOMultiplex, è quindi stato scelto di sviluppare questo oggetto secondo il pattern Singleton [14]
che garantisce queste caratteristiche.
class Session e class State La macchina a stati finiti è stata sviluppata
utilizzando il pattern State [14]: gli algoritmi che implementano le azioni che
devono essere eseguite al manifestarsi di un certo tipo di evento in un determinato stato sono stati incapsulati all’interno di metodi di un’interfaccia. La
classe State, astratta, crea tale interfaccia, definendo i 5 metodi corrispondenti agli eventi di invio e ricezione dati su udp o seriale e di scadenza del
timeout; le classi istanziate, rappresentanti un certo stato della FSM, andranno a reimplementare i metodi che devono gestire le azioni previste per il
proprio ruolo. É importante che nessun dato venga memorizzato all’interno
della classe State, ma che tutte le informazioni vengano copiate all’interno
della classe Session; quest’ultima rappresenta la sessione di comunicazione
TWNET ed è l’entità che gestisce i parametri di comunicazione (per esempio
la struttura dati TwnetCallData come da figura 2.30) ed include dentro di
se la FSM. Conseguentemente è la Session che, al manifestarsi di un certo-
118
evento, va a richiamare il metodo corrispondente sull’interfaccia State (vedi
figura 2.31)
class UdpBuffer La ricezione dei messaggi sulla seriale deve avvenire immediatamente, con priorità maggiore rispetto alla ricezione lato rete multihop, poiché è requisito fondamentale che la macchina a stati della TE sia
sincronizzata con quella del proprio MT: se infatti, per esempio, il MT invia
un messaggio di errore o di chiusura chiamata durante una comunicazione
voce, la TE deve smettere di inviare frame voce verso il terminale, scartare
le TRAFFIC PDU che ha ricevuto e gestire questo cambiamento di stato per
evitare di entrare in situazioni di blocco. Sempre per garantire la sincronia
fra le due macchine a stati, in presenza di stati di transizione in attesa di
una risposta dalla seriale, si forza il blocco dell’invio dei pacchetti UDP alla Session, blocco che, come vedremo in seguito, non causerà la perdita del
pacchetto ma solo un ritardo nella sua elaborazione.
Inoltre lato seriale, visto che si comunica direttamente col device Tetra,
non ci sono problemi di mancata ricezione di dati o di ricezione di messaggi
fuori ordine. Queste però sono tutte problematiche che possono manifestarsi
nelle trasmissioni via rete, in particolare se ci troviamo ad usare una rete
mesh. Quindi per risolvere problemi di:
• perdita pacchetti UDP;
• arrivo pacchetti fuori ordine;
• jitter;
è stato implementato un buffer di ricezione dei pacchetti IP. Il funzionamento è semplice, la ricezione dei dati dalla socket udp è sempre attiva, quando
un pacchetto viene ricevuto, questo non passa per la classe Session e quindi
119
per la macchina a stati, ma viene direttamente passato all’interno del buffer
che è implementato all’interno della classe UdpBuffer. All’inserimento del
pacchetto viene controllato il suo unique id e nel caso sia un frame precedente all’ultimo aggiunto, viene cercato e collocato nel posto di competenza,
altrimenti viene accodato in fondo al buffer.
Per fare in modo che i pacchetti raggiungano la FSM viene definita una
pipe: un canale dati unidirezionale, solitamente usato per le comunicazioni
fra processi, che consiste in una struttura con due file descriptor, il primo fa
riferimento alla cima della coda e l’altro alla fine; i dati che vengono inviati
usando la funzione write() nel secondo file descriptor, vengono resi disponibili per la lettura utilizzando la read() sul primo file descriptor come se si
trattasse di un normale socket (vedi figura 2.32). Questo meccanismo viene
utilizzato per integrare l’invio dei dati dal buffer alla FSM col meccanismo
della select presentato al capitolo 2.2.4. Quando il buffer non è vuoto e presenta dati in attesa di essere elaborati, automaticamente viene prelevato il
primo pacchetto della coda e trasmesso all’interno della pipe; a questo punto
il primo file descriptor della pipe presenterà dati pronti per essere letti ed
andrà a sbloccare la select() che gestisce la notifica degli eventi alla Session.
Questo passaggio attraverso la pipe ci permette inoltre di mettere in pausa
l’elaborazione dei pacchetti UDP, per permettere la corretta comunicazione
col MT, vista anche la lentezza del canale di comunicazione seriale. Infatti
nella definizione dell’interfaccia State, viene anche implementato il metodo
enableUdpBuffer() che ritorna sempre true e vincoliamo a questo valore di
ritorno la possibilità che la pipe possa essere o meno inserita fra i file descriptor che permettono di sbloccare la select(). Negli stati di transizione, dove il
software deve aspettare la risposta dal MT, questo metodo viene sovrascritto
in modo che ritorni false, disabilitando cosı̀ il passaggio dei dati dalla pipe
120
alla macchina a stati ma permettendo comunque l’inserimento di nuove PDU
all’interno del buffer (entro i limiti di ampiezza dello stesso).
Figura 2.32: Passaggio dei dati in ingresso lato rete multihop
2.3
Risultati
L’attività svolta all’interno del progetto di collaborazione con Selex-Comms
ha portato quindi all’integrazione del sistema di telecomunicazioni professionali Tetra DMO con una rete wireless multihop: è stato identificato un metodo
per importare all’interno di una rete IP le segnalazioni ed i dati provenienti
da un’isola DMO e un sistema per reinserire tali informazioni in un’altra isola. Per permettere ciò è stato inoltre ideato un protocollo di trasmissione dati
su UDP per veicolare le informazioni Tetra e permettere le comunicazioni fra
i nodi costituenti la rete multihop. Sono stati progettati e creati dei prototipi
di Mobile Node unendo le componenti hardware di un terminale Tetra ed un
router wireless dotato di sistema operativo GNU/Linux embedded; inoltre
per la creazione di questi nodi è stato necessario estendere lo standard ETSI
per la comunicazione su seriale tramite PEI e quindi modificare software e
firmware dei device Tetra. Infine è stato sviluppato un software in grado di
poter gestire la comunicazione tramite le interfacce di rete IP e seriale PEI
per interagire con le varie componenti del sistema e tradurre le segnalazioni
2.3. Risultati
121
ed i dati ricevuti su di un’interfaccia in informazioni valide per l’altra, il tutto rispettando importanti vincoli real time dettati dalla necessità di gestire
traffico voce. Sono stati prodotti 3 prototipi di Mobile Node ed è stato creato un testbed per validare il nostro approccio e valutarne le funzionalità.
La rete di test permette quindi di andare ad analizzare il comportamento
delle componenti in un percorso a due hop: è stato studiato il funzionamento
dei sistemi DMO puri che non sono in grado di rilevare la presenza della
rete TWNET, ma che comunque vengono influenzati dalla sua presenza che
inserisce dei ritardi nella propagazione della segnalazione Tetra. Sono stati
valutati i vari servizi DMO di:
• Chiamata individuale senza presence check;
• Chiamata individuale con presence check;
• Chiamata di gruppo;
• Chiamata di emergenza;
• Chiamata con cifratura di tipo end to end encryption attivata;
• Chiamata con cifratura di tipo AIE attivata;
• Chiamata individuale senza presence check in presenza di DM-REPeater;
• Chiamata individuale con presence check in presenza di DM-REPeater;
• Chiamata di gruppo in presenza di DM-REPeater;
• Chiamata di emergenza in presenza di DM-REPeater;
• Chiamata con cifratura di tipo end to end encryption attivata in presenza di DM-REPeater;
122
• Chiamata con cifratura di tipo AIE attivata in presenza di DM-REPeater;
• Chiamata individuale senza presence check in presenza di DM-GATEway;
• Chiamata individuale con presence check in presenza di DM-GATEway;
• Chiamata di gruppo in presenza di DM-GATEway;
• Chiamata di emergenza in presenza di DM-GATEway;
• Chiamata con cifratura di tipo end to end encryption attivata in presenza di DM-GATEway;
• Chiamata con cifratura di tipo AIE attivata in presenza di DM-GATEway;
• Changeover per tutte le precedenti tipologie di chiamata;
• Invio di SDS di testo a diversa priorità in tutte le varie configurazioni
di rete precedenti;
• Invio di SDS di stato a diversa priorità in tutte le varie configurazioni
di rete precedenti;
In tutti questi casi non si sono riscontrate anomalie, i servizi sono stati verificati e testati garantendone la conformità con le specifiche di funzionamento;
inoltre i ritardi che la rete inserisce nella propagazione di segnalazioni e dati
voce non vanno ad influire sul comportamento del sistema. Infatti non si è
mai verificato che uno dei vari contatori, definiti dalle specifiche Tetra DMO,
scadesse a causa dei ritardi generati dalla rete IP o dalla comunicazione via
seriale causando l’impossibilità di usufruire di un servizio. Questa attività di ricerca ha prodotto la pubblicazione di un articolo [15], la proposta
di 4 brevetti [16] [17] [18] [19] ed è stato insignito del premio innovazione
Selex-Communications 2009.
Parte II
Testing funzionale per la
sicurezza dell’implementazione
di protocolli di rete
Capitolo 3
S.T.R.E.S.S.
L’attività di software testing risulta essere di fondamentale importanza nei
processi di sviluppo software proprio perché mira a ridurre il più possibile la
presenza di bug all’interno del codice, anche se uno dei principali problemi è
che nessuna metodologia di testing può dare la certezza matematica di assenza di errori. Il costo economico di questa attività inoltre risulta essere molto
oneroso arrivando fino ad equivalere quello dello sviluppo del codice. Si cerca
quindi di ridurre il più possibile i tempi ed i costi derivati da questa attività senza però comprometterne il risultato finale, sviluppando metodologie e
strumenti in grado di automatizzare il più possibile il processo cercando di
diminuire i costi e minimizzando gli errori umani.
L’obbiettivo di questa parte dello studio di dottorato ha mirato alla
creazione di una metodologia di testing ed allo sviluppo di un framework
flessibile, generico e dinamico capace di adattarsi ad ambiti diversi e fornire
supporto ed automazione in tutte le fasi del processo di testing del software
di rete.
Vedremo quindi aspetti generici del black box testing, in particolare
riguardanti quelli di ricerca delle vulnerabilità e robustness testing, sarà pre125
126
Capitolo 3. S.T.R.E.S.S.
sentata la metodologia che abbiamo sviluppato e la piattaforma con le varie
componenti e strumenti che la costituiscono. Infine andremo ad illustrare le
prove sul campo che sono state effettuate per presentare i risultati ottenuti.
3.1
Black-Box Testing
Ormai l’utilizzo del software ha permeato moltissimi se non tutte le infrastrutture della società moderna, computer e le reti di telecomunicazioni permettono di fornire servizi che ormai sono divenuti fondamentali ed indispensabili. La dipendenza che si è venuta a generare rende un eventuale
malfunzionamento del software un problema di entità maggiore rispetto al
passato. Inoltre la maggiore accessibilità a tali sistemi, non solo permette
a più persone di usufruire di un servizio, ma aumenta il rischio che eventuali vulnerabilità possano venir introdotte in qualche software e possano
venir sfruttate per attacchi, quindi l’attività di testing risulta essere fondamentale per tutte queste componenti, soprattutto per quelle che prevedono
una connessione con la rete. Spesso gli errori nel software vengono scoperti e notificati a partire dall’uso che ne fanno le utenze, viene segnalato un
malfunzionamento ed in seguito si indaga sull’origine del fallimento, questo
soprattutto nei software proprietari dove non si ha accesso al codice sorgente
e quindi non c’è alcun mezzo per gli utenti finali di valutare quale sia il livello
di sicurezza del software in oggetto. Diventa cosı̀ necessario sviluppare una
metodologia di tipo funzionale che permetta di verificare lo stato dei software
utilizzati ed il loro livello di sicurezza senza però avere a disposizione dettagli
implementativi come il codice sorgente. Il software testing prevede un’attività, non solo in fase di post implementazione, ma anche durante la stesura
delle specifiche di funzionamento e nella fase di progettazione, è quindi parte
3.1. Black-Box Testing
127
integrante di tutto il processo di sviluppo del software.
Una prima grossa distinzione può essere fatta in base alle informazioni
ed ai dettagli di cui si è a conoscenza o su cui si vuole basare il processo di
testing [20]. Si può quindi parlare di testing funzionale se il sistema da analizzare viene visto come una black box: non si ha conoscenza di alcun dettaglio
implementativo e quindi possono essere utilizzate solo le specifiche di funzionamento. L’esecuzione dei test prevede di inviare determinati input al sistema
per poterne analizzare i comportamenti e valutare la loro attinenza con le
specifiche. Un approccio di questo tipo solitamente viene utilizzato quando
i dettagli implementativi non sono di libero accesso o quando comunque si
ha una conoscenza limitata dell’oggetto sotto test, andandosi conseguentemente a basare su ciò che è a disposizione: analisi dei requisiti, specifiche
dei protocolli e le definizioni di interfacce. Diversamente, nel testing strutturale, l’analisi si basa su dettagli implementativi come il codice sorgente,
e viene quindi adottato un approccio di tipo white box. Vi è poi un livello
intermedio fra questi due tipi, il grey box testing [21]: in questo approccio
si ha una limitata conoscenza della componentistica interna del sistema, per
esempio si può avere accesso solo ad una parte del codice sorgente mentre
altre componenti sono software proprietario, oppure più semplicemente si ha
un accesso ai documenti di design più dettagliati delle specifica dei requisiti.
Per quanto riguarda la metodologia di testing è analoga a quella del black
box testing, cioè si opera una comunicazione dall’esterno con la “scatola”
analizzandone il comportamento per valutare i risultati dei test.
Il nostro lavoro si soffermerà principalmente sulla parte di testing funzionale, detto anche black-box testing, ed in particolar modo sull’analisi della
sicurezza delle implementazioni a partire dalle specifiche di funzionamento.
128
3.1.1
Concetti di base
Il testing viene definito come il processo che fa operare un sistema o una componente sotto particolari condizioni, osservando e memorizzando i risultati ed
infine valutando alcuni aspetti dell’oggetto analizzato alternativamente come
il processo di analizzare un software per rilevare le differenze fra il suo funzionamento e ciò che viene descritto nelle specifiche ed infine per valutarne
le caratteristiche [22].
Vengono identificate cinque diverse fasi del testing [20] in base agli obiettivi preposti:
• Fase 0: il testing coincide con l’attività di debugging.
• Fase 1: l’obiettivo del testing è verificare il corretto funzionamento del
codice.
• Fase 2: verificare che il software non funziona correttamente.
• Fase 3: il testing non deve più dimostrare qualcosa, ma deve ridurre il
rischio di non funzionamento fino ad un livello accettabile (ovviamente
in base alle caratteristiche e allo scopo del software sotto analisi).
• Fase 4: il testing non è più un’attività a sé stante ma un approccio per
lo sviluppo del software.
Queste fasi in realtà sono i 5 obbiettivi che devono essere tutti soddisfatti dal processo dello sviluppo del software che deve comprendere anche
quelle attività necessarie a determinare se il prodotto soddisfa le specifiche e
individuare eventuali malfunzionamenti.
La IEEE definisce i concetti di errore, guasto e fallimento [22]: il programmatore scrivendo codice può commettere un errore, questo se si manifesta può causare un guasto, che rappresenta un’espressione errata o uno
129
stato della memoria non corretto, cioè quello che più comunemente chiamiamo bug. Quando vi è un guasto questo può generare una condizione tale che
il software non si comporti in modo coerente con quello che ci si aspetta, cioè
non rispetta le sue specifiche di funzionamento e si ha quindi un fallimento.
Il processo di testing prevede alcune fasi, la cui automatizzazione può
velocizzare ed agevolare il lavoro: come prima cosa devono essere creati i
test case, sono l’unità base del testing ed hanno lo scopo di valutare certi
comportamenti o verificare la realizzazione di una determinata funzionalità
del sistema o, come nel nostro caso, valutare la robustezza ad un certo tipo
di sollecitazioni. I vari test case possono essere raggruppati in test group ed
a loro volta, più gruppi formano una test suite. L’obbiettivo del test case
prende il nome di test purpose e solitamente i gruppi di test case vengono
creati in base ad uno scopo comune che prende il nome di test group objective.
Successivamente alla creazione, i test case vengono eseguiti sulla componente
sotto analisi, si ha quindi un test run; ad ogni test case possono corrispondere
diverse esecuzioni e quindi diversi test run. Durante questa fase il sistema
sotto test deve essere monitorato senza però che venga modificato il suo funzionamento o il suo stato; inoltre spesso è necessario sviluppare stub o driver
specifici per interfacciarsi col sistema e per eseguire le varie run. Infine si
ha il verdetto dell’oracolo (oracle verdict): si definisce oracolo il meccanismo
che permette di valutare l’output del test case con le specifiche ed emettere
quindi il verdetto che può essere: pass, fail o inconclusive. Un verdetto di
pass significa che in risposta al test case il sistema ha reagito come ci si aspettava e che quindi non manifesta malfunzionamenti; contrariamente se è fail vi
sono delle palesi violazioni delle specifiche nell’implementazione dell’aspetto
sotto test e che quindi saranno necessarie ulteriori analisi per comprenderne
le cause. Se invece non si è in grado di assegnare uno dei due precedenti
130
verdetti, definiremo il risultato del test case come inconclusive, e quindi non
utile ai nostri scopi. Come detto precedentemente, in caso di verdetto fail, si
eseguirà il debug del codice per andare a risalire la catena dell’errore, guasto,
fallimento, partendo dalla failure generata dal test run per trovare il fault
che l’ha causato.
Livelli di testing
Una ulteriore distinzione può esser fatta in base al livello della componente
sotto test [20]:
• Unit testing: la unit è la più piccola parte di software che può essere analizzata, cioè la più piccola porzione di codice che può essere
compilata e venir caricata in memoria.
• Component testing: testing su un aggregato di due o più unit.
• Integration testing: l’integrazione è il processo per il quale si vanno
a generare elementi complessi aggregando diversi component; dopo
aver controllato i singoli elementi è necessario valutare anche le loro
combinazioni.
• System testing: un sistema è un componente complesso, il testing di sistema riguarda il comportamento dell’intero oggetto integrato e quindi
si va a controllare la sua conformità rispetto al design dell’architettura.
• Acceptance testing: il software terminato viene controllato per valutarne l’attinenza con i requisiti funzionali.
Ogni livello di test è associato alle varie fasi di sviluppo software, secondo
il modello a V rappresentato in figura 3.1 [23].
131
Figura 3.1: Modello a V del processo di sviluppo software
Conformance Testing
La ISO in collaborazione con la ITU-T ha sviluppato uno standard per fornire
una metodologia per il conformance testing delle implementazioni dei protocolli: è lo standard ISO 9646, OSI conformance testing methodology and
framework [24] [25]. Lo scopo del conformance testing [26] [27] è verificare
che il comportamento di una implementazione di un protocollo rispetti i requisiti dello stesso, questo permette di validare sia il corretto funzionamento
che l’interoperabilità fra implementazioni diverse del medesimo protocollo.
Questa tipologia di testing utilizza un approccio funzionale, viene valutato
solo il comportamento del sistema senza alcun interesse per la sua struttura
interna. Questa caratteristica permette quindi di poter riutilizzare le test
suite per più implementazioni diverse dello stesso protocollo.
Solitamente il processo di conformance testing procede in parallelo con lo
132
sviluppo dell’implementazione del protocollo, infatti entrambi queste procedure prendono come input la stesura delle specifiche: queste vengono utilizzate per la generazione dei test case in maniera indipendente dall’implementazione dello standard. Successivamente i test case vengono implementati
per andare infine ad essere eseguiti sulla IUT (Implementation Under Test)
per ottenere il verdetto sulla conformità della stessa rispetto alle specifiche.
Completezza del livello di testing
Oltre al problema dell’oracolo, un altro elemento estremamente complesso
del testing è la completezza. Per definizione il software testing è in grado di
dimostrare la presenza di bug, non è in grado invece di dimostrarne l’assenza
[20]. Infatti nel testing funzionale il numero degli input possibili è infinito,
ciò fa capire che è impossibile, sia teoricamente che praticamente, eseguire un
testing completo su tutto lo spazio degli ingressi. Quindi l’unica possibilità è
quella di eseguire un numero limitato di test, cioè eseguire un campionamento
degli ingressi per cercare di coprire più tipologie di input possibili.
3.1.2
Testing per la sicurezza del software
Come accennato precedentemente, la diffusione e l’uso del software ha coinvolto ogni aspetto della società moderna, dai più frivoli a quelli critici, tanto
che un fallimento di questi sistemi può causare conseguenze molto gravi. A
peggiorare la situazione è la continua esportazione dei vari servizi su internet
migliorandone si l’accessibilità ma esponendoli a maggiori rischi di attacchi:
chi sviluppa software deve quindi tener conto di questo e assumere che il loro
prodotto non verrà usato solo dagli utenti destinatari ma anche da eventuali
attaccanti [28].
133
Diventa quindi importante valutare la sicurezza dei sistemi sia per chi
produce software, sia per coloro che lo adottano, per avere una valutazione
della sicurezza delle proprie strutture IT.
La maggior parte delle violazioni della sicurezza dei sistemi informatici
vengono causate da errori nel software che vengono sfruttati come vettori di
attacco. C’è una distinzione da fare su queste vulnerabilità, si può parlare
di design vulnerability se deriva da un errore inserito in fase di progettazione
del sistema; contrariamente si parla di implementation vulnerability quando
vengono inserite in fase di implementazione e quindi derivano da errori di
programmazione. Per esempio, anche se un design è privo di errori e quindi
il sistema è privo di difetti da un punto di vista di progettazione questo può
essere costituito da componenti difettose che vanno quindi a compromettere
un impianto teoricamente sicuro. Per quanto riguarda i primi tipi di vulnerabilità, in fase di design si possono produrre modelli formali per dimostrarne
la correttezza e la sicurezza, contrariamente all’altra tipologia poiché la complessità dell’implementazione supera la capacità dell’analisi formale; inoltre
una maggiore complessità del codice aumenta anche la probabilità che vi
siano inseriti errori.
Robustness testing
La robustezza è una caratteristica fondamentale per le componenti software
ed è definita come: la capacità di resistere ad un input anomalo e mirato
ad ottenere un comportamento non previsto nelle specifiche. I problemi di
robustezza rappresentano anche problemi alla sicurezza del sistema, infatti le
vulnerabilità che sono presenti in un software possono essere utilizzate da un
attaccante per la sua compromissione, con impatto ovviamente maggiore nei
casi di componenti con accesso ad internet. Il testing di robustezza si discosta
134
dai test tradizionali poiché quest’ultimi hanno come obiettivo verificare che il
comportamento dell’oggetto sotto analisi sia conforme alle specifiche, mentre
i test per la robustezza mirano ad analizzare le reazioni ad ingressi anomali
ed a valutare la capacità del software di gestire eventuali attacchi con l’obiettivo ultimo di cercare le implementation vulnerability. Conseguentemente
cambia anche l’approccio alla macchina sotto test, infatti non ci interessa
solamente se le risposte sono attinenti allo standard ma deve essere valutato se si sono manifestati fallimenti o se le politiche di sicurezza sono state
rispettate. Un’ulteriore differenza fra questa tipologia di test e quella per la
conformità consiste nel numero di test case generati, infatti si passa da un
ordine delle centinaia ad un ordine delle migliaia [29].
3.1.3
Tecnologie di Black-box testing e stato dell’arte
Affrontiamo ora una panoramica delle varie metodologie di testing funzionale
utilizzate per attuare testing di robustezza, considerando anche che le varie
tecniche non sono mai esclusive anzi spesso un particolare approccio può
rientrare in più di una di queste categorie.
Fuzzing
Il termine fuzzing è stato introdotto per la prima volta da Miller [30] creando
uno strumento anonimo che eseguiva dei test per la robustezza di applicazioni
inviando dati random sulle loro interfacce, per poi valutare la reazione del
sistema e se erano presenti vulnerabilità o errori software. Concettualmente
la tecnica del fuzzing consiste nell’introdurre rumore sulle interfacce interne
o esterne fornite da un programma. Successivamente l’approccio tramite
fuzzing si è evoluto ed ampliato andando a sovrapporsi con altre metodologie come il domain testing, syntax testing e fault injection; nella sua accezione
135
più attinente al termine, il fuzzing consiste in una ricerca alla cieca di problemi nella gestione degli input nei vari programmi, ma questo tipo di approccio
risulta molto spesso inadeguato. Per esempio nel caso del test di un server
POP3, inviare dati casuali difficilmente permetterà di superare il primo scambio di messaggi, col risultato che soltanto una piccola parte dell’implementazione del protocollo verrà controllato, tralasciando gran parte del codice.
Quindi, il più delle volte la tecnica del fuzzing totalmente casuale risulterà
di scarsa efficacia, per questo motivo vi è stata un’evoluzione e sono stati
implementati approcci più intelligenti: gli strumenti possono essere specifici
di un determinato protocollo da testare e permettono di andare ad inserire
dati random in una parte specifica dello scambio di messaggi oppure possono
utilizzare un range di dati anomali da inserire invece di affidarsi al generatore
random. Questo approccio permette quindi di andare più in profondità nelle
macchine a stati del protocollo di fatto sovrapponendosi con la metodologia
tipica del syntax testing. Un importante aspetto del fuzzing è il controllo sul
trust boundary: cioè quando in un sistema l’esecuzione o i dati passano da
un trust level ad un altro e quindi vengono cambiate le loro risorse ed i loro
permessi. Un esempio di trust boundary che viene attraversato si ha quando
i dati ricevuti in rete vengono trasmessi ad un’applicazione per il parsing e
per l’elaborazione. Lo spazio degli input che possono essere inviati al sistema
è costituito da tutte le possibili combinazioni di dati ed è ovviamente infinito,
quindi per limitarlo è necessario scegliere un subset di valori da utilizzare nei
test. Per facilitarne la selezione, vengono usate delle euristiche: le euristiche
di attacco sono tecniche finalizzate alla ricerca di specifiche tipologie di bug
nelle applicazioni, per esempio se vogliamo cercare errori che causano buffer
overflow si inviano input particolarmente lunghi oppure se vogliamo sfruttare
errori di format bug si inviano caratteri speciali di controllo all’interno degli
136
input stinghe. I test case vengono quindi generati a partire dallo spazio degli
input e da un’euristica di attacco, ma come vengono generati dipende dal
tipo di fuzzer che viene utilizzato:
• un generation fuzzer è un programma autonomo che produce delle sessioni semi valide: è in grado di creare le informazioni da inviare in
base ad un modello, può essere più semplice e creare dati casuali o più
complesso ed utilizzare una rappresentazione del protocollo;
• un mutation fuzzer preleva una sessione valida, ne muta i dati creando
cosı̀ il test case.
I primi tendono ad essere specifici per un particolare standard o applicazione mentre i secondi sono fuzzer generici poiché non hanno bisogno di
modelli ma si basano su comunicazioni prelevate precedentemente al test.
L’azione del fuzzer può essere suddivisa in tre fasi
1. La tokenization: le comunicazioni protocollari vengono suddivise in
parti variabili o costanti, le prime sono quelle che saranno oggetto del
fuzzing (siano esse interi stringhe o dati binari), mentre le seconde sono
la parte costante del protocollo come gli header.
2. Vengono generati in modo manuale o automatico i test case, partendo
da un modello del protocollo oppure da traffico precedentemente catturato. Questa fase è importante perché un errore nella generazione
dei case può portare l’applicazione in esame ad ignorare gran parte del
traffico facendo risultare i test inutili.
3. Il traffico generato viene trasformato in traffico malformato in modo
da portare alla luce problemi nell’implementazione sfruttabili per un
137
eventuale attacco. Questo può essere effettuato in modo banale, semplicemente invertendo il valore di alcuni bit oppure con approcci più
sofisticati anche in base al tipo di dato. In questa fase entrano in gioco
le euristiche di attacco. Un’ulteriore accorgimento deve essere preso
perché quando si va a modificare i dati a volte è necessario modificare
altre parti del messaggio da inviare per assicurarci che il pacchetto
non venga scartato per altri motivi. Ad esempio, nel caso di controlli
di checksum o anche più semplicemente nel ricalcolo dei campi della
lunghezza.
Domain Testing e Syntax Testing
Si definiscono gli input domain come intervalli uniformi di valori che possono
essere ricevuti in ingresso da un’applicazione, valori appartenenti allo stesso
dominio probabilmente verranno processati in modo simile. Quindi un domain testing preleva alcuni valori dai vari domini, con attenzione a prelevare
almeno un input da tutti i range, per valutare come vengono elaborati dal
sistema in esame; i test case dovrebbero concentrarsi particolarmente sui confini dei domini dove è maggiore la probabilità di una errata gestione. Questo
tipo di testing viene solitamente utilizzato per verificare il comportamento
del sistema in risposta ai valori validi, ma è necessario, al fine dell’analisi
della sicurezza, integrarlo con l’invio di input non validi. Il syntax testing è
un altro approccio di testing funzionale, prevede l’utilizzo di dati in ingresso
che vanno a violare la sintassi del protocollo [20]: l’oggetto del nostro test
riceve cosı̀ input con caratteri casuali o elementi inseriti in ordine non previsto o con campi omessi, possono venir utilizzati limitatori non legali e cosı̀
via. L’obiettivo di questa tipologia di test è quello di controllare se gli input vengono controllati in modo robusto dall’implementazione del protocollo.
138
Tutti gli input che vengono passati ad un applicativo sfruttano un’interfaccia
che questo fornisce, essa può essere un socket di rete ma anche il prompt da
riga di comando o variabili di ambiente o qualsiasi altro mezzo di prelievo
di dati; ogni interfaccia utilizza un linguaggio secondo il quale un determinato input può risultare legale o meno, questi linguaggi possono essere o
nascosti o aperti. Un linguaggio nascosto non viene definito esplicitamente
dagli sviluppatori ma è il protocollo intrinseco di un’interfaccia che utilizza
l’applicazione per leggere dei dati che vengono inviati da una componente
software all’altra. Un linguaggio aperto invece è esplicitamente specificato
dalla documentazione come per esempio un protocollo di rete come POP3
o IP. La base teorica del syntax testing è che ogni interfaccia ha associato
un linguaggio, aperto o nascosto che sia, la cui implementazione può essere
analizzata con uno sforzo relativamente limitato [31]. Per automatizzare la
generazione dei test case per questo tipo di testing è necessario fornire un
modello del linguaggio di input che può essere utilizzato dalla macchina: un
esempio di grammatica formale per la definizione di una specifica è il BNF
(Backus-Naur form) o le espressioni regolari [32]: entrambe queste notazioni
definiscono dei linguaggi liberi dal contesto. Una frase di un linguaggio è
una sequenza di simboli inseriti secondo delle regole sintattiche, i linguaggi
liberi dal contesto vengono utilizzati per definire tali regole e per verificare
se un’espressione è sintatticamente corretta per quel linguaggio; questi particolari linguaggi vengono utilizzati per esempio nei parser per validare le
espressioni in ingresso. Nel testing possiamo utilizzare tali linguaggi descrittivi per creare delle sequenze da mandare in input al sistema sotto analisi
per valutarne il comportamento. La generazione dei test case può inizialmente produrre delle sequenze contenenti solo un errore, cioè un punto in
cui non vengono rispettate le regole del linguaggio, per poi successivamente
139
inserire doppi errori, tripli e cosı̀ via; quindi il numero dei test case prodotti
aumenterà esponenzialmente al numero degli errori che verranno introdotti.
Possiamo poi introdurre vari tipologie di errori:
• Errori di sintassi: violazioni della grammatica del linguaggio, vengono
creati rimuovendo un elemento, aggiungendone uno non previsto o
inserendoli in ordine scorretto.
• Delimiter error : i delimitatori rappresentano la separazione fra diversi campi della sequenza; nei linguaggi human readable, codificati in
ASCII, i campi vengono sperati o da spazi (space o tab) oppure da
simboli di delimitazione come virgole o punto e virgola. Per introdurre
questo tipo di errore si può rimuovere uno di questi simboli o inserirlo più volte o sostituirlo con un altro analogo. Nel caso di limitatori
che vengono usati a coppie come le parentesi possono essere inseriti in
modo non bilanciato.
• Field-value error : solitamente il valore di un campo risulta valido quando rientra in un certo intervallo, si possono quindi introdurre valori
errati fuori dagli intervalli di validità.
• Context-dependent error : violano delle regole che definiscono i valori
che possono essere assunti dai campi in base al contesto, sono proprietà
che non possono essere descritte dale grammatiche libere dal contesto.
• State dependency error : non tutte le espressioni sono valide ma dipendono dallo stato in cui si trova il sistema: errori di questo tipo consistono nell’inviare un’espressione non valida nello stato in cui si trova
in quel momento.
140
Solitamente è possibile automatizzare il processi di creazione delle sequenze corrette, per poi andare ad inserire gli errori per generare i test case. I
tool di test che implementano questa tipologia di approccio possono permettere la definizione di una specifica della sintassi, per creare la test suite in
modo automatico. Questa fase di generazione automatica può essere molto
complessa perché può avvenire che le informazioni da inviare all’interfaccia
siano miste: per esempio una richiesta HTTP può avere al suo interno script
SQL o Javascript. Proprio questa caratteristica di alcuni protocolli causa
vulnerabilità di tipo injection, per esempio la possibilità da parte dell’utente
di inserire dati in alcune posizioni come una query SQL all’interno di una
URI. Un ulteriore esempio di vulnerabilità causata da una injection che può
essere rivelata dal syntax test è il cross-site scripting (XSS) [33]: questo tipo
di attacco prevede l’inserimento da parte dell’attaccante di codice all’interno
della pagina web in modo che venga successivamente eseguito sulla macchina
delle vittime. In questo caso il codice inserito viene interpretato dal client
della vittima, ma la vulnerabilità è nel server che ha permesso l’injection di
codice per la mancanza di un corretto controllo dell’input (la URI è un input
per i server web).
Exploratory Testing
Quando parliamo di test per la sicurezza a volte può essere utile procedere
“a vista” senza avere aspettative sull’esito delle risposte. Questo perché il
tester può rivelare anomalie nel comportamento o spostare l’attenzione su
particolari elementi del sistema da analizzare più approfonditamente con un
approccio più standard. Questo tipo di metodologia di testing è sensibilmente
differente rispetto alle precedenti, solitamente infatti quando si procede con
l’esecuzione dei test si hanno informazioni precise sul tipo di risposta atte-
141
sa. Però può essere utile procedere con l’analisi senza pattern predefiniti,
facendo in modo che il passo successivo venga guidato da quello precedente.
Quindi il tester esplora il comportamento dell’oggetto sotto test: soprattutto
quando viene rivelata un’anomalia è utile indagare tramite nuovi test case.
La maggior parte delle tecniche di testing possono essere usate per questo
tipo di approccio, ma alcune si prestano particolarmente, come per esempio
il fuzzing (capitolo 3.1.3), e generalmente vengono utilizzate quando è difficile dire quali siano le anomalie che possono presentarsi nel comportamento
del sistema. Ovviamente il limite maggiore per un approccio del genere è
la mancanza di una metodologia vera e propria, di fatto non si tratta di un
vero e proprio sistema di testing: la sua esecuzione non può essere oggetto di
pianificazione e risulta profondamente dipendente dall’esperienza del utente
che ne guida l’avanzamento.
Penetration Test Un particolare approccio che può essere classificato
come exploratory testing è il penetration testing: si parla di una metodologia
per ricercare le vulnerabilità all’interno di un software o di una infrastruttura per successivamente sfruttarla ed attaccare effettivamente il sistema,
simulando un attacco reale. Durante questo tipo di procedura, il tester può
ricercare nel sistema delle vulnerabilità conosciute per poterle sfruttare, tale
ricerca può avvenire in modo manuale o automatico: nel secondo caso vi
sono tool specifici (security scanner ) che aiutano l’operatore andando a cercare eventuali problematiche appoggiandosi ad un database contenente le
vulnerabilità segnalate in passato. Inoltre spesso si possono creare input
potenzialmente dannosi da inviare al sistema, anche in questo caso aiutati
da tool automatici.
142
Stress Testing
L’obiettivo di questo metodo di testing è valutare il comportamento del sistema quando è sottoposto ad un pesante carico di richieste, per esempio
possono essere fatte richieste multiple o molto complesse o trasferimenti ingenti di dati; quindi si cerca di creare delle condizioni estreme per simulare
particolari eventi quali risorse esaurite o guasti hardware. Come prima cosa
durante lo stress test si cerca di evidenziare se l’applicazione è in grado di
continuare a fornire il servizio e con che livello di qualità, mentre se vogliamo
concentrarci su aspetti di sicurezza si cercano di individuare anomalie di tipo
diverso; per esempio si cerca di far eseguire le routine per la gestione degli
errori per valutarne la correttezza e la robustezza oppure si può cercare di
rallentare il sistema per sfruttare problematiche di race condition. Per quanto riguarda il testing della sicurezza questo tipo di approccio si basa sull’idea
che un attaccante è in grado di riprodurre ogni tipo di situazione, anche la
più estrema per riuscire a sfruttare qualche vulnerabilità per compromettere
il sistema [21].
Fault Injection
Procedura ereditata dal testing applicato a piattaforme hardware, prevede la
manomissione volontaria di certe componenti per valutare la resistenza delle
altre ad eventuali guasti. Mutuando questo tipo di approccio al testing del
software si inseriscono dei guasti volontari all’interno della comunicazione o
in dati che vengono inviati ad un’interfaccia valutandone cosı̀ il comportamento. Visto che in una filosofia black box non possiamo andare a modificare
componenti interne del codice, necessariamente l’inserimento del guasto deve
avvenire su un’interfaccia esterna, come nel nostro caso per analizzare le implementazioni di protocolli di rete. Questa metodologia può essere utilizzata
143
sia per eseguire stress test che per valutare la robustezza del software ad
anomalie nelle comunicazioni di rete, ma anche per esempio per un syntax
testing.
Monitoring
Una componente fondamentale di tutte queste procedure è la capacità di
osservare il comportamento della componente sotto analisi per valutare il
risultato dei vari test case. Questo è ancora più difficile nel testing per la
sicurezza di un sistema poiché, a differenza del conformance testing, non ci
si può basare esclusivamente sui messaggi di risposta o sull’assenza di essi; devono essere valutati anche altri aspetti che possono essere sintomi di
una vulnerabilità anche in presenza di risposte corrette secondo lo standard.
Infatti, là dove possibile, in un approccio black box, si deve cercare di monitorare parametri spesso invisibili al normale utente, tipo l’utilizzo delle risorse
del sistema o il proliferare di processi figli. Automatizzare questo aspetto del
testing può essere estremamente utile soprattutto quando vengono utilizzati
approcci come il fuzzing che operano con alti volumi di dati procedendo alla
“cieca”.
3.1.4
Stato dell’arte degli strumenti esistenti
Come accennato precedentemente, l’attività di software testing è molto onerosa,
la stima ci dice che il 50% dei costi dello sviluppo vengono assorbiti da questa attività, costi che aumentano nel caso di applicazioni critiche [34]. Ovviamente lo sviluppo di strumenti automatici per il testing può permettere
un’agevolazione del lavoro da parte del tester, velocizzandone l’attività. Vi
sono vari tipi di strumenti che variano per la generalità e per il grado di
automazione: ce ne sono di disponibili sia specifici per un singolo protocollo
144
che sotto forma di framework, o librerie per dare supporto per lo sviluppo di
applicativi veri e propri. Andiamo a presentare alcuni di questi strumenti,
prevalentemente non specifici ma che possono essere usati per più protocolli.
I progetti PROTOS e PROTOS protocol genome Il progetto PROTOS [29] nasce nel 1999 come collaborazione fra la VTT Electronics e l’Università di Oulu, come attività di ricerca per valutare differenti approcci
al testing funzionale di protocolli, con particolare attenzione alla robustezza
del software. Viene sviluppato un metodo che prevede la produzione di un
gran numero di test case con l’inserimento all’interno di un pacchetto di uno
o due elementi modificati mentre le restanti parti risultano intatte e quindi valide. Per prima cosa viene scritto un modello formale del linguaggio
dell’interfaccia da analizzare tramite l’utilizzo di una grammatica libera dal
contesto (BNF); successivamente questa specifica viene semplificata ed arricchita tramite regole che aggiungono elementi semantici alla specifica del
linguaggio. Una volta creato il modello di base vengono prodotti alcuni test
case senza l’inserimento di componenti eccezionali per validare la rappresentazione prodotta dello standard e, solo successivamente, si andrà a stilare
manualmente una lista di anomalie che verranno inserite all’interno dei pacchetti durante la generazione automatica dei vari test case. Infine si andrà ad
eseguire i vari test sull’implementazione sotto analisi. Va fatta una considerazione, una volta generati i test case, nel caso si voglia andare ad aggiungere
delle anomalie, sarà necessario riavviare da principio la fase automatica per
la loro generazione. Questo metodologia permette senza problemi di andare a testare protocolli stateless, mentre per quelli stateful i test in BNF
devono essere valutati in modo da poter raggiungere lo stato da analizzare
e poi inserire le anomalie. La fase successiva ai test di analisi dei risul-
145
tati si basa sui log prodotti. Per le caratteristiche di questo approccio viene
prevalentemente utilizzato per applicazioni di tipo client server con protocolli
request-response, fra gli altri LDAP, SNMP, H.323 e SIP [35].
PROTOS Protocol Genome Come evoluzione di PROTOS nel 2003
nasce il progetto PROTOS Protocol Genome con lo scopo di creare una serie
di strumenti per produrre automaticamente i test case partendo da dati validi
per aiutare e completare la fase di creazione manuale dei test. L’idea alla base
di questo progetto consiste nell’identificare dei blocchi strutturali che solitamente vengono usati nei vari protocolli, che quindi possono contenere tipi di
vulnerabilità simili, anche in diverse implementazioni di differenti protocolli. Questi blocchi prendono il nome di protocol gene [36]. La metodologia
di generazione automatica dei test case prende il nome di model inference
assisted fuzzing e prevede l’analisi di un certo quantitativo di dati di training di traffico valido da utilizzare come modello per la produzione dei frame
per il testing di robustezza. Questo approccio rappresenta una via di mezzo
fra il design manuale e un fuzzing completamente casuale. Una sostanziale
differenza rispetto al progetto originario è che questa metodologia non viene
applicata solamente a protocolli di rete ma a tutta una serie di linguaggi
implementati da varie interfacce e quindi da applicativi diversi; per esempio
è stato utilizzato per valutare come gli antivirus trattavano formati di compressione file differenti. Partendo da data set di training costituiti da alcuni
file compressi con un certo algoritmo, è stato prodotto un modello per ogni
formato e da questo una gran quantità di file modificati da far analizzare ai
vari antivirus. Gli autori hanno evidenziato un limite in questo approccio;
vi è nel modello una mancanza di conoscenza sul dominio, manca cioè ogni
tipo di significato semantico dei dati.
146
Codenomicon Defensic Da una spin-off del progetto PROTOS, Codenomicon, nasce un software commerciale denominato Defensic che prevede
una serie di strumenti per eseguire testing di robustezza, ognuno dei quali è
specifico per un singolo protocollo.
Applicativi per il fuzzing All’interno del fuzzing rientrano un gran numero di strumenti, ognuno specifico per un certo formato di file o per un
protocollo di rete, che possono essere utilizzati per analizzare ogni tipo di applicazione che implementa tale linguaggio. Inoltre vi sono fuzzer più semplici
che effettuano delle mutazioni partendo da dati validi, e che quindi possono
essere utilizzati con più protocolli differenti. Infine vi sono i fuzzing framework che forniscono un ambiente per gli sviluppatori di fuzzer per fornire
maggiore flessibilità e permettere di produrre strumenti per protocolli proprietari o non ancora testati [37], fornendo delle API per velocizzare o astrarre
alcune procedure quali:
• assistenza nella creazione del modello del linguaggio, per esempio un
programma di conversione che prende in input del traffico di rete traducendoli in un formato leggibile dal framework;
• ricalcolo automatico della lunghezza dei campi di un pacchetto in modo
da poter modificare dei dati ma automaticamente mantenere coerente
e valido il frame;
• calcolo dei checksum;
• metodo per generare dati random;
• fornire alcune euristiche d’attacco;
• fornire strumenti per rilevare la presenza di guasti nel software;
147
• strumenti e convenzioni per lo sviluppo degli strumenti permettendone
la riusabilità per progetti futuri e garantendone l’evoluzione.
SPIKE Sviluppato da Dave Aitel, SPIKE [38], è un fuzzing framework scritto in C che fornisce una serie di API per lo sviluppo di fuzzer per
protocolli di rete, include delle primitive molto frequenti nei vari protocolli
e include anche alcuni moduli per i quelli più usati. Utilizza un approccio block-based [39], la sintassi del protocollo viene divisa in blocchi di dati
che successivamente vengono mutati. Questi blocchi vengono definiti tramite
strutture denominate spike (da questo il nome del framework) che contengono
sia i dati binari che la loro lunghezza. Per utilizzarlo è necessario catturare
traffico valido ed immetterlo nel framework andando a definire i vari campi
usando le sue librerie, andando cosı̀ a creare i vari blocchi; dopodiché i blocchi vengono mutati con valori casuali o con valori presi da set di stringhe
o interi (euristiche d’attacco). Il difetto di questo progetto è la mancanza
di documentazione e dell’organizzazione dei moduli distribuiti, ogni piccolo cambiamento, anche l’aggiunta di una stringa in un’euristica richiede la
ricompilazione dell’intero pacchetto ed infine manca di strumenti che facilitino la riusabilità delle componenti realizzate. Riscritto in Python è stato
integrato nel framework per penetration test CANVAS.
Peach Peach è un framework multi piattaforma scritto in Python sotto
licenza MIT, permette la definizione dei dati da sottoporre al fuzzing tramite
XML, ed è in grado di modellare:
• informazioni sui tipi;
• relazioni fra i campi come dimensioni o contatori;
• checksum;
148
• trasformazioni di dati come la compressione;
• modellazione basi di una macchina a stati.
Questo framwork è in grado di produrre i test case sia tramite generazione
che mutazione.
GPF: General Purpose Fuzzer GPF [40] è un tool opensource per
piattaforme Unix, progettato come fuzzer generico può essere utilizzato sia
come fuzzer casuale, ma può anche effettuare mutazioni di dati empirici o
modellare manualmente un protocollo, tramite file scritti in C denominati
tokAids. L’utilizzo di questo framwork è molto complesso: infatti la modellazione degli standard usando i tokAids non è semplice [37]. É stato integrato
nel progetto Evolutionary Fuzzing System che si prefissa di utilizzare algoritmi genetici per produrre gli input da inviare alle componenti software. Si
basa sull’utilizzo di sessioni di dati semi valide che vengono inviate alla componente monitorata con un debugger (in questo caso si può parlare di grey
testing); i risultati vengono inseriti in un database e tramite un algoritmo genetico si cercano di modificare le sessioni facendole evolvere per le interazioni
successive.
Autodafè Un framework fuzzing sviluppato sotto GPL per piattaforma Unix [41] utilizza un approccio basato su strutture a blocchi; si prefissa come scopo principale quello di ridurre le dimensioni dello spazio di
fuzzing, andando a modificare quelle aree del pacchetti che possono portare
con maggior probabilità alla scoperta di vulnerabilità. I blocchi sono i marker
che vanno a definire un certo dato del pacchetto, associandogli un peso che
servirà per generare una scala di priorità con cui verranno processati i vari
campi. Anche in questo framework possiamo parlare di grey testing, poiché
3.2. Sviluppo piattaforma S.T.R.E.S.S.
149
integra un debugger che va a monitorare le chiamate alle API che vengono
ritenute pericolose come fprintf() e che utilizzano delle stringhe generate dal
framework.
Sulley Un altro framework scritto in Python utilizzato per sviluppo
di fuzzer e costituito da vari componenti estendibili. La maggior parte dei
fuzzer si concentrano sulle modalità di generazione dei dati, sulley invece si
concentra anche sulla parte di invio dei dati e sul monitoraggio del target [37].
Inoltre vengono affrontate le problematiche inerenti allo sviluppo di modelli
per protocolli stateful: raccogliendo le varie richieste da inviare ad un target
viene creato un grafo che successivamente verrà esplorato per analizzare i vari
percorsi interni. Sulley è l’unico framework che cerca di affrontare in maniera
differente la problematica degli stati in cui può trovarsi la IUT, solitamente
infatti vengono mandati messaggi in sequenza senza tener conto dello stato
attuale. Conseguentemente la maggior parte dei fuzzer vanno a testare solo
una parte dell’implementazione del protocollo, quella più superficiale, senza
considerare gli stati più nascosti.
3.2
Sviluppo piattaforma S.T.R.E.S.S.
Abbiamo presentato diverse soluzioni che vengono fornite per agevolare l’attività di testing funzionale, sia come supporto che come automazione; lo
scopo dell’attività di questo dottorato di ricerca è quella di studiare una
metodologia di testing funzionale per la robustezza delle implementazioni di
protocolli di rete tramite un approccio di fault injection e sviluppare una
piattaforma per la generazione automatica dei test case, la loro esecuzione e
l’analisi del comportamento dell’oggetto sotto analisi. L’idea alla base della nostra piattaforma rientra nell’intersezione fra syntax testing e fuzzing,
150
quindi si cerca di valutare le reazioni delle componenti in risposta a guasti
inviati in input, ma nonostante tutto la flessibilità del framwork ci permette
di utilizzarlo anche per valutare la conformità delle IUT alle specifiche dei
vari protocolli. Inoltre gli standard, che possono essere oggetti dello studio, sono dislocati in differenti livelli della pila ISO/OSI permettendo quindi
un analisi sia a basso livello che a livello delle applicazioni utente. I software sviluppati possono essere utilizzati come supporto per attività quali
stress test, testing di esplorazione. Infine, le particolari caratteristiche di espandibilità e di analisi del comportamento agevola anche attività di reverse
engineering per la ricostruzione del funzionamento di implementazioni proprietarie [42]. S.T.R.E.S.S. è stato ideato per lavorare con software di rete ma
non è vincolato a nessun protocollo, infatti è in grado di riprodurre un qualsiasi linguaggio, previa sua definizione formale tramite linguaggio libero dal
contesto. Nel nostro caso abbiamo scelto di utilizzare l’Augumented BackusNaur Form (ABNF) [43], una versione modificata del BNF, definita nel RFC
5234, espressamente ideata per la definizione di specifiche di protocolli di rete.
Il funzionamento del framework è schematizzato in figura 3.2, l’utente fornisce un modello del protocollo in ABNF, questo modello viene utilizzato per
creare in memoria il motore dei test case, la piattaforma inserisce automaticamente delle anomalie secondo un’euristica di attacco ed inizia l’esecuzione
dei test. Durante i test run viene monitorato l’apparato o il software oggetto dell’analisi per poi produrre degli output in vari formati (per esempio in
XML) contenenti sia i messaggi scambiati sia le informazioni prelevate dai
sensori di monitoring. Inoltre stiamo tutt’ora lavorando sulla parte di post
processing degli output per la rilevazione automatica dell’esito dei test case.
La parte principale del framework è stata sviluppata in C/C++ per poter
operare agevolmente anche a basso livello, mentre altri componenti come il
151
parser dell’output per fini statistici, editor di file ABNF e GUI sono state
sviluppate usando il linguaggio Ruby.
Figura 3.2: Schema del funzionamento della piattaforma S.T.R.E.S.S.
3.2.1
Generalità dei protocolli utilizzabili
Uno delle feature principali del framework è l’assoluta generalità del suo
utilizzo, la possibilità di eseguire test su diversi protocolli anche indipendentemente dal layer della pila ISO/OSI. Si è quindi resa necessaria la creazione
152
di un sistema per rappresentare un linguaggio comprensibile alla piattaforma che le permetta di parlare e comunicare in modo corretto seguendo tale
sintassi. Dopo l’analisi di varie soluzioni tipo ASN.1 o SDL si è deciso di
adottare una grammatica libera dal contesto, cioè una meta sintassi dove
ogni regola sintattica viene espressa tramite una derivazione, cioè un’equivalenza fra un simbolo non terminale a sinistra di un simbolo di uguaglianza e
uno o più simboli terminali o non a destra. Formalmente può essere definita
come una quadrupla:
G =< N, Σ, P, S > dove
• N è un insieme finito di simboli non terminali
• Σ è un insieme finito di simboli terminali
• P è un insieme di regole di derivazione
• S ∈ N è un elemento dei simboli non terminali e costituisce il simbolo
di partenza.
• Gli elementi di P sono nella forma N = (Σ ∪ N )
Le regole di derivazione trasformano una stringa composta da alcuni simboli
terminali e altri non terminali in un’altra stringa e cosı̀ via fino ad ottenere
una stringa di soli simboli terminali. Quindi un linguaggio descritto da una
grammatica di questo tipo è tutto l’insieme di stringhe costituite da simboli
appartenenti a Σ che possono essere derivati con una sequenza di passaggi di
riscrittura, partendo dal simbolo di partenza S.
Linguaggio di definizione dei protocolli: ABNF
Fra le possibili grammatiche libere dal contesto ve ne è una, derivata dal
BNF, specifica per rappresentare protocolli di rete bidirezionali, standardiz-
153
zata dall’IETF definita nel RFC 5234 [43]. Una specifica in ABNF è costituita
da un insieme di regole (chiamate nella specifica rule) costituite da:
rulename = elements
rulename ∈ N
elements ∈ (Σ ∪ N )
dove rulename è il nome della regola e gli elements sono uno o più simboli terminali o non terminali. I simboli appartenenti all’insieme Σ possono
essere o stringhe o valori numerici: le stringhe vengono definite fra virgolette
mentre i valori numerici avranno una notazione specifica: saranno indicati
dal simbolo % seguito da una lettera che rappresenta la base con cui viene
rappresentato il valore:
• %d rappresenta base decimale quindi il numero 34 sarà espresso dal
simbolo %d34
• %x rappresenta base esadecimale quindi il numero 10 sarà espresso dal
simbolo %x0a o %xa
• %b rappresenta base binaria quindi il numero 9 sarà espresso dal simbolo %b101 o %b0101 o 00000101
¯
Fra i simboli che possono essere introdotti nel lato destro delle regole vi sono
alcuni operatori che permettono di combinare gli altri elementi presenti alla
destra dell’uguaglianza: l’operatore di concatenazione permette di definire
una serie di elementi che, in fase di lettura, produrranno un simbolo terminale
formato dalla loro successione. Per esempio la seguente definizione:
154
elemento1 = ‘‘Ciao’’
elemento2 = ‘‘ ’’
elemento3 = ‘‘mondo’’
saluto = elemento1 elemento2 elemento3
Produrrà la stringa “Ciao mondo” che corrisponde alla regola saluto. L’altro operatore di alternativa è il simbolo “/ ” che separa i possibili valori di
sostituzione:
saluto = ‘‘ciao’’ / ‘‘mondo’’
In questo caso la regola saluto può corrispondere sia alla stringa “ciao”
che alla stringa “mondo”. Inoltre vi sono altri tipi di operatori per indicare
intervalli di valori, ripetizioni di elementi, sequenza opzionali o gruppi di
elementi.
Il modello del protocollo viene quindi creato tramite una serie di regole
di conversione, queste andranno a costruire una struttura ad albero, dove
la radice rappresenta il simbolo iniziale S ∈ N , ogni nodo dell’albero sarà
rappresentato da un elemento non terminale dell’ABNF, mentre le foglie
saranno gli elementi terminali. Per riprodurre la stringa valida per il linguaggio modellato si deve percorrere l’albero in profondità da sinistra verso
destra (in figura 3.3 un esempio con riferimento all’albero ABNF descritto
precedentemente).
Per definire quindi uno scambio di pacchetti secondo un linguaggio si
vanno a creare delle regole di derivazione con la descrizione dei contenuti dei pacchetti previsti dallo standard, per esempio nel caso del protocollo POP3 [44] la fase di connessione ed autenticazione prevede inizialmente
la ricezione del banner del server, poi l’invio di un pacchetto contenente il
nome utente, e successivamente un secondo con la password; in risposta il
155
Figura 3.3: Creazione dei messaggi utilizzando l’albero ABNF
server dovrà inviare degli acknowledge ed alla fine della procedura, l’esito
dell’autenticazione. Tale scambio di pacchetti può essere definito con:
protocollo_pop3 = connect autenticazione
connect = <%TCP_read%> descrizione
descrizione = "+OK Dovecot ready." %x0d0a
autenticazione = login read_ok password read_ok_login
login = <%TCP_send%> ‘‘User guest’’ %x0d0a
read_ok = <%TCP_read%> ‘‘+OK’’ %x0d0a
password = <%TCP_send%> ‘‘Pass guest’’ %x0d0a
read_ok_login = <%TCP_read%> ‘‘+OK Logged in.’’ %x0d0a
I simboli terminali fra parentesi angolari < e > rappresentano le istruzioni per
l’invio e la ricezione dei pacchetti e verranno illustrati più approfonditamente
nella sezione 3.2.1. Quindi percorrendo l’albero del protcollo POP3 (figura
3.4) otterremo:
<%TCP_read%> "+OK Dovecot ready." %x0d0a
<%TCP_send%> ‘‘User guest’’ %x0d0a
156
<%TCP_read%> ‘‘+OK’’ %x0d0a
<%TCP_send%> ‘‘Pass guest’’ %x0d0a
<%TCP_read%> ‘‘+OK Logged in.’’ %x0d0a
che corrisponde allo scambio di messaggi fra un client ed un server che implementano tale standard per l’accesso remoto alle caselle di posta elettronica.
Figura 3.4: Modello ABNF del protocollo POP3: creazione di traffico valido
L’esempio preso in considerazione è piuttosto semplice e rappresenta lo
scambio di un numero limitato di pacchetti; attraverso le definizioni in ABNF
siamo in grado di rappresentare modelli molto più complessi.
L’operatore di alternativa rappresenta la possibilità di avere due o più
possibili scelte e quindi avremo due o più possibili sequenze di messaggi rappresentati dal nostro modello. Questo operatore viene utilizzato nell’ambito
del nostro framework per inserire delle anomalie: partendo dal modello del
protocollo si vanno ad immettere dei valori dei campi errati o non previsti,
come alternativa ai dati corretti andando cosı̀ a creare situazioni non previste
dallo standard per valutare la robustezza della IUT (l’esempio in figura 3.5
prevede l’inserimento di alcune guasti rappresentati dall’elemento Anomalies
nella richiesta di login).
157
Figura 3.5: Esempio di inserimento di anomalie all’interno del modello ABNF
Estensione del linguaggio per l’uso nella piattaforma di testing Abbiamo visto che la potenza espressiva dell’ABNF è in grado di descrivere un
protocollo di rete, ma, per poterlo utilizzare per la creazione dei test suite
per il framework, è stata inserita la possibilità di immettere dei comandi:
delle azioni che la piattaforma S.T.R.E.S.S. elabora durante l’esecuzione dei
test case. Quindi per aggiungere questi comandi è stata utilizzata la sintassi
dell’ABNF in modo da includere tali azioni nel modello stesso del protocollo,
ma non andando a modificare in alcun modo le specifiche del metalinguaggio: secondo lo standard, fra i simboli terminali sono previsti alcuni elementi
racchiusi dalle parentesi angolari “<” e “>”, che vengono utilizzati per inserire delle descrizioni testuali; in questo caso vengono utilizzate per istruire
la piattaforma sulle azioni da compiere o sulle eventuali elaborazioni da effettuare. La sintassi utilizzata prevede che il primo simbolo della regola di
derivazione sia quello del comando seguito da eventuali argomenti:
nodo_comando = <%comando%> argomento1 argomento2 ... argomentoN
In questo modo, quando viene percorso l’albero ABNF il primo nodo terminale che viene letto sarà quello del comando e quindi permetterà di continuare
l’esplorazione utilizzando i nodi fratelli come argomenti. Come verrà illus-
158
trato nella sezione 3.2.2, il framework è stato pensato per permettere una
facile espandibilità ed agile implementazione di nuove azioni.
Comandi per la comunicazione Fra le azioni sviluppate, quelle di
fondamentale importanza sono le istruzioni per l’invio e la ricezione dei pacchetti di rete, indispensabili per l’esecuzione dei vari test case che vengono
generati. Attualmente sono state implementate:
• < %T CP send% > e < %T CP read% > invio e ricezione di un pacchetto di tipo TCP, all’inizio di un test case il framework si occuperà
di instaurare automaticamente la connessione TCP con la IUT ed al
termine si disconnetterà chiudendo la socket di comunicazione;
• < %U DP send% > e < %U DP read% > invio e ricezione di un
pacchetto di tipo UDP;
• < %RAW send% > e < %RAW read% > invio e ricezione di un
pacchetto a livello collegamento dati (livello 2 della pila ISO/OSI).
Comandi di comunicazione di rete che utilizzano diversi protocolli a livello
trasporto o socket a diversa profondità della pila ISO/OSI permettono di
garantire la generalità della descrizione di protocolli utilizzando il linguaggio
ABNF. Infatti, in protocolli di alto livello, viene demandata la costruzione
dei pacchetti dei layer più bassi al sistema dei socket del sistema operativo,
altrimenti può essere creato il modello degli incapsulamenti, andando cosı̀
ad utilizzare i vari standard protocollari permettendo l’analisi delle IUT dei
vari livelli ISO/OSI. Quindi il comando < %T CP send% >, visto precedentemente nel modello dello standard POP3, permette l’invio di un pacchetto
su una socket TCP (senza quindi definirne l’header dei livelli inferiori): il
159
pacchetto da inviare viene definito dalla concatenazione di simboli a destra
del comando di invio:
login = <%TCP_send%> ‘‘User guest’’ %x0d0a
piloterà la piattaforma per inviare un pacchetto TCP contenente la stringa
User guest con alla fine il terminatore cr-nl.
Figura 3.6: Esempio di pacchetto di login inviato durante una sessione valida del
protocollo POP3
Invece il comando < %T CP read% > pilota il framework perché si metta
in ascolto sulla socket TCP in attesa di pacchetti in arrivo: alla ricezione
il contenuto viene memorizzato e successivamente vengono eseguiti i nodi
rappresentati dai simboli alla destra del comando di lettura.
<%TCP_read%> ‘‘+OK’’ %x0d0a
In questo caso non sono presenti ulteriori azioni da eseguire sui dati ma, nei
log in output al test case, verrà associate al messaggio ricevuto le informazioni
160
attese (“+OK” %x0d0a) utili per un’analisi successiva. Sono stati inoltre
implementati alcuni comandi (capitolo 3.2.1) per permettere un controllo al
momento della ricezione e quindi valutare se il messaggio ricevuto è quello
atteso o si continuerà a rimanere in ascolto fino alla ricezione del frame o
fino alla scadenza del timeout. Il funzionamento dei comandi per UDP e
RAW è analogo a quelli appena presentati, l’unica differenza riguarda l’invio
e la ricezione tramite il socket RAW, oltre ad avere la necessità di avviare
il framework con permessi di amministratore, la definizione del pacchetto
risulterà diversa e poiché è necessario andare a definire un frame di contenuti
binari.
Comandi di controllo dei dati Come accennato precedentemente,
quando si ha un’azione di ricezione di un pacchetto, si possono eseguire alcuni
controlli per valutare se il frame era quello atteso o meno. Questa possibilità
non è particolarmente utile per quanto riguarda la ricezione su socket TCP
o UDP ma risulta fondamentale nell’utilizzo di quelli RAW: infatti quando
si attiva in lettura una socket su un’interfaccia di rete di tipo wireless, non
riceviamo solamente i frame diretti alla stazione che esegue i test, ma vengono
letti i frame di tutte le macchine presenti, i frame di controllo e di gestione
del canale, fra cui i beacon. Si è reso quindi indispensabile lo sviluppo di un
sistema che ci permetta di filtrare tali informazioni per prelevare ed analizzare
solo quelle interessanti al fine dei test. I comandi attualmente implementati
sono:
• < %M askCheck% >: prevede la presenza obbligatoria di due informazioni. La prima deve contenere la maschera per il confronto e la
seconda i dati da confrontare; il funzionamento è analogo alle operazioni che vengono eseguite per capire se due indirizzi IP appartengono
161
alla stessa sottorete tramite l’uso della netmask. Il framework esegue
un and bit a bit fra la maschera ed i dati, poi fra la maschera ed il
pacchetto ricevuto e se il risultato è lo stesso il pacchetto supera il
controllo.
controllo = <%MaskCheck%> mask data
mask = %xff
data = %x80
Nell’esempio viene valutato se il primo byte del pacchetto ha un valore, in esadecimale, uguale ad 80. (nello standard IEEE 802.11 [45]
corrisponde a verificare che il pacchetto ricevuto sia un beacon).
• < %V alueCheck% >: prevede la presenza obbligatoria di tre informazioni, la prima il byte che indica la posizione della campo del pacchetto da controllare, la seconda la lunghezza del campo, e la terza il
valore con cui confrontarlo.
controllo = <%ValueCheck%> start size data
start = %d0
size = %d4
data = ‘‘HTTP’’
Nell’esempio viene controllato che il pacchetto appena arrivato inizi
(byte alla posizione 0) con una stringa di 4 caratteri che deve essere
uguale ad HTTP.
Comandi di elaborazione dei dati Per rappresentare molti protocolli è necessario prevedere delle direttive per effettuare alcune operazioni sui
162
dati: per esempio delle funzioni che possano dinamicamente calcolare checksum, codificare e decodificare informazioni, e cosı̀ via in modo da andare a
riprodurre le varie primitive che vengono utilizzate all’interno degli standard
di rete. Per l’utilizzo del framework sono stati implementati i comandi di:
• < %Base64Encode% >: prevede almeno un’informazione che rappresenti i dati di input alla funzione di codifica base64, l’azione prevede il
prelievo dei dati e la conversione nella stringa base64.
encoded = <%Base64Encode%> "prova"
• < %Base64Decode% >: prevede almeno un’informazione che rappresenti la stringa in base64 da decodificare, viene prelevata e convertita
nei dati originali.
decoded = <%Base64Decode%> "cHJvdmE="
• < %M D5% >: prevede almeno un’informazione che contenga l’input
di cui deve essere calcolato la funzione di hash MD5.
encoded = <%MD5%> "prova"
• < %Sum% >: prevede due o più informazioni che contengano dei valori
numerici che verranno sommati, se saranno presenti delle stringhe non
convertibili in numero saranno equiparati al valore 0.
dieci = <%Sum%> %d5 %d2 %x3
Nell’esempio viene sommato il valore in base decimale 5 più 2 più 3 in
base esadecimale (che corrisponde a 3 in base decimale) ottenendo il
risultato 10.
163
Comandi di memorizzazione Per poter produrre traffico valido secondo molto protocolli, è necessario elaborare molte informazioni che devono
essere prelevate dai pacchetti ricevuti precedentemente. Si rende quindi indispensabile un sistema per estrarre delle informazioni al momento della
ricezione di un pacchetto e per la loro successiva memorizzazione. Il comando
ideato a questo scopo:
• < %V ariable% >: prevede due modalità di utilizzo, nel caso in cui sia
stata precedentemente memorizzata una variabile con il nome indicato
oppure viene richiamata per la prima volta per quella variabile. Se
deve essere memorizzato un valore il comando prevede tre informazioni
che contengano in ordine, una stringa che indichi il nome della variabile, un valore numerico contenente il byte iniziale da cui leggere ed
infine un valore numerico contenente la lunghezza delle informazioni da
prelevare.
var1 = <%Variable%> "NomeVar1" start size
start = %d10
size = %d4
In questo esempio si comanda il framework di prelevare dall’ultimo
pacchetti ricevuto una variabile, di nome NomeVar1 contenente i dati,
dal decimo byte per una lunghezza di 4 byte. Se invece è già presente
in memoria una variabile con quel nome è necessario introdurre solo la
stringa identificativa in modo che il comando ritorni le informazioni in
memoria.
164
3.2.2
Componenti principali
Per permettere l’esecuzione dei test case secondo un protocollo espresso in
ABNF dobbiamo rappresentare in memoria l’albero prodotto dal meta linguaggio, per far questo è stato scelto di implementare tale struttura dati
utilizzando il pattern Composite che permette la realizzazione di un albero
costituito da oggetti di tipo diverso ma che possono venir utilizzati in modo
uniforme [14]. In particolar modo i vari elementi dell’ABNF vengono rappresentati con oggetti differenti corrispondenti al simbolo terminale o non
terminale del metalinguaggio:
• Composite: rappresenta il nodo generico
• OrComposite: reppresenta l’operatore alternativa
• RepeatComposite: indica l’operatore per ripetizioni di un campo
• Leaf: classe astratta che rappresenta la foglia dell’albero e quindi un
nodo terminale dell’ABNF. Da questa classe ereditano gli oggetti che
rappresentano i vari nodi terminali previsti:
– StringLeaf: rappresenta una stringa
– HexLeaf: rappresenta un valore numerico in base esadecimale
– DecLeaf: rappresenta un valore numerico in base decimale
– BinLeaf: rappresenta un valore numerico in base binaria
– CommandComposite: è il nodo che corrisponde ad un comando,
quindi ai simboli terminali racchiusi fra parentesi angolari
Quindi la classe Composite viene creata da un simbolo non terminale
dell’ABNF, da questa ereditano gli altri oggetti che andranno a sostituire
165
Figura 3.7: Diagramma delle classi del modello ABNF
gli eventuali operatori e simboli terminali (figura 3.7). Con riferimento all’esempio in figura 3.5 il sotto albero raffigurante l’inserimento di anomalie
nel pacchetto di login del protocollo POP3 verrà rappresentato in memoria
dall’albero in figura 3.8.
Figura 3.8: Rappresentazione della definizione ABNF del messaggio di login del
POP3
166
Parser ABNF
La componente del framework che va a costruire il modello ad albero è il
parser ABNF, creato tramite la struttura rappresentata in figura 3.9. La
classe ABNFParser costituisce l’interfaccia esposta verso il core della piattaforma; se l’esecuzione del parsing ha esito positivo allora viene creato
l’albero ABNF e memorizzato un puntatore all’oggetto Composite che ne
costituisce la radice. La classe yy::Parser è il risultato prodotto da Bison
(capitolo 3.2.2), l’oggetto ParserDriver è usato per effettuare delle operazioni
ausiliarie al parsing: istanzia il parser, apre il file, mantiene in memoria le
strutture intermedie. Tale driver riporta al parser eventuali errori e l’esito
dell’analisi del file di input. La creazione dei nodi dell’albero è delegata alla
classe CompositeFactory.
Figura 3.9: Diagramma delle classi della componente Parser
Il parser utilizza alcune strutture intermedie per rappresentare i dati durante il processo, in particolare durante l’analisi sintattica vengono valutate le
167
Figura 3.10: Diagramma sequenziale della procedura di parsing
regole grammaticali che definiscono l’ABNF e quindi saranno gestiti i simboli
di tale linguaggio (che differiscono dai simboli della grammatica del protocollo
che viene definito per mezzo dell’ABNF). Infatti i simboli che rappresentano
il protocollo definito dal metalinguaggio sono quelli terminali dell’ABNF, ma
nel processo di creazione dell’albero il parser deve valutare anche i simboli
non terminali: per questo abbiamo creato la classe Symbol che rappresenta
un qualunque simbolo della grammatica di specifica.
Figura 3.11: La classe Symbol
168
A ciascun simbolo terminale corrisponde esattamente un simbolo della
grammatica del protocollo e quindi un nodo dell’albero ma ad uno non terminale possono corrispondere più simboli della grammatica dello standard,
infatti la regola di derivazione generica viene definita:
rulename = elements
con elements unione di uno o più elementi appartenenti agli insiemi dei
simboli terminali e non. Se ci troviamo ad analizzare una riga del tipo:
protocollo_pop3 = connect autenticazione
possiamo far corrispondere il simbolo protocollo pop3 a rulename ed i due
connect ed autenticazione ad elements; quindi all’elemento non terminale
dell’ABNF elements corrispondono due simboli della grammatica che stiamo
analizzando. La classe Symbol quindi ha un vettore di Composite in modo
da mantenere legata ad i simboli dell’ABNF l’informazione necessaria per la
costruzione dell’albero quando si va a ricostruire la struttura di derivazione
descritta nel file in input. Quindi per ogni simbolo che il parser incontra,
viene creato un oggetto Symbol e, se questo rappresenta una rulename, un
valore numerico o un comando, viene richiamata la factory per istanziare
l’oggetto Composite corrispondente. Alla fine, quando si trova la struttura
base della regola, viene creato il sotto albero relativo, la radice corrisponde al
nome della regola ed i figli rappresentano gli elementi che la costituiscono. I
vari sotto alberi vengono inseriti in una mappa ed indicizzati in base al nome
della radice, cosı̀ che, quando viene richiamato il processo di costruzione
dell’albero, questo viene ricostruito in modo ricorsivo a partire dalla sua
radice: ogni nodo cerca il suo identificativo nella mappa e aggiunge ai suoi
figli quelli del sotto albero nella mappa, richiamando poi la costruzione per
ognuno di quei nodi inseriti.
169
Successivamente abbiamo creato una serie di controlli da eseguire durante la creazione dell’albero, per validare alcune regole semantiche che non
potevano essere espresse con una grammatica libera dal contesto:
• una rule non può essere definita tramite se stessa, cioè il simbolo alla
sinistra dell’uguale non può essere presente anche a destra;
• tutti i nodi eccetto la radice devono avere un padre; il controllo viene
fatto alla fine della creazione dell’albero consultando se tutti i nodi
della mappa sono stati richiamati o meno. In caso contrario avremo un
errore di unreference symbol ;
• le foglie dell’albero devono essere simboli terminali del linguaggio; il
controllo viene eseguito dopo la creazione dell’albero assicurandoci che
tutte le foglie siano rappresentate da classi derivanti dalla classe astratta Leaf. In caso contrario avremo un errore di undefined symbol.
Bison e Flex La costruzione di un parser può essere un’operazione complicata, esistono però degli strumenti che ne facilitano la creazione. Per il
framework S.T.R.E.S.S. è stato adottato GNU Bison [46], utilizzato insieme
al generatore di analizzatori lessicali Flex [47]. Bison è un progetto open
source dello GNU Project, si tratta di un generatore di parser che converte
una grammatica libera dal contesto in un parser per tale linguaggio, producendo codice C/C++. Flex è un generatore di scanner che produce codice
C. Per la generazione di un parser per prima cosa è necessario descrivere la
grammatica in un formato riconosciuto da Bison e definire l’azione che deve
essere eseguita quando viene trovata una determinata regola sintattica. Successivamente si deve creare un analizzatore sintattico, tramite Flex, che prenda in input il file di descrizione del modello ABNF, ne estragga i vari elementi
170
costituenti, definiti token, per poi passarli al parser. La comunicazione dei
token dall’analizzatore alla componente per la loro interpretazione avviene
inserendo delle chiamate esplicite nel suo codice di controllo che richiama
anche le funzioni per la gestione degli errori. La grammatiche viene descritta
in un file (parser.yy) dove vengono rappresentate le regole sintattiche in un
linguaggio BNF, le azioni associate alle varie regole sono porzioni di codice
C/C++ che verranno richiamate dal parser ogni volta che una certa regola
viene applicata. Analogamente Flex prende le regole lessicali di un linguaggio definite in un file (scanner.ll), descritte tramite espressioni regolari, sono
associate ad una eventuale porzione di codice. L’utilizzo delle utility bison
e flex con questi file producono come output dei file C e C++ che verranno
inclusi nella componente del parser.
Modularità delle operazioni
Abbiamo visto che in memoria la struttura grammaticale dell’ABNF viene
riprodotta da un albero di oggetti Composite, l’utilizzo di questo pattern permette di trattare ogni nodo dell’albero come un oggetto uniforme nonostante
il differente significato sintattico. L’interfaccia esposta dalla classe Composite fornisce l’azione runTest() che permette l’esecuzione di un test case, ma
questa distinzione sintattica non è sufficiente per riprodurre una completa
procedura di testing. Infatti se consideriamo i vari comandi che vengono
inseriti nella definizione ABNF, questi sono tutti tradotti come oggetti CommandComposite, senza alcun tipo di riferimento al comando effettivo, cioè
non viene valutato il valore semantico del simbolo stesso. Per questo è stato
necessario ampliare la struttura creata sull’ABNF con un sistema per associare a nodi dello stesso tipo delle funzionalità differenti. Quindi è stato
incapsulato all’interno di una classe le azioni che vengono eseguite durante
171
i test case, in modo da creare un sistema che permettesse di avere delle
azioni intercambiabili, facilmente mantenibili ed espandibili. La struttura
che è stata creata segue i dettami del pattern Strategy [14]: definisce una
classe astratta Action che fornisce un’interfaccia unica per tutti gli oggetti,
composta da un metodo runAction(Composite*) che verrà richiamato dalla runTest() dei nodi dell’albero. Al primo metodo vengono delegate tutte
le operazioni necessarie per l’invio e la ricezione dei pacchetti, l’inserimento
delle anomalie, le varie funzionalità di elaborazione dati. Le classi che imple-
Figura 3.12: Diagramma delle classi previsto secondo il pattern Strategy
mentano Action vengono prelevate dalla ActionFactory nella fase successiva
al parsing; alla factory viene delegato il riconoscimento delle azioni da istanziare in base al tipo di oggetto richiamante o in base ai suoi nodi figli.
In particolare l’azione collegata ad un CommandComposite, non deve essere
assegnata al nodo rappresentante quel simbolo ABNF, ma a quello padre
che dovrà interpretare in maniera differente i risultati delle azioni degli altri
nodi figli. Per esempio in figura 3.13 al nodo login verrà associata l’azione
172
TcpSendAction, definita questa dal suo primo nodo figlio, e quindi andrà ad
utilizzare gli altri figli per costruire il pacchetto TCP da inviare.
Figura 3.13: Esempio: come vengono associate le classi del pattern Strategy
Nel dettaglio, ogni comando è identificato da una stringa che rappresenta
il simbolo terminale che viene indicata nel file ABNF, quindi tale stringa
determina il tipo di oggetto Action che dovrà venir istanziato ed associato al
nodo competente. Quindi si rende necessario creare in memoria un database
che permetta l’associazione fra la chiave che indica il comando con l’oggetto
da utilizzare come azione. Viene quindi creata una mappa all’interno della
ActionFactory dove sono inseriti i comandi disponibili con gli oggetti corrispondenti e si utilizza, come metodologia per la creazione di nuove istanze,
il pattern Builder [14]. Per rendere più semplice la procedura di espansione
del framework e di inserimento dei comandi nella mappa, abbiamo creato
una classe astratta Command che deve venir implementata da tutte le classi
dei comandi, fornendo cosı̀ l’interfaccia utilizzata per il pattern Builder per
la creazione di nuovi oggeti ed il metodo per l’auto-registrazione nella mappa
dell’oggetto stesso. Inoltre, per velocizzare ulteriormente l’aggiunta di nuovi
comandi, è stato creata una classe ad-hoc (chiamata SkelCommand) con i
suoi file di codice e di header contenenti la struttura vuota dell’oggetto che
implementa un’azione; la procedura per inserire nuove istruzioni prevede:
173
1. la creazione dei nuovi file di codice e di header copiando e rinominando
quelli dello SkelCommand;
2. lo sviluppo del metodo runAction(Composite*) che implementa l’azione
da inserire;
3. indicare la stringa che rappresenta il comando nella definizione ABNF,
che deve quindi essere racchiusa fra parentesi ancolate;
4. inserire all’interno dell’apposito file header include-actions.h l’include
del nuovo file .h che si è andato a creare.
In questo modo alla successiva ricompilazione, sarà automaticamente riconosciuto il nuovo comando ed all’avvio del programma, quando verrà creato
il database, sarà inserita anche la nuova funzionalità.
Figura 3.14: La classe ActionFactory
Injector automatico di anomalie
La specifica in ABNF prevede la possibilità di inserire manualmente le anomalie nel traffico di rete. Questa possibilità è essenziale quando vogliamo andare
ad analizzare particolari aspetti ed alcuni punti precisi del protocollo, quindi
in una fase più avanzata del processo di testing; risulta invece lungo e macchinoso operare un inserimento del genere nelle prime fasi, quando ci interessa
174
mettere sotto stress tutta la IUT. Per agevolare e velocizzare questo procedimento è stato progettato un sistema per permettere l’implementazione di
euristiche di attacco per automatizzare l’inserimento delle anomalie favorendo il riutilizzo di tali euristiche per l’implementazione di protocolli diversi.
Figura 3.15: Diagramma delle classi del sistema di inserimento automatico di
anomalie
Nella fase successiva al parsing ed alla creazione del modello, viene invocato l’AnomalyInjector, la classe che va ad implementare le procedure di
ricerca all’interno dell’albero Composite, dei nodi dove andare ad inserire le
anomalie, cioè quelli deputati all’invio dei pacchetti. Una volta identificati,
questa richiama la classe InjectorPerformer che opererà sui figli di tali nodi
ed andrà a modificare la parte del sotto albero contenente le informazioni
che devono essere inserite all’interno del pacchetto da inviare. In base alle
euristiche abilitate, i nodi foglia contenenti le informazioni corrette verranno sostituiti da un OrComposite (il nodo collegato all’operatore alternativa
175
e quindi alla presenza di anomalie) con vari figli contenenti il valore originale ed altri valori anomali. La selezione delle anomalie viene delegata alle
classi Injector, che implementano le varie euristiche; nel nostro studio abbiamo implementato una semplice euristica che inserisce valori anomali solo nei
campi stringa, ma possono essere implementate logiche più complesse che,
analizzando la struttura dell’albero, possono inserire anomalie più raffinate
(per esempio riconoscere campi di lunghezza o simboli terminatori). Attualmente l’unica euristica inserita opera solo sulle StringLeaf, quindi su i nodi
che contengono il simbolo terminale ABNF di stringa operando le seguenti
mutazioni:
• Inserimento all’interno della stringa originale di alcuni byte speciali:
– Terminatore: simbolo ABNF %x00;
– Carriage Return: simbolo ABNF %x0d;
– New Line: simbolo ABNF %x0a;
• creazione di una stringa di input molto lunga ottenuta concatenando
512 volte la stringa originale;
• sostituzione con una serie di byte non ASCII di uguale lunghezza;
• un valore completamente casuale come in un fuzzer;
• inserimento di una stringa nulla.
Utilizzando questa euristica su un modello del protocollo POP3 che prevede
l’invio di 5 messaggi di testo verranno prodotti il totale di 32768 test case.
Per implementare nuove euristiche è necessario creare un nuovo oggetto che
implementi l’interfaccia Injector, andando a produrre solo i metodi inject che
mutano quel tipo di informazione, tralasciando gli altri; l’InjectorPerformer
176
quando andrà a modificare l’albero del modello richiederà a tutti gli Injector
presenti di modificare i nodi interessati.
Monitoring
Aspetto fondamentale in tutte le procedure di testing funzionale è l’analisi
del comportamento della IUT, per permettere il riconoscimento dell’esito del
test case. Il problema dell’oracolo (presentato nel capitolo 3.1.1) è una delle
problematiche principali quando si parla di black box testing, perché non
avendo alcuna informazione aggiuntiva, salvo le specifiche di funzionamento,
è estremamente difficoltoso capire quando si viene a manifestare un guasto
che non sfocia in un fallimento del sistema. Per cercare quindi di agevolare
l’analisi del comportamento della componente sotto test si è sviluppato il supporto per una serie di sensori che andranno a prelevare informazioni durante
l’esecuzione dei vari test case.
Abbiamo innanzitutto identificato le fasi di interesse durante i test case
a cui vincolare eventuali segnali da inviare ai sensori per le rilevazioni:
1. all’inizio di ogni test case per la procedura di setup e l’inizio delle
misurazioni;
2. al momento dell’invio di un pacchetto;
3. al momento della ricezione di un pacchetto;
4. alla fine di ogni test case per compiere una misurazione finale e disabilitare l’osservazione;
5. successivamente alla fine del test case per prelevare i dati raccolti.
Deleghiamo la comunicazione con i vari sensori alla classe che gestisce l’evoluzione
della test suite, l’oggetto TestCaseManager che, come si vede in figura 3.17,
177
Figura 3.16: Schema di funzionamento del monitor e scambio di messaggi con le
componenti
178
ha nell’interfaccia i cinque metodi che si occupano di inviare i segnali durante
le fasi identificate precedentemente, in ordine:
1. sendNotificationStartTestCase()
2. sendNotificationPacketSend()
3. sendNotificationPacketRead()
4. sendNotificationStopTestCase()
5. getReport()
Figura 3.17: Diagramma delle classi del sistema di analisi del comportamento
Viene quindi definita una classe astratta per la specifica dell’interfaccia
degli oggetti che si occuperanno di gestire la registrazione dei dati di comportamento della IUT: la classe AbstractMonitor presenta sempre cinque metodi
179
distinti per le diverse segnalazioni da gestire, definendo però un algoritmo di
default per i segnali di invio e ricezione dei pacchetti. Infatti per alcune misurazioni non è necessario avere l’informazione di quando i vari frame sono
stati inviati o ricevuti, mentre obbligatoria è l’implementazione dei metodi per la gestione degli altri tre eventi. Quando viene segnalato alla classe
TestCaseManager il manifestarsi di uno dei cinque passi interessati, l’oggetto
rigirerà la segnalazione a tutte le classi di monitor attive. Attualmente sono
stati implementati due tipi di sensori:
• RTTMonitor: misura il round trip time fra un messaggio inviato e la
sua successiva risposta; in caso di connessione diretta fra la IUT e il sistema di testing, e quindi stimando il tempo di trasmissione pressoché
costante, ci permette di avere una misurazione del tempo di elaborazione dei dati inviati e quindi rilevare un eventuale carico anomalo.
La caratteristica positiva di questo tipo di monitor è che essendo una
misurazione lato framework non genera traffico aggiuntivo e quindi non
rischia di falsare i risultati.
• Monitor: questo sensore si connette ad un demone remoto per pilotare
le misurazioni delle risorse di sistema sulla macchina in analisi (ove
questo è possibile, cioè dove la black box è il software e non tutto il
sistema); quindi la componente che misura effettivamente le statistiche
di interesse si trova in remoto mentre la classe Monitor si occupa di inoltrare le segnalazioni degli eventi via rete e prelevare successivamente
i risultati richiesti. Questo sistema ha lo svantaggio di interferire con la
macchina oggetto dei test occupando risorse e generando traffico di rete
aggiuntivo, per questo è stato scelto di non utilizzare la segnalazione
dell’evento di pacchetto inviato ma soltanto quello di pacchetto ricevu-
180
to, riuscendo ugualmente ad isolare il periodo di elaborazione dati fra
ricezione e risposta nella IUT.
System Resources Monitor Per prelevare informazioni sul consumo di
risorse da parte di un processo che vogliamo osservare, è stato sviluppato un
demone in linguaggio Ruby funzionante su sistemi operativi GNU/Linux, in
grado di poter prelevare dalla rete le segnalazioni provenienti dal framework.
Viene configurato inserendo il nome dei processi da osservare, andando cosı̀
a leggere le informazioni di interesse direttamente dal file system proc fornito
dal sistema operativo stesso (questa è la componente che rende questo software funzionante esclusivamente su macchine GNU/Linux). Quando il software viene avviato si mette in ascolto aspettando messaggi dalla piattaforma;
il suo comportamento alla ricezione dei segnali è il seguente:
1. ricezione dell’evento di inizio test case: il software azzera i contatori e
strutture di memoria e preleva le prime misurazioni;
2. ricezione dell’evento di pacchetto ricevuto: preleva nuovamente le informazioni dalla proc, ne calcola il delta rispetto alla misurazione precedente, memorizza il risultato nelle strutture dati e aggiorna i valori
dell’ultime misurazioni fatte;
3. ricezione dell’evento di fine test case: esegue l’ultima misurazione inserendo le informazioni nelle strutture dati;
4. ricezione dell’evento di richiesta dati: preleva i dati dalle strutture, li
converte in una stringa leggibile e li invia al framework.
Il demone resta comunque in ascolto di nuove istruzioni dalla piattaforma e
quindi viene riutilizzato successivamente per ogni test case che viene eseguito.
Le informazioni che vengono prelevate sono:
181
• utilizzo CPU del processo;
• utilizzo memoria del processo;
• tempo di attesa per operazioni IO del sistema;
• aggregazione con contenuto del file di syslog;
Logging
Risulta indispensabile avere un sistema che permetta di tenere traccia delle
operazioni eseguite durante la procedura di testing: i messaggi inviati e le
risposte ricevute, i dati prelevati dai sensori ed eventuali mancate risposte.
Durante l’esecuzione di un test case, come abbiamo visto, viene utilizzato il
metodo runTest() della classe Composite il quale ricorsivamente richiama se
stesso nei nodi figli e cosı̀ via, andando ad esplorare tutto l’albero del modello
in profondità e da sinistra verso destra; l’esecuzione dell’azione associata
al nodo comporta il ritorno di un puntatore ad una classe State: è una
classe astratta che viene implementata da diversi tipi di oggetti che vanno
a rappresentare i risultati avuti dalle singole operazioni eseguite dai nodi
dell’albero durante il test case. Successivamente alll’esecuzione dell’azione,
in base all’esito viene istanziato un nuovo oggetto di un tipo derivato da State
per indicare l’esito positivo o negativo della singola operazione ed eventuali
dati da comunicare come risultato, permettendo cosı̀ di capire cosa è successo
durante il testing.
Anche State segue i dettami del pattern composite [14] cosı̀ da poter ricreare una struttura simile a quella del modello ABNF che li ha creati; infatti
tutte le azioni associate ai vari nodi, quando eseguono i nodi figli ottengono
una serie di oggetti State che vengono associati alla propria risposta, anch’essi come figli, riproducendo cosı̀ la stessa fisionomia della struttura sintattica
182
Figura 3.18: Diagramma delle classi delle risposte alle azioni dei test
183
del protocollo. Per esempio nel caso di una AdditionCommand avremo come
risultato un oggetto ValueIntState contente il valore sommato e come figli
di questo oggetto dei nodi analoghi contenente il valore degli addendi. Un
ulteriore esempio si vede in figura 3.19 dove viene presentato l’albero degli
State risultante dall’invio della login nel protocollo POP3. In figura viene
presentato un attributo delle classi state, state value che indica se il valore
contenuto nella classe è rappresentativo di:
• FAULT: derivato dall’inserimento di una anomalia;
• PACKET: la descrizione di un pacchetto inviato o ricevuto;
• FAIL: si è generato un errore;
• OK: l’oggetto riporta dati derivati dall’esecuzione di nodi ad una profondità maggiore dell’albero e non si è manifestato alcun errore;
utile per capire a cosa si riferisce un determinato valore riportato. Le classi
definite all’interno del framework sono:
• State: classe astratta, definisce l’interfaccia;
• OkState: nessun errore è presente nel sotto albero di cui lui è la radice;
• FailState: si è manifestato un errore generico nell’esecuzione del test
case;
• ValueState: classe astratta, implementa alcuni metodi comuni agli
oggetti contenenti i dati inviati o ricevuti;
• ValueStringState: contiene informazioni da trattare in formato stringa;
• ValueHexState: contiene informazioni da trattare come buffer di dati
esadecimali;
184
• ValueIntState: contiene informazioni numeriche in base decimale;
• ValueBinState: contiene informazioni numeriche in base binaria.
Figura 3.19: Esempio di State risultanti dall’invio del pacchetto di login del POP3
Conseguentemente, ogni volta che viene avviato un albero abnf, si ottiene
di ritorno un albero di oggetti State che descrivono l’esito del test case; inoltre
nel caso che i monitor siano presenti e funzionanti, i report vengono esportati
dalla classe TestCaseManager già incapsulati all’interno di classi State in
modo da poter aggregare i dati all’albero ottenuto dal modello ABNF. Per
permettere un’analisi successiva e più approfondita degli eventi per capire
il responso del test, viene delegata ad una serie di classi AbstractOutput la
scrittura di tali informazioni all’interno di file in vario formato o all’interno
di un database. Definita l’interfaccia con la classe astratta AbstractOutput,
sono stati implementati il supporto per la scrittura in file di testo semplice,
di file XML e di un file DOT contenente il disegno dell’albero di State.
185
Figura 3.20: Diagramma delle classi della parte di scrittura dell’output
Creazione automatica di un modello di traffico
La creazione di un modello corretto di protocollo è un procedimento molto
lungo se eseguito a mano senza alcun tipo di supporto, con i soli documenti
di specifica. Per agevolare tale operazione è stato ideato un sistema per
creare dei modelli semplificati di traffico del protocollo, partendo da sessioni
reali di scambio di dati; una componente, che prendendo in input un file
contenente traffico di rete “catturato“, restituisce come output un file con
la rappresentazione ABNF di tali pacchetti. Questi file poi devono essere
modificati per inserire anomalie o i comandi per pilotare la piattaforma, ma
costituiscono un grosso aiuto per agevolare l’attività di modellazione degli
standard da analizzare. Tale componente prende il nome di dissector poiché
analizza il traffico estraendo le informazioni ivi contenute e, riconoscendo il
protocollo, le suddivide per i vari campi che costituiscono i pacchetti.
libwireshark Wireshark [48] è un analizzatore di pacchetti di rete, ovvero
un software in grado di prelevare i pacchetti che passano su una rete e di
visualizzarne il contenuto. Uno strumento estremamente utile per risolvere
problemi di networking, analizzarne la sicurezza, eseguire un debug di implementazione dei protocolli di rete ed analizzarne il funzionamento interno. E’
stato sviluppato in C ed è costituito da una GUI, alcune utility e una libre-
186
Figura 3.21: Schema generale del funzionamento del dissector
ria che permette l’utilizzo di alcune funzionalità a programmi esterni. Fra
queste funzionalità vi sono una serie di decodificatori, i dissector appunto,
che eseguono l’analisi dei pacchetti di numerosi protocolli, cercano di identificare il tipo e ne estraggono le informazioni contenute. Il funzionamento
è analogo a quello previsto dal normale flusso di dati nei socket di sistema:
i pacchetti che vengono prelevati sono passati al dissector competente del
livello più basso, il Frame dissector, che preleva le informazioni dall’header
e passa i dati al dissector delegato al livello successivo della pila ISO/OSI;
l’Ethernet frame dissector legge le informazioni dall’header ethernet e passa il payload all’IP dissector e cosı̀ via, ad ogni passaggio vengono ricavati
dettagli specifici relativi ai vari protocolli usati nei differenti layer dalle pila
ISO/OSI.
S.T.R.E.S.S. Dissector Sfruttando quindi le capacità fornite dalle librerie di wireshark è stato sviluppato un software in grado di ricavare da
un traffico di frame catturati, una definizione formale in ABNF. Per poter
utilizzare tali librerie scritte in C, è stato necessario sviluppare un’interfaccia
ad oggetti, e successivamente tutta la componente di trasformazione delle
187
strutture ritornare dai dissector in regole di derivazione del metalinguaggio.
Le classi che compongono questo tool sono:
• Dissector: rappresenta la classe principale e fornisce l’interfaccia alle
sue funzionalità;
• CaptureFile: implementa i metodi per leggere le informazioni dal file
contenente il traffico di rete catturato;
• CaptureModel: crea il modello del pacchetto a partire dai dati ritornati
dai dissector, memorizza le istanze della classe Packet;
• Packet: associato ad un pacchetto contenuto nel file pcap si occupa di
creare la struttura per la memorizzazione dei dati contenuti nel frame;
• Tree: ogni pacchetto viene associato ad un albero che contiene fisicamente le informazioni prelevate dal file pcap;
• Node: rappresenta il nodo dell’albero e contiene una frazione del messaggio che è stato decodificato dal dissector, può quindi contenere anche informazioni relative al layer superiore, che verranno rappresentate
come i nodi figli;
• Filter e ProtocolFilter: implementano un filtro per estrarre solo alcuni
layer di interesse, scartando cosı̀ tutte le informazioni ai livelli più bassi.
Una volta eseguita l’estrazione dei dati e la creazione della struttura dati,
viene chiamato ricorsivamente il metodo printTree() su tutti gli elementi
dell’albero che va fisicamente a creare le varie regole sintattiche in ABNF.
188
Figura 3.22: Diagramma delle classi del Dissector
3.3
Utilizzo della piattaforma
Successivamente alla creazione del modello di protocollo ed alla assegnazione
delle varie azioni ai suoi nodi, il framework è pronto per eseguire i test
case sulla IUT selezionata, la procedura di test viene avviata richiamando il
metodo
Composite::runTest()
fornito dal nodo radice dell’albero ABNF che invoca iterativamente quello
dei figli e cosı̀ via, permettendo cosı̀ l’esplorazione dell’albero. Quindi durante questo procedimento, man mano che si passa da un nodo all’altro del
modello, viene eseguito anche l’algoritmo incapsulato dentro allo strategy
che va a creare la sequenza di messaggi validi per il protocollo rappresentato; infine l’esplorazione dell’albero genera un test case con il rispettivo file
3.3. Utilizzo della piattaforma
Figura 3.23: Diagramma di sequenza del Dissector
189
190
di output dove vengono registrate le azioni e le misurazioni effettuate. In
assenza di anomalie, la procedura di testing produrrà il traffico valido descritto dal modello, concludendo successivamente la procedura. In caso in
cui vi siano delle anomalie, l’approccio prevede che vengano eseguiti tanti
test case quante sono le possibili combinazioni di anomalie e di valori delle
stesse: infatti per eseguire correttamente la procedura di stress test e robustness test tramite fault injection, si deve andare a generare un grande volume
di traffico, valutando il comportamento della IUT sottoposta ad ogni possibile combinazione di guasti inseriti nel traffico protocollare. La generazione
dei vari test case a partire dal modello ABNF viene effettuata nel seguente
modo:
1. ogni punto di inserimento di un’anomalia viene identificato con un id
univoco (costituito da un intero a 64 bit con tutti i bit settati a zero
tranne uno)1 ;
2. viene associato all’id dell’anomalia il numero dei nodi figli, cioè il
numero dei valori anomali da poter inserire;
3. ogni test group è identificato da un id (intero a 64 bit) e da un numero
di ripetizioni, l’identificativo indica quali anomalie sono attivate e il
numero delle ripetizioni da eseguire viene generato dal prodotto dei
possibili valori delle anomalie attive;
4. per ogni id viene invocato il metodo runTest() un numero pari alle
ripetizioni;
5. alla fine di ogni test case viene prodotto l’albero di oggetti State che
viene passato alle classi Output per la registrazione dei log.
1
Questo limita il numero dei punti di inserimento a 64 all’interno di una test suite; è
comunque un limite accettabile visto l’elevato numero di test case prodotti
191
Possiamo identificare come una test suite l’intero numero dei test case
generati rappresentata dal modello ABNF e costituita da vari test group costituiti da un id a 64 bit che indica quali anomalie sono attivate e quindi quali
aspetti del protocollo verranno analizzati. Ogni test group è costituito da
vari test case generati dalla combinazione dei vari valori di anomalie inserite
nel modello ABNF per i punti di inserimento attivati.
Per capire quali anomalie vengono attivate per un determinato test group,
utilizziamo l’identificativo a 64 bit associato al gruppo. Infatti abbiamo visto
che ogni punto di inserimento di un guasto è associato ad un id univoco, anche
questo a 64 bit, caratterizzato da un unico bit settato ad 1: se l’operazione di
and bit a bit fra id anomalia e id del test group genera un risultato diverso da
0 allora l’anomalia è attivata per quel gruppo. Ad esempio se in un modello
abbiamo due punti di inserimento di guasti, questi verranno identificati da i
seguenti id (in questo esempio abbiamo usato una rappresentazion ad 8 bit):
1. 00000001
2. 00000010
ogni anomalia ha tre possibili valori, uno valido e gli altri due rappresentano
due guasti.
• il primo test group generato avrà un id uguale a 0, quindi nessuna
anomalia attivata: il modello verrà percorso soltanto una volta generando un traffico coerente con il protocollo che valida la correttezza del
modello stesso.
• Il secondo test group generato è identificato dall’id 1, eseguiamo l’operazione di and bit a bit fra 1 e l’id della prima anomalia che ritornerà un
valore pari ad 1 e quindi un numero diverso da zero attivando l’anomalia; eseguendo la stessa operazione sull’id della seconda anomalia il
192
risultato sarà 0 e quindi non verrà utilizzata. A questo punto il modello verrà percorso un numero di volte pari al valore delle anomalie
associate al primo punto di inserimento, in questo caso 2.
• il terzo test group avrà come id il numero 2, eseguendo l’operazione di
bit a bit con i due id di anomalie vedremo che la prima è disattivata
mentre la seconda risulterà attiva; quindi verranno generati due test
case dalle due possibili anomalie inserite nel secondo punto.
• il quarto test group verrà identificato dall’id 3, vediamo che l’operazione
di and bit a bit con gli id delle anomalie ritornerà per la prima 1 e per
la seconda 2, quindi entrambe saranno attive; in questo caso il modello
verrà percorso 4 volte, per introdurre qualsiasi combinazione di valori
anomali possibili.
Durante la procedura di testing, mano a mano che i vari test case vengono eseguiti, si deve tenere traccia di quali anomalie sono attive e quali valori sono stati utilizzati per creare i test case successivi e alla fine procedere
con la creazione dei test group mancanti. Per far questo è necessario utilizzare un sistema centralizzato per registrare le anomalie presenti nel modello
e mantenere ed aggiornare lo stato di quelle attive: abbiamo implementato secondo il pattern Singleton l’oggetto TestCaseManager (figura 3.24) in
modo da usufruire della stessa istanza dell’oggetto in più punti del codice
distinti. Abbiamo delegato all’oggetto la gestione degli id a 64 bit ed il calcolo di quanti test group devono essere generati e soprattutto di quanti test
case genererà un determinato test group. Nel modello ABNF l’inserimento
delle anomalie viene gestito dall’azione InjectAction che, però, non possiede
informazioni generali sul test case in esecuzione o su quante altre anomalie
sono presenti nel modello, quindi per coordinare le varie azioni si è fatto in
193
modo che ogni InjectAction quando viene inserita nel modello vada a registrare nel TestCaseManager per segnalare la propria presenza, andando poi
a prelevare il proprio id numerico; all’interno del TestCaseManager si tiene
traccia delle varie azioni e di quanti valori anomali sono fornite, in modo da
pilotare la creazione dei vari test group e garantendo un corretto e completo
svolgimento della procedura di testing.
Figura 3.24: Diagramma delle classi della componente di gestione dei test case
3.3.1
CLI: command line interface
Per utilizzare il framework ed avviare la procedura di testing, allo stato
attuale dei lavori, viene fornito un eseguibile invocabile da linea di comando
che richiede come input un file di testo contenente la descrizione ABNF del
protocollo, l’IP della IUT e la porta del servizio che implementa lo standard;
se ovviamente si deve analizzare un’implementazione a basso livello in tal
194
caso la porta non è necessaria e l’indirizzo IP viene utilizzato esclusivamente
per il collegamento ai monitor per l’analisi del comportamento (se abilitati).
stress -a FILENAME -d DESTINATION_ADDRESS -p PORT
--------------------------------------------------------------
--abnf=FILENAME
-a FILENAME
--destination IP
-d IP
--source IP
-s IP
--port PORT
-p PORT
--timeout N
-t N
Insert ABNF model file
Insert Destination IP Address
Insert Source IP Address
Insert Port Number
Wait n msec for reading
packets
--iface IFACE
-i IFACE
Network interface used for
RAW socket
--help
-h
Display this help
--output FILENAME -o FILENAME
--type
Insert output root filename
-O OUTPUT-TYPE xml, dot [default: xml]
--monitor -M Activate observing modules
--delay n -D n Delay n (msec) befare AND
after a test case
--inject -j MODE Activate anomalies
auto-injection.
3.4. Risultati
195
Il file ABNF deve essere creato in modo che la prima riga abbia come
simbolo la radice dell’albero, cosı̀ che il software possa andare a costruire a
partire dal questo simbolo tutta la struttura del modello. Le altre possibili
opzioni di configurazione prevedono:
• l’abilitazione dell’auto injector, che può essere utilizzata con modelli
ABNF contenenti la sola descrizione del protocollo senza alcun guasto;
• l’attivazione della componente di analisi del comportamento tramite
sensori esterni;
• la configurazione di alcuni ritardi da inserire prima e dopo l’avvio dei
test case, utili per permettere il corretto allineamento dei monitor in
presenza di ritardi sulla rete;
• la configurazione del percorso di scrittura dei file di output e la selezione
del formato degli stessi.
3.4
Risultati
In questo capitolo vengono presentati i vari test suites e i risultati che abbiamo prodotto, creati ed eseguiti utilizzando la piattaforma sviluppata. Gli
scopi principali dei test eseguiti sono:
1. Ricostruire il comportamento di sistemi chiusi, di cui non si conosce
il codice sorgente per poterne espandere la compatibilità (nel caso di
apparati di rete non si conosce il software di gestione memorizzato nelle
memorie flash).
2. Verificare che gli standard di funzionamento siano rispettati e correttamente implementati.
196
3. Recuperare informazioni sulla sicurezza delle implementazioni di applicativi e apparati di rete.
Abbiamo quindi selezionato protocolli differenti per poter valutare l’effettiva generalità della nostra piattaforma, i cinque standard scelti sono uno
basato su TCP, due basati su UDP e due a basso livello:
• IEEE-802.11b/g
• IEEE-802.11i
• XMPP
• SIP
• DNS
Per quanto riguarda la parte a basso livello, quindi gli standard di comunicazione e autenticazione in reti wireless l’approccio è stato utilizzato per
analizzare le fasi di:
• Autenticazione IEEE 802.11.
• 4 Way Handshake del WPA PSK di IEEE 802.11i.
• La prima parte dell’autenticazione EAP-TLS e la resistenza di freeRADIUS a stringhe anomale.
Il processo di testing ha portato alla luce varie incongruenze nel controllo di
alcune parti dei pacchetti, soprattutto gli indirizzi sorgente e destinazione,
errata gestione dei campi di lunghezza e interpretazione di dati fuori standard
[49]. Inoltre, fra i sistemi analizzati, era presente anche il software Hostapd
[50], che implementa funzionalità avanzate di Access Point ed Authenticator.
In questo sistema è stata riscontrata una grave problematica di robustezza
3.4. Risultati
197
che ha portato alla chiusura improvvisa del servizio per segmentation fault,
portando cosı̀ alla luce una vulnerabilità presente nella versione del software
presa in esame [51].
3.4.1
SIP
Il protocollo SIP è uno dei principali standard utilizzati per le comunicazioni voice over IP, si tratta di un protocollo di segnalazione per la gestione
delle chiamate [52]; ci siamo soffermati sull’analisi dell’implementazione di
questo standard fornita da differenti pacchetti software, nel dettaglio i sistemi
analizzati sono:
• Debian Etch con pacchetto Asterisk PBX fornito dalla distribuzione;
• AsteriskNow Beta 6 distribuzione fornita dalla stessa Digium, software
house produttrice di Asterisk;
• Debian Etch con pacchetto Yate PBX versione 1.2.0.
Le procedure del protocollo analizzate sono state l’interrogazione e la registrazione.
In fase di interrogazione il software asterisk si è dimostrato mancante di
molti controlli sulla correttezza dei messaggi inviati, rispondendo in maniera
errata o con codici di errore inesatti o addirittura restituendo l’acknowledge
come se il messaggio fosse stato correttamente interpretato.
In fase di registrazione la versione di asterisk fornita dalla distribuzione
Debian presenta un errore nella gestione di una richiesta con alcuni campi
mancanti che causa il fallimento del sistema per NULL ponter dereference
e quindi segmentation fault. Inoltre mancano i controlli sulla validità dei
restanti campi dei messaggi violando in più punti il protocollo o permettendo
198
operazioni teoricamente impossibili (per esempio la registrazioni di client con
indirizzi non validi come quello di broadcast).
Abbiamo potuto valutare una migliore gestione delle risposte ai messaggi
anomali nel sistema AsteriskNow dove la versione del PBX è più recente mentre nella versione fornita in Debian Etch è stato individuata una problematica
nella gestione dei guasti che causava il fallimento del sistema. Inoltre, grazie
alle caratteristiche di riusabilità delle test suite, è stato possibile eseguire
un confronto fra il comportamento del sistema Asterisk e il software Yate,
identificando nell’ultimo una maggiore attenzione agli standard al fronte di
minore controlli sulla validità sintattica del contenuto dei messaggi.
3.4.2
DNS
Il Domanin Name System (DNS) è il sistema di risoluzione dei nomi di dominio utilizzato su internet ed è un protocollo di tipo request-response [53].
Per l’attività di testing abbiamo scelto due implementazioni:
• BIND [54]: è uno dei programmi più utilizzati fra tutti i server DNS,
è open source e viene distribuito di default sulla maggior parte dei
sistemi UNIX e distribuzioni GNU/Linux. La versione presa in esame
è la 9.6.1-P2 per GNU/Linux.
• PowerDNS [55]: server DNS scritto in C++ distribuito con licenza
GPL; è un server che si appoggia a diversi backend, sia file in stile
BIND che database veri e propri. La versione presa in esame è la
2.9.22 per GNU/Linux con database MySQL come backend.
Non sono state rilevate problematiche di sicurezza, i due demoni si sono
rivelati robusti, come prevedibile visto la maturità dei progetti e del protocollo; nonostante questo l’attività di testing ci ha permesso di evidenziare
3.4. Risultati
199
un diverso comportamento delle due IUT: il software BIND risponde secondo standard ai messaggi non corretti, segnalando la presenza degli errori ed
indicando le motivazioni del rifiuto, invece PowerDNS solitamente non invia
alcuna risposta tranne che in tre casi:
1. Anomalia nel campo QNAME con valore %x00000000000000000;
2. Anomalia nel campo di lunghezza con valore nullo in presenza di una
label non vuota;
3. Anomalia generata inserendo una stringa successivamente al campo
QNAME;
in questi casi PowerDNS risponde con un messaggio senza segnalazione di
errori e con il campo Answer vuoto. Nello standard non viene specificato
se un server, in presenza di errori nelle richieste, debba o meno rispondere,
quindi possiamo dire che il differente modo di comportarsi è, in entrambi i
casi, attinente al protocollo; invece nelle tre precedenti eccezioni del software
PowerDNS vi è una chiara violazione dello standard poiché le risposte non
segnalano, come previsto, la presenza di guasti nei messaggi ricevuti.
3.4.3
XMPP
Protocollo creato per sistemi di messaggistica istantanea basato su XML per
la formattazione dei messaggi [56]. Per l’attività di testing abbiamo scelto
due implementazioni del protocollo:
• ejabber [57]: scritto in Erlang, distribuito sotto licenza GPL, è uno dei
server più popolari usati anche nei servizi di chat di Facebook e Nokia
Ovi; la versione analizzata è la 2.1.2.
200
• Openfire [58]: scritto in Java, distribuito sotto GPL, la versione presa
in esame è la 3.6.4.
Ci siamo soffermati ad analizzare prevalentemente la fase di autenticazione prevista dallo standard, che coinvolge alcune primitive come l’hash
MD5 e la codifica e decodifica base64.
L’implementazione dello standard di openfire risulta non essere conforme
ai requisiti di sicurezza previsti dalla specifica, infatti non vengono rifiutati
i messaggi contenenti caratteri non validi per la codifica base64 e l’analisi
del comportamento ci permette di capire che lo stato della FSM del software
è errato: infatti durante un autenticazione in chiaro il server risponde con
una challenge non prevista per questo tipo di autenticazione. Anche ejabber
non si dimostra attinente alle specifiche perché ignora semplicemente l’errore
senza andare a rifiutare esplicitamente l’autenticazione come previsto dal
RFC. Infine abbiamo rivelato comportamenti anomali nel software openfire
durante la sua esecuzione: vengono infatti sollevate alcune eccezioni non
gestite che solo il meccanismo di recupero tipico di Java permette al server
di non produrre un fallimento. Però la loro comparsa sono sintomi di errori
nel codice che non gestisce in modo corretto eventi particolari (sono quindi
guasti prodotti da errori), in un caso particolare il software chiude, in seguito
ad un messaggio anomalo, lo stream XML non andando però a chiudere la
connessione causando, alla ricezione del successivo pacchetto, un accesso a
risorse non più disponibili.
3.5. Sviluppi Futuri
3.5
201
Sviluppi Futuri
Il progetto oggetto di questo lavoro di tesi è attualmente in fase di sviluppo
con l’obbiettivo di agevolare il processo di testing e permetterne l’utilizzo
con la maggior generalità possibile: innanzitutto è stato identificato come
aspetto da approfondire l’interfaccia utente con cui utilizzare la piattaforma,
che verrà ampliata con una GUI attualmente in fase di beta testing, sviluppata utilizzando il framework per applicazioni web Ruby on Rails, fornirà
una soluzione per agevolare la creazione dei modelli ABNF, il loro storage
per usi futuri e la raccolta dei log delle test suite per permettere una più
approfondita analisi dei risultati successivamente all’effettiva esecuzione dei
test.
Inoltre verranno introdotte ulteriori primitive, alcune già implementate ed
utilizzate [49] ma da aggiornare e da mettere in produzione, altre da aggiungere completamente per permettere una assoluta generalità dei protocolli che
possono essere utilizzati con la piattaforma S.T.R.E.S.S. come ad esempio la
funzione hash SHA1 o una primitiva di checksum crittografico (MAC ).
Infine l’aspetto più importante ed innovativo attualmente in fase di ideazione
consiste in un sistema automatico per la funzionalità di oracolo che permetta
una valutazione dei singoli test case in modo da agevolare l’attività dell’utente. Il sistema di oracolo prende in input il risultato di un test case, quindi
i messaggi inviati e ricevuti, le anomalie inserite e i valori rilevati dai monitor
delle IUT; come output ritorna la probabilità che tale test case possa aver
evidenziato un comportamento anomalo nel sistema in analisi. Sono state
identificati due approcci distinti:
• viene considerato tutto lo scambio dei pacchetti e quindi una valutazione unica per ogni test case;
202
• per ogni log vengono estratte le informazioni associate al singolo scambio di pacchetti, ogni test case verrà quindi valutato più volte per ciascuna trasmissione indipendentemente dagli esiti precedenti (per esempio nel caso dello scambio di frame nel modello POP3, il test case avrà
cinque valutazioni in base al comportamento della IUT alla ricezione
e risposta del primo pacchetto di login, al secondo pacchetto di invio
password, e cosı̀ via).
Per ciascuno di questi approcci è stato valutato un sistema di classificazione
automatica distinto: nel primo caso, deve essere valutato il comportamento
nel caso di una sequenza di eventi, dove ogni singolo evento è rappresentato
dalle misurazioni dei monitor e dalla presenza di eventuali anomalie, è stato
quindi scelto un approccio basato sul Hidden Markov Model [59]. Si tratta di una catena di Markov dove gli stati non sono osservabili direttamente
ma soltanto l’evento generato: questo tipo di modello permette, data una
sequenza, di trovare lo stato più probabile per cui si possa avere tale serie
di eventi in uscita. Un tipo di approccio che prevede una fase preliminare di
addestramento dei coefficienti della catena di Markov mediante un training
set di log di test case ed una successiva analisi dei risultati delle singole run.
Questo approccio presuppone di individuare un’anomalia nella sequenza di
passi della macchina a stati interna che potrebbe essere deviata dal suo funzionamento corretto a causa delle anomalie inserite.
Nel secondo approccio sono da analizzare i singoli eventi raggruppati per
successione temporale, cioè il primo scambio di pacchetti verrà valutato e
confrontato con le misurazioni di tutti gli altri pacchetti scambiati inizialmente e cosı̀ via. Vista la granularità degli eventi, è stata selezionato un
approccio di classificazione basato su Support Vector Machines [60]: classificatori binari in grado di gestire in modo efficiente osservazioni caratterizzate
3.5. Sviluppi Futuri
203
da un alto numero di misurazioni e modelli estremamente complessi tramite
superfici decisionali non lineari. In questo caso invece, si semplifica l’analisi immaginando che un’anomalia influenzi in modo riconoscibile non solo
la sequenza, ma anche il risultato dell’elaborazione di un singolo pacchetto
ricevuto dalla IUT.
204
Conclusioni
Durante la prima parte del dottorato, l’attività è stata svolta all’interno del
laboratorio di Comunicazioni Avanzate congiunto fra l’Università di Firenze
e Selex-Comms ed ha portato alla creazione di un metodo di auto configurazione di una rete multi hop costituita da router wireless multi interfaccia. La procedura per il deployment facilitato della rete permette di ridurre
le interferenze elettromagnetiche andando ad utilizzare i canali di comunicazioni più liberi e adottando collegamenti singoli fra due nodi per ridurre
al minimo problemi di collisione e massimizzare il throughput. Le simulazioni hanno validato il nostro approccio, evidenziando che soltanto in casi
estremi non pertinenti all’uso reale, con un numero di nodi molto alto e con
una dislocazione casuale si ha un fallimento nella creazione della rete. Successivamente è stato sviluppato un prototipo di software per implementare
tale metodologia e la macchina a stati per gestire le ricostruzioni della rete
in caso di fallimento di alcune connessioni. Il programma è stato integrato con il sistema operativo linux embedded dei router wireless ed è stato
installato su di una rete di 6 router. Si è quindi potuto eseguire un vero
e proprio collaudo del sistema che ha dimostrato la validità del prototipo:
la rete veniva configurata completamente e diveniva operativa in un tempo
massimo di 10 minuti, circa 2 minuti per nodo escluso il gateway. I prototipi erano dotati di batteria, circuiti di alimentazione ed antenne in grado
205
206
Conclusioni
di essere trasportati facilmente tramite valigie. Andando quindi a simulare
una situazione di emergenza si è stati in grado di installare una backbone di
comunicazione operativa in pochi minuti. Questa prima parte del lavoro ha
portato, oltre alla creazione di un prototipo funzionante, alla pubblicazione
di un brevetto. La seconda parte della collaborazione ha visto l’integrazione
del sistema di comunicazione Tetra-DMO con la backbone wireless multi hop;
il lavoro ha visto una prima parte di studio per la creazione del nodo mobile,
la macchina a stati ed il protocollo di comunicazione TWNET, inoltre è stato
necessario estendere lo standard di comunicazione PEI dei terminali Tetra.
Successivamente sono state implementate le necessarie modifiche al firmware
ed al software dei terminali utilizzati nel nodo mobile e soprattutto è stato
sviluppato il software pe2ne, che implementava la macchina a stati che permetteva la comunicazione dei vari MN sulla backbone multi hop tramite il
protocollo da noi ideato. Infine il software è stato integrato nella toolchain
del sistema operativo linux dei router wireless (OpenWRT) ed è stato creato
un prototipo della rete che ci ha permesso di testare il nostro lavoro, sia di
design del sistema che dell’implementazione. Il progetto TWNET ha, inoltre,
portato alla stesura di 4 brevetti [16] [17] [18] [19] che attualmente risultano
ancora o in fase di scrittura o in valutazione, comunque non sono ancora
stati pubblicati ed è il motivo per cui non sono stati affrontati in maniera
dettagliata certi aspetti del lavoro.
Il secondo filone di ricerca su cui si è incentrato il lavoro ha portato alla
creazione di una metodologia di testing funzionale per la robustezza del software che potesse essere applicata alla totalità degli standard che attualmente
vengono utilizzati per le comunicazioni di rete. Inoltre è stato prodotto un
framework per l’attuazione di tale approccio nel processo di testing in grado
sia di automatizzare la creazione dei test case e l’inserimento di anomalie, sia
207
di eseguire un’analisi del comportamento delle implementazioni analizzate.
Si è da prima analizzato lo stato dell’arte delle varie tecnologie di testing
funzionale, con particolare attenzione al testing di sicurezza e quindi alle diverse tecniche mirate a rilevare le vulnerabilità, ovvero gli errori che possano
essere sfruttati da un attaccante per la compromissione di un sistema. Sono
stati individuati come approcci più utili per il testing di robustezza il fuzzing
ed il syntax testing eseguito tramite fault injection: l’idea di base è quella di
inviare come input dei dati non corretti per valutare il comportamento della
componente software in reazione a questi eventi non previsti e valutare se
possono essere presenti errori nel codice. Per poter trasmettere informazioni
secondo un determinato protocollo è necessario definirne il linguaggio in modo da permettere alla piattaforma di inviare pacchetti che possano essere
accettati dal software. Per descrivere gli standard è stato scelto il metalinguaggio ABNF, definito dalla IETF proprio per la descrizione dei protocolli
di rete. Successivamente è stato sviluppato il framework in modo da poter
applicare la metodologia precedentemente identificata ed in grado di interpretare le regole sintattiche descritte all’interno di una definizione ABNF per
poter riprodurre correttamente pacchetti di un certo protocollo. Si è fatta
particolare attenzione alla modularità della piattaforma per garantire una
facile espandibilità al fine di aggiungere nuove primitive da utilizzare nella
creazione dei dati da inviare o delle informazioni da interpretare. Inoltre è
stata creata una componente che permettesse, data una definizione ABNF,
l’introduzione automatica di anomalie secondo alcune euristiche di attacco, e
quindi permettere una facile aggiunta di ulteriori metodi di inserimento automatico di guasti. Infine si è prodotta una parte del framework specifica per
l’analisi del comportamento delle IUT, in modo da poter agevolare l’attività
di oracolo per l’identificazione di quali test case risultino passati o falliti o
208
Conclusioni
inconcludenti. Successivamente la piattaforma è stata utilizzata per l’analisi di implementazioni dei protocolli IEEE 802.11b/g/i, DNS, SIP e XMPP,
per valutarne la robustezza e la loro conformità alle specifiche. I processi di
testing sono stati in grado di rilevare che alcune IUT considerate non risultavano conformi al protocollo di riferimento ed inoltre si sono rivelate carenti
per quanto riguarda la validazione degli input presentando problematiche
che possono venir sfruttate per attacchi. I risultati di questi test hanno
inoltre validato la metodologia e l’efficacia della piattaforma S.T.R.E.S.S.
prodotti dall’attività di ricerca svolta durante questo dottorato. Inoltre sono
stati individuati alcune caratteristiche da approfondire e da sviluppare al fine
di aumentare la generalità del framework ed il livello di automazione della
procedura di test, questi aspetti sono stati presentati precedentemente nel
capitolo 3.5.
Appendices
209
rulelist
=
1*( rule / (*c-wsp c-nl) )
rule
=
rulename defined-as elements c-nl
; continues if next line starts
;
with white space
rulename
=
ALPHA *(ALPHA / DIGIT / "-")
defined-as
=
*c-wsp ("=" / "=/") *c-wsp
; basic rules definition and
;
incremental alternatives
elements
=
alternation *c-wsp
c-wsp
=
WSP / (c-nl WSP)
c-nl
=
comment / CRLF
; comment or newline
comment
=
";" *(WSP / VCHAR) CRLF
alternation
=
concatenation
*(*c-wsp "/" *c-wsp concatenation)
concatenation
=
repetition *(1*c-wsp repetition)
repetition
=
[repeat] element
repeat
=
1*DIGIT / (*DIGIT "*" *DIGIT)
element
=
rulename / group / option /
char-val / num-val / prose-val
211
212
group
=
"(" *c-wsp alternation *c-wsp ")"
option
=
"[" *c-wsp alternation *c-wsp "]"
char-val
=
DQUOTE *(%x20-21 / %x23-7E) DQUOTE
; quoted string of SP and VCHAR
;
without DQUOTE
num-val
=
"%" (bin-val / dec-val / hex-val)
bin-val
=
"b" 1*BIT
[ 1*("." 1*BIT) / ("-" 1*BIT) ]
; series of concatenated bit values
;
dec-val
=
or single ONEOF range
"d" 1*DIGIT
[ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
hex-val
=
"x" 1*HEXDIG
[ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
prose-val
=
"<" *(%x20-3D / %x3F-7E) ">"
; bracketed string of SP and VCHAR
;
without angles
; prose description, to be used as
;
last resort
ALPHA
=
%x41-5A / %x61-7A
BIT
=
"0" / "1"
CHAR
=
%x01-7F
; A-Z / a-z
; any 7-bit US-ASCII character,
;
CR
=
excluding NUL
%x0D
; carriage return
CRLF
=
CR LF
213
; Internet standard newline
CTL
=
%x00-1F / %x7F
; controls
DIGIT
=
%x30-39
; 0-9
DQUOTE
=
%x22
; " (Double Quote)
HEXDIG
=
DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB
=
%x09
; horizontal tab
LF
=
%x0A
; linefeed
LWSP
=
*(WSP / CRLF WSP)
; Use of this linear-white-space rule
;
permits lines containing only white
;
space that are no longer legal in
;
mail headers and have caused
;
interoperability problems in other
;
contexts.
; Do not use when defining mail
OCTET
=
;
headers and use with caution in
;
other contexts.
%x00-FF
; 8 bits of data
SP
=
%x20
VCHAR
=
%x21-7E
; visible (printing) characters
214
WSP
=
SP / HTAB
; white space
Bibliografia
[1] Openwrt: a linux distribution for embedded devices. [Online]. Available:
http://openwrt.org
[2] S. Leffler. Madwifi, multiband atheros driver for wifi. [Online].
Available: http://madwifi.org
[3] A. Raniwala, K. Gopalan, and T. Chiueh, “Centralized channel assignment and routing algorithms for multi-channel wireless mesh networks.
ACM SIGMOBILE Mobile Comput,” Commun. Rev, vol. 8, pp. 50–65,
2004.
[4] R. Draves, J. Padhye, and B. Zill, “Routing in multi-radio, multi-hop
wireless mesh networks,” in Proceedings of the 10th annual international
conference on Mobile computing and networking. ACM, 2004, pp. 114–
128.
[5] H. Wu, F. Yang, K. Tan, J. Chen, Q. Zhang, and Z. Zhang, “Distributed
channel assignment and routing in multiradio multichannel multihop
wireless networks,” IEEE journal on selected areas in communications,
vol. 24, no. 11, 2006.
[6] Institute of Electrical and Electronic Engineers, Inc., IEEE Standard
for Information technology – Telecommunications and information ex215
216
BIBLIOGRAFIA
change between systems – Local and metropolitan area networks-Specific
requirements – Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications, IEEE Std., 2007.
[7] ETSI, METTERE LO STANDARD TETRA, ETSI Std., 200X.
[8] ——, Terrestrial Trunked Radio (TETRA); Direct Mode Operation
(DMO), ETSI Std. EN 300 396, ETSI Std., 2006.
[9] “Modified ad-hoc on-demand distance-vector routing protocol,” Italy
EPO Patent Request PCT/IT/2008/000359 000 359, 2008.
[10] ETSI, Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D);
Part 5: Mobile station to mobile station (MS-MS) air interface (AI)
protocol, European Standard EN 300 392-5 Std., 2006.
[11] C. Ltd. Ubuntu. [Online]. Available: http://www.ubuntu.com
[12] ETSI TS 100 392-3-8, Terrestrial Trunked Radio (TETRA); Voice plus
Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI);
Sub-part 8: Generic Speech Format Implementation, ETSI Std.
[13] L. Zhang, L. Zheng, and K. Soo Ngee, “Effect of delay and delay jitter
on voice/video over ip,” Computer Communications, vol. 25(9), pp. 863–
873, 2002.
[14] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns,
P. E. Italia, Ed. Addison-Wesley, 1995.
[15] L. Adamo, R. Fantacci, M. Rosi, D. Tarchi, and F. Frosali, “Analysis
and design of a tetra-dmo and ieee 802.11 integrated network,”
in Proceedings of the 6th International Wireless Communications
BIBLIOGRAFIA
and Mobile Computing Conference, ser. IWCMC ’10.
217
New York,
NY, USA: ACM, 2010, pp. 774–778. [Online]. Available:
http:
//doi.acm.org/10.1145/1815396.1815574
[16] “Nodo twnet,” Europe Patent Request -, 2011.
[17] “Trasmissione su seriale del traffico tetra dmo,” Europe Patent Request
-, 2011.
[18] “Estensione delle funzionalità changeover e preemption tipiche dello
standard dmo allo scenario multi isola twnet,” Europe Patent Request
-, 2011.
[19] “Soluzione di sicurezza per la negoziazione di chiavi crittografiche per
applicazioni tetra dmo su reti etorgenee,” Europe Patent Request -,
2011.
[20] B. Beizer, Software Testing Techniques. Second Edition. Van Nostrand
Reinhold., 1990.
[21] C. C. Michael, Black box security testing tools. Tech. Rep., 2005.
[22] Institute of Electrical and Electronic Engineers, Inc., standard glossary
of software engineering terminology, IEEE Std., 1990.
[23] I. Sommerville, Software Engineering. Addison-Wesley, 2007.
[24] ISO/IEC, Conformance testing methodology and framework, International Organization for Standardization, Geneva, Switzerland., Tech.
Rep., International Standard IS-9646 Std., 1991.
[25] ITU, OSI Conformance Testing Methodology and Framework for Protocol Recommendations for ITU-T Applications - General Concepts,
218
BIBLIOGRAFIA
INTERNATIONAL TELECOMMUNICATION UNION, Tech. Rep.,
ITU-T Recomendation X.290 Std., 1995.
[26] J. Tretmans, “An overview of osi conformance testing,” University of
Twente, Tech. Rep., 2001. [Online]. Available: http://www.cs.aau.dk/
∼kgl/TOV03/iso9646.pdf
[27] ETSI, Methods for Testing and Specifcation (MTS); Protocol and profle
conformance testing specifcations; Standardization methodology, European Telecommunications Standards Institute, Tech. Rep., ETS 300 406
Std., 1995.
[28] B. Schneier,
“Software complexity and security,”
Crypto-Gram
Newsletter, 2000.
[29] R. Kaksonen, “A functional method for assessing protocol implementation security,” Technical Research Centre of Finland, VTT
Publications 447. 128 p., Tech. Rep., 2001. [Online]. Available:
http://www.vtt.fi/inf/pdf/publications/2001/P448.pdf
[30] B. P. Miller, L. Fredriksen, and B. So, “An empirical study of the reliability of unix utilities,” In Proceedings of the Workshop of Parallel and
Distributed Debugging, pp. ix–xxi, 1990.
[31] R. Kaksonen, M. Laakso, and A. Takanen, “Vulnerability analysis of
software through syntax testing,” Tech. Rep., 2000. [Online]. Available:
https://www.ee.oulu.fi/research/ouspg/PROTOSWP2000-robustness
[32] G. Ausiello, F. d’Amore, and G. Gambosi, Linguaggi, Modelli,
Complessità. Franco Angeli, 2003.
BIBLIOGRAFIA
219
[33] G. Hoglund and G. McGraw,
Break Code.
Addison-Wesley,
Exploiting Software:
How to
2004. [Online]. Available:
http:
//catdir.loc.gov/catdir/toc/ecip0411/2003025556.html
[34] P. Ammann and J. Offutt, Introduction to Software Testing. New York,
NY, USA: Cambridge University Press, 2008.
[35] C. Wieser, M. Laakso, and H. Schulzrinne, “Security testing of sip
implementations,” Tech. Rep., 2003.
[36] A. Helin, J. Viide, M. Laakso, and J. Roning, “Model inference
guided random testing of programs with complex input domains,”
https://www.ee.oulu.fi/research/ouspg/genome?action=AttachFile&do=view&target=Gen
2006.
[37] M. Sutton, A. Greene, and P. Amini, Fuzzing: Brute Force Vulnerability
Discovery. Addison-Wesley Professional, 2007.
[38] Immunity. Spike. [Online]. Available: www.immunitysec.com
[39] D. Aitel, “The advantages of block-based protocol analysis for security
testing,” Tech. Rep., 2002.
[40] J. DeMott. Gpf:
General purpose fuzzer. [Online]. Available:
http://www.vdalabs.com
[41] M. Vuagnoux, “Autodafé: an act of software torture,” 2005. [Online].
Available: http://infoscience.epfl.ch/record/140525
[42] E. J. Chikofsky and J. H. C. II, Reverse engineering and design recovery:
A taxonomy. IEEE Software, 1990, vol. 7.
220
BIBLIOGRAFIA
[43] D. H. Crocker and P. Overell, “Augmented bnf for syntax specifications:
Abnf,” RFC 2234, 1997.
[44] Post Office Protocol - Version 3, IETF RFC 1939 (also STD0053), May
1996. [Online]. Available: http://www.rfc-editor.org/rfc/rfc1939.txt
[45] Institute of Electrical and Electronic Engineers, Inc., Wireless
LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications, IEEE Std., 2004.
[46] Gnu/bison. [Online]. Available: http://www.gnu.org/software/bison/
[47] Flex: Fast lexical analyzer. [Online]. Available: http://flex.sourceforge.
net/
[48] Wireshark. [Online]. Available: http://www.wireshark.org/
[49] M. Rosi, L. Maccari, and R. Fantacci, “S.t.r.e.s.s. : Stress testing and
reverse engineering for system security,” in ICC, 2007, pp. 1429–1434.
[50] J. Malinen. hostapd: Ieee 802.11 ap, ieee 802.1x/wpa/wpa2/eap/radius
authenticator. [Online]. Available: http://hostap.epitest.fi/hostapd
[51] M. Rosi and L. Maccari. [security] [dsa 1065-1] new hostapd packages
fix denial of service. [Online]. Available:
http://lists.debian.org/
debian-security-announce/2006/msg00150.html
[52] RFC 3261 - SIP: Session Initiation Protocol, IETF Std., 2002.
[53] RFC 1035 - Domain names - implementation and specification, IETF
Std., 1987.
[54] Bind:
Berkley internet name domain. [Online]. Available:
//www.isc.org/software/bind
http:
BIBLIOGRAFIA
221
[55] Powerdns. [Online]. Available: http://www.powerdns.com
[56] RFC 3920 - Extensible Messaging and Presence Protocol (XMPP): Core,
IETF Std., 2004.
[57] Erlang jabber daemon. [Online]. Available: http://www.process-one.
net/en/ejabberd/
[58] J. Software. Openfire. [Online]. Available: http://www.igniterealtime.
org/projects/openfire/index.jsp
[59] L. Rabiner, “A tutorial on hidden Markov models and selected applications in speech recognition,” Proceedings of the IEEE, vol. 77, no. 2, pp.
257–286, 1989.
[60] C. Cortes and V. Vapnik, “Support-vector networks,” Machine learning,
vol. 20, no. 3, pp. 273–297, 1995.

Metodologie di autocongurazione,integrazione e testing di sistemi in

Transcript

Documenti analoghi

Scarica la scheda tecnica

CONVENZIONE SERVIZIO TELEFONIA MOBILE - Intercent-ER

La Centrale Operativa Mobile per il controllo del territorio

tetra pak bootcamp 2016

lingue

tetra pak bootcamp 2016 - Servizi per la didattica

Untitled - DM Orthotics ltd

Hytera PT580H Plus - Radio portatili TETRA

COMUNICATO STAMPA Finmeccanica: contratto Tetra PIT con il

TMR880i RADIO VEICOLARE TETRA