ÚVOD DO PROBLEMATIKY PREPOJENIA PRIVÁTNYCH SIETÍ …

Žilinská univerzita v Žiline Katedra telekomunikácií

- 1 -

ÚVOD DO PROBLEMATIKY PREPOJENIA PRIVÁTNYCH

SIETÍ A SIETÍ PROVIDEROV NA BÁZE IP

Moderná konvergovaná telekomunikačná sieť dnes poskytuje svojim zákazníkom

nespočetné množstvo možností a služieb. Poskytuje komfortné využívanie všetkých

komunikačných služieb (hlas, video a dáta). Základom takejto siete je výkonné jadro

(core), teda nosná širokopásmová chrbticová sieť, ku ktorej sú popripájané všetky

periférie (rozhrania). Trend vo svete ukazuje, že je snaha o budovanie nosných

(chrbticových) sietí na báze IP. Rozhrania potom robia konverziu protokolu IP/ (hlasové

služby, dátové služby, mobilné služby a iné). Tým sa podstatne zjednoduší manažovanie

takejto siete (na rozdiel od hybridných sietí tvorených – PSTN, ATM, IP, FR...). Na

druhej strane je ale dôležité definovať štandardy konverzie IP/(ostatné služby). V tejto

práci sa budem venovať problematike IP/hlasová služba, inak povedané prenosom hlasu

po IP sieti – VoIP (Voice over IP), bezpečnostným problémom hlasovej služby v IP sieti

ako aj ich riešeniam.

Na začiatok je nutné povedať, že prenos hlasu po IP sieti (VoIP) je „krok vpred“

smerom k intergrácii služieb, ale ako bude spomenuté v tejto práci, existujú isté riziká

(bezpečnostné, implementačné). Napríklad stačí spomenúť, že je viacero štandardov

(protokolov), ktoré podporujú VoIP. Samozrejme je nutné si tento fakt uvedomiť

a uvažovať, ktorý zo štandardov implementovať, či už z hľadiska bezpečnosti,

kompatibility a budúceho vývoja sietí.

Cieľom mojej práce bude navrhnúť prepojenia privátnych sietí zákazníkov ku

konvergovaným sieťam operátorov (ďalej providerov), pričom sa zamerám na bezpečnosť

prepojenia a na hlasovú službu v IP prostredí (VoIP).

1. DEFINOVANIE SIGNALIZA ČNÝCH PROTOKOLOV VoIP – SIP

(a príbuzné štandardy) a H.323 (a príbuzné štandardy)

1.1 Protokoly rodiny H.323

Štandard H.323 [ 1 ] [ 2 ] zatiaľ prešiel piatimi verziami: H.323v1, H.323v2,

H.323v3, H.323v4 a H.323v5. Verzia 1 nazývaná „Vizuálne telefónne systémy a


- 2 -

zariadenia pre LAN, ktoré neposkytujú zaručenú kvalitu služieb“ bola prijatá ITU

skupinou 16. októbra 1996. Táto verzia neposkytovala garantovanú kvalitu služieb.

Zariadenia vyrábané v tejto dobe pre VoIP (Voice over IP) komunikáciu boli

nekompatibilné z dôvodu neexistencie doporučení, ktorými by sa mali výrobcovia riadiť.

S rozširovaním VoIP prišli požiadavky uskutočňovať spojenie medzi klasickými

telefónnymi sieťami PSTN a prístrojmi založenými na technológií VoIP. Z týchto

dôvodov bola v januári 1998 vytvorená H.323 verzia 2 nazývaná „Systémy paketovej

multimediálnej komunikácie“. Verzia 3 bola prijatá v septembri 1999. Táto verzia

priniesla len niekoľko dôležitých vylepšení do hlavného doporučenia. Väčšina zmien sa

týkala doplnkov H323. Oproti tomu verzia 4 priniesla mnoho vylepšení, týkajúcich sa

hlavne spoľahlivosti, rozšíriteľnosti a pružnosti. Táto verzia bola prijatá v novembri 2000.

V septembri roku 2003 sa prijala zatiaľ posledná 5. verzia H.323, ktorá je v dnešnej dobe

stále upravovaná a obohacovaná o doteraz nešpecifikované časti, ako je napr.

komunikácia medzi gatekeepermi, prenos faxov po paketových sieťach a mechanizmy

rýchleho zostavovania spojenia.

H.323 je množina štandardov ITU pre hlasovú, dátovú a obrazovú komunikáciu

prostredníctvom paketových sietí. H.323 špecifikuje, akým spôsobom by mali terminály

vzájomne komunikovať v IP prostredí. H.323 bol vyvinutý s cieľom zabezpečiť

dostupnosť garantovanej úrovne služieb pre multimediálnu komunikáciu cez LAN.

Štandard je do istej miery odvodený od multimediálneho štandardu H.320 pre ISDN a

využíva tieto štyri typy zariadení: terminál, brána, Gatekeeper a konferenčná jednotka

(Multipoint Control Unit MCU). Tieto elementy sú popísané v kap. 1.1.1 – 1.1.5.

Obr. 1.1.1 - Komponenty H.323 siete


- 3 -

1.1.1 H.323 terminály

Sú to terminály na báze LAN a koncové body na prenos hlasu. Napríklad môžu

byť reprezentované ako: Software bežiaci na počítači alebo Ethernetový telefón. H.323

terminály podporujú prenos hlasu v reálnom čase a umožňujú duplexný prenos. H.323

terminály implementujú prenos hlasu a ich súčasťou sú kodeky posielajúce a prijímajúce

paketizovaný hlas. Podporované kodeky sú: G.711, G.723, G.729A a GSM. Každý kodek

sa vyznačuje určitými špecifickými vlastnosťami, ktoré sú popísané v prílohe 1.

Terminály samozrejme potrebujú byť vybavené signalizačnými funkcionalitami,

ktoré sú nutné pre zostavenie volania, rozpojenie a iné procedúry. Aplikačné štandardy sú

H.255.0 signalizácia, ktorá je časťou signalizácie Q.931; H.245 nutný na výmenu

informácii medzi H.323 entitami o prenosových schopnostiach terminálov; a RAS

spájajúci terminál ku Gatekeeper-u. terminály môžu mať implementované video a dátové

komunikačné schopnosti.

Obr. 1.1.2 - H.323 terminál

1.1.2 Gateways (Brány)

Slúžia ako rozhranie medzi sieťou H.323 a inou sieťou (napr. TDM). Z jednej

strany sa pripájajú k tradičnej hlasovej sieti a z druhej strany k paketovo-orientovanej

sieti. Kedže tvoria rozhranie, musia prekladať signalizačné správy medzi oboma stranami

a komprimovať/ dekomprimovať hlas. Príklad takejto brány je na obrázku 1.1.3.


- 4 -

Obr. 1.1.3 - Funkcionalita brán (SCN – Switched Circuit Network – okruhovo spínaná

sieť)

Dnes existuje veľa druhov brán, počnúc od malých firemných riešení po veľké riešenia

schopné spojovať niekoľko tisícok spojení.

1.1.3 Zóna

Je množina zariadení (terminálov, brán a MCU) riadených jedným Gatekeeperom.

Musí obsahovať aspoň jeden terminál a môže obsahovať viacero brán a MCU. Obsahuje

však len jeden Gatekeeper. Zóna môže byť nezávislá od topológie siete a môže sa skladať

z viacero sieťových segmentov pospájaných navzájom smerovačmi či inými

zariadeniami.

1.1.4 Gatekeeper

Gatekeeper musí plniť niektoré funkcie. Gatekeeper manažuje H.323 zónu,

napríklad zónu zariadení, ktorým prislúcha IP subnet. V sieti môže byť zastúpených

viacero Gatekeeperov, ktoré majú napríklad funkcionalitu rovnomerného spravovania

záťaže alebo ako záložné riešenie pri výpadku (BACK UP). Filozofia definície

Gatekeepera je povoliť H.323 dizajnérom separovať prvotný proces telefónie

z inteligentnej časti siete na Gatekeepere. Typickým príkaldom Gatekeepera je PC , kde

Gateways sú reprezentované nejakou hardwarovou platformou. Gatekeeper robí preklad

adries a routing (smerovanie) pre zariadenia v jeho zóne. Môže to byť napríklad medzi

interným a externým číslovacím systémom. Ďalšou dôležitou funkciou Gatekeepera je

kontrola prístupu, teda ktoré zariadenia majú oprávnenie volať a aké čísla môžu volať.

Medzi ďalšie funkcie patrí SNMP – manažovanie siete.


- 5 -

Gatekeeper je schopný participovať na množstve signalizačných modelov.

Signalizačný model pritom hovorí o tom, ktoré signalizačné správy pôjdu cez Gatekeeper

a ktoré mimo neho, priamo len medzi entitami ako Gateway a terminál. Na obrázku 1.1.4

sú znázornené dva signalizačné modely (vľavo – priamy signalizačný model, vparvo –

Gatekeeperom smerovaná signalizácia).

Obr. 1.1.4 - Signalizačné modely v H.323 sieti

1.1.5 MCU (Multipoint Control Unit)

Zostavujú konferencie medzi tromi a viacerými terminálmi. Logicky sa skladajú

z dvoch častí:

- MC (Multipoint Controler), ktorý má na starosti signalizáciu a kontrolné správy

nevyhnutné pre inicializovanie a manažovanie konferencie

- MP (Multipoint Processor), ktorý akceptuje streamy z koncových bodov, replikuje

ich a smeruje ich na príslušné terminály

1.1.6 H.323 a model OSI – štandardy v H.323

Na obrázku 1.1.5 sú v modeli OSI znázornené štandardy, ktoré využíva H.323.


- 6 -

Obr. 1.1.5 – Štandardy používané v H.323

1.1.7 Popis štandardov audia, dát a videa (Príloha 1)

1.1.8 Popis používaných portov a protokolov v H.323 a niektoré bezpečnostné

riešenia v H.323 (Príloha 2)

1.2 SIP (Session Initiation Protocol) a príbuzné protokoly

Protokol SIP [ 1 ] [ 4 ] bol vytvorený v roku 2000 cez MMUSIC (Multiparty

Multimedia Session Control) pracujúcí pod správou IETF. Štandard SIP zostal originálne

projektovaný pre služby internetových multimediálnych konferencií a je stavaný na

základe jazyka HTML.

Protokol SIP vznikol neskôr ako H.323 a svojou textovou a mnemotechnickou

podobou pripomína rozšírené protokoly SMTP pre prenos elektronickej pošty a protokolu

HTTP pre prenos obsahu na Webe. Vlastná komunikácia prebieha formou výmeny

textových správ ako pri protokole HTTP. Na rozdiel od HTTP protokol SIP môže bežať

nad TCP, ako aj nad UDP. V SIP je jednoduchšie riešenie prechodu cez Firewally ako v

H.323 a umožňuje pridávať nové vlastnosti a funkcie jednoduchým rozšírením syntaxe.


- 7 -

Oproti H.323 má SIP mnoho výhod. Protokol je celkovo jednoduchší a nadväzovanie

spojenia je veľmi rýchle. Na rozdiel od H.323 sa dá adresovať nie len vzdialený počítač,

ale aj konkrétny užívateľ na ňom. Protokol H.323 vie adresovať len terminál a aliasy, ale

tie sa musia prekladať cez Gatekeeper. V príslušnom RFC je SIP charakterizovaný ako

signalizačný protokol slúžiaci k zostaveniu, modifikácii a ukončeniu spojenia medzi

dvoma alebo viacerými účastníkmi. Spojenie môže predstavovať obecne akýkoľvek

multimediálny prenos, v praxi je ale SIP najčastejšie využívaný pre telefonovanie po IP

sieti.

Sila protokolu SIP sa prejaví hlavne v spolupráci s protokolmi SOAP (Simple

Object Access Protocol) pre prístup k webovým službám (webovým stránkam) a SIMPLE

(SIM for Instant Messaging and Presence Leveraging Extensions). Protokol SIMPLE

rozširuje protokol SIP o pokročilé funkcie instant messagingu (transport krátkych správ v

reálnom čase). Protokoly SIP, SOAP a SIMPLE bývajú dohromady nazývané ako Triple-

S, Trojité S.

SIP poskytuje nasledujúce služby:

• lokalizáciu užívateľa – určenie koncového systému pre danú komunikáciu,

• naviazanie spojenia – stanovenie parametrov pre volajúcu a volanú stranu,

• dostupnosť užívateľa – zistenie dostupnosti volanej strany a sledovane jej

prítomnosti,

• užívateľské možnosti – určenie média a jeho parametrov.

SIP naproti tomu :

• neuskutočňuje manažment interaktívnych relácií po ich naviazaní,

• nedokáže zaistiť požadovanú kvalitu služby (QoS), pretože nevie uprednostňovať

prevádzku ani rezervovať potrebné sieťové prostriedky, ale môže spolupracovať s

protokolmi, ktoré sa o zaistenie kvality môžu postarať (napr. RSVP)

• nieje protokol určený k prenosu veľkého objemu dát, ako napr. HTTP, namiesto

toho prenáša iba malý objem dát potrebný pre naviazanie interaktívnych relácií a

okrem toho je ešte schopný prenášať krátke textové správy.


- 8 -

1.2.1 Architektúra protokolu SIP

SIP nie je závislý na topológii sietí a môže spolupracovať s niekoľkými

protokolmi napr. UDP, TCP, IPX alebo PPP. Súčasťou základu architektúry protokolu

SIP sú tieto protokoly SDP, SAP, RTP, RTCP, RTSP a RSVP.

Obr. 1.2.1 - Začlenenie SIP v architektúre protokolov pre VoIP

SDP slúži k popisu možností a typu posielaných implementovaných médií v

termináli. Správy sú zasielané pomocou textových správ, rovnako ako v SIP. SDP posiela

informácie o možnostiach a podpore funkcií terminálu (popisuje použité kódovanie, čísla

portov a parametre). SAP sa používa k informovaniu väčšieho počtu osôb (verejné

konferencie, televízia alebo rozhlas cez internet). SIP rovnako ako H.323 využíva

protokoly transportnej vrstvy (RTP a RTCP). Dodatočne SIP zahrňuje RTSP, ktorý plní

kontrolné funkcie nad inicializáciou spojení a prenosu toku multimediálnych dát s

multimediálnymi servermi, a protokol RSVP rezervuje požadovanú kapacitu pre spojenie

v sieťových prostriedkoch a tým zabezpečuje požadovanú QoS.

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 195.113.147.120:1912Date: Wed, 1 Feb 2006 10:56:34 GMTFrom: <sip:[email protected]>To: <sip:[email protected]>Subject: Hovor 1Priority: normalExpires: 3600CSeq: 1691095645 INVITECall-ID: [email protected]: <sip:[email protected]:5060>Content-Type: application/sdpContent-Length: 143v=0o=jozko 987504994 987504994 IN IP4 195.113.147.120s=Hovor 1c=IN IP4 195.113.147.120t=3196493794 3196497394m=audio 10000 RTP/AVP 0

Obr. 1.2.2 - Správa protokolu SIP s enkapsulovanou správou SDP


- 9 -

1.2.2 Popis protokolu SDP

Protokol SDP [ 3 ] je dôležitým elementom v správach SIP. Má na starosti

dohodnutie portov a protokolov na prenos dát medzi koncovými bodmi. Prenos dát potom

výhradne prebieha medzi terminálmi, teda medzi volajúcim a volaným. Z hľadiska

bezpečnosti komunikácie je veľmi dôležité sledovať, ktoré protokoly a porty SDP

dohodne pri SIP signalizácii. Zápis SDP v SIP správe je typ=hodnota (obr. 1.2.2):

v – verzia protokolu SDP

o – pôvodca (originator) spojenia, udáva jeho užívateľské meno, identifikátor spojenia a

IP adresu

s – meno (subject) spojenia

c – adresa spojenia (connection), na ktorú majú byť posielané dáta, obvykle ide o

multicastovú IP adresu, za ktorou môže nasledovať lomítko a hodnota TTL (Time To

Live) definujúca rozsah šírenia paketov v sieti

a – atribút prenášajúci doplnkové informácie, môže byť v tvare hodnota alebo

meno:hodnota, napríklad recvonly znamená, že odosielateľ tejto správy bude jedine

prijímať dáta

m – popis toku dát (media), udáva typ dát (audio, video, atď.), číslo portu na adrese

udanej riadkom c, na ktorom bude tento prúd dát posielaný, transportný protokol (RTP,

UDP, atď.) a kódovanie, obvykle ako číslo definované ako typ dát v protokole RTP

1.2.3 Architektúra siete SIP

Architektúra siete SIP sa skladá zo štyroch základných elementov: terminálov,

serverov proxy a serverov pre presmerovanie a registráciu. Funkcie terminálu SIP sú

rovnaké ako pri termináli H.323. Server SIP zahrňuje časť funkcie Gatekeepera zo

štandardu H.323. Prihlásenie nemusí byť realizované priamo cez server. Servery sú

užívané hlavne pre smerovanie a presmerovanie prihlásenia. Môžu realizovať aj

overovaciu funkciu, v tom prípade ide o registračný server. Server typu redirect

informuje klienta, aby sa bezprostredne skontaktoval s iným serverom. Server proxy

predáva prihlásenie do ďalšieho servera. Nadviazanie spojenia je menej komplikované a

je kratšie ako v prípade štandardu H.323. Úspešné spojenie pomocou SIP sa skladá z

dvoch príkazov: INVITE a ACK na strane volajúceho. Hovor je prerušený po príkaze

BYE.


- 10 -

Obr. 1.2.3 - Architektúra SIP siete

1.2.4 Signalizácia

SIP je protokol typu klient-server. Klient nadväzuje spojenie so serverom. Jedno

zariadenie môže pracovať súčasne ako klient i server. Napríklad telefón pracuje ako klient

pre odchádzajúce volania a ako server pre prichádzajúce volania. Fakt, že protokol je typu

klient-server neznamená, že komunikácia môže byť iba dvojbodová. Hovor, ktorý môže

byť hlasový alebo multimediálny, môže prebiehať medzi viacerými účastníkmi.

Multimediálne dáta sú potom prenášané naraz pre všetkých účastníkov spojením typu

multicast, spojením typu unicast medzi každou dvojicou účastníkov alebo ako

kombinácia týchto metód. Správy protokolu SIP sú dva typy – REQUEST (požiadavka)

a RESPONSE (odpoveď). Správy SIP:

SIP Request (požiadavky) správy

INVITE – žiadosť o nadviazanie spojenia alebo o zmenu parametrov už existujúceho

spojenia

BYE – žiadosť o rozpojenie spojenia

ACK – žiadosť, ktorou klient potvrdzuje, že obdržal odpoveď na žiadost INVITE

