labtel.diet.uniroma1.itlabtel.diet.uniroma1.it/tesi/vi/TesiIelapi.pdf · SOMMARIO S copo principale...

Valerio Ielapi

S A P I E N F E D : U N A P K I T R A P R O V I D E RV O I P E S T E N S I B I L E A G L I E N D - S Y S T E M

Maggio 2008UNIVERSIT DI ROMA LA SAPIENZA

UNIVERSIT DI ROMA LA SAPIENZA

FACOLT DI INGEGNERIA

Corso di Laurea inINGEGNERIA DELLE TELECOMUNICAZIONI

TESI DI LAUREA MAGISTRALEMaggio 2008

S A P I E N F E D : U N A P K I T R A P R O V I D E RV O I P E S T E N S I B I L E A G L I E N D - S Y S T E M

CandidatoValerio Ielapi

Relatore Co-relatoreChiar.mo Prof. Marco Listanti Prof. Alessandro Falaschi

ANNO ACCADEMICO 2006/2007

Graphics

The seal on title page is copyrighted by the University ofRoma LA SAPIENZA

First printing, May 2008Copyright 2008 by V. Ielapi

Permission is granted to make and distribute verbatim copies of thisbook provided the copyright notice and this permission notice are pre-served on all copies. Permission is granted to copy and distribute trans-lations of this book into another language, from the original Italian,with respect to the conditions on distribution of modified versions,provided that it has been approved by V. Ielapi.

For informations please contact: Valerio Ielapi, via Tommaso Smith 16,00159 Roma RM, Italy.

Printed and bound in Italy

. Authors email: [email protected]

mailto:[email protected]

A Mio Padre, Mia Madre,Ivano, ed Emiliano

S O M M A R I O

Scopo principale di questo lavoro di tesi quello di mostrare co-me limplementazione di uninfrastruttura a chiave pubblica pos-sa limitare gli effetti dello Spam over Internet Telephony (SPIT)sugli utenti di VoIP provider utilizzanti la segnalazione SIP, sfruttandoil concetto di federazione definito dallo SPEERMINT Working Groupdi IETF.

Linfrastruttura a chiave pubblica pu infatti essere utilizzata per rila-sciare dei certificati digitali ai membri di una federazione di VoIP provi-der, la cui unica regola della policy quella di utilizzare connessioniTLS presentando il suddetto certificato, ed instaurando cos delle re-lazioni di peering diretto, on-demand, basato sulla federazione. In questamaniera non possibile segnalare al destinatario della chiamata sequesta sicuramente SPIT, ma possibile segnalare se il dominio am-ministrativo di provenienza della chiamata sicuramente fidato. Que-sto fattibile sfruttando lintestazione SIP Alert-Info, che, ricevuta dauno user agent, pu abilitare in esso una modalit di squillo telefoni-co speciale, indicante allutente lassoluta sicurezza della chiamata inarrivo.

Questa tesi studia limplementazione di questo tipo di soluzionesul VoIP provider SapienTel, appartenente allUniversit di Roma LaSapienza, interessandosi dellarchitettura SIP dellInternet Telephonyservice provider in questione, della realizzazione della federazione Sa-pienFed a cui esso appartiene, e dellinfrastruttura a chiave pubblica adessa associata.

v

Sar necessaria quella determinazione che le persone sanno dimostrarequando danno valore alla propria libert e non permettono a nessuno disottrargliela.

Richard M. Stallman

R I N G R A Z I A M E N T I

Desidero ringraziare in primo luogo il Relatore di questa tesi, ilProfessor Marco Listanti: il prezioso aiuto fornito, la sua alta profes-sionalit ed esperienza, unite alla sua gentilezza e disponibilit, sonostati indispensabili per la riuscita del mio lavoro di ricerca. Un ringra-ziamento particolare va al Professor Alessandro Falaschi per il suosupporto ed i suoi consigli spesso illuminanti, per la sua illimitatapazienza e per aver sempre saputo fugare ogni mio dubbio, ed infineper avermi aperto lesaltante mondo del sistema GNU/Linux e delsoftware libero.

Ringrazio il mio amico Daniele V. per la sua grande disponibi-lit, per la sua grande pazienza, per il suo grande aiuto, sempredisinteressato, e per i suoi tanti consigli, spesso provvidenziali.

Ringrazio i miei grandi amici Marco D. G. e Massimiliano B. perogni singolo minuto di studio condiviso con loro, e per ogni momentodi vicendevole supporto nei periodi pi sconfortanti del mio percorsodi studi.

Ringrazio Giuseppe P. per la sua amicizia, il suo sostegno, e le suecritiche, sempre costruttive.

Ringrazio tutti i miei cari amici per il notevole supporto e limmen-sa allegria che mi hanno sempre trasmesso, su tutti Michele N., Fran-cesco P., Daniele C., Francesco R., Marco G., Emanuele B., GiordanoV., e Davide C.

Intendo inoltre ringraziare tutti i giocatori, il mister, e lo staff tec-nico della Leonina Sport per avermi subito accolto tra loro come unamico, per avermi ridato lemozione che solo in un campo di pallonesi pu provare, e per avermi sopportato in questanno per me moltoduro.

Infine un ringraziamento speciale alle due persone pi importantidella mia vita, mia madre e mio fratello. La prima per il suo straordi-nario affetto, simbolo per me dellamore perfetto ed incondizionatoa cui tendere, ed esempio di vita e di impegno nel lavoro, anche sespesso faticoso e stancante, senza mai lamentela alcuna. Il secondoper il suo aiuto costante ed il continuo supporto, per la sua presenza,e per il suo sorriso, sempre sincero e mai forzato.

Roma, maggio 2008 V. I.

vi

I N D I C E

i presentazione del lavoro 11 introduzione 2

ii il problema e la soluzione 52 il problema 6

2.1 La Tecnologia Voice over Internet Protocol 62.1.1 Cos? 62.1.2 Principali Vantaggi 82.1.3 Problemi 92.1.4 Protocolli 10

2.2 Il Session Initiation Protocol 112.2.1 Descrizione 112.2.2 I Messaggi 132.2.3 Architettura di Rete 17

2.3 Il Peering 192.3.1 Peering di Strato 3 192.3.2 Peering di Strato 5 19

2.4 Perch abbiamo bisogno del Peering SIP? 213 la soluzione 23

3.1 LAutenticazione 233.1.1 LAutenticazione nelle Comunicazioni SIP 25

3.2 Il Session PEERing for Multimedia INTerconnectWorking Group 273.2.1 I Draft 28

3.3 Le Federazioni 303.3.1 Esempi 313.3.2 Il Peering basato sulla Federazione 333.3.3 La Policy della Nostra Federazione 40

3.4 La Public Key Infrastructure 413.4.1 La Crittografia a Chiave Pubblica 413.4.2 Cos una PKI? 463.4.3 Da cosa composta? 473.4.4 Certificate Authority e Registration Authority 48

3.5 Il Protocollo Transport Layer Security 543.5.1 Descrizione 543.5.2 Il TLS Record Protocol 553.5.3 Il TLS Handshake Protocol 573.5.4 Utilizzi 61

3.6 Formalizzazione della Soluzione 62

vii

Indice viii

iii gli strumenti e lo svolgimento 644 gli strumenti open source 65

4.1 Il Software Open Source 654.1.1 Le Licenze dUso 674.1.2 I Vantaggi 67

4.2 La Distribuzione GNU/Linux Ubuntu 694.2.1 Le Caratteristiche Principali 69

4.3 Il SIP Server OpenSER 724.3.1 LArchitettura 724.3.2 LImplementazione del TLS in OpenSER 764.3.3 Il Peering On-Demand con Openser 79

4.4 La PKI OpenCA 814.4.1 Funzionamento Generale 83

4.5 Lo User Agent Twinkle 855 larchitettura 88

5.1 SapienTel 885.1.1 Gli Elementi dellArchitettura 89

5.2 Il SIP Proxy smile.ing.uniroma1.it 915.3 Il Gateway comel.ing.uniroma1.it 935.4 La PKI di SapienFed 95

6 la realizzazione 976.1 Implementazione del Gateway comel.ing.uniroma1.it 97

6.1.1 Installazione di OpenSER 976.1.2 Configurazione del File openser.cfg 986.1.3 Creazione e Popolazione del Database Locale 1056.1.4 Configurazione del DNS 107

6.2 Modifica del Proxy smile.ing.uniroma1.it 1076.3 I VoIP Provider con IP Dinamico 1096.4 Implementazione della PKI 110

6.4.1 Installazione di OpenCA 1106.4.2 Configurazione del Web Server Apache 1126.4.3 Inizializzazione della Certificate Authority 1136.4.4 Richiesta di un Nuovo Certificato 1146.4.5 Accesso alla Registration Authority 1156.4.6 Emissione, Recupero, e Revoca di un Certifica-

to 1166.5 Configurazione degli User Agent 117

iv argomentazioni conclusive 121

v appendici 125a le licenze open source 126

a.1 Gnu General Public License 126a.1.1 Terms and Conditions 127

a.2 Berkeley Software Distribution 138

indice ix

b i file di configurazione di openser 140b.1 comel.ing.uniroma1.it 140b.2 smile.ing.uniroma1.it 145b.3 Il File Bash verifica_certificato 154

vi materiale finale 156bibliografia 157

E L E N C O D E L L E F I G U R E

Figura 1 Elementi terminali coinvolti nelle comunicazio-ni VoIP. 7

Figura 2 Esempio di messaggio SIP (INVITE). 15Figura 3 Flusso di messaggi in una comunicazione SIP. 17Figura 4 Trapezoide SIP. 19Figura 5 Esempio di peering diretto. 20Figura 6 Esempio di peering indiretto. 20Figura 7 Esempio di autenticazione. 24Figura 8 Registrazione tramite Digest Authentication. 26Figura 9 Chiamata con Digest Authentication. 27Figura 10 Appartenenza alle federazioni. 31Figura 11 Flusso di messaggi di base in una relazione di

peering. 34Figura 12 Peering diretto (statico e on-demand). 36Figura 13 Corrispondenza di federazione semplice. 39Figura 14 Nessuna corrispondenza di federazione. 40Figura 15 Federazione con Certificate Authority. 40Figura 16 Cifratura a chiave pubblica. 41Figura 17 Autenticazione a chiave pubblica. 42Figura 18 Linfrastruttura a chiave pubblica 47Figura 19 Formato del certificato X.509. 52Figura 20 Esempio di certificato X.509. 53Figura 21 Posizionamento del TLS nella pila protocolla-

re. 55Figura 22 Sequenza delle trasformazioni TLS. 57Figura 23 Formato del Record Protocol. 58Figura 24 Payload del Record Protocol. 58Figura 25 TLS Handshake completo. 61Figura 26 Le interfacce di OpenCA. 84Figura 27 Esempio di interfaccia OpenCA. 85Figura 28 Il softphone Twinkle. 86Figura 29 La vecchia architettura SapienTel. 89Figura 30 Richiesta di un utente di ing.uniroma1.it per

un diverso dominio amministrativo. 92Figura 31 Richiesta per ing.uniroma1.it ricevuta da un

diverso dominio amministrativo. 92Figura 32 Richiesta per un utente di ing.uniroma1.it ri-

cevuta da un utente dello stesso dominio. 93

x

Elenco delle figure xi

Figura 33 Richiesta da parte di un utente di ing.uniroma1.itverso un utente di un altro dominio appartenen-te a SapienFed. 94

Figura 34 Richiesta verso un utente di ing.uniroma1.itproveniente da un utente di un altro dominioappartenente a SapienFed. 94

Figura 35 La nuova architettura SapienTel. 96Figura 36 Linterfaccia grafica di MySQL Query Browser. 106Figura 37 Configurazione della SIP URI Twinkle. 118Figura 38 Configurazione SIP server di Twinkle. 118Figura 39 Configurazione Scripts di Twinkle. 119Figura 40 Interfaccia grafica di Twinkle. 120

A C R O N I M I

3DES Triple Data Encryption Standard

ACK ACKnowledgment

ADSL Asymmetric Digital Subscriber Line

AoR Address of Record

ASN1 Abstract Syntax Notation One

ATA Analog Telephone Adapter

BGP Border Gateway Protocol

CA Certificate Authority

CBC Cipher Block Chaining

CPS Certificate Practice Statement

CRL Certificate Revocation List

DB2 IBM DataBase 2

DBMS DataBase Management System

DER Distinguished Encoding Rules

DES Data Encryption Standard

DN Distinguished Name

DoS Denial of Service

DSA Digital Signature Algorithm

DTMF Dual-Tone Multi-Frequency

ENUM tElephone NUmber Mapping

FIPS Federal Information Processing Standards

FTP File Transfer Protocol

HMAC keyed-Hash Message Authentication Code

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol over Secure SocketLayer

xii

Acronimi xiii

IANA Internet Assigned Numbers Authority

IAX Inter Asterisk eXchange

IDEA International Data Encryption Algorithm

IEEE Institute of Electrical and Electronics Engineers

ICMP Internet Control Message Protocol

ICT Information and Communication Technology

IETF Internet Engineering Task Force

IMAP Internet Message Access Protocol

IMS IP Multimedia Subsystem

IP Internet Protocol

IRC Internet Relay Chat

ISO International Organization for Standardization

ITSP Internet Telephony Service Provider

ITU International Telecommunication Union

MAC Message Authentication Code

MCD Massimo Comun Divisore

MD5 Message-Digest algorithm 5

MIT Massachusetts Institute of Technology

NAPTR Naming Authority PoinTeR record

NAT Network Address Translation

NGN Next Generation Network

NIST National Institute of Standards and Technology

NNTP Network News Transfer Protocol

NSS Network Security Services

OCSP Online Certificate Status Protocol

ODBC Open DataBase Connectivity

PEM Privacy Enhanced Mail

PIN Personal Identification Number

Acronimi xiv

POSIX Portable Operating System Interface for uniX

PKCS Public Key Cryptography Standards

PKI Public Key Infrastructure

POP Post Office Protocol

PRACK Provisional Response ACK

PSTN Public Switched Telephone Network

QoS Quality of Service

RA Registration Authority

RC Rons Code

RFC Request For Comments

RSA Rivest Shamir Adleman

RTP Real-time Transport Protocol

SCCP Skinny Client Control Protocol

SCEP Simple Certificate Enrollment Protocol

SDP Session Description Protocol

SEMS SIP Express Media Server

SHA-1 Secure Hash Algorithm 1

SIM Subscriber Identity Module

SIP Session Initiation Protocol

SMTP Simple Mail Transfer Protocol

SP Service Provider

SPEERMINT WG Session PEERing for Multimedia INTerconnectWorking Group

SPIT SPam over Internet Telephony

SQL Structured Query Language

SRV SeRVice record

SS7 Signaling System 7

SSL Secure Sockets Layer

Acronimi xv

SSP SIP Service Provider

TCP Transmission Control Protocol

TELNET TELecommunication NETwork

TLS Transport Layer Security

TURN Traversal Using Relay NAT

TXT TeXT

UA User Agent

UAC User Agent Client

UAS User Agent Server

UDP User Datagram Protocol

URI Uniform Resource Identifier

URL Uniform Resource Locator

VoIP Voice over Internet Protocol

VSP VoIP Service Provider

XMPP eXtensible Messaging and Presence Protocol

Parte I

P R E S E N TA Z I O N E D E L L AV O R O

1I N T R O D U Z I O N E gi da qualche anno che il Voice over Internet Protocol ha comin- La diffusione del

VoIPciato il suo processo di diffusione. Il grande successo di questa tecno-logia la conseguenza del grande aumento degli utenti con accessoInternet a larga banda (ADSL), e dei grandi sviluppi relativamenterecenti nel settore dellInformation and Communication Technology. Perdare unidea, tra questi sviluppi possiamo citare: gli algoritmi di com-pressione audio e video, i protocolli per velocizzare le trasmissioni dicontenuti multimediali, la diminuzione dei tempi di risposta, ed imeccanismi di cifratura per la confidenzialit della chiamata. Luten-te dal canto suo attirato verso la tecnologia VoIP grazie al granderisparmio da questa ottenibile rispetto alla telefonia tradizionale.

Un fattore trainante dello sviluppo del VoIP sicuramente lutilizzo SIP si occupa dellasegnalazione per lecomunicazioniVoIP

del Session Initiation Protocol come protocollo di segnalazione. I puntidi forza di questo protocollo sono la semplicit, lestensibilit a favo-re di nuovi servizi, e la modularit e scalabilit della sua architettura.Oltre ai tanti vantaggi del protocollo, c per un notevole problema,dato dal fatto che quello SIP un sistema aperto, come quello email,e per questo un utente fornito di indirizzo SIP pu raggiungere ognialtro utente con indirizzo SIP e viceversa. Infatti, come accaduto Il problema dei

sistemi aperti: lospam

per il sistema email, anche il sistema SIP potrebbe essere soggetto aspam, che nel contesto della telefonia Internet prende il nome di SPIT(Spam over Internet Telephony). In pi, il verificarsi dello SPIT, ossia dimiriadi di telefonate pubblicitarie in qualunque ora del giorno e del-la notte, sarebbe senza dubbio molto pi fastidioso del normale spamemail, effettivamente seccante ma solo nel momento in cui si apre lacasella di posta elettronica. Di fatto poi, per contrastare, almeno inparte, lo spam email prima che il messaggio di posta elettronica siaaperto, possibile applicare dei filtri anti-spam; la stessa soluzioneper non pu essere applicata per contrastare lo SPIT, infatti possi-bile verificare che la chiamata sia effettivamente SPIT solo dopo averrisposto e ascoltato la voce dallaltra parte.

Nella maggior parte dei casi non infatti possibile intuire e rico- Un possibileapproccio: lafederazione

noscere che la chiamata sia sicuramente SPIT prima di rispondere,ma in effetti possibile fare il contrario, ossia affermare con certez-za se una chiamata sicuramente fidata, ovvero proveniente da undominio amministrativo fidato nei confronti del VoIP provider di de-stinazione. Questo possibile grazie al concetto di federazione fornitodallo SPEERMINT Working Group di IETF. Una federazione un insie-me di VoIP provider che si interconnettono tra loro utilizzando regole

2

3

di peering ben definite dalla policy della federazione. Questo concettopu essere applicato contro lo SPIT implementando una federazionedi VoIP provider (tra loro fidati) che si connettono tramite TLS, presen-tando i propri certificati digitali rilasciati da una Certificate Authority.Le chiamate da parte di utenti appartenenti a VoIP della stessa fede-razione sono dunque fidate, e possono essere cos contrassegnate inmaniera che lo user agent destinatario lo segnali in qualche modo,magari tramite uno squillo speciale.

Questa tesi si prefigge il compito di studiare e di implementare Obiettivo della tesiuna soluzione di questo tipo. Infatti, anche lUniversit di Roma LaSapienza ha il suo VoIP provider, di nome SapienTel, grazie al qualeprofessori, ricercatori, e studenti possono comunicare tra di loro, ocon professori, ricercatori, e studenti di altre universit, italiane ed in-ternazionali. Larchitettura esistente stata modificata, inoltre statarealizzata una federazione, SapienFed, ed una Certificate Authority adibi-ta a rilasciare i certificati digitali, da utilizzare durante le connessioniTLS, ai membri di tale gruppo (VoIP provider aderenti alle regole); inpi stato aggiunto allarchitettura SapienTel un SIP gateway neces-sario per lautenticazione dei membri di SapienFed. Per finire abbia-mo preso in delega un dominio amministrativo, affinch, tramite unaben determinata configurazione del DNS, sia possibile far entrare afar parte della federazione anche quei VoIP provider con indirizzo IPdinamico.

Il resto del lavoro strutturato come segue: Struttura dellatesi

nel secondo capitolo dopo aver introdotto la tecnologia VoIP,il protocollo SIP, ed il concetto di peering, sar argomentato ilproblema in questione.

nel terzo capitolo sar descritta la soluzione presa in conside-razione, ossia quella legata al concetto di federazione, coadiuvatadallimplementazione di uninfrastruttura a chiave pubblica per ilrilascio di certificati digitali da presentare durante lhandshakeTLS.

nel quarto capitolo saranno presentati gli strumenti open sour-ce utilizzati per implementare la soluzione descritta nel capi-tolo 3, ossia il SIP server OpenSER, la Public Key InfrastructureOpenCA, e lo user agent Twinkle.

nel quinto capitolo sar illustrata la nuova architettura Sapien-Tel, ossia quella ottenuta dopo limplementazione della soluzio-ne descritta nel capitolo 3 .

nel sesto capitolo saranno descritti i passi effettuati per realiz-zare la nuova architettura SapienTel illustrata nel capitolo 5, la fe-derazione SapienFed, e la sua infrastruttura a chiave pubblica, facen-

4

do particolare attenzione al caso dei VoIP provider con indirizzoIP dinamico.

in appendice a sono consultabili le licenze duso dei software opensource utilizzati in questo lavoro di tesi, ossia la GNU GeneralPublic License e la Berkeley Software Distribution.

in appendice b infine sono riportati i file di configurazione dei SIPserver implementati con OpenSER.

Parte II

I L P R O B L E M A E L A S O L U Z I O N E

2I L P R O B L E M Aindice

2.1 La Tecnologia Voice over Internet Protocol 62.1.1 Cos? 62.1.2 Principali Vantaggi 82.1.3 Problemi 92.1.4 Protocolli 10

2.2 Il Session Initiation Protocol 112.2.1 Descrizione 112.2.2 I Messaggi 132.2.3 Architettura di Rete 17

2.3 Il Peering 192.3.1 Peering di Strato 3 192.3.2 Peering di Strato 5 19

2.4 Perch abbiamo bisogno del Peering SIP? 21

In questa sezione si vuole svolgere una panoramica sullo scenarioin questione. Sar prima introdotta la tecnologia VoIP; si passerquindi alla descrizione del protocollo SIP e alla definizione delpeering; e si concluder con la spiegazione del problema a cui porrerimedio.

2.1 la tecnologia voice over internet protocol

2.1.1 Cos?

Il Voice over Internet Protocol (VoIP) [7], una tecnologia che rende Il VoIP unatecnologia chepermette leconversazionitelefoniche tramitereti IP