REGISTER – žiadosť o registráciu klienta na register server

CANCEL – žiadosť o zrušenie prebiehajúcej žiadosti INVITE

OPTIONS – žiadosť o zaslanie podporovaných funkcií na serveri

INFO – prenos informácií počas hovoru (rozšírenie protokolu SIP popísané v RFC2976)


- 11 -

SIP Response (odpoveď) správy

1xx – informačná odpoveď, napr. 180 ringing (vyzváňanie)

2xx – úspešná odpoveď, napr. 200 ok

3xx – odpoveď presmerovania, napr. 302 moved temporarily (dočasné presmerovanie)

4xx – odpoveď, že požiadavka zlyhala, napr. 404 not found (nenájdené)

5xx – odpoveď, že server nepodporuje službu, napr. 503 service unavailable (služba

neprípustná)

6xx – odpoveď o globálnej chybe, napr. 600 busy everywhere (neprípustné všade)

Volajúci klient môže kontaktovať volaný server priamo alebo prostredníctvom

iného servera, ktorý pracuje ako tzv. proxy alebo redirect server. Priame volanie sa

používa, ak klient vie IP adresu serveru, na ktorom sa nachádza volaný užívateľ. Priebeh

spojenia je znázornený na obr. 1.2.4.

1 2 3

4 5 6

7 8 9

* 8 #

1 2 3

4 5 6

7 8 9

* 8 #

Obr. 1.2.4 - Priame volanie (volajúci-volaný)

Častejší prípad je keď klient nevie IP adresu servera, na ktorom sa nachádza

volaný užívateľ. V tom prípade klient naviaže spojenie cez proxy alebo redirect server.

Ten cez lokalizačnú službu zistí IP adresu volaného severa. Lokalizačná služba

najčastejšie pracuje na inom protokole ako SIP, väčšinou ide o protokol typu LDAP,

rwho či finger. Lokalizačná služba môže vrátiť niekoľko IP adries, preto proxy server

musí kontaktovať všetky servery a čakať od nich odpoveď. Ak niektorý odpovie, ostatné

žiadosti môžu byť stornované správou CANCEL. Na obrázku 1.2.5 a 1.2.6 sú znázornené

možné priebehy spojenia cez proxy a redirect server.


- 12 -

1 2 3

4 5 6

7 8 9

* 8 #

1 2 3

4 5 6

7 8 9

* 8 #

IDC

Obr. 1.2.5 - Nadviazanie spojenia cez proxy server

[email protected]

1 2 3

4 5 6

7 8 9

* 8 #

1 2 3

4 5 6

7 8 9

* 8 #

1.

2.

ACK

3.

[email protected]

Redirect server

IDC

Lokalizačná služba

INVITE

from: pic

hlos@vini

ce.sk

to: jozo

@vinice.s

k

Reques

t-URI: jo

zo@vini

ce.sk

INVITE

from: [email protected]

to: [email protected]

Request-URI: [email protected]

[email protected] [email protected]

200 ok

ACK

4.

5.

6.

7.

8.

302 Mo

ved

jozo@vrab

le.sk

SIP žiadosť

SIP odpoveď

Iný protokol100

trying

180 ringing

9.10.

Obr. 1.2.6 - Nadviazanie spojenia cez redirect server (podrobný popis správ je na obr.

1.2.8)

1 2 3

4 5 6

7 8 9

* 8 #

1 2 3

4 5 6

7 8 9

* 8 #

1 2 3

4 5 6

7 8 9

* 8 #

Obr. 1.2.7 - Registrácia užívateľa na register server a rozpad spojenia


- 13 -

Obr. 1.2.8 - Podrobný popis správ výstavby spojenia cez redirect server

1.2.5 Adresácia v SIP

SIP URL majú rôzne formy (obecne sip: user@domain) a môžu obsahovať

telefónne čísla. Napr. sip:[email protected] adresa počítača užívateľa abc v doméne ferko.sk

sip:[email protected] – telefónne číslo užívateľa dosiahnuteľného

prostredníctvom brány.

Podpora webovej adresácie, ako aj telefónnych čísel umožňuje IP komunikácii bez

väčších problémov prechádzať medzi telefónnou sieťou a Internetom. Užívatelia v

ktorejkoľvek sieti tak môžu komunikovať s kýmkoľvek v telefónnej sieti, alebo v

Internete a nemusia pritom vymeniť svoje zariadenia. IP zariadenia s podporou SIP

(telefóny, počítače) môžu komunikovať priamo, pokiaľ poznajú URL druhej strany.

Čo sa týka adries tak najdôležitejšie adresy v SIP správach sú: FROM (v hlavičke

od koho správa prichádza), TO (v hlavičke komu je správa adresovaná) a REQUEST-URI

(väčšinou zhodná adresa s TO). Ale REQUEST-URI môže byť aj odlišná od adresy TO

a to v prípade, ak je správa posielaná cez proxy server . Vtedy je správa prepísaná proxy

serverom na adresu nasledujúceho serveru. Hlavička TO sa pri prechode proxy serverom

nemení (obr. 1.2.5). V žiadostiach REGISTER je REQUEST-URI vždy adresa register

servera – jeho doménové meno (obr. 1.2.7). IP adresa proxy servera alebo redirect servera

môže byť priamo nakonfigurovaná v zariadení volajúceho, alebo je získaná pomocou


- 14 -

DNS servera. Vtedy je poslaná na DNS server požiadavka na vrátenie SRV záznamov.

Ako odpoveď je vrátený zoznam IP adries a portov SIP serverov.

1.2.6 Prenos správ SIP v TCP/ UDP paketoch a popis štandartne používaných

portov

Na obrázku 1.2.9 je znázornený priebeh zapúzdrenia správy SIP do transportnej vrstvy

[ 5 ]

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 195.113.147.120:1912Date: Wed, 1 Feb 2006 10:56:34 GMTFrom: <sip:[email protected]>To: <sip:[email protected]>Subject: Hovor 1Priority: normalExpires: 3600CSeq: 1691095645 INVITECall-ID: [email protected]: <sip:[email protected]:5060>Content-Type: application/sdpContent-Length: 143v=0o=jozko 987504994 987504994 IN IP4 195.113.147.120s=Hovor 1c=IN IP4 195.113.147.120t=3196493794 3196497394m=audio 10000 RTP/AVP 0

obr. 1.2.9 – Zapúzdrenie SIP správy do transportnej vrstvy

SIP verzií 1 a 2 používa štandartne protokol UDP a port 5060 pre signalizáciu,

kontrolu a SIP správy. Vyššie verzie už používajú protokol TCP a port 5060. SDP potom

cez SIP správy dohoduje porty a protokol pre prenos dát v reálnom čase. Štandartne sú

vyberané porty z dynamického rozsahu 1024-65535, pričom prenos dát zabezpečuje

štandartne protokol UDP (vyššie verzie SIP uvažujú o prenose dát v reálnom čase cez

TCP). Paketizáciu dát v reálnom čase zabezpečujú protokoly RTP a RTCP. Paketizované

dáta (napr .hlas) sú potom prenášané ako užitočná informácia v UDP paketoch. Príklad

takejto komunikácie je na obr. 1.2.10.


- 15 -

Obr. 1.2.10 – Problematické miesta vo VoIP

Na obr. 1.2.10 je viditeľné, kde nastávajú otázky povolenia a zakázania

protokolov a portov pri službách VoIP. Tieto miesta sú aj zdanlivo najcitlivejšími bodmi

komunikácie VoIP. Sú však aj iné miesta v sieťovej hierarchii, ktoré je nutné sledovať

(napr. NAT). Týmto problematickým miestam bude venovaný priestor v ďalších

kapitolách tejto práce (3.2 a 3.3).

1.2.7 Kvalita a bezpečnosť hlasovej služby pri použití protokolu SIP

SIP podporuje interaktívne aplikácie, ktoré sú citlivé na oneskorenie a jeho

kolísanie a taktiež sú citlivé na stratu datagramov, ku ktorej dochádza pri vysokom v

zaťažení siete. Tie nemusia vystačiť iba s bežnou úrovňou služby typu „best effort“,

poskytovanou v IP sieťach a môžu vyžadovať konkrétnejšiu a vyššiu úroveň prenosovej

služby na prenos užívateľských dát a signalizácie.

SIP je taktiež zabezpečený z hľadiska autentifikácie a ochrany dát (RFC 3323,

3325, 3329) a spolupracuje s bezpečnostnými prvkami na Internete, ako je napr. firewall.

Zabezpečenie SIP signalizácie a mediálneho prenosu je rozpracované v kapitolách

4.1, 4.2, 4.3 a 4.4.


- 16 -

1.3 SIP – T (Session Initiation Protocol for Telephones) [ 6 ]

Dôležitou vlastnosťou každej SIP sieťovej štruktúry je rešpektovanie architektúry

PSTN a zabezpečenie transparentnosti medzi sieťami. Tradičné telekomunikačné služby

ako CALL WAITING (čakanie volania) či FREEPHONE NUMBERS (bezplatné čísla) a

pod., implementované v signalizačných protokoloch PSTN sietí, ako napr. SS7 by mali

byť dostupné aj v SIP sieti. Je nevyhnutné, aby SIP podporoval všetky základné funkcie

a aby bol schopný rozlišovať medzi SIP terminálmi a SS7 terminálmi. Je podstatné, aby

Gateway (brány) mali informácie o oboch stranách siete (SIP aj SS7), pretože práve brána

tvorí rozhranie medzi oboma sieťami.

SIP – T predstavuje nosnú štruktúru pri integrácii prenosu starších typov

signalizácií (v PSTN) cez SIP signalizačné správy. SIP – T robí dve techniky nazývané

ako: enkapsulácia (encapsulation - zapúzdrenie) a translácia (translation - preklad). Na

SIP – ISUP bráne sú SS7 ISUP správy enkapsulované do SIP správy, tak aby neboli

stratené dôležité informácie o službách. Rozhrania ako proxy server, ktorý smeruje SIP

REQUEST (požiadavku), nerozumie správam typu ISUP. Správy typu ISUP sú

prekladané do hlavičiek protokolu SIP, tak aby bolo jasné ako bude SIP REQUEST

smerovaná.

Čisté správy typu SIP obsahujú všetky mechanizmy na zostavovanie a rozpad

spojenia, ale nemajú definované mechanizmy na prenos informácií počas SIP session

(spojenia) ako je to v ISUP (INF/INR query). Tieto medzistavové informácie by

neovplyvnili nadviazané SIP spojenie. Ale prenos podobných správ aplikačnej vrstvy je

vo väčšine prípadov žiadúci.

1.3.1 Popis problémov pri zabezpečení transparentnosti prenosu správ SIP – SS7

SS7 - SIP požiadavky na spoluprácu SIP - T funkcie

transparentnosť prenosu ISUP signalizácie enkapsulácia ISUP správ do SIP

smerovateľnosť SIP správ v závislosti na ISUP preklad informácií správ ISUP do hlavičky SIP

prenos signalizačných správ ISUP počas spojenia použitie metódy INFO pre takúto signalizáciu

Tabuľka 1


- 17 -

Obr. 1.3.1 - Príklad SIP správy obsahujúcej ISUP správu

1.3.2 Typy SIP – ISUP spojení

Reálne v telekomunikačných sieťach môžeme uvažovať o troch prípadoch, kdey

bude užitočné použiť protokol SIP – T: 1, ak hovor začína v PSTN sieti a smeruje do IP

sieti, teda ak volajúci volá z PSTN sieti užívateľa v IP sieti (podporujúcej SIP)

2, ak hovor začína v IP sieti a smeruje do PSTN sieti, teda ak volaný terminál je v PSTN

sieti a volajúci v IP sieti

3, ak volanie smeruje z PSTN sieti do PSTN sieti ale cez veľkú IP sieť

Popis SIP – ISUP spojení z hľadiska výstavby a rozpadu spojenia

1, hovor smerujúci z PSTN siete do IP siete


- 18 -

2, hovor smerujúci z IP siete do PSTN siete

3, hovor smerujúci z PSTN do PSTN siete cez IP sieť

1.4 Porovnanie protokolov H.323 a SIP [ 7 ]

1.4.1 SIP verzus H.323

H.323 protokol vníma IP telefóniu ako aplikáciu multimediálnych konferenčných

služieb. Štandard rozširuje rodinu protokolov vyvinutých organizáciou ITU-T. SIP je

novší signalizačný protokol aplikačnej vrstvy, určený na budovanie, modifikáciu a

ukončenia hlasových a multimediálnych relácií medzi dvoma alebo viacerými účastníkmi

vyvinutý organizáciou IETF. Architektúra protokolu je typu klient/server, je podobná

HTTP, nezávislá od transportnej vrstvy, so silnou podporou SDP. Tábor podporovateľov

SIP protokolu zastáva názor, že H.323 je veľmi komplexný protokol a práve SIP dokáže

využiť dynamickú povahu IP sietí.


- 19 -

1.4.2 Spoľahlivosť spojenia

Protokol H.323 obsahuje viacero mechanizmov, pomocou ktorých je schopný

vyrovnať sa s výpadkami komunikačných elementov. Napríklad ak nastane výpadok

správcu brány, protokol je schopný využiť služby iného dostupného správcu. Rovnako

aj v prípade, že je hovor smerovaný cez komunikačný element, ktorá zlyhal, je ho možné

presmerovať cez iný dostupný element, bez nutnosti prerušenia hovoru. SIP protokol

nemá definované žiadne procedúry, ktoré by umožňovali ošetrenie takýchto výpadkov.

Neexistujú žiadne prostriedky na detekciu výpadku niektorého z komunikačných

elementov. Jedinou výnimkou je detekcia výpadku UA, kedy pri vyslaní správy INVITE,

proxy serverom, vyprší časový interval pre odpoveď od UA. To môže signalizovať jeho

nedostupnosť. Protokol neumožňuje presmerovanie prebiehajúceho spojenia v prípade

výpadku niektorého z aktívnych komunikačných elementov.

1.4.3 Kódovanie správ

Oba protokoly prenášajú samotné hlasové a obrazové dáta v binárnej forme,

komprimované pomocou niektorého z kodekov. Majú však rozdielnu reprezentáciu

svojich riadiacich správ. Nároky na prenos riadiacich správ sú však neporovnateľne nižšie

ako nároky na prenos samotných komunikačných dát. H.323 je binárnym protokolom, to

znamená, že svoje signalizačné správy kóduje v binárnom formáte pomocou špecifikácie

ASN.1. Takto zakódované správy sú v kompaktnom formáte. Ten vyžaduje menšie

prenosové pásmo ako v prípade prenosu ich textovej formy. Jedinou výnimkou je

komunikačný protokol H.248, ktorý umožňuje reprezentovať svoje správy rovnako v

textovej, ako aj binárnej forme. Existujú štúdie, zaoberajúce sa výskumom efektivity

prenosu oboch foriem správ tohto protokolu, ktoré uvádzajú, že neexistuje podstatný

rozdiel v prenosových nárokoch na prenos oboch typov správ. Správy protokolu SIP sú

kódované v textovej forme podľa štandardu ANSI, vďaka čomu sú čitateľné pre človeka,

na rozdiel od binárnej formy správ protokolu H.323. Rovnako aj implementácia funkcií

na ich tvorbu a rozoznávanie v rôznych programovacích jazykoch je omnoho

jednoduchšia. Textovo kódované správy sú však väčšie ako v prípade ich binárnej

reprezentácie, takže sú menej vhodné na prenos v úzkopásmovom prostredí. Organizácia

IETF definovala viacero návrhov pre rôzne typy kompresie takto reprezentovaných správ.

Ich použitie zaznamenalo zmenšenie veľkosti správ, avšak ich implementácia


- 20 -

predstavovala omnoho väčšie výpočtové zaťaženie pre systém. Z dôvodu, že sa prenosové

kapacity stále zvyšujú, je rozdiel medzi náročnosťou prenosu textových a binárnych správ

oboch protokolov zanedbateľný. Naopak, práve rozdiel vo výpočtovej náročnosti a

jednoduchosti implementácie sa dostáva v poslednej dobe čoraz viac do popredia a hovorí

v prospech textovej reprezentácie riadiacich správ.

1.4.4 Rozšíriteľnosť štandardov a spätná kompatibilita

Podpora štandardov na implementáciu novovznikajúcich požiadaviek a vlastností

je zásadným znakom každého z protokolov. Návrh protokolu H.323 umožňuje pridávanie

nových vlastností a služieb, a to len pomocou vydania novej verzie tohto protokolu. Ich

vydávanie riadi organizácia ITUT, ktorá definuje nové funkcie, ktoré bude protokol

poskytovať a zároveň dbá na spätnú kompatibilitu jednotlivých verzií. Prináša to však so

sebou veľkú zložitosť protokolu a nižšiu flexibilitu v porovnaní s protokolom SIP. Spätná

kompatibilita môže však byť veľkou výhodou a často ekonomickým riešením pre

používateľa, ktorý požaduje súčasné nasadenie viacerých zariadení s podporou rôznych

verzií tohto protokolu. Protokol SIP v sebe obsahuje mechanizmy na pridávanie nových

používateľsky špecifických funkcií. Takto je umožnené výrobcom poskytovať rôzne

neštandardizované funkcie, avšak s rizikom možnej nekompatibility zariadení. Protokol

sa snaží byť čo najjednoduchším a obsahuje v sebe aj mechanizmy na redukciu

nepoužívaných služieb. Tento prístup šetrí veľkosť kódu a redukuje tiež komplexnosť, za

cenu straty spätnej kompatibility.

1.4.5 Riadenie vyrovnávania záťaže v sieti

Protokol H.323 pomocou RAS správ umožňuje riadiť prevádzku cez viacero

správcov

prípadne brán, za účelom vyrovnania záťaže jednotlivých komunikačných elementov. SIP

v sebe neobsahuje žiadnu podobnú funkciu, plne sa v dnešnej dobe spolieha na služby

rozšírenia doménového pomenovacieho serveru DNS SRV (Domain Name System

Service). V budúcnosti však počíta za týmto účelom využiť HTTP riadenie vyrovnania

prevádzky s možnou modifikáciou pre rozoznávanie SIP hlavičiek.


- 21 -

1.4.6 Účtovanie hovorov

Pri ktoromkoľvek spôsobe priebehu H.323 spojenia má správca brány vždy

dostatok informácií o smerovaní a trvaní hovoru, takže je veľmi ľahko schopný

uskutočniť účtovanie hovorov. V SIP protokole jediným komponentom, ktorý je schopný

vykonávať účtovanie hovorov, je proxy server. Tento však za týmto účelom musí počas