possibile effettuare una conversazione telefonica sfruttando una con-nessione ad Internet, o anche una rete dedicata che utilizzi il protocol-lo IP, senza passare attraverso la rete telefonica tradizionale (PSTN);ci consente di eliminare le relative centrali di commutazione, e dieconomizzare sulla larghezza di banda occupata. Non pi presenteil collegamento fisico della linea (doppino telefonico e centrali); mala voce, trasformata in un segnale digitale, viene incapsulata in pac-chetti di dati e inviata in rete. Una volta giunti a destinazione, talipacchetti vengono ricomposti per ricostruire il segnale originale, chesar cos fruibile nellapparecchio ricevente. Lutente ricevente deveutilizzare un dispositivo specifico, come ad esempio un computer, unadattatore per il telefono utilizzato, oppure un telefono IP, per ren-dere possibile la conversione del segnale digitale in segnale vocale.

6

2.1 la tecnologia voice over internet protocol 7

Figura 1: Elementi terminali coinvolti nelle comunicazioni VoIP.

Nella Figura 1 sono rappresentati gli elementi terminali che possonoessere coinvolti in una comunicazione VoIP.

Lapproccio utilizzato da Internet nelle comunicazioni si basa sulla Approccioutilizzato dallereti a pacchettoe...

commutazione a pacchetto, e dunque sullinvio di pacchetti di dati attra-verso la rete. Questo sistema permette ai dati di giungere a destina-zione attraverso differenti percorsi. Giunti poi a destinazione, questidati vengono ricomposti per essere utilizzati dallutente (pagine web,video, mp3, e voce) con determinati programmi o accessori. Lapproc-cio di Internet nella comunicazione totalmente differente rispetto aquello utilizzato dalla rete telefonica tradizionale. La rete telefonica ...approccio

utilizzato dallereti a circuito

tradizionale utilizza la classica comunicazione basata sulla commuta-zione a circuito, in cui tutti i telefoni sono collegati fisicamente uno conlaltro, e nel momento in cui un utente compone un numero, la lineache collega i due telefoni in questione viene totalmente impegnataper lintera durata della conversazione.

Utilizzare il proprio accesso ad Internet per telefonare permette dirisparmiare sul costo della bolletta telefonica, poich tutte le telefo-nate sono trattate come locali, ed hanno un costo indipendente dalladurata; inoltre, il costo dellinfrastruttura molto inferiore rispetto alcaso della telefonia tradizionale. Attualmente il VoIP molto diffuso


nelle aziende (ed in crescita anche tra gli utenti domestici); questoperch le compagnie telefoniche hanno gi cablato (o stanno provve-dendo a farlo) le proprie dorsali per la trasmissione della voce tramiteil protocollo IP. Un problema serio della tecnologia VoIP, legato allu-tilizzo della rete Internet, riguarda la sicurezza informatica poich idati che viaggiano in rete possono essere intercettati, e i computerrisultano sempre interessati da attacchi informatici e da tentativi diintrusione. Non meno fastidiosi sono i problemi di sicurezza legatialle vulnerabilit presenti nei protocolli di comunicazione utilizzatidal VoIP.

2.1.2 Principali Vantaggi

Nel paragrafo precedente si spiegata la differenza tra la telefo-nia tradizionale a commutazione di circuito e la tecnologia VoIP basatasulla commutazione di pacchetto. Ora si vuole puntare lattenzione suiprincipali vantaggi che il VoIP, con il suo utilizzo, pu fornire.

Il vantaggio, non trascurabile, che lutente domestico pu trarre Vantaggi perlutentedallutilizzo del VoIP, per le proprie telefonate, riguarda il minor co-

sto delle chiamate; questo perch tale costo dipende dalla quantitdi traffico trasmessa, in termini di bit al secondo, ed indipendentedalla durata della chiamata. Telefonare utilizzando il VoIP significa:spesa nulla per le chiamate verso utenti facenti capo allo stesso VoIPprovider, e nel peggiore dei casi una spesa molto ridotta per le chia-mate verso altre destinazioni geografiche (specialmente per le lunghedistanze). Per le aziende la convenienza ancora maggiore perch possibile utilizzare il VoIP per comunicare gratis tra le differenti filialisparse nel mondo. In questo modo, di fatto, si realizza una rete digi-tale interna al gruppo, che si presta molto bene ad essere modificatae adattata per fornire i pi disparati tipi di servizio. Tra i servizi chepossono risultare importanti, possiamo citare quelli inerenti alla sicu-rezza (come ad esempio limplementazione di comunicazioni sicure,tramite meccanismi crittografici a chiave pubblica e a chiave simmetrica),e quelli legati alla compressione dei dati. Questo tipo di elaborazio-ne possibile grazie al formato digitale dei dati scambiati durantela comunicazione. Grazie al VoIP viene inoltre garantita la portabilitdel numero a prefisso geografico, infatti il numero non pi legatofisicamente ad una linea telefonica (centrale relativa alla zona di resi-denza), e dal punto di vista dellutente non cambia nulla, in quantosi utilizzer sempre un normale telefono.

I vantaggi non sono solo per gli utilizzatori, ma anche per i gestori Vantaggi per ilgestore del serviziodel servizio. Adottare il VoIP, dal lato del gestore, significa diminui-

re il costo dinfrastruttura e cablaggio poich possibile eliminarele centrali di commutazione legate alla telefonia a commutazione dicircuito, ed sufficiente un unico tipo di cavo per il funzionamento


del personal computer e del telefono. C inoltre un netto risparmioanche per quanto riguarda loccupazione di banda, grazie alle evolu-te codifiche oggigiorno impiegate. Un altro aspetto fondamentale chenon pu essere trascurato la praticit. Infatti, dato che il VoIP uti-lizza le stesse tecnologie di Internet e della comunicazione di rete tracomputer, le risorse aziendali che si occupano della gestione e dellamanutenzione della rete possono occuparsi anche della gestione delVoIP, con il vantaggio di non dover spendere denaro per lutilizzo ditecnici esterni. Inoltre, con lutilizzo dei sistemi wireless, nemmeno icavi saranno pi un problema. Infine, possibile limplementazionedi funzionalit avanzate, e laggiunta di future opzioni non richiederla sostituzione dellhardware.

2.1.3 Problemi

Il VoIP, oltre ai vantaggi, porta con se anche una serie di possibi-li difficolt, che potrebbero influire sulla qualit del servizio offerto.Nelle comunicazioni basate su Internet, e di conseguenza sulla pila I problemi

principali dellecomunicazionibasate sulla pilaTCP/IP

TCP/IP, i problemi principali che possono manifestarsi riguardano laqualit della trasmissione dei dati e la gestione dei pacchetti trasmes-si. In un collegamento basato sulla pila TCP/IP, i dati in trasmissionevengono suddivisi in pacchetti, e spediti attraverso Internet, per esserepoi ricostruiti in ricezione. Le difficolt che possono sorgere nel caso Le difficolt legate

al VoIPdi utilizzo della tecnologia VoIP, per la comunicazione vocale, sono le-gate alla latenza e al jitter ( necessario ridurre e mantenere costante iltempo di transito e di elaborazione dei dati durante le conversazioni),e allintegrit dei dati ( necessario evitare le perdite dinformazionedovute alla perdita dei pacchetti). Diminuire il tempo di latenza signi-fica aumentare la velocit di transito delle informazioni, ed evitarepossibili pause nella conversazione; mentre migliorare lintegrit deidati significa evitare la perdita dei pacchetti, da cui conseguirebbeuna perdita di parole e/o di frasi durante la conversazione. Un altroproblema del VoIP limpossibilit di effettuare chiamate demergen-za, poich a causa della natura dellInternet Protocol, difficile loca-lizzare geograficamente un utente; leventuale chiamata demergenzanon pu essere quindi smistata al call center pi vicino.

Per affrontare i problemi sollevati in precedenza possibile adotta- Accorgimenti perlimitare i problemire una serie di accorgimenti:

implementazioni hardware capaci di distinguere i pacchetti VoIPdagli altri, e di gestire in modo efficiente le priorit;

utilizzo di buffer per memorizzare i pacchetti, prestando atten-zione a possibili aumenti del tempo di latenza (causati dalle ela-borazioni dei dati necessarie per la comunicazione, come adesempio la cifratura dei dati);


utilizzo di gestori di servizi ADSL che garantiscano una bandadi una certa qualit.

Detto ci, possiamo ora passare ad illustrare i protocolli utilizzatidalla tecnologia VoIP.

2.1.4 Protocolli

Per il funzionamento della tecnologia VoIP sono richieste due ti-pologie di protocolli di comunicazione, che funzionano in parallelo.Una tipologia necessaria per il trasporto dei dati (pacchetti voce suIP), e nella grande maggioranza delle implementazioni di VoIP vie-ne impiegato il protocollo RTP (Real-time Transport Protocol), per iltrasferimento dei dati con propriet di tempo reale.

Laltra tipologia di protocollo necessaria per la codifica della se- I protocolli disegnalazionegnalazione che assiste la conversazione. I protocolli di segnalazione

pi utilizzati sono:

SIP (Session Initiation Protocol) dellIETF;

H.323 dellITU;

XMPP, (eXtensible Messaging and Presence Protocol) usato da Goo-gle Talk;

SCCP (Skinny Client Control Protocol) della Cisco Systems;

IAX (Inter Asterisk Xchange), usato dai server Asterisk open sourcee dai relativi software client.

I primi tre sono protocolli aperti, mentre gli altri sono protocolli pro-prietari. Ci sono molteplici vantaggi nellutilizzare i protocolli aperti: Vantaggi dei

protocolli aperti c la possibilit di sviluppare software interoperabile e multi-

piattaforma;

la privacy nelle comunicazioni tra utenti preservata dalla tra-sparenza dei protocolli implementati;

i problemi nella migrazione tra software, piattaforme, e providersono limitati;

non sono possibili politiche di fidelizzazione dellutente ad unadata piattaforma o ad un determinato software;

favorita la competizione nello sviluppo di software e servizi(nel rispetto delle specifiche dei protocolli utilizzati);

lutente non in balia dei capricci di qualche multinazionale.

Tra i protocolli aperti citati, sicuramente quello oggigiorno pi utiliz-zato per le comunicazioni VoIP SIP.

2.2 il session initiation protocol 11

2.2 il session initiation protocol

Il Session Initiation Protocol (SIP) un protocollo di segnalazione SIP unprotocollo disegnalazione

di strato applicativo definito dallIETF (Internet Engineering Task Force)nellRFC 3261 [30], che ha reso obsoleto lRFC 2543 [17]. E stato svi-luppato ufficialmente a partire dal 1999, e fa parte dellInternet Multi-media Conferencing Suite. SIP basato su IP, ed impiegato principal-mente per applicazioni di telefonia VoIP; ma esso trova applicazioneanche nei servizi telefonici supplementari, nella video-comunicazione,nei videogiochi interattivi, e nella messaggistica istantanea.