celého trvania spojenia zostať prostredníkom medzi oboma komunikujúcimi entitami, aby

bol schopný určiť presné trvanie hovoru.

1.4.7 Oneskorenie budovanie spojenia

Oneskorenie sa definuje ako počet komunikačných slučiek nutných na

vybudovanie spojenia medzi volaným a volajúcim. Je závislé od skutočnosti, či je použitý

správca brány alebo nie. Vo verzii H.323 v1 bolo toto oneskorenie veľmi značné (6-7

slučiek). H.323 v2 (fast connect) dosiahlo výrazného zlepšenia, a to až na úroveň 2,5

slučky. SIP a H.323 v3 ešte viac zdokonalili stratégiu budovania spojenia, čím

oneskorenie kleslo na hodnotu 1,5 slučky. Využívaním UDP je možné vynechať slučky

asociované s transportnou vrstvou.

1.4.8 Komplexnosť

H.323 je oveľa komplexnejším protokolom ako SIP. Zahŕňa H.245 pre riadenie

spojenia, H.332 pre multimediálne konferencie, H.450 pre podporné služby, H.235 pre

bezpečnosť a kódovanie a H.246 pre spoluprácu so sieťami s prepojovaním kanálov. Veľa

služieb pritom požaduje vzájomnú interakciu týchto protokolov, čo ešte viac zvyšuje

komplexnosť. Na druhej strane SIP a SDP sú menej komplikované. Jednoduchý SIP

telefón obsahuje štyri základné hlavičky (To, From, Call-ID a Cseq) a tri typy

požiadaviek (INVITE, ACK a BYE), čo veľmi zjednodušuje úroveň programovania a

obsluhy.

1.4.9 Detekcia slučky

Protokol H.323 do verzie 3 nepodporoval mechanizmus detekcie slučky. Až vo

verzii 3 sa začína využívať pole „Path Value – Identifikácia cesty“ s indikáciou


- 22 -

maximálneho počtu správcov brán v ceste signalizácie. Tento prístup výrazne redukuje

pomer slučiek, avšak nie tak dokonale ako algoritmus použitý v SIP, ktorý je veľmi

podobný BGP (Border Gateway Protocol – protokol smerovania paketov).

1.4.10 Bezpečnosť

H.323 definuje mechanizmus bezpečnosti pomocou podporného protokolu H.235,

prípadne za účelom zabezpečenia spojenia umožňuje využiť aj SSL protokol (Secure

Socket Layer – protokol na bezpečný prenos informácií). SIP využíva end-to-end

autorizáciu a kódovanie s podporou buď PGP (RFC 1991), alebo S/MIME (Secure

Multipurpose Internet Mail Extensions – štandard pre zabezpečený prenos mailových

správ) (RFC 2311, 2312). Bezpečnosť komunikačného kanálu zabezpečuje využitím

transportnej vrstvy na báze mechanizmov SSL alebo HTTPS. Bližší popis v kapitole 4.1.

1.4.11 Mobilita

H.323 nepodporuje mobilitu klienta, pričom SIP klient nie je obmedzený na

používanie jedného definovaného koncového zariadenia. Dokonca nie je obmedzený na

používanie len jedného koncového zariadenia v danom čase.

1.4.12 Dodatočne podporované služby

Protokol SIP podporuje schopnosť vybudovať spojene medzi dvoma

komunikujúcimi stranami prostredníctvom inej nezúčastnenej strany. Táto funkcia sa

označuje ako riadenie nezúčastnenou treťou stranou. V súčasnosti sa na jej implementácii

do protokolu H.323 intenzívne pracuje. Na definovanie schopností multimediálnych

terminálov využíva H.323 servisný protokol H.245. Možnosti terminálov sú zadefinované

skupinou štruktúr (Capability Descriptor – popis schopností), ktoré obsahujú veľmi

precízne informácie o možnostiach každého terminálu. SIP využíva podporu SDP, takže

volajúci môže pomocou požiadavky OPTION zistiť komunikačné schopnosti volanej

strany. Na základe odpovede prispôsobí svoje možnosti prenosu. V súčasnosti SIP nemá

tak komfortnú podporu definície schopností terminálov, akú zabezpečuje H.245.


- 23 -

1.4.13 Video a dátové konferencie

H.323 pomocou MCU jednotky poskytuje riadiace schopnosti pre uskutočnenie

videokonferencií. Rovnako podporuje funkcie na zabezpečenie synchronizácie medzi

audio a video dátovými tokmi a pomocou protokolu T.120 umožňuje uskutočňovať aj

dátové konferenčné spojenia. SIP protokol obsahuje len veľmi obmedzené schopnosti pre

videokonferencie a vôbec nepodporuje dátové konferencie. Nepodporuje žiadne

protokoly na riadenie konferenčného spojenia za účelom synchronizácie hlasových a

obrazových tokov.

1.4.14 Budovanie a ukončenie spojenia

Výstavba spojenia H.323 v2 je založená na spoľahlivom transportnom protokole,

preto je spojenie budované v dvoch fázach: fáza TCP a fáza volania. H.323 v3 podporuje

TCP aj UDP, čo zjednodušuje procedúru budovania spojenia. SIP procedúra budovania

spojenia je veľmi podobná H.323 v3.

1.4.15 Zhodnotenie

Z porovnaní SIP a H.323 protokolov je zrejmé, že neustálym vývojom nových

verzií signalizačných protokolov sa ich vlastnosti veľmi približujú. V každom prípade je

však potrebné podotknúť, že SIP protokol v súčasnosti najmä vďaka svojej vysokej

flexibilite, dynamickosti a jednoduchej implementácii stále čoraz viac naberá na

význame.

Protokol H.323 ťaží hlavne zo svojej bohatej histórie a širokého rozšírenia.

Poskytuje obrovské množstvo funkcií, z ktorých mnohé chýbajú stále sa rozvíjajúcemu

protokolu SIP, alebo nedosahujú porovnateľnú kvalitu. Na druhej strane protokol SIP

prináša množstvo nových služieb, hlavne v oblasti lokalizácie, možností tzv. objednania

si hovoru, alebo nastavenia preferovania určitej formy komunikácie. Z týchto dôvodov

bude v ďalších kapitolách spracovaná téma VoIP so zameraním sa na signalizačný

protokol SIP.


- 24 -

2. PROTOKOLY ZABEZPE ČUJÚCE PRENOS DÁT V REÁLNOM

ČASE (zabezpečujúce paketizáciu)

2.1 Protokoly RTP (Real-time Transport Protocol) a RTCP (Real-time Transport

Control Protocol)

Prenos dát v reálnom čase vyžaduje výkonnú komunikačnú sieť. To znamená, že

musí spĺňať vysoké nároky na prenosovú rýchlosť, oneskorenie a kvalitu služieb. To je

hlavný rozdiel medzi prenosom statických dát a prenosom dát v reálnom čase. Preto

protokoly bežne používané pre prenos statických dát nevyhovujú prenosom dát v reálnom

čase.

Protokoly, ktoré sú vhodné pre spoľahlivý prenos dát v sieti s malou šírkou pásma

sú protokoly HTTP a FTP. Sú založené na protokoloch TCP/IP. Platí, že ak je paket

stratený či poškodený, dojde k jeho opätovnému vyslaniu. Z tohto dôvodu sa pre prenos

dát v reálnom čase používajú iné protokoly ako TCP. Jeden z najčastejšie používaných

protokolov je UDP (User Datagram Protocol). UDP je nespoľahlivý protokol, ktorý

nezaručuje, aby každý vyslaný paket bol doručený do cieľa. Dokonca nezaručuje ani to,

aby pakety dorazili v správnom poradí.

Internetovým štandardom pre prenos dát v reálnom čase je protokol RTP [ 8 ] [ 9 ]

[ 10 ], ktorý využíva protokol UDP.

Obr. 2.1.1 – Začlenenie RTP v architektúre protokolov

RTP môže byť použitý ako pre unicastové (pre každý cieľ je vysielaná zo zdroja jedna

kópia) tak aj pre multicastové (dáta sú vysielané zo zdroja jedenkrát a záleží od siete, aby

zaistila prenos dát do rozdielnych miest) služby siete.


- 25 -

2.1.1 Služby RTP

RTP umožňuje pred samotným začatím prenosu identifikovať typ dát, ktoré budú

prenášané, určiť poradie paketov v akom budú dáta posielané a synchronizovať dátové

toky z rozdielnych zdrojov. Pre dátové pakety RTP nie je garantované, že dorazia

v poradí v akom boli vysielané, ani nie je garantované, že dorazia všetky. Je na

adresátovi, aby rekonštruoval poradie prijatých paketov a detekoval neprijaté pakety

pomocou informácií v záhlaví paketu. Zatiaľ čo RTP neposkytuje žiadny mechanizmus

k zaisteniu včasného doručenia alebo k poskytnutiu záruky QoS (Quality of Service -

kvalita služieb), sú tieto mechanizmy poskytované kontrolným protokolom RTCP, ktorý

umožňuje sledovanie kvality distribúcie dát. RTCP tiež poskytuje kontrolný

a identifikačný mechanizmus pre RTP prenosy.

Obr. 2.1.2 - Príklad RTP session (spojenia)

Vytvorenie RTP session (spojenia) je vlastne asociácia skupiny aplikácií,

komunikujúcich s RTP. Session (spojenie) je identifikované sieťovou adresou a párom

portov. Jeden port je určený pre prenos dát a druhý port je určený pre RTCP kontrolné

dáta. Účasť na spojení môže byť pasívny príjem dát, vysielanie dát alebo oboje (príjem aj

vysielanie). Každý rozdielny typ dát je prenášaný iným spojením (session). Napríklad ak

je pri videokonferencii prenášaný zvuk aj obraz zároveň, je jedno spojenie určené pre

prenos audio a druhé spojenie pre video dáta. To umožní účastníkovi výber typu dát,

ktorý chce prijímať (napr. ak je niekto v mieste s nízkou šírkou pásma).


- 26 -

2.1.2 Štruktúra RTP a RTCP paketov

Dátový paket RTP (znázornený na obrázku 2.1.3)

Obr. 2.1.3 - Dátový paket RTP

Popis jednotlivých bitov v pakete a vysvetlenie významu:

V – verzia RTP protokolu (2 bity)

P – doplnenie (1 bit), ak je tento bit nastavený, je na konci paketu jeden alebo viacej

bytov, ktoré nie sú súčasťou užitočného obsahu. Úplne posledný byte v pakete indikuje

počet doplnených bytov. Doplnenie je využívané niektorými šifrovacími algoritmami.

X – extension (rozšírenie) 1 bit, ak je tento bit nastavený, nasleduje za pevným záhlavím

jedno rozšírené záhlavie. Tento mechanizmus umožňuje vloženie rozširujúcich informácií

do záhlavia RTP.

CSRC (CC) - 4 bity, je to počet CSRC identifikátorov, ktoré nasledujú za pevným

záhlavím. Ak je počet CSRC nula, je zdrojom synchronizácie zdroj užitočného obsahu.

M – záložka 1 bit, záložkový bit definovaný konkrétnym profilom média.

PT – typ užitočného obsahu 7 bitov, index z tabuľky profilu média, ktorý popisuje formát

užitočného obsahu.

Sequence Number – 16 bitov, jedinečné číslo paketu, ktoré popisuje pozíciu paketu

v poradí paketov. Číslo paketu je inkrementované po každom odoslanom pakete.

RTP timestamp – 32 bitov, vyjadruje moment odobrania vzorky prvého bytu užitočného

obsahu.


- 27 -

SSRC – 32 bitov, identifikuje synchronizačný zdroj. Ak je počet CSRC nula, je zdroj

užitočného obsahu zdrojom synchronizácie. Ak je CSRC nenulové, SSRC identifikuje

mixér.

Sample data bits – samotné prenášané dáta (prispievajúcich zdrojov do užitočného obsahu

môže byť max. 16 a počet určuje pole CSRC (CC) )

Kontrolný paket RTCP

Ako dodatok k multimediálnym dátam pre spojenie, sú pakety kontrolných dát

RTCP zasielané všetkým účastníkom spojenia. RTCP pakety môžu obsahovať informácie

o QoS (kvalita služieb) pre účastníkov spojenia, informácie o zdroji dát na dátovom porte

a štatistiky k dátam, ktoré boli doteraz prenášané. Je niekoľko typov RTCP paketov:

- sender report (správa odosielateľa) SR

- receiver report (správa príjemcu) RR

- source description (popis zdroja) SDES

- BYE, APP a iné

RTCP pakety sú zlúčiteľné a sú zasielané ako skupina minimálne dvoch paketov

(report paket a paket popisu zdroja). Všetci účastníci spojenia posielajú RTCP pakety.

Účastník, ktorý nedávno poslal paket, vydáva správu odosielateľa. Tá obsahuje celkový

počet odoslaných paketov a bytov a aj informáciu, ktorá môže byť využitá

k synchronizácii toku médií z iných spojov. Účastníci spojenia posielajú v pravidelných

intervaloch správu príjemcu určenú pre ostatné zdroje, z ktorých prijímajú dátové pakety.

Správa príjemcu obsahuje informáciu o počte stratených paketov, najvyššie číslo poradia

a TIMESTAMPu, ktorý môže byť použitý k odhadu obojsmerného oneskorenia medzi

odosielateľom a adresátom. Prvý paket v skupine RTCP paketov musí byť paket správy aj

v prípade, že neboli prijaté ani odoslané žiadne dáta. Všetky skupiny RTCP paketov

musia obsahovať popis zdroja (SDES), ktorý obsahuje kanonické meno (CNAME) –

identifikátor zdroja. Popis zdroja môže obsahovať aj ďalšie informácie ako je meno

zdroja, emailová adresa, telefónne číslo, zemepisná poloha, názov aplikácie alebo správu

popisujúcu aktuálny stav zdroja. Pokiaľ už zdroj nie je aktívny, pošle RTCP protokol

paket BYE. V správe môže byť zahrnutý dôvod zrušenia spojenia. Paket APP poskytuje

aplikáciám mechanizmus pre definovanie a zasielanie užívateľských informácií cez RTP

riadiaci port.


- 28 -

RTCP SR (sender report) – správa odosielateľa (obr. 2.1.4)

Správy SR umožňujú medzizdrojovú synchronizáciu, zabezpečujú meranie

parametrov pre prenos RTP, spätnú väzbu o prenesených dátach, prenášajú pakety

odosielateľa a počítadlo bytov, umožňujú príjemcovi kalkulovať so stratami a zahrňujú

správy RR pre odosielateľa.

Obr. 2.1.4 – RTCP SR

Popis polí v pakete:





RC – počet identifikátorov

RT=RR=200 – identifikácia, že sa jedná o SR

Length – dĺžka paketu

Sender SSRC – synchronizačné číslo odosielateľa

NTP timestamp + RTP timestamp = medzizdrojová synchronizácia

NTP timestamp – meranie a kontrola parametrov pri prenose

Cumulative number of packets sent – celkové číslo poslaných paketov

Cumulative number of octets sent – celkové číslo poslaných Bytov


- 29 -

RTCP RR (receiver report) – správa príjemcu (obr. 2.1.5)

Správy RR predovšetkým odpovedajú a posielajú spätnú väzbu o parametroch pre

RTP prenos (oneskorenie, poradové číslo, jitter, strata paketov...) a upravujú na základe

týchto parametrov kodek, prenosovú rýchlosť a iné parametre.

Obr. 2.1.5 – RTCP RR






RC – počet identifikátorov

RT=RR=201 – identifikácia, že sa jedná o RR


Sender SSRC – správa o SSRC odosielateľa

SSRC of sender reported in this block – popis SSRC

Fraction lost – strata rámcov

Cumulative number of packets lost – priemerné číslo straty paketov

Extended highest sequence number received – najvyššie prijaté sekvenčné číslo

Interarrival jitter – správa o jitteri po prijatí paketu

Last SR – posledná SR

DLSR – oneskorenie od poslednej SR

Further receiver report blocks – ďalšie bloky odpovedí príjemcu


- 30 -

Receiver report block – blok odpovede príjemcu

RTCP SDES (source description) – popis zdroja (obr. 2.1.6)

Správy slúžia na popis a identifikáciu zdroja ako CNAME, NAME, EMAIL,

PHONE, LOC, TOOL, PRIV (kanonické meno, meno, email, tel.č., poloha, nástroj,

privátne rozmery)

Obr. 2.1.6 – RTCP SDES






SC – počet identifikátorov

RT=RR=202 – identifikácia, že sa jedná o SDES


SDES chunk – časť SDES

Sender SSRC – synchronizačný zdroj odosielateľa

SDES items chunk – pole pre SDES aplikácie

Further SDES chunks – ďalšie polia SDES

SDES item data – dáta aplikácie SDES

Item type – typ aplikácie

Item length – dĺžka aplikácie


- 31 -

2.1.3 Prenos RTP/RTCP paketov v UDP paketoch

Na obrázku 2.1.7 je znázornený prenos RTP/RTCP v UDP pakete a následne

prenos do sieťovej vrstvy do IP paketu.

Obr. 2.1.7 – Prenos RTP/RTCP v UDP pakete

3. ANALÝZA POŽIADAVIEK PRIVÁTNYCH SIETÍ NA

BEZPEČNOSŤ PRIPOJENIA DO KONVERGOVANEJ SIETE

INÝCH OPERÁTOROV A BEZPE ČNOSTNÉ A IMPLEMENTA ČNÉ

PROBÉMY (z hľadiska VoIP cez protokol SIP)

3.1 Kategorizácia privátnych sietí z hľadiska nárokov na bezpečnostnú politiku

V súvislosti s rastúcou zložitosťou počítačových systémov, neskôr

kombinovaných s komunikačnými prostriedkami a súhrnne nazývanými informačnými

technológiami, sa postupne ukázala nutnosť otázku bezpečnosti neobmedzovať len na

počítačové systémy, ale chápať ju komplexnejšie. Táto zmena vnímania sa odrazila aj v

zmene názvu disciplíny – namiesto pojmu počítačová bezpečnosť sa začal presadzovať

pojem informačná bezpečnosť, ktorý lepšie vystihoval podstatu problému (bezpečnosť

informácii bez ohľadu na to, kde sa práve nachádzajú). Naviac sa ukázalo, že prudký

rozvoj IT ako aj rozličných metód útokov na systémy IT si vyžaduje špecializáciu –


- 32 -

vybudovanie účinného systému zabezpečenia systémov IT už presahuje sily a kvalifikáciu

bežného špecialistu na informačné technológie – informatika.

Je veľmi dôležitým aspektom zaoberať sa analýzou potrebných bezpečnostných

požiadaviek zákazníkov (firiem). Z hľadiska providera to má nesmierny význam v snahe

získať zákazníka na svoju stranu. V dnešnej dobe sú informácie o konkurencii

strategickým materiálom v boji o zákazníka. Preto je pochopiteľné, že každý subjekt na

trhu sa snaží všetkými možnými spôsobmi chrániť informácie. Firmy obchodujú na trhu

online, preposielajú sa strategické informácie medzi pobočkami, telefonujú atď. Špeciálne

telefónický kontakt je veľmi nevyhnutný. Vo väčšine veľkých firiem prevláda názor, že je

nevyhnutné takúto formu komunikácie chrániť (šifrovať). A platí to aj pri

implementovaní VoIP. Predtým ako sa začneme niečo chrániť pred potenciálnymi

útočníkmi, je nutné urobiť analýzu, čo daný zákazník potrebuje. Uvediem príklad: je asi

nezmyselné chrániť firmu vyrábajúcu klince, kde nebezpečenstvo odcudzenia

strategických informácií je minimálne. Ak by ale daná firma mala recept na to ako z kila

železa urobiť 10 kg klincov, je už potom namieste uvažovať o ochrane údajov. Preto je

veľmi potrebné zaoberať sa rozdelením zákazníkov do kategórií (v zmysle potreby

ochrany ich údajov). Je to ale veľmi individuálne a záleží to od konkrétnych požiadaviek

zákazníka. Vo väčšine prípadov však platí: čím má firma väčší podiel na trhu, tým sú jej

nároky na bezpečnosť vyššie. Samozrejme s výnimkou inštitúcií, ktoré majú

zhromaždené iné dôležité informácie (armáda, banky, zdravotníctvo, školstvo,

telekomunikácie a iné). K takýmto subjektom je nutné pristupovať špecificky. V analýze

sú ponúknuté rozdelenie zákazníkov a stručne špecifikované ich predpokladané

požiadavky na bezpečnosť siete.

3.1.1 Rozdelenie zákazníkov na subjekty s odlišnými požiadavkami na bezpečnosť

Malé subjekty (malé privátne siete)

Do tejto kategórie by som zaradil subjekty pôsobiace na trhu, ktoré zamestnávajú

do 10 zamestnancov. Zväčša sú to subjekty pôsobiace v nejakom regióne a ich postavenie

na trhu nie je strategické. V ojedinelých prípadoch vlastní takáto firma strategické

informácie (ak takýto subjekt je len pobočkou veľkého subjektu alebo regionálny úsek

strategického subjektu, napr .pobočka banky). Ale vo väčšine prípadov nevyžadujú

zvýšenú bezpečnosť ich informačnej infraštruktúry. Zväčša je ich informačná štruktúra


- 33 -

tvorená niekoľkými počítačmi a telefónmi. Z hľadiska implementovania novej služby

akou je VoIP, prevláda ich pozitívny názor a radi uvítajú toto lacnejšie a komplexnejšie

riešenie. Z hľadiska zabezpečenia ich siete im postačujú klasické a finančne pre nich

dostupné riešenia. Samozrejme s výnimkou subjektov, ktoré sa potrebujú chrániť formou

zvýšenej úrovne zabezpečenia. Pre providerov je tento segment zákazníkov dobrou víziou

do budúcnosti z hľadiska nasadzovania novej služby VoIP. Často je v praxi tento segment

zákazníkov nazývaný rezidenčný segment.

Uplatňovaná bezpečnostná politika a prepojenie s providerom:

Prepojenie: Telefónna linka, ISDN, xDSL, bezdrôtové prepojenie (WiFi) – z hľadiska

ceny, spoľahlivosti a bezpečnosti je toto riešenie pre takéhoto zákazníka postačujúce

Bezpečnosť: vo väčšine prípadov bezheslová politika, nešifrované spojenia, priame

prepojenie do internetu (modem, router) alebo cez malý server, kancelárske softwarové

balíky, často bez Firewallu, antivírová ochrana, VoIP bez nutnosti šifrovania

Požiadavky na VoIP: nie je nutné šifrovať, možnosť dovolať sa

Obr. 3.1.1 a 3.1.2 – Pripojenie malej organizácie k internetu

Stredné subjekty (stredne veľké privátne siete)

Sem možno zaradiť subjekty s väčším podielom na trhu a väčším počtom

zamestnancov ako 10 a menším ako 25. Zväčša opäť pôsobia v nejakom regióne. Ich

nároky sú v porovnaní s malými subjektami v podstate identické, s výnimkou

strategických subjektov. Vo všeobecnosti je dobré takýmto subjektom implementovať

určité bezpečnostné pravidlá z hľadiska ich budúceho vývoja. Je dobré, aby aj

zamestnanci takéhoto subjektu pristupovali zodpovedne k bezpečnosti informácií a snažili

sa dodržovať stanovené pravidlá (heslová politika, antivírová ochrana, softwarový

firewall, práca na internete, atď). Pre subjekty tohto typu je tiež výhodné implementovať

VoIP. Z hľadiska zabezpečenia takéhoto subjektu existuje mnoho finančne dostupných

a veľmi efektívnych riešení. Pre malé a stredné firmy je veľmi dobrým riešením


- 34 -

poskytnutie informačných služieb na báze IP. Oceňujú najmä lepšiu cenovú dostupnosť a

jednoduchosť riešenia.


Prepojenie: Telefónna linka, ISDN, xDSL, bezdrôtové prepojenie (WiFi) – z hľadiska

ceny, spoľahlivosti a bezpečnosti je toto riešenie pre takéhoto zákazníka postačujúce

Bezpečnosť: heslová politika, nešifrované spojenia, prepojenie do internetu cez router

(často nenastavený Firewall), mail server (často pripojený priamo na prístupový router),

často povolené všetky služby, VoIP nešifrované, antivírová ochrana, antispyware

Požiadavky na VoIP: nie je nutné šifrovať, možnosť dovolať sa

Veľké subjekty (veľké privátne siete)

Za veľké subjekty v tomto rozdelení by som považoval firmy, ktoré majú viac ako

25 a menej ako 200 zamestnancov. Sem by som zaradil veľkú škálu subjektov

pôsobiacich jednak na regionálnej, národnej a nadnárodnej úrovni. Z hľadiska

bezpečnosti ich privátnych sietí, tvoria tieto subjekty špecifickú kategóriu. Je nutné si

uvedomiť, že je veľmi dôležité konzultovať s takýmto subjektom ich požiadavky, kritériá

a potreby na zabezpečenie ich privátnej siete. Možno predpokladať, že väčšina takýchto

subjektov si potrebuje chrániť svoje informačné systémy voči Internetu. Preto musí

jednak samotná firma a jej tím správy IT bezpečnosti v spolupráci s providerom

konzultovať možné bezpečnostné slabiny a hľadať spoločné riešenia. Na druhej strane je

veľmi dôležité, aby samotná firma urobila maximum pre zabezpečenie svojej siete

a zaviedla pravidlá, ktorých dodržiavanie by mala striktne sledovať v rámci celej firmy.

Najdôležitejšie sú:

1. používanie silných hesiel a ich pravidelná obmena

2. opatrnosť pri narábaní s prílohami e-mailu a pri sťahovaní softvéru z webu

3. inštalácia a používanie antivírusových programov

4. inštalácia a používanie firewall

5. odstránenie nepoužívaného softvéru a používateľských účtov a „čistenie”

vyraďovaného zariadenia od údajov

6. kontrola fyzického prístupu k zariadeniam

7. zálohovanie dôležitých súborov, adresárov a programov

8. včasné aplikovanie bezpečnostných záplat


- 35 -

9. implementácia ďalších prvkov sieťovej bezpečnosti

10. obmedzenie prístupu k citlivým a dôverným údajom

11. plán riadenia bezpečnostných rizík

12. využitie externej špecializovanej podpory

Na obr. 3.1.3 je znázornený príklad štruktúry siete takéhoto subjektu (predpokladám, že

daný subjekt dodržuje štandardné implementovanie bezpečnostnej politiky). Sieť takéhoto

subjektu musíme chápať ako celok, aj keď je často tvorená z viacerých regionálnych sietí.

Z pohľadu implementácie služby VoIP požadujú zabezpečenie takejto dátovej

komunikácie. Momentálne prevládajú obavy takýchto subjektov pri nasadzovaní VoIP do

ich sieťovej infraštruktúry hlavne kvôli obave z napadnutia ich siete. V kapitolách 4.1,

4.2, 4.3 a 4.4 sú popísané možné bezpečnostné riešenia pri implementácii VoIP.


Prepojenie: xDSL – z hľadiska spoľahlivosti a bezpečnosti je toto riešenie pre takéhoto

zákazníka nepostačujúce, z hľadiska ceny výhodné

Prenajatý okruh (Lease Line) – z hľadiska spoľahlivosti a bezpečnosti je riešenie

postačujúce, z hľadiska ceny nevýhodné

MPLS - z hľadiska spoľahlivosti, ceny a bezpečnosti je toto riešenie pre takéhoto

zákazníka postačujúce (častý prípad prepojenia takéhoto subjektu a providera)

Ethernet (CISCO) - veľmi progresívne sa vyvíjajúca technológia, navyše nepotrebuje

žiadne iné prenosové systémy na 1. vrstve (SDH/SONET). Ukazuje sa, že siete tohto typu

sa postupne budú čoraz viac presadzovať na celom svete. Hlavnými dôvodmi je

jednoduchosť riešenia, komplexnosť a hlavne cena.

Bezpečnosť: Firewally, VPN (virtuálne privátne siete), často DMZ (demilitarizované

zóny), heslová politika, antivírová ochrana, antispyware, často povolené len určité služby

(http, SMTP, POP3), access listy, prepojenie často cez router (Firewall, NAT)

Požiadavky na VoIP: šifrovanie SIP, šifrovanie RTP, access listy, spoľahlivosť

(možnosť dovolať sa aj pri výpadku v sieti)


- 36 -

Obr. 3.1.3 - Príklad siete veľkého subjektu

Nadnárodné subjekty (nadnárodné privátne siete)

Do tejto kategórie zaradím subjekty nad 200 zamestnancov, ktoré pôsobia na

medzinárodnej pôde. Subjekty tohto typu majú veľmi dobre rozvinutú a zaužívanú

bezpečnostnú politiku, o ktorú sa im starajú tímy špecialistov v tejto oblasti. Pre ne platia

všetky doposiaľ spomenuté kritériá bezpečnosti, pričom, riziko útoku na takúto sieť je

značne väčšie. Pre providera bude ťažké presadiť u takéhoto subjektu služby VoIP bez

toho, aby mu poskytol komplexné riešenie. Záleží len od poskytovateľa služieb ako sa

dokáže s touto výzvou a problémom vysporiadať. Aj tu existujú dostupné riešenia

bezpečnostných problémov, tak aby bol takýto zákazník spokojný. Samozrejme, že aj

v tomto prípade má zmysel uvažovať nad výhodami a možnosťami VoIP cez SIP. Hlavne

je dobré spomenúť výhodné volania do zahraničia (v rámci firmy ale aj do iných sietí) cez

IP sieť. Je teda dobré uvažovať nad touto možnosťou aj zo strany providera ako aj zo

strany zákazníka. Z prieskumu medzi takýmito zákazníkmi vyplýva pre providera splniť

niekoľko nutných požiadaviek.

Uplatňovaná bezpečnostná politika a prepojenie k providerovi:

Prepojenie: SONET/SDH – spoľahlivosť, bezpečnosť a primeraná cena


- 37 -

ATM – spoľahlivosť, bezpečnosť a z hľadiska, že túto technológiu nasadzovalo

v minulosti veľa spoločností, je takýto spôsob prepojenia pre veľa zákazníkov výhodný,

cenovo však dosť náročný

Ethernet (CISCO) – do popredia sa dostávajúci spôsob prepojenia, vysoko spoľahlivý

a flexibilný, spoločnosti postupne prechádzajú na tento spôsob prepojenia (nízka cena)

Bezpečnosť: Firewally, VPN (virtuálne privátne siete), často DMZ (demilitarizované

zóny), heslová politika, antivírová ochrana, antispyware, často povolené len určité služby

(http, SMTP, POP3) a prístup k nim majú len určité skupiny, access listy, prepojenie

často cez router (Firewall, viacnásobný NAT), v rámci Intranetu https, servre na báze

CITRIX, mail server s distribuovanou štruktúrou, k informáciám majú prístup len

oprávnení užívatelia

Požiadavky na VoIP: šifrované SIP, RTP, kontrola prístupu, overovanie na základe

certifikátov, IPsec, spoľahlivosť služby na 99,999% (dovolatelnosť aj pri výpadku v sieti

providera), decentralizovaná štruktúra

Na obrázku 3.1.4 je príklad štruktúry siete nadnárodného subjektu.

Obr. 3.1.4 - Príklad štruktúrý siete nadnárodného subjektu

Špecifické subjekty (špecifické privátne siete)

Do tejto kategórie zaradím subjekty ako banky, armáda, telekomunikácie,

zdravotníctvo, školstvo a iné. Táto kategória privátnych sietí je veľmi špecifická kvôli

tomu, že sa nedajú presne zovšeobecniť požiadavky a potreby na bezpečnosť. Je veľký

rozdiel v zabezpečení privátnej siete banky a privátnej siete školy. Akademická pôda je


- 38 -

predsa len „volnejšie prostredie“ ako striktné prostredie v sieti banky. V sieti subjektu

akým je banka si nemôžeme dovoliť ani len najmenšiu chybu, pretože hrozí veľké

nebezpečenstvo. Na akademickej pôde tiež hrozí nebezpečenstvo útoku hackerom, ale

škody spôsobené nie sú až tak závažné ako v prípade banky. Práve kvôli tomuto rozdielu

som tieto subjekty zaradil do kategórie špecifické. Pri implementovaní nových služieb do

siete takéhoto subjektu, treba hľadať spoločné riešenia aj zo strany subjektu a aj zo strany

providera.

3.2 Bezpečnostné a implementačné problémy protokolu SIP pri službe VoIP

V tejto časti sa budem venovať službe VoIP z pohľadu protokolu SIP

(signalizácia). Poukážem na problematické miesta pri implementovaní takejto služby

(VoIP cez SIP). [ 11 ]

3.2.1 VoIP SPAM a lokalizácia pôvodu spojenia

SPIT (Spam over Internet Telephony) – nevyžiadané dáta prostredníctvom

internetovej telefónie. Pri signalizačnom protokole SIP je hrozba takéhoto SPAMu veľmi

reálna. Ako už bolo spomínané a vysvetlené, protokol SIP je aplikačným protokolom

a signalizačné správy sú v textovom formáte. Preto takýto SPAM môžeme považovať za

značnú hrozbu. SIP nedokáže automaticky zistiť pôvod signalizačných správ, nakoľko

útočník môže správy generovať a posielať ich ako inicializáciu SIP session (spojenia)

svojej „obeti“. Útočník to môže využiť a môže nadviazať viacero takýchto nevyžiadaných

spojení (voice SPAM) a tým zahltiť a vyradiť tak uzol obsluhujúci SIP spojenia. Alebo na

druhej strane si útočník prostredníctvom SIP signalizácie môže cez SDP protokol

dohodnúť vhodné 2 porty a cez tieto porty potom získať privilégiá a preniknúť tak do

siete obete.

3.2.2 DoS (Denial of Service) – odoprenie služby

Pri VoIP službe sa jedná o zahltenie uzla obsluhujúceho SIP spojenia, de-

registráciu zariadení z register servera (čo v konečnom dôsledku znamená, že zariadenia

nemôžu prijímať/uskutočňovať hovory) a ukončovanie nadviazaných spojení (call


- 39 -

termination by 3rd party). Dôvody prečo môže dojsť k takýmto situáciám (DoS) sú –

nepovinná autentifikácia a chýbajúci automatický mechanizmus overovania správ.

3.2.3 Neautorizované smerovanie volania

Na obrázku 3.2.1 je znázornený takýto prípad neoprávneného smerovania hovoru

v sieti. Útočník (prvý) volá terminál A, terminál A volá terminál B, terminál B potom C

atď. Takéto neautorizované (nepovolené) smerovanie volania môže útočník využiť na

vyradenie viacerých terminálov (klientov) v sieti. Opäť dôvodmi prečo takáto situácia

môže nastať sú – nepovinná autentifikácia a chýbajúci automatický mechanizmus

overovania správ.

Obr. 3.2.1 - Neautorizované smerovanie volania

3.2.4 Neautorizovaná registrácia terminálu (klienta) a odpočúvanie

Útočník si zaregistruje na register serveri ďalšieho klienta (terminál) pod SIP URL

obete. Takýmto spôsobom útočník prijíma všetky volania smerujúce poškodenému

užívateľovi. Príklad je znázornený na obrázku 3.2.2.


- 40 -

Obr. 3.2.2 - Odpočúvanie

3.2.5 Získanie údajov o registrovaných klientoch (Directory Harvesting)

Jedná sa o zneužitie príkazov REGISTER na získanie kompletného listu

registrovaných klientov na register serveri. Útočník tak má možnosť zahlcovať

jednotlivých klientov v privátnej sieti neoprávnenými a falošnými SIP spojeniami (VoIP

SPAM). Ak je samozrejme daná sieť málo zabezpečená, útočník získa ďalšie privilégiá na

manipuláciu so SIP klientami, registrovanie neoprávnených SIP klientov, poprípade

odcudzenie dôležitých informácií zo siete poškodeného.

3.2.6 Impersonifikácia SIP servera (vydávanie sa za server)

Útočník sa vydáva za SIP proxy/register server, a tým získa kontrolu nad všetkými

SIP správami a nad všetkými volaniami prechádzajúcimi cez SIP server. Na obrázku

3.2.3 je znázornený takýto prípad.

Obr. 3.2.3 - Impersonifikácia SIP servera (útočník je umiestnený medzi Proxy

servermi alebo medzi Proxy a UA)


- 41 -

3.2.7 Falšovanie správ (Message Tampering)

Falšovanie správ je možné ak útočník dokáže odchytiť a modifikovať pakety

prechádzajúce medzi SIP zariadeniami. Falšovanie správ môže zapríčiniť de-registráciu

UA, impersonifikáciu SIP serverov alebo môže byť zamerané na atakovanie iných

komponentov v sieti ako Firewall, brána a iné. Príklad je zobrazený na obrázku 3.2.4.

Obr. 3.2.4 - Falšovanie správ(útočník získava prístup ku každému sieťovému

prvku)

3.2.8 Zhodenie spojenia (Session Tear Down)

Takáto situácia nastane ak útočník spozoruje SIP signalizáciu a pošle falošné SIP

BYE správy obom UA. Veľa SIP UA nepožaduje autentifikáciu, preto útočník dokáže