SIP gestisce in modo generale una sessione di comunicazione tra I compiti di SIPdue o pi entit, ovvero fornisce i meccanismi per instaurare, modifi-care, e terminare (rilasciare) una sessione. Attraverso il protocollo SIPpossono essere trasferiti dati di diverso tipo (audio, video, messaggi-stica testuale, ecc.). Inoltre, SIP favorisce unarchitettura modulare escalabile, ovvero capace di crescere con il numero degli utilizzatoridel servizio. Queste potenzialit hanno fatto s che questo protocol-lo di segnalazione sia, ad oggi, il protocollo pi diffuso, nel mercatoresidenziale e business, per il supporto al VoIP.

Intorno a SIP sono sorti diversi tipi di utilizzatori, pensati per fa- Gli utilizzatoriSIPcilitare la fruizione della telefonia VoIP. Alcuni esempi sono: gli ATA

(Analog Telephone Adapter), capaci di convertire la segnalazione elet-trica di un normale telefono analogico in un flusso di dati IP; e gliIP Phone, dallunione tra telefono tradizionale e ATA, i quali sonotelefoni dalle funzionalit elevate, e ai quali non arriva il doppinotelefonico ma i cavi di rete. Evoluzione ulteriore sono i soft-phone, ap-plicazioni software per personal computer che emulano le funzioni diun telefono VoIP.

2.2.1 Descrizione

Storicamente SIP utilizza il protocollo di trasporto UDP, con portadi default 5060. Le revisioni di questo standard per ne permettonoanche lutilizzo attraverso TCP e TLS. La decisione di utilizzare TCPal posto di UDP viene presa dallo user agent client (il terminale mit-tente), quando ad esempio la dimensione del messaggio tale da nonrendere possibile lutilizzo di un singolo pacchetto UDP, oppure nel-leventualit che la comunicazione sia ritenuta a priori inaffidabile. IlTLS invece utilizzato per rendere sicuro il trasporto; in questo casola SIP URI di destinazione user lo schema sips anzich sip.

Nel caso del trasporto UDP, SIP fa uso di una macchina a statiche definisce i parametri della modalit di ritrasmissione seguente.Se lo user agent client non riceve risposta ad un suo messaggio entroun tempo T1 (posto a 500 msec), lo re-invia di nuovo, e raddoppiail valore del timer T1. Al nuovo scadere di T1 ripete ancora linvio


del messaggio, e raddoppia nuovamente T1, e cos via (ritrasmette eraddoppia il timer) finch:

non riceve una risposta valida, oppure

trascorso pi di 1 minuto dal primo invio, oppure

viene ricevuto un errore di tipo ICMP1.

In questo modo, mentre si sfruttano i vantaggi di velocit legati allu-tilizzo di UDP, si aggiunge una funzione di affidabilit al trasporto,che permette di gestire il caso dei messaggi perduti.

Le funzioni fondamentali del protocollo SIP sono: Funzioniprincipali di SIP la localizzazione degli utenti e lacquisizione delle preferenze di

questi ultimi;

linvito degli utenti a partecipare ad una sessione, effettuandouna negoziazione delle capability2, e trasportando una descrizio-ne della sessione;

linstaurazione delle connessioni di sessione;

la gestione di eventuali modifiche dei parametri di sessione;

il rilascio delle parti;

la cancellazione della sessione in qualunque momento.

Inoltre, grazie ad alcune estensioni, il protocollo pu: Funzionisupplementari pubblicare ed aggiornare le informazioni di presenza;

richiedere il trasporto di informazioni di presenza;

notificare levento di presenza;

trasportare messaggi istantanei.

Come gi detto, SIP non si occupa del trasporto dei media (au-dio/video), ma soltanto della segnalazione. La comunicazione vera epropria avviene tramite altri protocolli, tra i quali il pi utilizzato RTP.

Il modello utilizzato per la sintassi del protocollo SIP text-based,derivato dallHTTP. Per instaurare una sessione avviene un three-wayhandshake (concettualmente simile a quello che avviene con il proto-collo TCP).

Alcune caratteristiche importanti del protocollo Session Initiation Caratteristicheprincipali di SIPProtocol sono:

1 LInternet Control Message Protocol un protocollo di servizio che si preoccupa ditrasmettere informazioni riguardanti malfunzionamenti, informazioni di controllo,o messaggi tra i vari componenti di una rete di calcolatori.

2 Le capability sono le caratteristiche della comunicazione (media coinvolti, codec, ecc.)che sono negoziate tra le parti della comunicazione. Queste sono negoziate tramiteil protocollo Session Description Protocol.


la possibilit di essere impiegato sia in contesti client-server chein contesti peer-to-peer;

la facilit di estensibilit e di programmazione;

la possibilit di avere server sia stateless che stateful;

lindipendenza dal protocollo di trasporto.

Un messaggio SIP pu essere o una richiesta o una risposta. Una La transazionesequenza composta da una richiesta e da una o pi risposte dettatransazione: una transazione identificabile da un transaction-ID, chene specifica la sorgente, la destinazione ed il numero di sequenza.

Il protocollo SIP supporta la mobilit ed dialog-oriented: un dialo- Il dialogogo una relazione persistente tra entit paritetiche che si scambianorichieste e risposte in un contesto comune (equivale allinsieme delletransazioni dallinzio alla cancellazione di una chiamata).

2.2.2 I Messaggi

Gli utenti SIP sono risorse identificabili o localizzabili medianteURI o URL3 che contengono informazioni sul dominio, sul nome du-tente, sullhost, o sul numero col quale lutente partecipa alla sessione.Gli indirizzi sono stile email. Esempi fittizi possono ad esempio essere:

sip:[email protected]

sip:[email protected]:5060

[email protected]

Un messaggio SIP costituito dalla chiamata di un metodo (o SIP Composizione deimessaggi SIPrequest type; nella richiesta in Figura 2 il metodo INVITE), seguito da

una serie di campi dintestazione (header), da una riga vuota, e quindidal corpo (body) del messaggio. Questultimo contiene le intestazionidel protocollo SDP (Session Description Protocol, RFC 2327 [16]), chesegnalano allhost contattato il tipo di sessione multimediale che ver-r instaurata per la comunicazione (nellesempio una sessione audioRTP).

La prima riga del messaggio SIP, ossia quella in cui viene effettuatala chiamata del metodo, ha il seguente formato:

in cui individua la semantica del messaggio, indica il destinatario del messaggio, e rappresenta laversione del protocollo implementata.

I metodi che possono essere utilizzati nei messaggi SIP sono: Metodi SIP

3 Uno Uniform Resource Identifier o Uniform Resource Locator una stringa che identificaunivocamente una risorsa generica che pu essere un indirizzo web, un documento,unimmagine, un file, un servizio, un indirizzo di posta elettronica, ecc.


REGISTER: inviato da uno User Agent per registrare presso unRegistrar Server il proprio punto di ancoraggio alla rete;

INVITE: serve ad invitare un utente a partecipare ad una sessio-ne; dato che, tipicamente, a seguito di un messaggio contenentetale metodo, lo User Agent chiamato inizia a squillare, si dovrattendere che questultimo risponda, dunque viene subito invia-ta una risposta provvisoria, e solo successivamente, una rispostadefinitiva (positiva o negativa);

ACK: un messaggio di riscontro; inviato dallo User Agentchiamante, verso lo User Agent chiamato, per confermare la ri-cezione di una risposta definitiva ad un INVITE. LINVITE lunico metodo che innesca questa forma di three way handshake,inviando una risposta alla risposta;

PRACK: un Provisional Response ACK viene inviato da uno UserAgent Client che vuole riscontrare la ricezione di risposte tempo-ranee ad un INVITE gi inviato; infatti, mentre le risposte defini-tive sono riscontrate dallACK, quelle temporanee no, e lo UserAgent Server che le invia non ha conferma del loro arrivo. Allaricezione del PRACK (che una richiesta), lo User Agent Serverinvia una risposta 200 OK (che non quella relativa allINVITE,ma fa riferimento al PRACK), e lo User Agent Client cessa diinviare PRACK;

BYE: utilizzato per porre fine ad un dialogo SIP;

CANCEL: serve a terminare un dialogo se la sessione non haancora avuto inizio;

INFO: utilizzato per inviare ad uno User Agent, con cui si giinstaurata una sessione, delle informazioni relative ad eventiche avvengono dallaltro lato, come ad esempio, la pressionedei tasti del telefono;

REFER: lo User Agent che lo riceve trova nellintestazione Refer-to una nuova SIP URI da contattare; dopo aver chiesto confer-ma alla persona che gestisce lo User Agent, la nuova SIP URIviene contattata (pu essere una pagina web, od un altro UserAgent), ed il mittente del REFER viene notificato dellesito (conun messaggio NOTIFY);

SUBSCRIBE: consente a chi lo invia di manifestare linteressea ricevere delle notifiche riguardanti levoluzione di alcune va-riabili di stato (tramite messaggi NOTIFY), indicate mediantelintestazione Event, in cui si fa riferimento ad un event package; utilizzato per E-Presence;


Figura 2: Esempio di messaggio SIP (INVITE).

NOTIFY: tiene uno User Agent al corrente dellevoluzione dialcune variabili di stato; pu essere inviato anche senza averprima ricevuto un messaggio SUBSCRIBE;

OPTION: utilizzato per interrogare uno User Agent riguardoalle sue funzionalit, in questa maniera lo User Agent chiamantepu decidere il tipo di comunicazione da instaurare;

MESSAGE: permette linvio di messaggi istantanei, ospitati nelbody, e descritti da unintestazione Content-Type.

Per ogni messaggio SIP inviato, il terminale attende una risposta. Laprima riga di ogni risposta ha il seguente formato:

dove lo identifica la categoria della risposta, mentre la ne da una piccola descrizione testuale. Le categorie Risposte SIPdi risposte sono definite nelle seguenti classi:

1xx - Provisional: risposta di tipo provvisorio. Viene utilizzataper informare che in corso unoperazione;

2xx - Success: indica che loperazione avvenuta con successo;


3xx - Redirect: viene trasmessa a seguito dellattivazione di unaredirezione della chiamata. In questo caso il client (lo UserAgent o il proxy che ha inoltrato la chiamata) che si deve occu-pare di richiamare lindirizzo specificato;

4xx - Request Failure: la richiesta non pu essere soddisfattaperch contiene qualche errore sintattico;

5xx - Server Failure: la richiesta appare valida, ma non puessere soddisfatta per un problema interno del server;

6xx - Global Failure: la richiesta non pu essere accettata daparte di nessun server.

Per quanto riguarda le intestazioni, sono rappresentate nel seguen-te formato:

: (,)

dove il nome dellintestazione, ed ilvalore; (,) significa che ogni intestazione pu averepi di un valore, e che tali valori sono separati da una virgola. Inoltre,per ogni valore possono essere specificati dei parametri aggiuntivi,ognuno con il proprio valore, e separati da punto e virgola, in mododa arricchire il loro potere espressivo, e permettere lo sviluppo dinuove estensioni; dunque il formato di il seguente:

: (;=)

il valore dellintestazione, il nome delparametro, mentre ne il valore. Le intestazioni Intestazioni SIP

pi importantipi importanti sono:

To: indica la URI del destinatario della richiesta; nelle rispostetale intestazione resta invariata;

From: rappresenta la URI di chi invia la richiesta; nelle rispostequesta intestazione rimane invariata;

Call-ID: un identificatore semi-casuale, che resta uguale pertutti i messaggi di uno stesso dialogo, ovvero univocamenteassociato ad un INVITE iniziale;

CSeq: costituita da un numero, seguito dal nome del metodoche ha dato inizio alla transazione. Il numero si incrementa diuno ad ogni nuova transazione di uno stesso dialogo;

Via: inserita da ogni elemento che invia una richiesta SIP, incui indica il proprio indirizzo, porta, trasporto, ed un parame-tro branch utile per distinguere le diramazioni di un messaggio


forkato. Ogni elemento di transito che deve inoltrare la rispo-sta rimuove lintestazione da lui inserita, ed usa quella in ci-ma per determinare a chi inviarla. In questo modo non occorreconsultare il DNS, ed sufficiente un proxy stateless;

Max-Forwards: utile per limitare il numero di volte che unmessaggio inoltrato;

Contact: contiene uno o pi URI presso le quali il mittente diuna richiesta desidera essere ricontattato;

Allow: annuncia i metodi supportati da unentit;

Supported: elenca le estensioni supportate tra quelle elencatepresso IANA;

Record-Route: specifica la volont di un proxy di essere mante-nuto nel path dei futuri messaggi del dialogo.

La sequenza di messaggi inviati e ricevuti per instaurare una chia-mata SIP illustrata nella Figura 3.

Figura 3: Flusso di messaggi in una comunicazione SIP.

2.2.3 Architettura di Rete

Le entit essenziali di una rete SIP sono: ElementiprincipalidellarchitetturaSIP

SIP User Agent: un end-point e pu fungere da client o da ser-ver; i due ruoli sono dinamici, nel senso che, nel corso di una ses-sione, un client pu fungere da server e viceversa. Quando funge


da client d inizio alla transazione originando richieste. Quandofunge da server accoglie le richieste, e le soddisfa se possibi-le. Uno user agent sostanzialmente una macchina a stati, cheevolve a seconda dei messaggi SIP, e registra le informazionirilevanti del dialogo. Il dialogo ha inizio quando si risponde posi-tivamente al messaggio di INVITE, e termina con un messaggiodi BYE.

Registrar Server: un server dedicato o collocato in un proxy.Quando un utente iscritto ad un dominio, invia un messaggiodi registrazione del suo attuale punto di ancoraggio alla rete adun registrar server.

Proxy Server: un server intermedio; pu rispondere diretta-mente alle richieste, oppure reinstradarle ad un client, ad unserver, o ad un ulteriore proxy. Un proxy server analizza i para-metri dinstradamento dei messaggi, e nasconde la reale posi-zione del destinatario del messaggio, essendo questultimo in-dirizzabile con un nome convenzionale del dominio di apparte-nenza. I proxy possono essere di tipo stateless o stateful. Il primotipo processa ogni richiesta o risposta SIP, ma non viene im-magazzinata nessuna informazione riguardante il messaggio; ilsecondo tipo tiene traccia delle richieste e delle risposte ricevu-te, ed utilizza queste informazioni per processare i messaggifuturi. Quando uno user agent invia sistematicamente le pro-prie richieste ad un proxy vicino (di default), allora tale proxyviene detto Outbound-Proxy. Viceversa, un Inbound-Proxy unproxy che instrada le chiamate entranti in un dominio. Infine unForking-Proxy pu instradare una stessa richiesta in parallelo oin sequenza a pi destinazioni.

Redirect Server: server che reinstrada le richieste SIP, consenten-do al chiamante di contattare un insieme alternativo di URI.

Location Server: un database contenente le informazioni riguar-danti lutente, come il profilo, lindirizzo IP, e lURL.

Linstaurazione di una chiamata SIP segue lo schema che in gergoviene definito trapezoide SIP, illustrato in Figura 4.

2.3 il peering 19

Figura 4: Trapezoide SIP.

2.3 il peering

La definizione precisa del termine peering il soggetto di ac-cesi dibattiti. Con questo termine generalmente si intende la nego-ziazione reciproca degli assetti dinterconnessione tra service providerfunzionalmente indipendenti [23].

Si distinguono due tipi di peering: il peering di strato 3 ed il peeringdi strato 5, descritti nei seguenti paragrafi.

2.3.1 Peering di Strato 3

Il peering di strato 3 (livello di Rete) si riferisce allinterconnessione didue reti di service provider diverse, allo scopo di scambiare pacchettiIP destinati ad una o ad entrambe le reti. Il peering di strato 3 gene-ralmente indifferente al carico IP, ed frequentemente ottenuto utiliz-zando un protocollo dinstradamento, come il Border Gateway Protocol(BGP), per scambiare le informazioni dinstradamento richieste.

2.3.2 Peering di Strato 5

Il peering di strato 5 (strato di Sessione) si riferisce allinterconnessionedi due SIP Service Provider, allo scopo di instradare la segnalazionedelle chiamate real-time (o quasi real-time) tra i loro rispettivi utenti,utilizzando i metodi SIP. Tale peering pu essere diretto o indiretto.

2.3 il peering 20

Si noti che i flussi mediali associati a questa segnalazione (se presenti)non sono vincolati a seguire lo stesso insieme di cammini IP dellasegnalazione.

Il peering diretto (Figura 5) descrive quei casi in cui due SIP Service Il peering direttoProvider si interconnettono senza utilizzare una rete di strato 5 inter-media. Il peering indiretto (Figura 6) si riferisce allo stabilimento o di

Figura 5: Esempio di peering diretto.

Il peering indirettoun cammino per la segnalazione e i media, o di un cammino di solasegnalazione, tramite una o pi reti di transito. In questo caso gene-ralmente richiesto che sia stabilita una relazione di fiducia tra il SIPService Provider dorigine e la rete di transito da un lato, e tra la retedi transito ed il SIP Service Provider di destinazione dallaltro.

Figura 6: Esempio di peering indiretto.

2.4 perch abbiamo bisogno del peering sip? 21

E chiaro che nel nostro lavoro prenderemo in considerazione esclu-sivamente il peering di strato 5.

2.4 perch abbiamo bisogno del peering sip?

Quando SIP stato sviluppato non cera bisogno del peering SIP.SIP era considerato aperto come il sistema email. Come tutti possonoinviare email a chiunque, ogni utente SIP dovrebbe poter contattareogni altro utente SIP tramite tale protocollo. Dunque, affinch ci sia Requisiti di un

servizio SIP apertopossibile, sono necessari due requisiti:

il provider SIP del chiamante deve permettere le chiamate versoi SIP URI non appartenenti al dominio SIP locale;

il provider SIP del chiamato deve acconsentire alle chiamate SIPentranti provenienti dallesterno del dominio locale.

Un servizio SIP che soddisfa questi due requisiti viene definito ser-vizio SIP aperto. Attualmente ci sono molti servizi SIP aperti; degliesempi sono iptel.org e fwd.pulver.com.

Ma ci sono anche altri servizi SIP, che sono chiusi o limitati. Servizi SIP chiusie limitatiChiuso significa che il SIP service provider permette solo chiamate SIP

interne (chiamate per gli altri utenti dello stesso SIP service provider).Tutte le chiamate dirette verso gli altri utenti sono eventualmente in-stradate tramite la PSTN. Limitato significa che il SIP service providerpermette solo le chiamate SIP da e per alcuni domini, e non per tut-ti. Tutto questo ovviamente richiede lautenticazione delle chiamateentranti. Esempi di servizi chiusi sono yahoo, broadband, inode, vonage,IMS/NGN.

Ci sono 3 ragioni principali per cui un service provider non offre un Ragioni principaliper non offrireservizi SIP aperti

servizio aperto, ma soltanto chiuso o limitato:

modello di business: il service provider necessita di accordarsieconomicamente con la PSTN per le tariffe dinterconnessione edi transito;

sicurezza: il service provider teme eventuali problemi di sicu-rezza riguardanti lautenticazione dei proxy esterni al propriodominio, ed il Denial of Service (DoS);

SPIT: il service provider teme lo SPam over Internet Telephony(SPIT), che con ogni probabilit si verificher prima o poi (comelo spam email).

Avere dei provider SIP aperti mentre altri provider SIP sono chiusi con-duce a vari problemi dinterconnessione. Qui di seguito ve ne sonoalcuni esempi:

iptel.orgfwd.pulver.com

2.4 perch abbiamo bisogno del peering sip? 22

Un utente di un servizio SIP aperto chiama un utente di un ser-vizio SIP chiuso utilizzando il SIP URI del chiamato. Il providerSIP del chiamato ignora il messaggio SIP in arrivo, causando ilfallimento della chiamata.

Un utente di un servizio SIP chiuso chiama un utente di un ser-vizio SIP aperto tramite il numero telefonico E.164 di questulti-mo. Bench il chiamato possa essere raggiunto direttamente tra-mite ENUM+SIP, la chiamata sar instradata tramite la PSTN,causando cos tempi di configurazione della chiamata maggiori,costi di chiamata, e probabilmente anche una peggiore qualitdovuta al verificarsi di varie transcodifiche e pacchettizzazioni.

Due utenti vogliono effettuare una video-conversazione tra diloro. Entrambi i SIP provider supportano le sessioni video, ma selinterconnessione tra i due provider viene svolta tramite la PSTNnon c alcuna possibilit di usufruire di sessioni multimediali(Video, Instant Messaging, Presence).

Per risolvere questi problemi necessaria una modalit di peering de-dicata. Probabilmente qualcuno pu sostenere che il peering non necessario, e che i provider SIP dovrebbero soltanto aprire i loro ser-vizi SIP. Ma questo condurrebbe agli stessi problemi che si hannocol sistema email. Inoltre, se ci sono service provider che non voglionoaprire i loro servizi a tutti, la loro posizione deve essere rispettata.E anche se un service provider aprisse il suo servizio SIP, questo po-trebbe voler applicare alcune limitazioni sulla maniera di eseguire leinterconnessioni.

Dunque, per incoraggiare i SIP provider ad aprire il loro servizio I meccanismi diautenticazione traprovider

SIP, bisogna offrire loro dei meccanismi per autenticare gli altri servi-ce provider. Ci sono vari modi per autenticare gli utenti SIP o gli altriSIP service provider, ad esempio: SIP su TLS (autenticazione basatasul certificato), autenticazione basata sullindirizzo IP, SIP+S/MIME,VPN di strato 2, IPsec, ecc. Comunque, a prescindere dalla tecnologia,il service provider ha bisogno di autenticare le chiamate. In questo la-voro di tesi sar analizzata la soluzione relativa allautenticazione subase certificato (o SIP su TLS), per ovviare al problema dello SPIT.

3L A S O L U Z I O N Eindice

3.1 LAutenticazione 233.1.1 LAutenticazione nelle Comunicazioni SIP 25

3.2 Il Session PEERing for Multimedia INTerconnectWorking Group 273.2.1 I Draft 28

3.3 Le Federazioni 303.3.1 Esempi 313.3.2 Il Peering basato sulla Federazione 333.3.3 La Policy della Nostra Federazione 40

3.4 La Public Key Infrastructure 413.4.1 La Crittografia a Chiave Pubblica 413.4.2 Cos una PKI? 463.4.3 Da cosa composta? 473.4.4 Certificate Authority e Registration Authority 48