takúto situáciu využiť a poslať obom UA správu BYE a tým zhodiť spojenie. Obrázok

3.2.5 ilustruje danú situáciu.

Obr. 3.2.5 - Zhodenie spojenia

Ak UA nedokáže kontrolovať pakety, útočník nemusí zachytiť SIP signalizáciu, stačí mu

ak pozná IP adresu UA (moja brána, SIP telefón, X-lite atď) a pošle správu BYE a tak


- 42 -

ukončil nadviazané spojenie. Ďalším príkladom zhodenia spojenia je zahltenie Firewallu

BYE správami tak, že sa zahltia UDP porty pre legitímne volania.

3.2.9 Ďalšie možné útoky a prehľad najčastejších bezpečnostných problémov

Útoky tohto typu by som rozdelil do dvoch skupín – útoky smerujúce na sieťové

prvky a útoky zamerané na aplikačné vybavenie sieťových prvkov. Do prvej kategórie by

som zaradil: syn flood, smurfing, IP spoofing a iné. Do druhej kategórie by som zaradil

útoky zamerané na pretečenie pamäte aplikačných vybavení serverov (buffer overflow

attacks). Pre ilustráciu by som do tejto časti zaradil tabuľku 2, ktorá vyjadruje najčastejšie

bezpečnostné problémy pri SIP a následky týchto problémov. [ 12]

problém následok

odpočúvanie: neautorizované zachytenie a

dekódovanie signalizačných správ zníženie súkromia a dôveryhodnosti

vírusy a trójske kone DoS/neautorizovaný prístup

opätovné vysielanie správ DoS

spoofing:vydávanie sa za legitímneho

užívateľa neautorizovaný prístup

manipulácia so správami riziko neúplnosti správ, DoS

záplava SYN na Proxy/Register servery DoS

SIP IP telefóny: TFTP(trivial FTP),

odpočúvanie, DHCP, spoofing, telnet

DoS, neautorizovaný prístup, zníženie

súkromia

Tabuľka 2 - Najčastejšie problémy pri SIP protokole

3.2.10 Firewall a SIP

Vzájomná súčinnosť Firewallu a SIP protokolu je veľmi dôležitým aspektom pri

implementácii služieb VoIP. Ako som spomínal v predošlých kapitolách, prenos správ

protokolu SIP je realizovaný prostredníctvom protokolu UDP (vyššie verzie aj TCP)

a príslušného portu. Štandardne pre signalizáciu je to port 5060. Ako som spomenul, SIP

signalizácia dohoduje mediálne spojenie medzi volajúcim a volaným. Použité sú

protokoly RTP a RTCP, pričom sú zapúzdrené v UDP datagrame. V tomto prípade sú

využité 2 dynamické porty z rozsahu 1024-65535. Danú situáciu dobre ilustruje obr.


- 43 -

1.2.10. Keďže hovorím o implementačných problémoch VoIP cez SIP, uvediem príklad

kde takýto problém môže nastať. IT správca firmy RUDKO sa rozhodne, že na Firewalle,

ktorý robí prvotné filtrovanie protokolov a portov zakáže všetky prichádzajúce UDP

datagramy do jeho siete. Odchádzajúce UDP a porty sú povolené. Ak takáto firma má

službu VoIP cez SIP, potom nastane to, že síce UA sa budú snažiť prihlásiť na SIP proxy,

ale neprihlásia sa nakoľko na Firewalle sa všetky UDP pakety prichádzajúce zo SIP proxy

dropnú (obr. 3.2.6). Týmto príkladom chcem vyjadriť prečo je vážnym implementačným

problémom SIP vs. Firewall. Preto ak by správca RUDKO chcel vyhovieť

zamestnancom, aby mohli volať a aby mohli prijímať hovory, musel by na Firewalli

povoliť UDP a porty 5060 pre signalizáciu a 1024 – 65535 pre mediálny tok. Samozrejme

takýmto krokom sa dostaneme do situácie, že SIP vs. Firewall sa stáva aj vážnym

bezpečnostným problémom. Potenciálny útočník môže takéto otvorenie portov veľmi

rýchlo zneužiť. Preto stále pretrváva obava IT správcov pred implementáciou SIP. Mojou

snahou je ukázať, že riešenia takéhoto problému existujú a v ďalších kapitolách sa nimi

budem zaoberať.

Obr. 3.2.6 – Príklad konfigurácie Firewallu

3.2.11 NAT (Network Address Translation) a SIP

NAT je logická funkcia, zväčša používaná na zariadení tvoriacom rozhranie medzi

sieťami, ktorá prekladá interné (privátne) IP adresy na externé (verejné) IP adresy. NAT

zariadenia sú hardwarové/softwarové entity, ktoré pracujú na TCP/IP vrstve. NAT robí

značný problém VoIP komunikácii, hlavne kvôli tomu, že protokoly VoIP sú protokoly

vyšších vrstiev. Ak nejaký protokol z aplikačnej vrstvy obsahuje IP adresu a porty v tele

TCP/IP paketu, NAT v takomto prípade zlyháva. Existuje ale niekoľko možností ako

riešiť tento problém, ale najlepším riešením tohto problému je kombinácia viacerých


- 44 -

riešení. Ukážem niekoľko príkladov, kedy je nutné zaoberať sa problematickou

implementáciou SIP cez NAT:

• Dynamické IP porty: SIP zostavuje spojenia medzi doposiaľ neznámymi IP

adresami a dynamicky pridelenými portami. Tu teda nie je možné stanoviť

striktné pravidlá na Firewalli. Okrem toho tieto IP adresy a porty sa môžu počas

spojenia meniť.

• IP adresa v tele paketu: Mnohé SIP hlavičky (napr. contact, record-route, via,

from, to) obsahujú polia, v ktorých môžu byť použté IP adresy namiesto

doménových mien. Toto vedie k problémom pri zostavovaní SIP session

(spojenia), pretože IP adresy sú zvyčajne privátne a nie sú prístupné zariadeniam

z vonku (z verejnej siete). A práve preto je potrebné aby tieto adresy boli na NAT

zariadení preložené na verejne dostupné adresy.

• Životnosť: Na NAT zariadení je verejná IP adresa preložená na privátnu IP

adresu, ktorá má určitú životnosť T. Ak na NAT zariadení nie je žiadna prevádzka

určitú dobu T alebo spojenie bolo explicitne už ukončené, ukončí NAT zariadenie

aj preklad adries. SIP INVITE správa, ktorá smeruje z privátnej IP adresy cez

NAT na verejnú IP adresu, nesie informáciu o stave. Tento stav musí byť

eventuálne zmazaný. Ak je použitý TCP protokol, zavretie TCP spojenia je

dobrým indikátorom, že daná aplikácia bola ukončená. Keďže SIP používa UDP

pakety, zavretie spojenia chýba. Navyše určitá perióda ticha počas hovoru, ktorá

je dlhšia ako T sekúnd nemusí postačovať na indikáciu konca spojenia.

Výsledkom môže byť, že niektorá informácia o stave je zmazaná pred vybavením

a hovor je tým pádom ukončený.

• Multicast: SIP môže používať multicast pre správy INVITE a REGISTER. Hoci

multicast nie je dobre podporovaný NAT servrami, zvyčajne sa ako najlepšie

riešenie ukazuje použiť ALG (Application Layer Gateway) vo vnútri NAT

servera.

• Bezpečnosť: SIP je možno zabezpečiť spôsobom hop to hop a end to end

mechanizmami. RFC2543 hovorí o zabezpečení cez IPsec a TLS ako potenciálne

riešenie hop to hop mechanizmu. IPsec nie je priechodný cez NAT, teda

implementácia použitím IPsec je značne obmedzená. IPsec pre SIP je priechodný

cez Firewall, ale nemusí byť schopný rozoznať porty použité pre mediálny tok


- 45 -

dát. End to end mechanizmus v SIP je reprezentovaný autentifikáciou

a kryptovaním. Oba spôsoby ale robia problémy NAT serverom. [ 13 ]

Obr. 3.2.7 - Schéma NAT

3.2.12 Typy NAT

Full cone NAT

Čo sa týka full cone NAT, mapovanie je veľmi jednoducho realizované. Každý

kto chce kontaktovať z verejného internetu užívateľa v lokálnej sieti za NAT serverom

musí poznať iba schému mapovania adries. Napríklad počítač za NAT serverom s IP

adresou 192.168.1.100 komunikujúci cez port 5060 je mapovaný na externý port a IP

adresu 212.12.32.99:12768. Hocikto z internetu môže poslať pakety na túto IP:port

a pakety budú doručené užívateľovi v lokálnej sieti s IP 192.168.1.100:5060. Tento

píklad je znázornený na obr. 3.2.8.

Obr. 3.2.8 - Full cone NAT


- 46 -

Restricted cone NAT

V prípade restricted cone NAT je externá IP:port otvorená len pre jeden interný

počítač, ktorý posiela dáta smerom von. Napríklad klient posiela pakety externému

počítaču 1 a NAT mapuje klientovu IP 10.0.0.1:8000 na 202.123.211.25:12345. Externý

počítač 1 môže posielať naspäť pakety. NAT bude blokovať pakety prichádzajúce

z externého počítača 2, zatiaľ čo klient posiela dáta na IP adresu externého počítača 2.

Existuje možnosť, že externý počítač 1 aj 2 môžu posielať pakety naspäť klientovi

a mapovanie bude rovnaké pre oba externé počítače. Príklad je znázornený na obrázku

3.2.9.

Obr. 3.2.9 - Restricted cone NAT a port restricted cone NAT

Port restricted cone NAT

Tento typ NAT je takmer identický ako restricted cone, ale v tomto prípade bude

NAT blokovať všetky pakety iba ak klient predtým poslal paket na IP a port, ktoré slúžia

na posielanie dát cez NAT. Ak klient pošle externému PC 1 dáta na port 5060, NAT

povolí prístup paketom ku klientovi len z IP 222.11.22.33:5060. Ak klient pošle pakety

na viacero IP:port, vtedy mu môžu odpovedať všetci externí užívatelia a na NAT

zariadení budú mapovaní na jediný pár IP:port. Príklad je na obrázku 3.2.9.

Symetrický NAT

Posledný z typov NAT je symetrický NAT. Je dosť odlišný od prvých troch

techník mapovania interných IP:port na externé IP:port. Je závislý od IP adresy, na ktorú

sú posielané pakety. Napríklad klient pošle dáta z IP 192.168.1.100:5060 na externý PC

2, môže byť mapovaný na IP 212.12.32.99:15799, pričom ak by poslal dáta na externý PC


- 47 -

1 bude mapovaný inak napríklad 212.12.32.99:12768. Oba externé PC môžu klientovi

odpovedať, ale musia použiť IP adresu a port, cez ktoré majú povolený NAT. Ak by

poslali dáta na iný pár IP:port, ich dáta budú na NAT zariadení zahodené. Na obrázku

3.2.10 je príklad symetrického NAT.

Obr. 3.2.10 - Symetrický NAT

Zatiaľ všetky IP siete používajú IPv4, čo znamená, že je nutné sa zaoberať

problematikou NAT vs. SIP. Tento problém bude vyriešený pri nasadení IPv6, keďže

NAT už nebude potrebný. Existujú však riešenia ako implementovať SIP do IP sietí ak sa

v sieťach nachádzajú NAT zariadenia. Týmito možnými riešeniami sa budem zaoberať

v ďalších kapitolách. [ 14 ]

3.3 Bezpečnostné a implementačné problémy protokolov prenášajúcich dáta

v reálnom čase RTCP a RTP

3.3.1 Bezpečnostné problémy RTP a RTCP pri službe VoIP

Po dohodnutí spojenia SIP signalizácou, nasleduje samotný mediálny prenos dát

v reálnom čase protokolmi RTP a RTCP. Využité sú presne tie dva porty, ktoré sa

dohodnú signalizáciou. Prenos potom prebieha medzi volaným a volajúcim. Obr. 1.2.10

a 3.3.1 presne vyjadrujú danú situáciu. Z pohľadu bezpečnosti je to vážny problém,

hlavne ak si predstavíme, že spojenie inicioval užívateľ z internetu, ktorého vieme

identifikovať možno len podľa jeho IP adresy. Tu nastáva veľká obava väčšiny správcov

privátnych sietí. Hrozí veľké nebezpečenstvo odcudzenia strategických informácií,

nakoľko výmena dát je realizovaná ako spojenie koniec – koniec (obr. 3.3.1). Navyše

RTP a RTCP pakety sú prenášané v UDP datagramoch, čo dané riziko len znásobuje. Na

druhej strane je nutné poznať štruktúru danej privátnej siete. Je samozrejmé, že ak daná


- 48 -

firma povolí len používanie hardwarových SIP telefónov, maximálne jej hrozí útok na

vyradenie služby DoS. V takomto prípade je obava z odcudzenia dát minimálna. V prvom

rade je veľmi dôležité zvážiť požiadavky a potreby daného subjektu. Ak sa daná firma

rozhodne používať softwarové SIP telefóny, musí rátať s tým, že riešenie bezpečnosti

siete bude finančne náročnejšie. Na prvý pohľad sa zdá, že tento problém nemožno

vyriešiť k spokojnosti zákazníka. Môžeme predpokladať, že zákazník službu VoIP

odmietne práve kvôli tomuto problému. Existujú však veľmi dobré riešenia ako

zabezpečiť RTP a RTCP a zabrániť tak potenciálnemu útočníkovi zneužitie danej

situácie. Riešenia tohto bezpečnostného problému sú spomenuté v kapitole 4.2.

Obr. 3.3.1 – Prechod SIP signalizácie a RTP/RTCP dát

3.3.2 Implementačné problémy RTP a RTCP pri službe VoIP

Nesmieme zabúdať, že telefónna konverzácia je obojsmerný proces. Dáta musia

korektne doraziť k volanému terminálu a potom aj smerom naopak. Hovor smerujúci

z privátnej siete smerom do verejnej siete cez NAT zariadenie nepredstavuje až taký

problém. Zdrojová privátna adresa UDP datagramu bude na NAT zariadení preložená na

verejnú IP adresu. Problém skôr predstavuje dátový tok smerujúci z vonkajšej siete do

privátnej. Vtedy je nutné zabezpečiť, aby NAT zariadenie malo inštrukcie o tom na akých

RTP portoch sa môže uskutočňovať komunikácia a o nastavení mapovania portov.

Zariadenie teda musí identifikovať, kam presmerovať prichádzajúce UDP datagramy

a ako má mapovať UDP/RTP porty v konverzácii. Toto je dôležité si uvedomiť, nakoľko

existujú už spomínané 4 typy NAT. Je možné použiť viacero zariadení od viacerých

výrobcov, ktoré takéto mechanizmy majú implementované.


- 49 -

4. ANALÝZA EXISTUJÚCICH A DOSTUPNÝCH

BEZPEČNOSTNÝCH RIEŠENÍ V PRIVÁTNYCH SIE ŤACH A PRI

ICH PREPOJENÍ K SIEŤAM INÝCH OPERÁTOROV (z poh ľadu

VoIP cez SIP)

4.1 Zabezpečenie manažmentu SIP spojenia

Keďže protokol SIP bol odvodený z HTTP protokolu, všetky dostupné

bezpečnostné riešenia a algoritmy v HTTP je možné aplikovať aj na protokol SIP. [ 15 ]

Použitím MIME kontajnerov vnútri SIP správ podnecuje potenciálne využitie emailových

bezpečnostných mechanizmov ako PGP alebo S/MIME. A samozrejme URI z HTTP,

ktoré je podobné ako URI v SIP, je možné prenášať cez zabezpečený tunel na transportnej

vrstve (TLS). Posledným mechanizmom ako zabezpečiť všetky služby bežiace na IP

protokole, je použitím IPsec. Hlavné bezpečnostné mechanizmy určené na ochranu SIP

spojení sú v tabuľke 3. Zhodujú sa so súborom metód, ktoré sú odporúčané verziou 1 SIP

štandardu. Medzitým boli štandardom SIPv2 odmietnuté PGP a HTTP základná

autentifikácia.

Autentifika čné metódy: PSK (Pre-

Shared Keys) a PKI (Public Key

Infrastructure)

Au

ten

tifik

ácia

Dát

ová

inte

gri

ta

Uta

jen

osť

HTTP 1.0 základná autentifikácia PSK nie nie odmietnuté SIPv2,

nezabezpečený prenos hesla

HTTP 1.1 digest autentifikácia PSK nie nie výzva/odpoveď založená na MD5

algoritme, hash z hesla

PGP (Pretty Good Privacy) PKI x x odmietnuté SIPv2

S/MIME (Secure MIME) PKI x x pre kryptovanie verejného kľúča

užívateľa musí byť známý UA

SIPS URI (TLS) PKI x x SIP aplikácie a proxy servre

musia striktne podporovať TLS

IPsec PKI x x

integrácia so SIP aplikáciami nie

je nutná, ale proxy servre musia

byť dôveryhodné

Tabuľka 3 – Riešenia ako zabezpečiť SIP manažment


- 50 -

4.1.1 HTTP digest autentifikácia (RFC 2617)

V tejto časti je ukázané ako SIP INVITE správa poslaná užívateľom Alice je

autentifikovaná proxy serverom. Použitá je pritom HTTP digest autentifikácia. Akonáhle

proxy server obdrží SIP INVITE správu od užívateľa Alice, odpovedá na ňu výzvou (obr.

4.1.1). Výzva obsahuje náhodný výraz (nonce), definuje použitý digest algoritmus

(zvyčajne MD5 alebo SHA-1) a autentifikačnú zónu (voči ktorej sa musí užívateľ

autentifikovať). Ako odpoveď na výzvu, užívateľ Alice prepošle originálnu SIP INVITE

správu doplnenú v záhlaví o odpoveď na výzvu (obr. 4.1.2). Odpoveď obsahuje MD5

digest užívateľské meno, utajené heslo, náhodný výraz (nonce), SIP metódu a požadované

URI. Keďže heslo je prenášané v zašifrovanom formáte, musí byť proxy server schopný

dešifrovať heslo, aby bolo možné overiť autentifikačnú odpoveď.

Obr. 4.1.1 – HTTP digest autentifikácia – výzva

Obr. 4.1.2 – HTTP digest autentifikácia – autentifikačná INVITE správa


- 51 -

HTTP digest autentifikácia vylepšuje nedostatky HTTP základnej autentifikácie

tým, že sa prenáša MD5 alebo SHA-1 digest. Hoci HTTP digest autentifikácia má výhodu

v tom, že identita užívateľa môže byť platná aj bez potreby prenosu hesiel v cleartexte,