3.5 Il Protocollo Transport Layer Security 543.5.1 Descrizione 543.5.2 Il TLS Record Protocol 553.5.3 Il TLS Handshake Protocol 573.5.4 Utilizzi 61

3.6 Formalizzazione della Soluzione 62

In questo capitolo sar esposta la soluzione prescelta per la riso-luzione del problema esposto nella precedente sezione. Si arri-ver gradualmente alla formalizzazione di tale soluzione, comin-ciando col trattare largomento dellautenticazione, ed in particolarelautenticazione nelle comunicazioni SIP, passando poi allapproccioutilizzato dallo SPEERMINT WG di IETF, e cio quello relativo allefederazioni; si discuter poi dellinfrastruttura a chiave pubblica, e delprotocollo TLS che ne utilizza i certificati. Si concluder quindi lasezione formalizzando la soluzione da implementare.

3.1 lautenticazione

Nel campo della sicurezza informatica, si definisce autenticazione Lautenticazione il processo tramiteil quale un utenteverifica che il suointerlocutore chidichiara di essere

il processo tramite il quale un computer, un software, o un utente ve-rifica la corretta, o almeno presunta, identit di un altro computer,software, o utente che vuole comunicare attraverso una connessione[32]. Durante una comunicazione in Internet o durante laccesso adalcuni servizi messi a disposizione dal Web, importante per luten-

23

3.1 lautenticazione 24

te definire in modo univoco la propria identit, essere riconosciuto,e per questo ottenere laccesso ai servizi desiderati (Figura 7). Allostesso modo fondamentale anche conoscere lidentit di chi si tro-va dallaltra parte della linea di comunicazione, ed essere certi chelinterlocutore con il quale si stanno scambiando le informazioni siaveramente chi dichiara di essere e non un impostore.

Figura 7: Esempio di autenticazione.

Un esempio legato alla vita quotidiana la comune procedura diautenticazione che conosciamo come login (ad esempio per entrarenella propria casella di posta elettronica). Un sistema di elaborazio-ne, progettato per essere usato soltanto da utenti autorizzati, deveessere in grado di rilevare ed escludere i non autorizzati. Laccessoad esso, dunque, viene garantito solo dopo aver eseguito con succes-so una procedura di autenticazione in cui sono state presentate dellecredenziali (di solito uno username ed una password personale).

I metodi tramite i quali un essere umano pu autenticarsi sono Classi dei metodidi autenticazionedivisi in tre classi, in base a ci che egli:

(ad esempio, tramite impronte digitali, impronta vocale, mo-dello retinico, sequenza del DNA, calligrafia, o altri identificato-ri biometrici);

ha (ad esempio, tramite tesserino identificativo);

conosce (ad esempio, tramite password, parola chiave, o numerodidentificazione personale PIN).

Spesso, al posto del singolo metodo, viene usata una combinazionedi metodi, ad esempio un tesserino identificativo ed un PIN. Questaprocedura prende il nome di autenticazione a due fattori.

Il processo di autenticazione basato sulla misura del rischio. Siste-mi, applicazioni, ed informazioni ad alto rischio richiedono forme di-verse di autenticazione, che confermano pi accuratamente lidentitdigitale dellutente rispetto ad applicazioni a basso rischio.


Nel contesto dellICT (Information and Communication Technology),sono stati sviluppati dei metodi crittografici (come la firma digitale),i quali, per ora, non sono raggirabili se (e solo se) la chiave origi-naria, utilizzata per cifrare linformazione, non stata compromessa.Questi ottimi metodi sono, almeno per ora, considerati inattaccabili.Ma non c, per, la certezza che essi rimangano sicuri per sempre.Imprevisti sviluppi matematici futuri potrebbero rendere vulnerabi-le lintera generazione moderna di algoritmi di cifratura, mettendoin seria discussione tutto ci che stato autenticato in passato. Inparticolare, un contratto digitalmente firmato non avrebbe pi alcunvalore nelleventualit che il sistema crittografico di base fosse statobucato. La scelta dei diversi metodi di autenticazione condizionatada diversi fattori, tra cui lusabilit, limportanza delle informazionida proteggere, ed il costo del sistema.

3.1.1 LAutenticazione nelle Comunicazioni SIP

Addentriamoci ora nellargomento riguardante lautenticazione nel-le comunicazioni con segnalazione SIP. Lassociazione di un ContactAddress (indirizzo IP dello user agent) con un Address of Record (URISIP associata allutente), che avviene nel momento in cui uno useragent contatta un registrar, unoperazione che, se eseguita senza nes-suna verifica di autorizzazione, permetterebbe a chiunque di riceveretelefonate SIP dirette a qualcun altro. Pertanto, qualunque VoIP pro-vider minimamente serio intraprende una procedura di verifica delpossesso delle credenziali di accesso nei confronti dello user agent cherichiede la registrazione. Lautenticazione SIP consiste in una sfida La Digest

Authenticationche il registrar invia allo user agent, contenuta nellintestazione WWW-Authenticate presente in una risposta 401 Unauthorized, e basata sulmetodo della Digest Authentication [30]. La Digest Authentication unmeccanismo sviluppato inizialmente per HTTP. Tale meccanismo ve-rifica che entrambi i partecipanti alla comunicazione condividano laconoscenza di una parola chiave segreta. Quando un server vuole au-tenticare un utente genera una sfida (Digest Challenge) e gliela invia;a sua volta lutente, per essere autenticato, deve ritornare al serveruna risposta (Digest Reply) corretta alla sfida ricevuta. Ovviamente,la correttezza della risposta dipende dal possesso della parola chia-ve segreta. In questo modo, il VoIP provider che gestisce il registrar,e che rilascia lAddress of Record allutente dello user agent, concor-da con questo anche un segreto condiviso, o password, da utilizzarein associazione alla parte user dellAddress of Record, per verificarnelautorizzazione allutilizzo del registrar (Figura 8).

Allo stesso modo, anche i messaggi inviati da uno user agent alproprio outbound proxy devono essere autenticati, in modo da impe-dire al proxy di comportarsi come Open Relay, e di inoltrare richieste


Figura 8: Registrazione tramite Digest Authentication.

provenienti da chiamanti sconosciuti (Figura 9).Resta per aperta la questione di come procedere allautenticazione Il problema

dellautenticazionetra proxy

tra loutbound proxy sorgente della chiamata ed il registrar di destina-zione, senza contare la presenza di eventuali altri proxy intermedi:infatti, mentre tra user agent, registrar, e outbound proxy i rapporti sonodiretti e mediati da uno stesso VoIP provider, non invece pensabi-le poter stabilire un segreto condiviso tra tutte le coppie di proxypresenti in Intenet. La soluzione attualmente pi percorribile sembra La soluzione del

problemaessere quella allo studio da parte dello SPEERMINT WG (Session PEE-Ring for Multimedia INTerconnect Working Group) di IETF, che consistenella definizione di Federazioni SIP a cui i singoli VoIP provider pos-sono aderire. Tali federazioni svolgono la funzione di una CertificateAuthority comune per firmare i certificati digitali dei provider aderentiad essa; tali certificati saranno utilizzati nellambito delle connessioniTLS che le coppie di proxy federati devono stabilire quando coinvoltidallattraversamento della segnalazione SIP.

3.2 il session peering for multimedia interconnectworking group 27

Figura 9: Chiamata con Digest Authentication.

3.2 il session peering for multimedia interconnectworking group

Il termine VoIP Peering, come gi accennato, e utilizzato per de-scrivere linterconnessione di rete inter-provider, ed il transito dellechiamate vocali tra i punti dinterconnessione. Mentre oggigiorno lechiamate vocali sono la motivazione primaria del peering, altre formedi comunicazione real-time si stanno evolvendo, e continueranno afarlo. Per questo, lo SPEERMINT Working Group [14] descrive le chia- Ambito e obiettivi

delloSPEERMINT WG

mate come sessioni, tenendo in considerazione il fatto che tali comu-nicazioni sono di natura real-time. Lo SPEERMINT WG si concentrasulle architetture in grado di identificare, segnalare, ed instradare lesessioni di comunicazione sensibili al ritardo (real-time). Queste ses-sioni utilizzano il protocollo di segnalazione SIP per abilitare il pee-ring tra due o pi domini amministrativi in reti IP. Lo SPEERMINTWG si interessa delle considerazioni riguardanti lo stabilimento del-la fiducia, la sicurezza, e la resistenza agli abusi e agli attacchi tra isuddetti domini di peer. Lo SPEERMINT WG presta attenzione unica-mente al peering di livello applicativo. Tuttavia, per ottenere il peeringper una sessione real-time, bisogna tenere in considerazione sia i flussidi segnalazione che i flussi mediali. Inoltre, il gruppo di lavoro rico-nosce che c la probabilit che si presentino dei casi dutilizzo che


richiederanno di concentrarsi sullinterazione tra lo strato applicativoed i livelli di rete inferiori, o sulle dipendenze dello specifico livelloapplicativo dagli strati inferiori.

Pi specificatamente, lo SPEERMINT WG si concentra sulle archi-tetture dinstradamento per sessioni real-time e sui casi di utilizzo aqueste associati. In pi, si occupa della specifiche riguardanti i varitipi di flussi applicativi.

Per il futuro lo SPEERMINT WG si propone di considerare va- Gli studi futuriri meccanismi per supportare lapplicazione della Quality of Service,e/o i meccanismi dingegneria del traffico a supporto delle sessioni dipeering real-time.

In ogni caso, la maggior parte dellattenzione dello SPEERMINTWG rivolta alle migliori pratiche attuali riguardanti lo scambio disessioni real-time tra VoIP service provider, ed in particolare, a comequeste chiamate sono instradate. Lo SPEERMINT WG riconosce chealcuni di questi provider controllano anche le reti daccesso sottostanti,mentre altri no, e questo fatto pu presentare vari requisiti addizio-nali o casi dutilizzo da considerare. Il gruppo di lavoro sviluppa deidocumenti riguardanti i casi dutilizzo, per registrare la variet dellepratiche correnti.

Un posto di rilievo negli studi del gruppo di lavoro occupatodalle Federazioni di VoIP provider. Nel prossimo paragrafo sar ef-fettuata una panoramica dei documenti di questo gruppo di lavororiguardanti tale argomento.

3.2.1 I Draft

Prima di cominciare a definire il concetto di federazione, utile in-trodurre i documenti riguardanti tale argomento, e da cui si presospunto per questo lavoro di tesi.

Ancora non stato rilasciato uno standard riguardante le federa-zioni tra SIP service provider, ma sono stati rilasciati gi molti draft;questi possono essere suddivisi in tre categorie principali: preliminari,prenormativi, ed analitici.

I draft preliminari sono due: Draft preliminari

Background and Assumptions of the Speermint WG [20]: chiari-sce il ruolo dello SPEERMINT WG, che quello di suggerire so-luzioni al problema dellinterconnesione tra domini SIP. Vienesvolta unanalisi del perch le soluzioni previste dagli standardattuali non vengano in effetti attuate, e del perch sia il model-lo PSTN che il modello email dellinstradamento della chiama-ta non siano soddisfacenti. Quindi si individuano le assunzio-ni consolidate che devono essere rimosse, al fine di procedereverso una reale evoluzione.


VoIP Security Threats relevant to SPEERMINT [26]: illustra inmaniera esaustiva le minacce ed i pericoli riguardanti le fun-zionalit di individuazione, segnalazione, e trasmissione mul-timediale presenti in unarchitettura VoIP. Inoltre, descrive lemigliori pratiche correnti volte a contrastare tali pericoli.

Tra i draft prenormativi possiamo annoverare: Draftprenormativi

SPEERMINT Peering Architecture [28]: descrive i modelli diarchitettura di peering, adottando la distinzione e la separazio-ne tra Location Function1, Signaling Function2, e Media Function3.Questo documento si basa sul draft

Use of DNS SRV and NAPTR Records for SPEERMINT [6]:espone le query ed i record NAPTR4 ed SRV5 da adottare nelcontesto del peering SIP.

VoIP SIP Peering Use Cases [36]: discute i casi dinstradamen-to diretto ed indiretto, nonch quelli legati alle federazioni: tri-viali, basate sulle liste daccesso, su TLS, o su proxy centrale. Taledocumento basato sui draft:

A Minimalist Approach to Direct Peering [22]: che appro-fondisce il peering diretto;

A Federation based VoIP Peering Architecture [15]: che ap-profondisce la definizione di federazione, i flussi di chiama-ta, e larchitettura dinstradamento.

SPEERMINT Routing Architecture Message Flows [27]: espo-ne i casi di peering On-Demand, Statico, e basato su Federazione.Nel caso della federazione, distingue i casi in cui ne esiste unain comune tra chiamante e chiamato, oppure nessuna, oppureleventualit in cui il chiamato pu redirigere il chiamante at-traverso una terza federazione, accreditata presso il chiamante,di cui sfrutta il transito. Dal punto di vista della gestione dellachiamata, la federazione pu essere: implementata su di un proxycentrale che esegue delle redirezioni, basata su VPN, o basata su

1 La Location Function una funzione che determina, per il dominio di destinazione inuna data Request URI, la posizione della Signaling Function. Un elemento che eseguela Location Function il DNS.

2 La Signaling Function una funzione che esegue linstradamento delle richieste SIPper stabilire e mantenere le chiamate. La Signaling Function implementata dai SIPproxy.

3 La Media Function esegue le funzioni legate ai media, come ad esempio la transcodifi-ca dei media, limplementazione della sicurezza dei media tra due SIP service provider,ecc.

4 Il Naming Authority PoinTeR un tipo di record del DNS che supporta la riscritturabasata sulle espressioni regolari.

5 Il SeRVice record un tipo di record del DNS che specifica le informazioni sui servizidisponibili (usualmente TCP e UDP).

3.3 le federazioni 30

TLS. E fornito inoltre un ottimo esempio di rimappatura delleporte RTP nel caso di Media Relay.

Infine i tre draft analitici sono: Draft analitici

An ITSP Problem Statement Regarding SIP Peering [25]: illu-stra le considerazioni operative di un Internet Telephony ServiceProvider nei confronti del peering SIP.

Use cases for Enterprise Peering using the Session InitiationProtocol [10]: descrive alcuni casi dutilizzo per lapplicazionedel peering SIP tra VSP commerciali.

SIP Peering Use Case for VSPs [35]: tratta linterconnessione dipi VoIP service provider.

Grazie allo studio dei draft citati, si ha un quadro pi completoriguardo al lavoro svolto dallo SPEERMINT WG, e riguardo allargo-mento federazioni, che sar discusso nel seguente paragrafo.

3.3 le federazioni

Una Federazione [23] un gruppo di SIP service provider, i quali ac-cettano di ricevere chiamate lun laltro tramite SIP, e che aderisconoad un insieme di regole amministrative per tali chiamate (pagamen-to, gestione dellabuso, ecc.), e a delle regole specifiche riguardan-ti i dettagli tecnici del peering. Linsieme di tali regole costituisce lacosiddetta policy della federazione.

Come possiamo evincere dalla Figura 10, un SIP service provider puessere un membro di:

nessuna federazione (il peer E non appartiene a nessuna federazio-ne);

una singola federazione (i peer A e D appartengono soltanto allaFederazione X, mentre il peer C appartiene solamente alla Federa-zione Y);

federazioni multiple (il peer B appartiene sia alla Federazione X chealla Federazione Y).

Dunque, una federazione come un club. Tutti i membri condivido- Una Federazione un club in cuitutti i membricondividono uninteresse comune

no un interesse comune. Nel caso del VoIP peering, i membri condi-vidono lo stesso desiderio di interconnettersi direttamente tramite lasegnalazione SIP invece di interconnettersi tramite SS76. Una federa-zione necessita di almeno 2 membri, ma solitamente ve ne sono moltidi pi, i quali si trattano luno con laltro in maniera identica.

6 Il Signaling System 7 il tradizionale sistema di segnalazione per reti a commutazionedi circuito.


Figura 10: Appartenenza alle federazioni.

Ci possono essere molte federazioni differenti, con differenti scopi, edunque con differenti politiche dinterconnessione. Ad esempio, unafederazione pu attuare la politica di effettuare il peering gratuitamen-te, e tutti possono farne parte, purch siano autenticati tramite TLS.Altre federazioni possono mantenere le politiche di pagamento vigenti(ad esempio, lo scatto alla risposta); ma comunque i membri devo-no soddisfare alcuni requisiti (ad esempio, essere degli operatori ditelefonia mobile).

3.3.1 Esempi

Questo paragrafo espone alcuni esempi di come le federazioni pos-sono operare. I quattro esempi riportati riguardano: le Federazioni Tri-viali, le Federazioni basate sulla Lista dAccesso, le Federazioni basate suTLS, e le Federazioni con SIP Proxy Centrale.

Federazioni Triviali

Un accordo di peering privato tra due SIP service provider un ca-so speciale di federazione. Questi due SIP service provider accettano discambiarsi le chiamate tra di loro, e configurano linfrastruttura distrato 3, i Location Server, ed i SIP proxy di cui hanno bisogno, inmodo da riuscire ad instradare e a completare le chiamate. Questopu avvenire in maniera diretta o indiretta, ma usualmente si segue ilmodello di chiamata diretto.

Per, anche linsieme di tutti i SIP service provider che implementanoun servizio SIP aperto, in accordo agli RFC 3261 [30], 3263 [29], e 3761


[11], soddisfa la definizione di federazione. In questo caso, le regoletecniche sono contenute in questi tre RFC, ed il Location Server ilDNS pubblico.

Il modello amministrativo di questa federazione il modello email,infatti non esiste una lista dei membri, ed ogni SIP server, operante inInternet, che implementa linstradamento di chiamata in accordo aquesti RFC implicitamente un membro di questa federazione. Nonc bisogno di una relazione daffari tra i membri di questa federazione.Non c protezione contrattuale contro le chiamate indesiderate, loSPIT, o gli attacchi di tipo Denial of Service (DoS)7.

Federazioni basate sulla Lista dAccesso

E legittima la volont di non implementare il servizio SIP tramiteun proxy aperto; in questo caso, un gruppo di SIP service provider chevogliono permettere le chiamate dagli altri SIP service provider, appar-tenenti allo stesso gruppo, pu raccogliere la lista degli indirizzi IPdi tutti i loro outbound proxy. Questa lista redistribuita a tutti i mem- La lista degli

indirizzi IP deimembri serve perla configurazionedei firewall

bri, i quali la utilizzeranno per configurare i firewall dei loro elementidingresso (inbound proxy). In questa maniera le chiamate provenientidagli altri membri della stessa federazione saranno accettate, mentre lechiamate provenienti dagli altri host di Internet saranno bloccate.

Linstradamento delle chiamate pu ancora essere svolto tramite leregole standard degli RFC 3261 [30], 3263 [29], e 3761 [11].

Se un nuovo membro entrasse a far parte di questo club, ogni altroSIP service provider necessiterebbe di adattare le proprie regole per ilfiltraggio.

Federazione con SIP Proxy Centrale

Un modo per semplificare la gestione delle suddette regole dei fi- La semplicegestione deifirewall

rewall quello di implementare un SIP proxy centrale, a cui instradaretutti i messaggi SIP. In questo caso, tutti i membri della federazionehanno solo bisogno di aprire i loro elementi dingresso alle richiestedi tale server centrale. Lingresso, nella federazione, di un nuovo SIPservice provider innesca soltanto un cambiamento nella configurazionedel proxy centrale e non negli altri SIP service provider.

Tale approccio abbastanza popolare oggigiorno. Questo un esem-pio di peering indiretto.

7 Lattacco di tipo Denial of Service (in italiano negazione del servizio) mira a portareil funzionamento di un sistema informatico, che fornisce un servizio, al limite delleprestazioni, fino a rendergli impossibile lerogazione del servizio. Gli attacchi vengo-no abitualmente attuati inviando al server un alto numero di richieste, saturandonele risorse, e rendendo tale sistema instabile.


Federazioni basate su TLS

Un altra opzione per limitare le chiamate entranti ai soli membri Il controllodaccesso si basasui certificatirilasciati da unaCA, magariimplementatadalla federazione

della federazione quella di utilizzare dei certificati, da presentare me-diante il protocollo TLS, come controllo daccesso. Questo meccani-smo funziona meglio se la federazione si comporta anche da CertificateAuthority (CA), in modo da firmare le chiavi TLS di ogni SIP serviceprovider membro della federazione. Cos, lelemento dingresso di unSIP service provider ha bisogno di controllare solo se il certificato delclient, ovvero del SIP proxy chiamante, contiene una firma correttadella CA.

Aggiungere il supporto alle Certificate Revocation List (CRL) risolve ilproblema del bloccaggio delle chiamate provenienti dagli ex membridella federazione.

Il beneficio principale di questo modello che, se un SIP serviceprovider entra a far parte della federazione, non c bisogno di farealcuna modifica agli elementi dingresso dei membri di questa.

Data la presenza di un controllo daccesso, ed il basso carico di Questo il nostrocaso dutilizzoconfigurazione richiesto, questo caso dutilizzo chiaramente adatto

per lo svolgimento del nostro lavoro realizzativo; comporta per lim-plementazione di uninfrastruttura a chiave pubblica per il rilascio deicertificati da utilizzare col protocollo TLS.

3.3.2 Il Peering basato sulla Federazione

Per comprendere appieno cosa succede nel peering basato sulla fede-razione [36], bisogna prima capire in generale come si instaura unarelazione di peering tra due SIP proxy appartenenti a due dominiamministrativi differenti.

A tale scopo, nella Figura 11 rappresentato il flusso di messaggidi base in una relazione di peering (abbiamo considerato che i dueSIP proxy non svolgano il ruolo di Media Relay, ma lunico cambia-mento avrebbe interessato soltanto i flussi RTP, che non sarebberostati inoltrati direttamente end-to-end, ma sarebbero invece passati perentrambi i proxy).

I vari scenari differiscono soprattutto nella maniera e nella tempi-stica in cui il peering implementato. Il peering pu essere stabilito aseguito dellarrivo di un messaggio allinbound proxy di un dominioamministrativo (Peering On-Demand), o staticamente a seguito di unaccordo tra i due domini amministrativi (Peering Statico). In entram- La scelta del