môže byť citlivá na ataky založené na odchytení hash hodnôt, najmä ak sú použité krátke

a slabé heslá. Ďalšou veľkou nevýhodou je nedostatočný kryptovací mechanizmus

zabezpečujúci utajenosť. Navyše nie je možné garantovať dátovú integritu SIP správ.

4.1.2 PGP (Pretty Good Privacy) (RFC 1991)

PGP je možno potenciálne využiť na autentifikáciu a kryptovanie MIME tela

paketu v SIP správach. Avšak verzia 2 protokolu SIP už takúto možnosť nepodporuje

a vylučuje.

4.1.3 S/MIME (Secure MIME) (RFC 2312)

SIP správy obsahujú MIME správy, ktoré je možno zabezpečiť. Mechanizmus

zabezpečenia MIME správ sa nazýva S/MIME. X.509 certifikáty sa používajú na

identifikáciu koncových užívateľov na základe ich emailových adries, ktoré sú súčasťou

SIP URI ([email protected], [email protected] atď). Podpisovanie MIME správ nie je veľký

problém, nakoľko každý užívateľ má svoj privátny kľúč a užívateľský certifikát môže byť

poslaný v pkcs7-mime alebo pkcs7-signature poliach. Na druhej strane pri kryptovaní

MIME správ napríklad SDP správ je nutné poznať príjemcov verejný kľúč. Tento kľúč je

zvyčajne certifikovaný X.509 certifikátom a musí byť získaný pred začiatkom spojenia.

Kľúč je buď stiahnutý z verejného adresára alebo môže byť vyžiadaný prostredníctvom

špeciálnej SIP správy.

S/MIME sa používa na zabezpečenie MIME správ buď spôsobom hop-hop alebo

koniec-koniec (UA-UA). Na obr. 4.1.3 je možné vidieť SDP MIME správu zapúzdrenú

do SIP INVITE správy a zakryptovanú S/MIME algoritmom. Application/pkcs7-mime

binárne envelopedData pole zapúzdruje symetricky kryptované SDP telo paketu a tiež

obsahuje symetrický kľúč. Symetrický kľúč je zakryptovaný verejným kľúčom užívateľa.

V tomto prípade je kryptované telo paketu dodatočne podpísané. Použitá je

multipart/signed metóda. Podpis a X.509 certifikát užívateľa sa nachádzajú v binárnom

poli application/pkcs7-signature, ktoré nasleduje za MIME telom paketu. Ako

alternatívne riešenie je možné využiť aj binárne pole signedData.


- 52 -

Obr. 4.1.3 - S/MIME kryptované a autentifikované SDP MIME telo paketu

Každý mechanizmus, ktorý je závislý na existencii certifikátov pre koncových užívateľov,

je určitým spôsobom limitovaný. V dnešnej dobe existuje celosvetovo viacero

nekonsolidovaných autorít, ktoré ponúkajú certifikáty pre koncových užívateľov. Preto je

veľmi dôležité mať certifikáty od verejne známych certifikačných autorít (CA), ktorých

certifikáty sa navzájom poznajú.

4.1.4 SIPS URI (TLS) (RFC 2246)

Použitie SIPS URI v SIP INVITE správe znamená, použiť TLS cez celú trasu

spojenia až ku koncovému bodu. TLS ochrana musí byť realizovaná spôsobom hop-hop

na každom segmente trasy. TLS vyžaduje použiť transportný protokol TCP (TCP/SIP)

a infraštruktúru verejných kľúčov.

4.1.5 IPsec (RFC 2709)

IPsec je základný bezpečnostný mechanizmus, ktorý chráni SIP správy na sieťovej

vrstve. Kvôli požiadavke, že každý proxy server na trase musí čítať/prepísať prístup k SIP

záhlaviu, musia byť IPsec ESP (RFC 2406) alebo AH (RFC 2402) založené na báze hop-

hop. Potrebné IPsec bezpečnostné mechanizmy môžu byť založené na pevnej báze - bez


- 53 -

aktívnej účasti SIP UA (tie čo využívajú spojenie) alebo na dynamickej báze – UA

a proxy servre si počas nadväzovania spojenia interaktívne dohodnú IPsec mód.

IKE (RFC 2409) podporuje aj PSK a PKI. Keďže IP adresy SIP užívateľov sú

často dynamicky prideľované, IKE v hlavnom móde nebude fungovať a IKE

v agresívnom móde má svoje bezpečnostné problémy (ataky typu man-in-the-middle,

offline dictionary ataky a iné). V tomto prípade je preferovaná viac autentifikácia

verejnými kľúčmi. To ale znamená značný problém v dôveryhodnosti X.509 (RFC 2459)

certifikátov. IPsec metódy zabezpečenia a vytváranie VPN sú popísané v Prílohe 3.

4.2 Zabezpečenie mediálneho kanálu (zabezpečenie protokolov RTP a RTCP)

4.2.1 SRTP a SRTCP

Audio a video dáta v reálnom čase sú veľmi citlivé na celkové oneskorenie

a fázové chvenie (jitter). Žiadny z algoritmov zabezpečujúci takéto dáta by nemal výrazne

ovplyvňovať tieto parametre. Z dôvodu, že dáta sú na transportnej vrstve mapované do

UDP paketov, v praxi je možné využiť iba dve metódy zabezpečenia takýchto dát.

Popísané sú v tabuľke 4.

Autentifika čné metódy: PSK

(Pre-Shared Keys)a PKI

(Public Key Infrastructure)

Au

ten

tifik

ácia

Dát

ová

inte

gri

ta

Uta

jen

osť

SRTP (Secure RTP) PSK x x

použitie vlastných kľúčov, ktoré musia

byť distribuované rôznymi spôsobmi

IPsec (IP Security) PKI x x

integrácia so SIP aplikáciami nie je

nutná, ale spojenie musí byť

dôveryhodné

Tabuľka 4 - Metódy zabezpečenia RTP

4.2.2 SRTP (Secure RTP)

SRTP je len rozšírením štandardu RTP a poskytuje utajenie dát, autentifikáciu

správ a ochranu voči opätovnému preposielaniu v RTP a RTCP. Použitím kryptograficky


- 54 -

výkonnej ale počítačovo nenáročnej AES šifry v móde SC (Stream Cipher), je

garantovaná vysoká úroveň bezpečnosti, pričom sa v podstate nezväčší objem

prenášaných dát. Autentifikačné návestie požaduje pre dátovú integritu pridať len 10

Bytov ku každému RTP/RTCP paketu, ale je možnosť ho zredukovať len na 4 Byty ak je

použitý veľmi úzky komunikačný kanál.

Ako alternatívne riešenie je možné použiť zabezpečenie RTP a RTCP dát na

sieťovej vrstve a to už spomínaným súborom protokolov IPsec v transportnom móde.

Oba RTP a RTCP pakety môžu byť kryptograficky zabezpečené s protokolomi

SRTP a SRTCP. Na obr. 4.2.1 je znázornený formát SRTP paketu.

Obr. 4.2.1 – Formát SRTP paketu

Ako je možné vidieť na obr. 4.2.2, jedine RTP dáta sú zakryptované. Ako už bolo

povedané, veľkosť RTP dát sa kryptovaním nezväčšila. MKI (Master Key Identifier) pole

nie je povinné a identifikuje vlastný kľúč, z ktorého sú odvodené kľúče pre spojenie. Ak

je nutné zmeniť kľúče, užívateľ môže MKI použiť na získanie správneho vlastného kľúča.

SQN (Sequence Number) je 16 bitové pole a je použité spolu s 32 bitovým poľom ROC

(Rollover Counter) ako časť kryptografického kontextu v SRTP spojení. Tieto polia

slúžia na zabezpečenie SRTP spojenia voči opätovnému preposielaniu (zahlteniu

spojenia). Autentifikačné návestie (authentication tag) je kryptografická suma vypočítaná

z celého RTP paketu. Táto suma chráni celý RTP paket voči neautorizovaným

modifikáciám. Dĺžka tejto sumy v Bytoch už bola spomenutá.


- 55 -

4.2.3 SRTCP (Secure RTCP)

Na obr. 4.2.2 je znázornený SRTCP paket, ktorý je zabezpečený podobným

spôsobom ako SRTP paket. Je tu len jeden rozdiel, že v tomto prípade je pole AT

(authentication tag) povinné. Na druhej strane môže útočník poslať BYE paket, aby tak

ukončil RTP spojenie. Ďalšie pole je SRTCP index, ktorý slúži ako sekvenčné počítadlo

v prevencii voči opätovným atakom (zahltenie spojenia). Ak je použité E (Encryption

Flag) pole v SRTCP indexe, potom je telo RTCP paketu kryptované.

Obr. 4.2.2 – Formát SRTCP paketu

4.2.4 Štandardný kryptovací algoritmus

V princípe každá kryptovacia schéma môže byť použitá pre SRTP. Štandardne sa

používajú NC (NULL cipher) a AES-CTR (Advanced Encryption Standard in Counter

Mode). AES-CTR je znázornený na obr. 4.2.3.

Obr. 4.2.3 – AES-CTR kryptovací algoritmus


- 56 -

AES v CTR móde vystupuje ako generátor kľúčov produkujúci pseudonáhodné streamy

kľúčov ľubovoľných dĺžok, ktoré sú aplikované v bitovo-orientovanom tvare do

RTP/RTCP tela paketu. Používa logickú funkciu XOR. Samostatne je AES blok šifier,

ktorý tvoria 128 bitový blok a kľúč o veľkosti 128,192 alebo 256 bitov. AES je spustený

spolu s jednoznačným IV (initialisation vector) vždy na začiatku každého RTP a RTCP

paketu. IV je odvodený ako hash zo 112 bitového salt_key, SSRC toku dát a paket

indexu. IV je na výstupe kryptované 128 pseudonáhodnými bitmi. Ďalej je IV zväčšený

o jeden a je znovu zakryptovaný generovaním ďalších 128 bitov. Opakovaním tohto

postupu je možné zakryptovať celé telo RTP/RTCP paketu. AES sa používa v CTR móde

namiesto CBC (Cipher Block Chaining) módu. Oproti CBC módu má veľkú výhodu

v tom, že stream kľúčov môže byť prepočítaný skôr ako sa telo paketu stane prístupné.

Takto sa výrazne minimalizuje oneskorenie spojené s kryptovaním. A samozrejme ak

použijeme streamovú šifru namiesto bloku šifier, nie je potrebné doplniť k telu

RTP/RTCP paketu ďalší blok. V najhoršom prípade by mohol tento blok spôsobiť

zväčšenie RTP/RTCP záhlavia o 15 Bytov.

4.2.5 Štandardný autentifikačný algoritmus

Štandardný SRTP autentifikačný algoritmus správ je HMAC-SHA-1, ktorý je

založený na známej 160 bitovej SHA-1 hash funkcii. Kryptografická bezpečnosť je

dosiahnutá hashovaním 160 bitového tajného kľúča (auth_key) do kontrolnej sumy

(autentifikačné návestie), ktorá je potom konvertovaná na 80 bitov, aby sa zredukovala

veľkosť záhlavia paketu a skryla hash funkcia. V aplikáciách, kde je problém so šírkou

pásma, je možné autentifikačné návestie zredukovať až na 32 bitov.

Obr. 4.2.4 – Autentifikácia s použitím HMAC-SHA-1


- 57 -

4.2.6 Odvodenie kľúčov pre spojenie

Kryptovací a autentifikačný algoritmus už boli popísané. Oba algoritmy vyžadujú

pre spojenie utajené symetrické kľúče, ktoré musia poznať všetci UA participujúci na SIP

spojení. Toto zvyšuje problém s generovaním a distribúciou kľúčov pre spojenie. SRTP

štandard ponúka čiastočné riešenie. Toto riešenie spočíva v odvodení všetkých

potrebných kľúčov pre spojenie zo známeho vlastného kľúča. Otvorená je však

distribúcia vlastného kľúča. Ten musí klient získať sám. Na obrázku 4.2.5 je znázornené

ako sú vypočítané kľúče pre spojenie z vlastného kľúča. Znovu je blok šifry AES v CTR

móde, aby vygeneroval nevyhnutné kľúčové dáta. Vlastný kľúč, ktorý môže mať veľkosť

128, 192 alebo 256 bitov, slúži na kryptovanie AES. Pseudonáhodný generátor je

načítaný s IV. IV je funkcia zložená z 112 bitov salt_key, label a session key number. Pre

návestia 0x00 po 0x05, sú kryptovanie, autentifikácia a salt_key pre oba SRTP a SRTCP

pakety odvodené z rovnakého vlastného kľúča. Ak bola definovaná rýchlosť odvodenia

kľúčov, potom boli takou istou rýchlosťou generované a posielané SRTP a SRTCP

pakety a vypočítané kľúče pre spojenie. Ak je rýchlosť odvodenia kľúčov nastavená na

nulu, potom je rovnaký počet kľúčov použitý pre celú dĺžku spojenia.

Obr. 4.2.5 – Odvodenie kľúčov pre spojenie


- 58 -

4.2.7 Distribúcia vlastných kľúčov

Ide o distribúciu vlastných kľúčov k UA, ktorá tvorí časť inicializácie spojenia.

Distribúcia je založená na MIKEY (Multimedia Internet Keying) algoritme. MIKEY je

nový protokol výmeny kľúčov podobný IPsec-ovému IKE (Internet Key Exchange), ale je

už prispôsobený na špecifické požiadavky multimediálneho prostredia. Nanešťastie,

k tomuto štandardu nie je zatiaľ dostupná dokumentácia. Ako náhradné riešenie pre

prenos vlastného kľúča je možné použiť k parameter v SDP protokole. Obrázok 4.2.6

znázorňuje typickú SIP INVITE správu, ktorá zapúzdruje SDP MIME správu.

V SDP správe sa nachádza parameter k reprezentujúci 128 bitový SRTP vlastný

kľúč v hexadecimálnom tvare. Samozrejme prenos vlastného kľúča v nešifrovanom

formáte prináša so sebou veľké riziko. Za predpokladu, že proxy servre dokážu

spoľahlivo SIP INVITE správu odkryptovať, môže byť SIP INVITE hop-by-hop

zakryptovaná použitím TLS alebo IPsec. Ak je požadovaná utajenosť SDP MIME správy

typu koniec-koniec, potom je možné použiť ochranu S/MIME.

Obr. 4.2.6 – SIP INVITE správa s enkapsulovanou SDP MIME správou (k -128 bitový

vlastný kľúč)


- 59 -

4.3 Riešenie základných bezpečnostných problémov vo VoIP

V tabuľke 5 sú uvedené základné bezpečnostné problémy a ich riešenia.

Problém a dôvody Riešenie

DoS (odoprenie služby): prevencia prístupu k službe a zabránenie bombardovania SIP proxy alebo VoIP brán z Internetu neautentifikovanými paketmi

konfigurácia zariadení voči takýmto atakom

Odpo čúvanie: neoprávnené zachytenie hlasových paketov (RTP) a dekódovanie signalizačných správ

Použiť SRTP

Záplava paketmi: impersonifikácia legitímneho užívateľa

Preposlať adresnú autentifikáciu medzi komunikujúcimi partnermi

Preposielanie správ: zahltenie systému obsluhujúceho spracovanie signalizačných správ

Kryptovanie sekvenčných správ (použiť Cseq a Call ID)

Integrita správ: zabezpečiť aby prijaté správy boli tie, ktoré boli skutočne vyslané

Autentifikovať správy použitím HTTP digest autentifikácie

Tabuľka 5

4.4 Implementačné riešenia (Riešenie problému s Firewallom a NAT)

4.4.1 UPnP (Universal Plug and Play)

UPnP [ 16 ] [ 17 ] je technológia zameraná na domácich používateľov a domáce

kancelárie (home Office). Táto architektúra je určená na adresovanie množstva hlavných

požiadaviek (problémov) (nie len VoIP) a je navrhnutá tak aby umožnila použitie hotovej

konfigurácie pre malé siete aj neskúsenými používateľmi. UPnP umožňuje klientským

aplikáciám odhaľovať vyhľadávať a konfigurovať sieťové komponenty, vrátane NAT

firewallov, ktoré sú zahrnuté v UPnP softwari.

Základnou potrebou vo VoIP aplikáciách je odhaliť a použiť externú IP adresu a

port ktorý NAT vyberie pre signalizáciu a toky médií. Ak sú už potrebné informácie

známe, VoIP klient môže túto informáciu použiť na VoIP signalizáciu na nadviazanie

spojenia. Toto zabezpečuje, že hovor je uskutočnený použitím verejných, smerovateľných

adries a portov a je uskutočnené priame spojenie. Na dosiahnutie spojenia musia mať

NAT a VoIP klienti zapnuté a podporované UPnP. Zatiaľ čo mnoho menších spoločností


- 60 -

podporuje NAT UPnP pre VoIP, existuje len veľmi málo VoIP klientov s touto podporou.

Hlavná nevýhoda tejto technológie súvisí s bezpečnosťou, keďže nedostatočne rieši

problém s firewallom. UPnP závisí na NAT opening pinholes (otvorenie portov nutných

na VoIP) do vonkajšieho sveta ktoré sú pod dynamickou kontrolou UPnP klienta. Toto

riešenie je protikladom k viacerým bezpečnostným/firewallovým politikám a práve preto

táto technológia nemôže byť akceptovateľná pre väčšie spoločnosti.

Obr. 4.4.1 – UPnP komponenty

4.4.2 STUN (Simple Traversal of User Datagram)

Protokol STUN (Simple Traversal of User Datagram) [ 16 ] [ 17 ] umožňuje SIP

klientovi zistiť či sa nachádza za NAT a determinovať typ tohto NAT. STUN je veľmi

dobrým riešením pre VoIP za NAT avšak, má jeden významný nedostatok, funguje len

pri niektorých typoch NAT. Dokonca nepracuje so symetrickým NAT ktoré je používané

vo väčšine podnikových sietí. STUN taktiež nepodporuje SIP zariadenia založené na

TCP.

Obr. 4.4.2 – STUN, signalizačný tok

Návrh protokolu STUN definuje špeciálny server (STUN server) vo verejnom

adresnom priestore. Slúži na informovanie SIP klienta s aktivovaným STUN privátneho


- 61 -

adresného priestoru istej verejnej NAT IP adresy a portu ktorý bude použitý pri danom

spojení. Avšak používanie klientov s podporou STUN prípadne vylepšovanie už

použitých klientov na podporu STUN, robia tento protokol nie veľmi populárny u

veľkých spoločností. STUN identifikuje verejnú stranu NAT pomocou prieskumných

STUN správ ktoré prichádzajú do STUN servera. Klient s aktivovaným STUN posiela

tieto prieskumné STUN správy externému STUN serveru aby determinoval prijímací port

ktorý bude používať. STUN server overí prichádzajúcu správu a informuje klienta, ktorá

verejné IP adresa a porty boli použité NAT. Tieto údaje sú neskôr použité pri správach

pre nadviazanie spojenia. Ako už bolo spomenuté STUN nedokáže pracovať so

symetrickým NAT. Symetrické NAT vykonávajú mapovanie na základe zdrojovej IP

adresy a čísla portu, ako aj cieľovej IP adresy a príslušného čísla portu. IP adresa

cieľového VoIP klienta je iná ako tá ktorú má STUN server. To znamená, že NAT

uskutoční nové mapovanie za použitia iného portu pre odchádzajúce dáta, čo vedie k

tomu, že informácie obsiahnuté v správe pre nadviazanie spojenia sú nesprávne a pokus o

spojenie zlyhá. Ten istý problém sa vyskytuje aj u prijímaných dát. Práve preto STUN je

závislý od toho, že ak je raz port pre odchádzajúce dáta STUN servera namapovaný,

všetky dáta z hociktorej časti siete s ľubovoľnou zdrojovou IP adresou budú schopné

použiť mapovanie v opačnom smere a dosiahnuť prijímací port v klientovi.

NAT, ktoré pracujú na princípe spomenutom vyššie sú náchylné na útoky z vonku,

čo nie je z hľadiska bezpečnosti žiadúci jav. Táto metóda preto zlyháva v riešení

problémov s firewallmi pretože zo sebou prináša väčšie riziká z hľadiska bezpečnosti.

4.4.3 Comedia (Connection Oriented Media)

Problém symetrických NAT rieši metóda označovaná ako “Connection oriented

media“ [ 16 ] [ 17 ]. V prípade symetrických NAT musí klient poslať RTP na a prijímať

RTP z tej istej IP adresy. Každé RTP spojenie medzi koncovým bodom mimo NAT a

bodom za NAT musí byť point-to-point a preto koncový bod mimo NAT musí čakať

pokiaľ neprijme paket od klienta predtým ako vie kam má odpovedať.

Ak koncový bod komunikuje s klientmi za NAT a súčasne s klientmi mimo NAT,

musí vedieť, kedy môže dôverovať SDP správam ktoré prijíma v SIP správach, a kedy

potrebuje počkať na prijatie paketu priamo od klienta ešte pred tým ako otvorí kanál späť

k zdroju IP:port odkiaľ bol paket prijatý.


- 62 -

Jeden z návrhov ako informovať koncový bod aby čakal na prichádzajúci paket je

pridať riadok “a=direction:active” do SDP správy (ktorá prichádza od klienta za NAT).

Keď koncový bod prečíta pridaný riadok, vie že klient aktívne nastaví IP:port kam má

koncový bod vrátiť RTP a IP:port ktorý bude v SDP správe bude ignorovať.

Primárne SIP klienti nepodporujú ‘a=’ tag. Na podporu tagu je potrebné aby mali do SIP

toku vložený istý druh prekladača, ktorý môže rušiť ostatné rozhodnutia aby determinoval

že sa klient nachádza za symetrickým NAT. Ak je rozhodnuté že klient je za symetrickým

NAT, prekladač vloží vyššie uvedený riadok do SDP v SIP správe.

Žiaľ veľkou nevýhodou je, že toto riešenie nefunguje ak sú obaja klienti za NAT.

Obr. 4.4.3 - Comedia

4.4.4 TURN (RTP Relay)

Ak koncové body podporujú Connection Oriented Media, problém prenosu cez

symetrické NAT je vyriešený. Avšak stále existujú 2 problematické situácie:

• Ak koncový bod nepodporuje tag a=direction:active

• Ak obaja klienti sú za symetrickým NAT

V týchto prípadoch je jedným z riešení mať RTP Relay (server) [ 16 ] [ 17 ] v ceste RTP

toku medzi dvoma koncovými bodmi. RTP relay sa správa ako druhý koncový bod vo

vzťahu k aktuálnym koncovým bodom, ktoré medzi sebou chcú komunikovať. Väčšinou

je ešte prítomný server v strede SIP toku (nazývaný NAT Proxy) ktorý manipuluje s SDP

tak aby koncové body posielali RTP do RTP relay a nie sebe. RTP vykoná vlastné interné

mapovanie a zaznamená zdrojovú IP:port každého koncového bodu, teda používa toto

mapovanie na posúvanie RTP z jedného do druhého koncového bodu.


- 63 -

Typický priebeh hovoru, ktorý môže byť medzi User Agentom (užívateľským

klientom) za symetrickým NAT a hlasovou bránou mimo NAT, znázorňuje obrázok

4.4.4.

Obr. 4.4.4 – RTP Relay

1. UA pošle pozývaciu správu (invite message) NAT Proxy cez NAT

2. NAT Proxy kontaktuje RTP relay a požiada o nadviazanie spojenia

3. RTP Relay pridelí voľné páry portov pre toto spojenie. NAT Proxy to využije na

modifikovanie SDP informácie prijatej pozývacej správy.

4. NAT Proxy posunie ďalej SIP pozývací odkaz so zmeneným SDP druhému

klientovi

5. Druhý klient odpovie svojou vlastnou SDP informáciou ktorá obsahuje port na

ktorom prijíma RTP pakety

6. NAT Proxy kontaktuje RTP Relay aby zamenil IP:port druhého klienta (ak je brána

(Gateway) taktiež za symetrickým NAT, NAT Proxy dá inštrukcie RTP Relay aby

počkal na pakety od druhého klienta predtým ako nastaví IP:port na posielanie RTP

na bránu)

7. RTP Relay odpovedá NAT Proxy že RTP port je pripravený ma tok dát (upstream)

8. NAT Proxy posiela odpoveď späť UA hneď ako zmení SDP s odpoveďou s IP:port

z RTP Relay

9. UA začína posielať RTP na IP:port RTP Relay ktorý dostal

10. RTP Relay zaznamená IP:port odkiaľ prijal paket a posunie paket na IP:port

druhého klienta

11. RTP pakety od druhého klienta smerujú do RTP Relay

12. RTP Relay tieto pakety posiela klientovi


- 64 -

Pri tomto riešení je dôležitých niekoľko skutočností:

1. Klient potrebuje stále posielať a prijímať RTP na rovnakom porte

2. Toto riešenie funguje na všetkých typoch NAT, avšak kvôli oneskoreniu spojenému s

RTP Relay, je menej výhodné ho nasadiť pri symetrickom NAT.

3. Existujú aj iné riešenia implementácie RTP Relay.

Veľkou výhodou tohto riešenia je, že dokáže prekonať všetky typy NAT. Avšak

nevýhodou môže byť, že celá komunikácia stojí na jednom bode a tým je RTP Relay a

taktiež môže byť nevýhodou vysoká cena, ktorá predurčuje toto riešenie pre väčšie firmy.

4.4.5 ALG (Application Layer Gateway)

Táto metóda stojí na inštalácii nového Firewall/NAT – Application Layer

Gateway (ALG) [ 16 ] [ 17 ]. Dané zariadenie alebo software nahrádza privátnu IP:port v

odchádzajúcej SIP/SDP správe externou IP:port. Potom inštruuje NAT aby urobilo

verejno-privátne mapovanie. Prichádzajúce SIP a RTP pakety budú teda niesť verejnú IP

adresu a portu. Pri ďalšom NAT sú tieto údaje namapované znovu na privátnu IP adresu a

port cieľového bodu. ALG a NAT sa môžu zdať ako dva komponenty s rovnakým

riešením. Väčšinou sú implementované ako dve aplikácie v rámci jedného zariadenia. SIP

signalizácia musí stále prechádzať cez ALG avšak u RTP to nie je potrebné.

Obr. 4.4.5 – ALG

4.4.6 Tunelovacie techniky

Táto metóda je založená na vytvorení tunela pre média aj signalizáciu, ktoré sú

pomocou tunela prenášané cez NAT/firewall do servera vo verejnom adresnom priestore


- 65 -

[16 ] [ 17 ]. Táto technológia vyžaduje existenciu servera v privátnej sieti a servera mimo

privátnej siete. Tieto zariadenia vytvoria medzi sebou tunel a pomocou neho prenášajú

všetky SIP dáta. Server mimo privátnej siete modifikuje signalizáciu tak aby zohľadnil

vlastné porty pre odchádzajúce dáta a umožnil tak VoIP systému vytvárať odchádzajúce

hovory a prijímať prichádzajúce hovory. Zvyčajne sa v takomto tuneli nepoužíva

enkrypcia dát.

Aj keď táto technológia vyžaduje minimálne zmeny v bezpečnostnej politike, jej hlavným

problémom je nutnosť existencie servera mimo privátnej siete.

Obr. 4.4.6 – Tunelovacie techniky

4.4.7 External Query

Pri absencii metódy komunikácie s NAT zariadením, najlepšou cestou pre klienta

na získanie svojej externej IP adresy a čísla portu, je vyžiadať si od servera mimo NAT

informáciu, ako vidí zdroj paketu ktorý pošle. V tomto prípade, externý server (NAT

probe) čaká na pakety. Ak príjme paket, vráti správu z rovnakého portu zdroju ktorý

paket poslal. Táto správa už obsahuje externú IP adresu a číslo portu. Takto to funguje vo

všetkých typoch NAT.

Klient vie za daných okolností determinovať:

a) že je za NAT (ak dvojica IP adresa:port ktorá sa vráti v správe z externého servera je

iná akú má pôvodne

b) ktorá externá IP adresa:port má byť použitá v SDP správe aby mohol byť klient

dosiahnuteľný

Napríklad chce byť klient dosiahnuteľný na 192.168.1.100:5060, najprv pošle požiadavku

„NAT probe“ z portu 5060. NAT probe automaticky príjme paket s požiadavkou z adresy

212.12.32.99:12768 a odpovie na túto adresu a port tou istou IP:port dvojicou.


- 66 -

Obr. 4.4.7 – External Query

Táto metóda funguje len za splnenia týchto podmienok:

• klient musí posielať a prijímať RTP na tom istom porte

• klient musí posielať SIP správy krátko po poslaní požiadavky NAT probe. Ak je medzi

nimi oneskorenie príliš veľké, môže dôjsť k zmene mapovania NAT

• v prípade Restricted Cone a Port Restricted Cone NAT musí klient poslať paket k cieľu

skôr ako NAT dovolí prijať pakety z cieľového bodu (nikto nemôže kontaktovať klienta

skôr ako ho klient sám kontaktuje). [ 16 ] [ 17 ]

4.4.8 Interactive Connectivity Establishment (ICE)

Na rozdiel od predošlých riešení prenosu hlasu za NAT ktoré používajú server

ktorý je medzi dvoma koncovými bodmi, toto riešenie sa zameriava na koncové body,

konkrétne na proces ich vyhľadávania.

ICE umožňuje koncovým bodom determinovať typy NAT ktoré medzi nimi existujú a

taktiež umožňuje zistiť IP adresy pomocou ktorých môžu komunikovať. Proces

vyhľadávania koncových bodov používa mnoho z mechanizmov spomenutých vyššie.

Proces komunikácie prebieha nasledovne:

1. Koncový bod ktorý iniciuje spojenie (iniciátor) najprv získa informáciu o tom na akej

IP adrese a porte ho vidia zariadenia mimo NAT použitím vlastných konfiguračných

informácií a taktiež mechanizmov ako STUN alebo TURN. Teda využíva vonkajší server

len na získanie informácie o externej IP adrese a čísle portu.


- 67 -

2. Iniciátor posiela inicializačnú správu druhému koncovému bodu. Táto správa obsahuje

informácie získané v prvom kroku. ICE zahŕňa signalizačné informácie na základe

ktorých vie prekonať NAT.

3. Na základe prijatej inicializačnej správy, druhý koncový bod získa informáciu o svojej

externej IP adrese a čísle portu rovnako ako v prvom kroku iniciátor.

4. Následne pošle správu s odpoveďou iniciátorovi. Hneď ako je signalizácia dokončená,

každý koncový pod posiela dáta na danú adresu v poradí s najvyššou prioritou.

5. Pri výmene dát medzi koncovými bodmi, každý z bodov súčasne posiela STUN

požiadavku druhému koncovému bodu. Z toho je zrejmé, že každý z koncových bodov

slúži tomu druhému ako STUN server.

6. Nasledujú STUN odpovede na požiadavky

7. Zo všetkých STUN odpovedí ktoré sa vrátili je tá s najvyššou prioritou použitá pre

následné dátové pakety. [ 16 ] [ 17 ]

Obr. 4.4.8 – ICE proces 4.4.9 SBC (Session Border Controller)

SBC (Session Border Controller) je zariadenie predovšetkým pre VoIP sieť, ktoré

kontroluje prístup hovorov do siete. Niekedy má funkciu (závisí od zariadenia) hostu,

ktorý obsluhuje kontrolu hovorov v sieti, čiže UA v sieti nie sú touto kontrolou zaťažený.

SBC má dve hlavné funkcionality:

• Signalizačná funkcionalita (SBC - SIG) – kontroluje prístup VoIP

signalizačných správ do siete a obsluhuje tieto správy


- 68 -

• Mediálna funkcionalita (SBC - MEDIA) – kontroluje prístup mediálnych

(RTP/RTCP) paketov do siete, zabezpečuje diferencovanie služieb a QoS pre

rôzne typy mediálnych spojení (media streams) a chráni sieť voči útokom

Použitie SBC

• Chránia okrajovú časť siete providera.

o Sú implementované ako NAT servre.

o Môžu zastávať funkcionalitu Firewallu alebo spolupracovať s existujúcimi

Firewallmi v DMZ. Môžu otvárať priechodné porty (pinholes) na

Firewalli, aby tak povolili prechod VoIP signalizácii a mediálnemu toku

do siete.

o Majú schopnosť utajiť sieťovú topológiu a tým utajiť detaily konfigurácie

siete (providera, zákazníka, atď) alebo smerovania hovorov. Modifikujú

VoIP signalizačné správy.

o Eliminujú nepodporované VoIP signalizačné a mediálne protokoly na

okraji siete

• Podporujú VoIP signalizáciu a mediálny prenos k zariadeniam za

Firewallom/NAT bez požiadavky na rekonfiguráciu zariadení alebo Firewallu

• Dokážu kontrolovať prístup hovorov do siete. Chránia sieť pred DoS útokmi,

pretože neoprávnené hovory sú odmietnuté. Garantujú dodržiavanie SLA (Service

Level Agreement).

Obr. 4.4.9 – Bloková architektúra SBC

[ 18 ]


- 69 -

5. ROZBOR STAVU SIETE ŽILINSKEJ UNIVERZITY Z H ĽADISKA

BEZPEČNOSTI A ROZHRANÍ (VoIP CEZ SIP)

5.1 Všeobecné poznatky o stave siete Žilinskej univerzity z hľadiska bezpečnosti

V tejto kapitole bude spomenutá analýza momentálneho stavu siete Žilinskej

univerzity z hľadiska bezpečnosti a to na základe konzultácií so správcom siete UIaKT

(Ústav informačných a komunikačných technológií). Požadované vlastnosti siete

Žilinskej univerzity sú nasledovné:

• Vysoké pokrytie univerzity dátovou sieťou • Komunikačná infraštruktúra pre IIS • Efektívny management siete • Účinná bezpečnostná politika • Garantované pásmo pre koncového užívateľa 10/100Mb • VLAN • QoS • Multicast • Konvergovaná sieť • IP Telefónia • Videokonferencie

Súčasný stav je charakterizovaný v tabuľke 6 a na obrázkoch 5.1.1 a 5.1.2.

Fyzická vrstva Optika (Backbone) aj metalika Prenosová technológia

Ethernet (CISCO) - jeden dodávateľ, v budúcnosti možný upgrade siete

Smerovanie L3 switching - VLAN

Kryptovanie (VPN) len strategické úseky siete (rektorát) – zdieľanie Intranetu

Monitorovanie siete áno (monitorovanie iba prevádzky), neuvažuje sa o prideľovaní prístupových práv

Bezpečnostná politika nie je presne definovaná (neboli vydané pravidlá), evolučný vývoj zabezpečenia siete, zabezpečenie hlavne chrbticovej siete

Spoľahlivos ť

veľký dôraz na spoľahlivosť siete, niektoré sieťové prvky sú zálohované (VD a knižnica vzájomne), snaha o nepretržitú prevádzku siete, riešené aj záložné napájanie najdôležitejších sieťových prvkov

Služby povolené všetky služby (http, smtp, pop3, telnet, ftp, atď), neuvažuje sa o obmedzeniach

Obmedzenia na serveroch

servre sú monitorované a pri prípadnom napadnutí je limitovaná prenosová rýchlosť na 128 kb/s


- 70 -

Prepojenia prepojenie s SSE, pripravuje sa aj prepojenie s Orange a T-Mobile

Prípojné body Nemocnica s poliklinikou (nepripojené), Regionálna knižnica (spojenie aktívne), Bilingválne gymnázum (spojenie aktívne)

Pripojenie detaš. pracovísk

FRI detašované pracovisko Ružomberok, FRI detašované pracovisko Prievidza, EF detašované pracovisko L. Mikuláš, FŠI detašované pracovisko Košice

Tabuľka 6 – Súčasný stav siete Žilinskej univerzity

VD-A

VD PIX

VD-B

VD-CVD-D

VD-E

SANET PU

SANET MTZA Moyzesova

FSI

SvF

Internaty Hliny

Hurbanova A

Hurbanova B

NRNSPolop

FRI B

HB

Menza

H

Internavt VD

CCM

VoiP GW + GK

UK

FRI

VD

Obr. 5.1.1 – Topológia siete Žilinskej univerzity


- 71 -

1Gb S

MF

1Gb SMF

1Gb SMF

100Mb MMF

2x100Mb M

MF

2x100Mb M

MF

2x100Mb M

MF

2x10

0Mb

MM

F

100Mb MMF

100Mb MMF

CI SC O S Y ST EMS

C 3550 - Velky Diel

C 2950C - FEL+SjF

C 2950C - FEL+SjF

C 2950C - FEL+SjF

C 2950C -FPEDaS

1Gb SMF

1Gb S

MF

34Mb

C IS C O S YS TE MS

C 3524 XL -SvF

CI SC O S YS T EMS

C3550 - FRI

100Mb MMF

100Mb M

MF

100M

b M

MF

1 00M

b M

MF

CI S CO S YSTEM S

C 3550 - Un.Kniznica

Hosp.Blok

C2950 - Menza USZ-VD

1 2 3 4 5 6 7 8 9 10 11 1 2 13 14 15 16 17 18 19 20 21 22 23 24