peering direttobi i casi il peering pu essere diretto o indiretto, ma, data lassenza direti di strato 5 in grado di offrirci il transito, si scelto di fare rife-rimento unicamente al modello di peering diretto. Tra laltro, la sceltadel peering diretto (ossia tra due soli proxy con domini amministratividifferenti) quasi obbligata dal fatto che il protocollo TLS funzionahop-by-hop e non end-to-end.


Figura 11: Flusso di messaggi di base in una relazione di peering.


I SIP service provider eseguono un peering statico nel caso in cui, per Il peering staticoliniziazione di ogni transazione real-time (come un messaggio SIP),sia richiesta una pre-associazione tra i provider. Per quanto riguarda ilpeering statico nelle federazioni, ogni peer della federazione deve primaaderire ad un insieme comune di regole e di linee guida legate allin-terconnessione, e quindi pre-associarsi con ogni altro peer prima diiniziare ad inviare le richieste di sessione.

Tra i casi dutilizzo, la forma pi semplice di peering quella del Peering staticodirettopeering statico diretto. Due SIP service provider negoziano e aderiscono

a stabilire una relazione di peering SIP. La connessione dei peer confi-gurata staticamente, e connette direttamente i due SIP service provider.Prima dello stabilimento della connessione, i peer possono scambiarsidelle informazioni, quali, ad esempio, i SIP URI degli abbonati, la po-sizione dei proxy, ecc. I peer accettano solo il traffico originato dai peerfidati. La seguente una descrizione di alto livello di questo caso diutilizzo (Figura 12):

1. lo User Agent Client inizia una chiamata tramite un messaggioINVITE;

2. loutbound proxy del dominio sorgente della richiesta (Proxy A)interroga un database per ottenere i dati riguardanti lo stabili-mento della sessione;

3. il database restituisce le informazioni richieste;

4. la richiesta trasmessa allinbound proxy del dominio di destina-zione (Proxy B);

5. linbound proxy del dominio di destinazione (Proxy B) determinalo stato del chiamato, e dirige la chiamata verso questultimo;

6. viene stabilita una connessione RTP tra lo User Agent Client e loUser Agent Server.

Il peering statico diretto tipicamente implementato in uno scenariodove esiste un alto livello di fiducia tra i due domini amministrativi.Entrambi i domini amministrativi normalmente firmano un accordo,che dichiara chiaramente le politiche di peering ed i termini.

I SIP service provider mettono invece in pratica un peering on-demand Il peeringon-demandnel caso in cui essi siano in grado di scambiarsi il traffico senza alcuna

pre-associazione precedente loriginazione di una transazione real-timetra i domini amministrativi. Ogni informazione che necessita di es-sere scambiata tra i domini, a supporto dellinterconnessione, puessere ottenuta tramite un meccanismo protocollare dinamico. Comegi accennato, il SIP service provider sorgente ed il SIP service providerdi destinazione non condividono alcuna informazione prima dellarichiesta che inizia il dialogo. Quando il proxy del dominio sorgente


Figura 12: Peering diretto (statico e on-demand).

interroga il proprio database, richiedendo le informazioni relative allostabilimento della sessione, le informazioni riguardanti lutente desti-natario devono essere pubblicamente disponibili. Inoltre, quando ilproxy del dominio sorgente instrada la richiesta al proxy del dominiodi destinazione, questultimo deve accettare la richiesta senza alcunapre-associazione con il SIP service provider sorgente.

Il caso del peering on-demand diretto tipicamente implementato in Peeringon-demand direttouno scenario dove il SIP service provider di destinazione permette ad

ogni SIP service provider sorgente di raggiungere i suoi abbonati alservizio. Il dominio amministrativo del SIP service provider di desti-nazione non richiede alcun pre-accordo per accettare la chiamata. IlSIP service provider di destinazione rende linformazione riguardantei suoi abbonati disponibile pubblicamente. Questo modello imita ilmodello email di Internet: il mittente non ha bisogno di un pre-accordoper inviare lemail al destinatario. Le operazioni per linstaurazionedella chiamata sono le stesse del caso di peering statico diretto mostratoin Figura 12. Nel peering on-demand il SIP service provider di destinazio-ne aperto al pubblico, e deve essere preparato a subire il problemadello spam esistente nel sistema email. Lo spam VoIP (SPIT) consi-derato, dagli abbonati al servizio, pi fastidioso di quello email (lospam email raggiunge lutente ogni volta che questo apre la caselladi posta elettronica, mentre lo SPIT potrebbe far squillare il telefonoin continuazione durante larco della giornata); dunque il SIP serviceprovider di destinazione dovrebbe applicare delle regole per filtrare le


chiamate spam.La soluzione offerta dal peering on-demand una soluzione pi sca- La scelta del

peeringon-demand diretto

labile, che permette di minimizzare le modifiche da effettuare sui SIPproxy di ogni singolo dominio; infatti, a differenza del peering stati-co, non necessario ne modificare i proxy ogni volta che un dominioamministrativo entra a far parte della federazione, ne distribuire la li-sta dei membri della federazione, ma basta pubblicare nel DNS la listadelle federazioni a cui si appartiene. Il rovescio della medaglia perquello di non conoscere direttamente, e a priori, i domini amministra-tivi membri delle federazioni a cui si appartiene. Dunque, alla luce diqueste considerazioni, si giunti alla scelta di adottare, per la nostraarchitettura, il peering on-demand diretto.

In generale, nel tipo di peering scelto (basato sulla federazione, diretto, Il peering direttoon-demand, basatosu federazione

on-demand), lidea di base che il dominio di destinazione possa pub-blicare le informazioni relative al peering nel proprio DNS. Grazie allefederazioni, la rete della sorgente e la rete della destinazione possonotrovare un insieme comune di procedure per il peering. In seguito sa-ranno esposti alcuni esempi che dimostreranno come Alice possa uti-lizzare questo schema per selezionare dinamicamente i meccanismidi peering corretti, allo scopo di parlare con Bob; non prima per diaver illustrato lalgoritmo Domain Policy-Dynamic Delegation DiscoverySystem (DP-DDDS), utilizzato per interrogare il DNS, e per recupe-rare da questo le informazioni utili per instaurare una relazione dipeering tra due membri della stessa federazione.

LAlgoritmo Domain Policy-Dynamic Delegation Discovery System

Lalgoritmo Domain Policy-Dynamic Delegation Discovery System (DP-DDDS) prende spunto dallRFC 3401 [24]. Tale algoritmo prende ininput un dominio (preso dalla URI SIP della destinazione o RequestURI) e linsieme delle federazioni localmente supportate, e come out-put restituisce le regole della federazione con priorit maggiore a cuiappartengono sia il proxy sorgente che il proxy destinatario. Il risultatoguida linstradamento della chiamata.

I passi dellalgoritmo sono i seguenti: I passidellalgoritmo

1. Sono recuperati tutti i record NAPTR in cui i servizi (camposervice) sono di tipo D2P+SIP:;

2. Se non ci sono record NAPTR di questo tipo, allora il destinatarionon aderisce a nessuna federazione, e linstradamento eseguitoattraverso le regole dellRFC 3261 [30];

3. Se c un gruppo di record NAPTR di questo tipo, allora sonoraccolti e messi in ordine crescente rispetto al campo order;

4. Per ogni guppo:


a) Viene estratta la URI da ogni record NAPTR;

b) Se il campo service contiene il valore fed, allora la URIestratta individua la federazione dappartenenza del desti-natario, la quale viene confrontata con le federazioni a cuiappartiene la sorgente (memorizzate in un database locale).Se il mittente ed il destinatario sono membri della stessa fe-derazione, allora la URI estratta precedentemente identificaunivocamente la policy di tale federazione (contenuta nel da-tabase), e vengono restituite in output le regole di tale policy,che guideranno linstradamento. Se non ci sono federazioniin comune, linstradamento eseguito attraverso le regoledellRFC 3261.

Qui di seguito sono riportati alcuni esempi di peering diretto basatosulla federazione, e che dunque fanno uso dellalgoritmo DP-DDDS.

Esempi

Nei seguenti due esempi sono riportati i due casi possibili che sipossono verificare nel contesto del peering on-demand, diretto, basato sul-la federazione, e sono quello in cui la sorgente ed il destinatario dellachiamata appartengono alla stessa federazione, e quello in cui la sor-gente ed il destinatario della chiamata non hanno nessuna federazionein comune.

corrispondenza di federazione In questo caso Alice e Bobappartengono alla stessa federazione (Proxy 1 e Proxy 2 appartengonoalla stessa federazione), cio http://example.com/Wonderland, la qualead esempio implica unulteriore configurazione di chiamata tramiteTLS.

Il database locale del Proxy 1 elenca le federazioni a cui esso appar-tiene (inclusa http://example.com/Wonderland) e le regole da segui-re nel caso in cui una tra queste federazioni sia selezionata per unachiamata. Linsieme dei record NAPTR nel DNS del Proxy 2 include:

IN NAPTR 10 50 "u" "D2P+SIP:fed" ("!^.*$!http://example.com/small-federation!" . )

IN NAPTR 20 50 "u" "D2P+SIP:fed" ("!^.*$!http://example.com/Wonderland!" . )

In Figura 13 rappresentata la cronologia della procedura che prece-de lo stabilimento della connessione tra i due proxy; quando il Proxy1 riceve un INVITE da parte del suo utente Alice, che vuole chiamareBob, interroga il DNS per ottenere i record NAPTR pubblicati dal Proxy2 a cui Bob appartiene; ottenuti i record NAPTR, e verificata la corri-spondenza con una federazione, recupera la policy della federazione neldatabase locale, e ne impiega le regole per linstradamento. Abbiamo

http://example.com/Wonderlandhttp://example.com/Wonderland


supposto che la policy implichi una connessione con trasporto TLS;dunque il Proxy 1 ri-interroga il DNS per ottenere le informazioni sucome contattare il Proxy 2 mediante TLS. Ottenute le informazioninecessarie, Il Proxy 1 pu raggiungere il Proxy 2 con le regole impostedalla federazione, e la connessione pu essere instaurata.

Figura 13: Corrispondenza di federazione semplice.

nessuna corrispondenza di federazione Se il Proxy 2 noncondivide alcuna federazione con il Proxy 1, ad esempio facendo partesolamente di small-federation (e non di Wonderland), allora non possibile alcun peering diretto tra i due proxy.

Il DNS del dominio del Proxy 2 contiene il record:

IN NAPTR 10 50 "u" "D2P+SIP:fed" ("!^.*$!http://example.com/small-federation!" . )

Nella Figura 14 rappresentata la cronologia dei messaggi inviati nelcaso in questione; quando il Proxy 1 riceve un INVITE da parte delsuo utente Alice, che vuole chiamare Bob, interroga il DNS per ottene-re i record NAPTR pubblicati dal Proxy 2 a cui Bob appartiene; otten

labtel.diet.uniroma1.itlabtel.diet.uniroma1.it/tesi/vi/TesiIelapi.pdf · SOMMARIO S copo principale...

Documents

Transcript of labtel.diet.uniroma1.itlabtel.diet.uniroma1.it/tesi/vi/TesiIelapi.pdf · SOMMARIO S copo principale...