1 2

R PS C 2950

C 2950 - Int.VD. Blok E F

100M

b M

MF

C 2950 - Int.VD. Blok G H

NR

1Gb SMF

CISCO S YSTEMS

C2950 - FSI

CI SCO S YSTEMS

C2950 - FPV

CISCO S YSTEMS

C2950 - Int.Hliny.B3

1 2 3 4 5 6 7 8 9 1 0 11 12 1 3 14 15 16 17 18 19 20 21 22 23 24

1 2

R PS

C 2950

1Gb - SANET -PU

1Gb - SANET -MT

CISC O S Y STEM S

Cisco 12000SERI ES

SANET C6509 - Rektorat

Blok H

Obr. 1. Topológia MAN UTCNet

NS

St. router - E

Poloprevadzka

PIX - Rektorat

CISCO S YSTEMS

C2500 - SjF KAM

C 2950T

Obr. 5.1.2 - Topológia siete Žilinskej univerzity

5.1.1 Popis stavu siete

Z hľadiska dostupných materiálov a poznatkov o toplógii a rozhraní je možné sieť

Žilinskej univerzity zaradiť do kategórie špecifických subjektov (kap. 3.1.1). Je potrebné

si uvedomiť, že takáto akademická sieť musí ponúknuť široký priestor pre oblasť

výskumu, vedy, vzdelávania a prístupu k informáciám. Zrejme aj z tohto hľadiska bola

takýmto spôsobom koncipovaná a navrhnutá. Predovšetkým musí byť spoľahlivá

(odolnosť voči výpadkom v sieti) a musia byť dostupné potrebné informácie. Na druhej

strane môže byť takáto sieť aj dobrým testovacím prostredím pre výskum v oblasti

telekomunikácií, čoho dôkazom bol aj výber prenosovej technológie (CISCO – Gbit

Ethernet).


- 72 -

5.1.2 Vplyv projektu SANET II na IKT Žilinskej uni verzity Prínosy:

• Nárast objemu prenesených a spracovaných údajov

• Penetrácia VT do prostredia univerzity (správa a riadenie, veda a výskum,

výučba)

• 80% pokrytie pracovísk univerzity dátovými prípojkami (pracoviská, učebne,

laboratóriá, internáty,..)

• Vytvorenie podmienok pre rozvoj univerzitného intranetu (univerzitná pracovná

plocha, internetové kiosky)

• Vytvorenie podmienok pre rozvoj Integrovaného informačného systému

univerzity

• Vysoká kvalita dátovej siete a služieb (odozva, spoľahlivosť, priepustnosť,...)

• Spoločenská prezentácia univerzity – konferencie, streaming video, web kamery,

virtuálna knižnica ...

Problémy:

• zvýšenie požiadaviek na počítačovú gramotnosť a zručnosť používateľov

• zvýšenie nákladov na podporu používateľov (help-desk, školenia, nápovedy,

príručky,...)

• nárast prienikov a útokov na univerzitnú sieť

• nárast porušovania AUP (Acceptable Use Policies) užívateľmi (študenti,

doktorandi)

• väčšie dôsledky vírusových útokov (epidémie)

• spam

• nárast nákladov na prevádzku siete (antivírus, antispam, firewall, správa siete,

technický servis, ...)

5.1.3 Integrovaný informačný systém ŽU

Tvoria subsystémy:

� personalistika a mzdy, dochádzkový systém

� stravovací systém

� register študentov


- 73 -

� e-Vzdelávanie (prihlasovanie na skúšky, evaluácia, zadávanie známok, testovací

systém, ...)

� register preukazov na čipových kartách (zamestnanci, študenti, návštevy)

� ekonomický informačný systém + MIS, evidencia majetku

� knižničný informačný systém

� jednotný systém správy účtov užívateľov (LDAP). Zamestnanci i študenti

univerzity majú pridelené užívateľské meno, heslo, prístup k aplikáciám

� redakčný systém pre správu univerzitného intranetu (za obsah, správnosť a

aktualizáciu zodpovedá pracovisko kde prvotná informácia vznikla)

5.1.4 Popis stavu siete z hľadiska VoIP

• Aktívny CallManager, gateway prepojenia na PBX, gatekeeper prepojenia na Košice a CESNET

• Hlasové služby na IP sieti – integrálna súčasť riešenia VoIP v sieti SANET • Problémy s dokončením výstavby infraštruktúry pre VoIP

Tabuľka 7 – Popis súčasného stavu vo VoIP sieti

H.323 Gatekeeper (GNUGK) - 1. pre smerovanie (SR a mimo SR), 2. peering do CZ

SIP

SIP proxy - 1. SIP Express Router (prihlasovanie užívateľov), 2. SIP Express Router (smerovanie)

Možnos ť zabezpečenia

V SIP možnosť SSL, autorizácia, možnosť doinštalovania mechanizmov IPsec

SBC (Session Border Controller)

zatiaľ nebola potreba nasadzovať ich do siete


- 74 -

<---

Obr. 5.1.3 – Topológia a logická štruktúra VoIP siete Žilinskej univerzity


- 75 -

5.1.5 Výhody prepojenia VoIP a PBX

• Volanie medzi budovami univerzity „zadarmo“ po IP sieti

• Volanie medzi univerzitami na Slovensku a do ČR „zadarmo“

• Jednotný číslovací plán IP telefónov a PBX umožňuje jednoduché telefonovanie

Problémy na riešenie pre rozvoj:

• Vytvorenie H.323 administratívnych zón pre hlasové služby v rámci SANET

• Vytvorenie služieb autentifikácie užívateľov, autorizácie hovorov

• Riešenie problematiky tarifikácie pre účastníkov IP telefónie

• Vypracovanie pravidiel pre pripájanie účastníkov do siete IP telefónie

• Riešenie problematiky komplexných adresárových služieb

• Riešenia XML služieb pre IP telefóniu v rutinnej prevádzke

6. NÁVRH OPTIMÁLNEHO RIEŠENIA PREPOJENIA

PRIVÁTNYCH SIETÍ K SIETI PROVIDEROV NA BÁZE IP (z

hľadiska VoIP)

Pri návrhu optimálneho riešenia prepojenia privátnej siete a siete providera (z

hľadiska VoIP ) je nutné aplikovať všetky poznatky spomenuté v tejto práci.

6.1 Návrh prepojenia malej privátnej siete a providera

Pripojenie:

• pripojenie k providerovi cez ISDN linku

• pripojenie k providerovi cez aDSL linku

• pripojenie k providerovi cez WiFi

Koncové zariadenie:

• ISDN TA

• aDSL modem, aDSL router

• WiFi karta


- 76 -

Bezpečnosť a VoIP:

• zákazník by mal používať antivírovú ochranu, používať antispyware, zablokovať

nepotrebné služby

• použiť softwarový Firewall, poprípade nastaviť Firewall na koncovom zariadení

• použitie softwarového SIP klienta (Softphone, X-Lite, iné)

• použitie hardwarového SIP klienta (IP telefón)

• povoliť na Firewalli príslušné UDP porty dané providerom

• doporučené šifrovanie spojenia (UA to musí podporovať) SIP

Na obrázku 6.1.1 je znázornené odporúčané prepojenie takejto siete k sieti providera.

Zákazník má možnosť vybrať si z VoIP služieb, ktoré momentálne provideri poskytujú.

Obr. 6.1.1 – Príklad prepojenia malej privátnej siete a providera

6.2 Návrh prepojenia strednej privátnej siete a providera

Pripojenie:

• pripojenie k providerovi cez ISDN linku


• pripojenie k providerovi cez WiFi


• ISDN TA

• aDSL modem, aDSL router

• WiFi karta


• používanie antivírovej ochrany a antispyware, zablokovať nepotrebné služby,

sústrediť sa na implementovanie heslovej politiky


- 77 -

• používať Firewall na koncovom zariadení, zablokovať nepotrebné porty

a protokoly

• hlasovú prevádzku obmedziť na zariadeniach, kde sú uložené dôležité dáta

(Softphone nenainštalovať na PC, ktorý slúži ako server)

• použitie softwarového SIP klienta (Softphone, X-Lite, iné)


• povoliť na Firewalli príslušné UDP porty dané providerom

• doporučené šifrovanie spojenia (UA to musí podporovať) SIP

• Softphone nainštalovať iba na vyhradené počítače

Na obrázkoch 6.2.1 a 6.2.2 sú znázornené odporúčané prepojenia takejto siete k sieti

providera. V súčasnosti väčšina providerov dokáže takémuto zákazníkovi poskytnúť

akceptovateľnú VoIP službu zo svojho portfólia.

Obr. 6.2.1 – Príklad prepojenia strednej privátnej siete a providera

Obr. 6.2.2 – Príklad prepojenia strednej privátnej siete a providera


- 78 -

6.3 Návrh prepojenia veľkej privátnej siete a providera

Pripojenie:


• pripojenie k providerovi cez MPLS okruh

• pripojenie k providerovi cez prenajatý okruh (lease line)

• pripojenie k providerovi cez Ethernet (CISCO)

Koncové zariadenie (u zákazníka):

• aDSL router (vyššej triedy – Firewall, VoIP brána, podpora IPsec)

• CISCO router (buď pre MPLS alebo pre Ethernet)

• Iné rozhranie (ATM, FR, atď)

Bezpečnosť a VoIP (u zákazníka):

• používanie antivírovej ochrany a antispyware, zablokovať všetky služby

a postupne povoliť potrebné, sústrediť sa na silnú heslovú politiku (pravidelná

obmena hesiel)


a protokoly

• hlasovú prevádzku oddeliť od dátovej (použitie VLAN)

• použitie softwarového SIP klienta (Softphone, X-Lite, iné) ale len na

zariadeniach, ktoré sú na inej LAN ako servre a databázy


• použitie ALG zariadení (riešenie problému s NAT a Firewallom)

• Access listy, verifikácia volajúceho podľa certifikátov

• Kontrola logov a neoprávnených spojení

Na obrázkoch 6.3.1, 6.3.2 a 6.3.3 sú znázornené odporúčané prepojenia takejto siete

k sieti providera.


- 79 -

Obr. 6.3.1 – Príklad pripojenia pobočiek privátnej siete do MPLS siete providera

Obr. 6.3.2 - Prepojenie sietí cez VPN tunel (IPsec)

Obr. 6.3.3 - VPN prepojenie pobočiek cez centrálnu pobočku

6.3.1 Odporúčané bezpečnostné pravidlá

Zákazník by mal:

• presne zadefinovať bezpečnostné pravidlá v sieti a podmienky a zdokumentovať

ich


- 80 -

• chrániť dôležité databázy a servre prístupovými právami a certifikátmi a doležité

informácie zálohovať (CD)

• do VoIP siete implementovať pre seba potrebné bezpečnostné mechanizmy (kap.

4.1 – 4.4)

Provider by mal:

• podporovať štandardné bezpečnostné mechanizmy (IPsec)

• poskytnúť zákazníkovi cenovo dostupné a spoľahlivé riešenie (k službe VoIP

poskytnúť telefónnu linku)

6.4 Návrh prepojenia nadnárodnej privátnej siete a providera

Pripojenie:

• pripojenie k providerovi cez prenajatý okruh (lease line)

• pripojenie k providerovi cez Ethernet (CISCO)

• pripojenie k providerovi cez SONET/SDH - odporúčané


• CISCO router vyšších tried ako 3

• Iné rozhranie (ATM, FR, atď)

• SDH rozhranie (napr. Lucent LKA.., Alcatel, Nortel a pod.)


• používanie antivírovej ochrany a antispyware, zablokovať všetky služby

a postupne povoliť potrebné, sústrediť sa na silnú heslovú politiku (pravidelná

obmena hesiel)


a protokoly

• hlasovú prevádzku oddeliť od dátovej (použitie VLAN)

• použitie softwarového SIP klienta (Softphone, X-Lite, iné) výlučne na

zariadeniach fyzicky oddelených od Intranetu, databáz, servrov

• použitie hardwarového SIP klienta (IP telefón) – odporúčané sieť takýchto

klientov oddeliť od dátovej siete (smerom k providerovi nezávislé rozhrania pre

dátovú a pre hlasovú prevádzku)

• použitie ALG zariadení (riešenie problému s NAT a Firewallom)

• Access listy, verifikácia volajúceho podľa certifikátov


- 81 -


Na obrázkoch 6.4.1 - 4 sú znázornené odporúčané prepojenia takejto siete k sieti

providera.

Obr. 6.4.1 – Príklad pripojenia privátnej siete k providerovi

Obr. 6.4.2– Príklad spolupráce Firewallu a SBC (Session Border Controller)


- 82 -

Obr. 6.4.3 – Príklad prepojenia privátnej siete na providera s využitím funkcionalít SBC

Ďalšie možné prepojenie k providerovi na báze dostupnej softwarovej alebo hardwarovej

platformy:

Obr. 6.4.4 – Pripojenie k providerovi cez softwarovú platformu bežiacu na serveri (napr.

Bordeware - SIPassure)


Zákazník by mal:


ich


informácie ukladať na zrkadlové servre (záloha dát)


- 83 -

• do VoIP siete implementovať SBC a bezpečnostné mechanizmy vo VoIP (kap. 4.1

– 4.4)

• robiť monitorovanie svojej siete

Provider by mal:

• podporovať požadované bezpečnostné mechanizmy zákazníkom (IPsec, TLS, SSL

a iné)

• poskytnúť zákazníkovi náhradné riešenie pri výpadku siete (napr. pri výpadku vo

VoIP spojení presmerovať hlasovú prevádzku na PSTN sieť alebo na mobilnú

sieť) obr. 6.5.2, prípadne SLA

• vo VoIP presunúť právomoc registrácie užívateľov na privátny proxy server

(umiestnený v privátnej sieti obr. 6.4.3)

6.5 Návrh prepojenia špecifickej privátnej siete a providera (Prepojenie siete

Žilinskej univerzity a providera)

Prepojenie siete Žilinskej univerzity a providera bude realizované optickým

vláknom. Ako rozhranie prepojenia bude použitý router CISCO 7204 VXR (Príloha 4),

ktorý bude prepojený k rozhraniu CISCO Catalyst 6509 (obr. 5.1.2). V tomto prípade

bude len potrebné uvažovať, či daný provider má rozhrania podporujúce prenosové módy

buď ATM, SDH alebo Ethernet. Vyhovujúce by v tomto prípade bolo ak by provider mal

vo svojej sieti implementovaný niektorý z routerov CISCO sady 7200. V takomto prípade

by boli využité všetky funkcionality oboch routerov. Predpokladám situáciu, že provider

takéto zariadenie má. Prepojenie je znázornené na obr. 6.5.1.

SD

Catalys t8500

Power Supp ly 0CISCO YSTEMSS Power Supply 1

SwitchProcessor

SER IESSD

Cisco 1720

BRIS/T

CONSOLE

AUXWIC 0 OK

OK

B2

B1

WIC 1 OK

DSUCPU

LNK100FDX

S3

LOOP

LP

SD

Cisco 1720

BRIS/T

CONSOLE

AUXWIC 0 OK

OK

B2

B1

WIC 1 OK

DSUCPU

LNK100FDX

S3

LOOP

LP

Obr. 6.5.1 – Prepojenie siete Žilinskej univerzity a providera


- 84 -

Pripojenie:

• pripojenie k providerovi cez Fast/Gbit Ethernet (CISCO)

• pripojenie k providerovi cez SONET/SDH

• pripojenie k providerovi cez ATM


• CISCO 7204 VXR (Príloha 4)



a protokoly

• nie je nutné hlasovú prevádzku oddeliť od dátovej

• použitie softwarového SIP klienta (Softphone, X-Lite, iné) výlučne na

zariadeniach fyzicky oddelených od Intranetu (Rektorát), databáz, servrov –

použitie hardwarových IP telefónov


• distribuovaná štruktúra siete z hľadiska VoIP (využiť už existujúce SIP proxy a

Gatekeepre)

• šifrovanie SIP spojení a šifrovanie mediálneho kanálu – nutné hlavne v podsieti

Rektorátu (UA a rozhrania podporujúce IPsec, TLS, S/MIME, SRTP a SRTCP),

nutné aby aj provider podporoval tieto mechanizmy

• 99,999% spoľahlivosť spojení (možnosť dovolať sa kedykoľvek) – záložné

riešenia pre zákazníka



Zákazník by mal:


ich


informácie ukladať na zrkadlové servre (záloha dát)

• do VoIP siete implementovať kryptovanie a SBC (v Intranete)

• robiť monitorovanie siete a pri výpadku v sieti informovať (email, SMS) správcu

danej časti siete


- 85 -

Provider by mal:

• podporovať požadované bezpečnostné mechanizmy zákazníkom (IPsec, TLS, SSL

a iné)

• poskytnúť zákazníkovi náhradné riešenie pri výpadku siete (napr. pri výpadku vo

VoIP spojení presmerovať hlasovú prevádzku na PSTN sieť alebo na mobilnú

sieť) obr. 6.5.2, prípadne SLA

• vo VoIP presunúť právomoc registrácie užívateľov na privátny proxy server

(umiestnený v privátnej sieti obr. 6.4.3) – decentralizovaná štruktúra siete

Obr. 6.5.2 – Príklad presmerovania hlasovej služby na mobilnú sieť pri výpadku VoIP


- 86 -

7. ZÁVER

Témou mojej diplomovej práce bolo začlenenie privátnych sietí do verejnej

konvergovanej siete z hľadiska hlasovej služby v IP prostredí. V práci sú popísané dva

najrozšírenejšie VoIP signalizačné štandardy H.323 a SIP. Zameral som sa na

progresívnejšie sa vyvíjajúci protokol SIP. Ďalej sú popísané štandardy pre prenos dát

v reálnom čase RTP a RTCP. Urobil som analýzu požiadaviek na bezpečnosť VoIP

rôznych typov zákazníkov a uviedol som najčastejšie problémy (implementačné a

bezpečnostné) vo VoIP.

V druhej časti práce som ukázal možné riešenia implementačných aj

bezpečnostných problémov vo VoIP (S/MIME, TLS, IPsec, SRTP, SRTCP a ďalšie)

a urobil som analýzu stavu siete Žilinskej univerzity a ukázal som súčasný stav v sieti.

Výsledkom mojej práce sú návrhy možných prepojení rôznych typov zákazníkov

a providerov pri zohľadnení dodržania potrebných bezpečnostných požiadaviek

prepojenia. Medzi prepojeniami je aj návrh prepojenia našej univerzitnej siete k inej sieti

(alebo providera).

Documents

ÚVOD DO PROBLEMATIKY PREPOJENIA PRIVÁTNYCH SIETÍ …