Analyzátor SIP provozu

Prepis

1 Univerzita Karlova v Praze Matematicko-fyzikální fakulta DIPLOMOVÁ PRÁCE Ondrej Šterbák Analyzátor SIP provozu Katedra softwarového inženýrství Vedoucí diplomové práce práce: RNDr. Ing. Jiří Peterka Studijní program: Informatika, softwarové systémy 2008

2 Ďakujem predovšetkým RNDr. Ing. Jiřímu Peterkovi za laskavé a podnetné vedenie práce. Taktiež sa chcem poďakovať za dlhodobú podporu rodine, priateľom a známym. Zvláštna vďaka patrí Miroslavovi Týnovskému, Karlovi Diblíkovi a Anne Mintálovej za cenné rady, pomoc pri organizácii času a korektúru textu. Prohlašuji, že jsem svou diplomovou práci napsal samostatně a výhradně s použitím citovaných pramenů. Souhlasím se zapůjčováním práce. V Praze dne 12. prosince 2008 Ondrej Šterbák

3 Obsah 1 Úvod 6 2 Fungovanie SIP-u Súhrnný prehľad fungovania SIP-u Prvky SIP-u Koncoví užívatelia Registrar servery Proxy servery Redirect servery Správy SIP-u SIP žiadosti SIP odpovede Príklady z prevádzky SIP-u Registrácia klienta Vytvorenie a zrušenie spojenia Transakcie v SIP-e Problémy v komunikácii SIP-u a ich riešenia Problémy s NAT-om a firewallmi Nemožnosť prijímania odpovedí Nemožnosť prijímania nových žiadostí Nepriechodnosť médií Prítomnosť zle naimplementovaných SIP ALG Zvládanie záťaže Veľkosť užívateľskej populácie Relay u Media proxy a TURN serverov Kvalita hovoru Existujúce analyzátory SIP-u Testovanie existujúcich implementácií Analyzátory testujúce funkčnosť

4 4.1.2 Analyzátory testujúce výkon Analyzátory testujúce bezpečnosť Analýza SIP prevádzky Návrh analyzátora História vývoja Voľba PJSIP stacku Vývoj Dôvody pre ukončenie vývoja v PJSIP stacku Výsledný návrh Formát dát a ich zber Vlastný zber dát Analýza Testovacie prostredie Vlastnosti a schopnosti programu Programátorská dokumentácia Použité moduly Popis fungovania programu Dosiahnuté výsledky Plne funkčná komunikácia Čiastočne funkčná komunikácia Nefunkčná komunikácia Záver Výsledky a prínosy Možné budúce vylepšenia A Popis obsahu DVD s návodom na použitie 55 Literatúra 57 4

5 Název práce: Analyzátor SIP provozu Autor: Ondrej Šterbák Katedra (ústav): Katedra softwarového inženýrství Vedoucí diplomové práce: RNDr. Ing. Jiří Peterka vedoucího: Abstrakt: Session Initiation Protocol (SIP) je signalizačný protokol aplikačnej vrstvy, ktorý slúži na vytváranie, upravovanie a rušenie spojení s jedným alebo viacerými účastníkmi. Takýmito spojeniami sú napr. telefónne hovory cez Internet alebo multimediálne konferencie. Táto práca stručne popisuje fungovanie SIP-u a zaoberá sa riešením možných problémov spojených s jeho používaním v domácom sieťovom prostredí. Pri hľadaní riešení vychádza z aktuálnych návrhov štandardov, ktoré zatiaľ neprešli schvaľovacím procesom. Zahŕňa tiež detailný návod pre zber sieťovej komunikácie SIP-u pomocou formátu libpcap, návrh analyzátora chýb v tejto komunikácii a jeho implementáciu v programovacom jazyku Perl. Obsahuje tiež tri vzorové záznamy komunikácie, plne funkčnú, čiastočne funkčnú a nefunkčnú, a zobrazuje na nich ukážkové výstupy analyzátoru. Klíčová slova: SIP, Analyzátor, NAT, Proxy, Registrar Title: SIP traffic analyzer Author: Ondrej Šterbák Department: Department of Software Engineering Supervisor: RNDr. Ing. Jiří Peterka Supervisor s address: Jiri.Peterka@mff.cuni.cz Abstract: Session Initiation Protocol (SIP) is an application-layer control signaling protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. This document briefly describes overview of SIP and is discussing the solutions to different problems which happen when is SIP used in home environment. It is looking for the solutions to actual Internet drafts, which have not been approved yet. It also includes detailed guide for capturing SIP network communication by using libpcap format, design of analyzer of problems in this communication and its implementation in Perl programming language. Three sample SIP communications are captured functional, partly functional and non-functional and the analyzer show its capabilities on them. Keywords: SIP, Analyzer, NAT, Proxy, Registrar

6 Kapitola 1 Úvod V dnešnej dobe je na Internete mnoho aplikácií, ktoré k svojej funkčnosti potrebujú vytváranie a správu spojenia, pričom pod spojením sa myslí výmena dát medzi účastníkmi (napr. telefonický hovor, videohovor, chat alebo sieťové počítačové hry pre viacerých hráčov). Implementácia týchto aplikácií je skomplikovaná zvyklosťami užívateľov, ktorí sa môžu pohybovať a používať rôzne zariadenia, vystupovať pod viacerými menami a môžu používať niekoľko rôznych druhov médií niekedy aj súčasne. Boli vyvinuté viaceré protokoly na vytváranie, správu a rušenie spojení. Dva najznámejšie z nich sú SIP a H.323. V tejto práci sa budeme podrobne venovať iba protokolu SIP. Cieľom práce je popis funkčnosti protokolu SIP, zhrnutie známych problémov spojených s jeho používaním a implementácia nástroja, ktorý má pomáhať s analýzou týchto problémov. Práca sa skladá z troch logických častí. Prvá časť popisuje v kapitole 2 zoznámenie sa s fungovaním SIP-u a so spôsobmi využitia tohto protokolu v praxi. Ďalej uvádza problémy, ktoré sa pri komunikácii vyskytujú a rozbor ich riešení v kapitole 3. Nakoniec v kapitole 4 rozoberá prístupy analýzy SIP protokolu a existujúce analyzátory. Druhá časť popisuje vývoj samotného analyzátora SIP prevádzky. V kapitole 5 je uvedená história vývoja predchádzajúca terajšiemu riešeniu a návrh tohto riešenia, kapitola 6 dokumentuje analyzátor z programátorského hľadiska. 6

7 Záverečná časť v kapitole 7 zhŕňa dosiahnuté výsledky použitia analyzátora. V poslednej kapitole potom hodnotí prínosy práce, zmieňuje niektoré nedostatky zvoleného prístupu a ponúka možné budúce vylepšenia. Práca je doplnená dvoma prílohami: príloha A obsahuje popis obsahu priloženého DVD s návodom na jeho použitie a druhou prílohou je samotné DVD s vyvinutým softvérom a s živou ukážkou jeho použitia. 7

8 Kapitola 2 Fungovanie SIP-u Táto kapitola popisuje základné fungovanie SIP-u. Predstavuje prvky SIP-u a správy, pomocou ktorých tieto prvky navzájom komunikujú. Záver kapitoly túto komunikáciu ilustruje niekoľkými príkladmi. Členenie textu a základné definície pojmov SIP-u vychádzajú zo špecifikácie SIP-u [4] a z prác [20], [21] a [22]. 2.1 Súhrnný prehľad fungovania SIP-u Session Initiation Protocol (SIP, protokol na vytváranie spojenia) slúži na vytváranie, upravovanie a rušenie multimediálnych spojení, ako napr. telefónne hovory cez Internet. SIP zaisťuje lokalizáciu koncových užívateľov, vytvorenie hovoru medzi nimi, ako aj dohodu o podporovaných službách (napr. typoch médií), ktoré sa budú počas hovoru používať. SIP takisto podporuje úpravu prebiehajúceho hovoru (napr. pridanie ďalších služieb alebo ich odobratie) a umožňuje prizvanie ďalších účastníkov do už prebiehajúceho hovoru (napr. multicastovej konferencie). SIP transparentne podporuje mapovanie užívateľských mien a presmerovaní. Týmto spôsobom umožňuje voľný pohyb užívateľov, ktorí tak môžu používať jedinú verejne viditeľnú adresu (napr. sip:ondrej@matfyz.cz) nezávisle na tom, kde sa práve nachádzajú a aké zariadenie pri komunikácii používajú. Ako pomoc pri vyhľadávaní účastníkov, ale tiež k ďalším účelom, ponúka SIP skupinu sieťových uzlov (nazývaných proxy servery), ktorým môžu koncoví užívatelia posielať registrácie, požiadavky na vytvorenie spojenia a rôzne ďalšie žiadosti (angl. requests). Pri vytváraní a rušení spojení pracuje SIP v piatich krokoch: 1. lokalizácia užívateľa: 8

9 vyhľadanie koncového zariadenia, ktoré sa bude používať pri následnej komunikácii 2. dostupnosť užívateľa: rozhodnutie, či je volaný účastník ochotný, resp. schopný hovor prijať (začať komunikáciu) 3. schopnosti užívateľa: určenie podporovaných typov médií a ich vlastností, ktoré sa budú počas hovoru používať 4. nastavenie spojenia: zvonenie ; nastavenie vlastností spojenia u volajúceho a u volaného účastníka; spojenie hovoru 5. správa spojenia: zahŕňa prepájanie hovorov, ukončenie hovoru a zmenu vlastností hovoru SIP nepredstavuje komplexné riešenie multimediálnej komunikácie. Ako také funguje len v spolupráci s ostatnými protokolmi IETF. Je to vlastne len jedna z vrstiev tohto riešenia, ktorá bude typicky používaná s týmito protokolmi: RTP (Realtime Transport Protocol) na prenos dát v reálnom čase a podporu QoS (Quality of Service), RTSP (Realtime Streaming Protocol) na kontrolu doručovania streamovaných médií, MEGACO (Media Gateway Control Protocol) na prepájanie hovorov do verejnej multimediálnej telefónnej siete (PSTN; Public Switched Telephone Network) a SDP (Session Description Protocol) na popis vlastností multimediálnych spojení. Samotná funkčnosť SIP-u však nie je závislá na žiadnom z týchto protokolov. SIP neponúka služby priamo. Ponúka skôr možnosti, pomocou ktorých sa rôzne služby dajú realizovať. SIP môže napr. vyhľadať užívateľa a doručiť požadovaný objekt na miesto, kde sa práve nachádza. Ak je týmto objektom popis spojenia definovaný pomocou SDP, koncové uzly sa môžu dohodnúť na parametroch spojenia. Ak je týmto objektom okrem popisu spojenia aj fotka volajúceho, je možné implementovať službu identifikácie volajúceho. Z tohto je evidentné, ako môže jednoduchý postup (angl. primitivum) slúžiť k poskytovaniu rôznych služieb. Keďže SIP správy a spojenia, ktoré vytvárajú môžu prechádzať cez úplne rôzne siete, nie je možné, aby SIP garantoval priepustnosť siete, a ani tak nečiní. Povaha poskytovaných služieb vyžaduje ich zabezpečenie. Na tieto účely SIP ponúka súbor bezpečnostných opatrení, ktoré zahŕňajú predchádzanie 9

10 DOS, overenie užívateľa (ako oproti proxy, tak aj oproti druhému užívateľovi), ochranu integrity, šifrovanie a služby určené na ochranu súkromia. V nasledujúcich častiach tejto kapitoly sa podrobnejšie pozrieme na fungovanie SIP-u. 2.2 Prvky SIP-u V najjednoduchšej sieťovej konfigurácii komunikujú dvaja koncoví užívatelia priamo medzi sebou navzájom. Väčšinou však bude sieťová topológia SIP-u zložitejšia a bude zahŕňať viaceré typy prvkov SIP-u. Základnými prvkami SIP-u sú koncoví užívatelia, registrar servery, proxy servery a redirect servery. Je nutné podotknúť, že toto je logické rozdelenie prvkov podľa ich funkcie. V praxi je bežné, že viaceré z týchto prvkov sú implementované v jednej aplikácii Koncoví užívatelia Koncové zariadenia v komunikácii SIP-u sa nazývajú User agents (užívateľskí agenti; UA). Logicky obsahujú dve časti: User Agent Client (UAC): posiela žiadosti a prijíma odpovede User Agent Server (UAS): prijíma žiadosti a posiela odpovede Užívateľských agentov nájdeme napr. vo forme aplikácií na počítači (v softvérových telefónoch), v hardvérových IP telefónoch, v telefónnych bránach (na prepájanie hovorov medzi SIP a PSTN sieťou) a v telefónnych záznamníkoch. V tomto texte budeme užívateľského agenta v koncovom zariadení nazývať aj ako SIP klient Registrar servery Registrar server prijíma registrácie od užívateľov. Z týchto registrácii získa informácie o ich aktuálnej polohe (užívateľské meno, IP adresu a port) a uloží si tieto informácie do lokačnej databázy. Takto si teda registrar server udržiava priradenia medzi globálnym užívateľským menom a momentálnymi polohami užívateľa. Registrácie sú časovo obmedzené a je starosťou užívateľa, aby si registráciu včas obnovil. Inak registrácia vyprší a vymaže sa z lokačnej databázy. 10

11 2.2.3 Proxy servery SIP umožňuje vytvorenie skupiny sieťových uzlov, ktoré sa nazývajú proxy servery. Proxy servery sú dôležité prvky v komunikácii SIP-u. Pomáhajú koncovým užívateľom s registráciou, smerujú žiadosti na vytvorenie spojenia podľa momentálnej polohy volaného užívateľa, overujú totožnosť volajúceho užívateľa a vykonávajú mnohé ďalšie užitočné funkcie. Najdôležitejšou úlohou proxy servera je však smerovanie žiadostí medzi koncovými užívateľmi. Žiadosť o vytvorenie spojenia zvyčajne prejde niekoľkými proxy servermi, než dorazí ku koncovému proxy serveru, ktorý pozná aktuálnu polohu volaného SIP klienta. Tento proxy server prepošle túto žiadosť klientovi, ktorý ju následne buď prijme alebo odmietne. Proxy server funguje v jednom z dvoch režimov, a to buď bez zachovania stavu (stateless proxy server; ďalej ako bezstavový proxy server) alebo so zachovaním stavu (stateful proxy server; ďalej ako stavový proxy server). Bezstavový proxy server Bezstavový proxy server pracuje ako jednoduchý preposielací prvok. Preposiela každú žiadosť smerom ku serveru k práve jednému prvku, ktorého polohu určí na základe informácií obsiahnutých v žiadosti. Takisto prepošle každú odpoveď, ktorú obdrží smerom ku klientovi. Bezstavový proxy server je teda veľmi jednoduchý, ale rýchlejší než stavový proxy server. Využíva sa na jednoduché rozloženie záťaže a smerovanie správ. Jeho nevýhodou je, že nie je schopný absorbovať znovu poslané správy ani obsluhovať pokročilé smerovanie správ ako napr. rozvetvenie (angl. forking; preposlanie správy viacerým serverom) alebo presmerovanie žiadosti. Stavový proxy server Stavový proxy server si pri príchode žiadosti vytvorí stav o tejto žiadosti a drží si ho až do konca transakcie. Niektoré transakcie môžu trvať dosť dlho. Napr. transakcia vytvorená žiadosťou o nadviazanie spojenia trvá dovtedy, dokiaľ volaný užívateľ neprijme alebo neodmietne hovor. Pretože stavový proxy server si musí držať stav transakcie počas celého jej trvania, obmedzuje to jeho výkon. Stavový proxy server môže preposlať správu viacerým príjemcom v snahe o zvýšenie šance na úspešnú odpoveď. Taktiež môže absorbovať znovu poslané správy, pretože zo stavu transakcie vie, či už rovnakú správu v minulosti obdržal. Stavový proxy server má možnosť prejsť do bezstavového režimu kedykoľvek v priebehu spracovávania žiadosti v prípade, že medzitým nevykonal 11

12 nič, čo by tomuto prechodu bránilo (napr. rozvetvenie alebo odoslanie dočasnej, tj. 1xx odpovede). Pri tomto prechode sa proxy server jednoducho zbaví celého doterajšieho stavu. Väčšina SIP proxy serverov v dnešnej dobe pracuje so zachovaním stavu, pretože ponúkajú komplexné služby ako napr. vetvenie správ alebo podporu prechádzania NAT-om, čo nie je možné bez zachovania stavu Redirect servery V niektorých systémových prostrediach môže byť žiadúce znížiť pracovné zaťaženie proxy serverov, ktoré sú zodpovedné za smerovanie žiadostí. Ako vhodné riešenie sa ponúka práve presmerovanie (angl. redirection). Presmerovanie umožňuje serverom vložiť informácie o smerovaní do odpovede klientovi. Týmto spôsobom sa vyhnú ďalšej komunikácii týkajúcej sa predmetnej žiadosti a zároveň pomáhajú klientom pri smerovaní dotazu. Keď žiadateľ obdrží správu o presmerovaní, vyšle novú žiadosť (príp. žiadosti) na adresy, ktoré obdržal. Presunutie znalosti adries z centrálneho servera ku koncovým uzlom výrazne napomáha škálovateľnosti siete. 2.3 Správy SIP-u Komunikácia sprostredkovávaná SIP-om pozostáva z výmeny správ. Správy sú nejakým spôsobom prenášané po sieti. V praxi sa používa rodina protokolov TCP/IP. SIP podporuje prenos správ pomocou protokolov UDP, TCP a TLS nad TCP. V tejto práci sa budeme venovať iba prenosu správ pomocou protokolu UDP. Každá správa pozostáva z troch častí: prvý riadok správy hlavička správy telo správy Prvý riadok správy určuje jej typ. V SIP-e sú dva typy správ: žiadosti a odpovede. Žiadosti požadujú od príjemcu správy nejakú funkčnosť alebo ho o niečom informujú. Odpovede potvrdzujú, že žiadosť dorazila k príjemcovi a bola spracovaná (resp. pracuje sa na nej) a obsahujú kód a text popisujúci stav spracovania žiadosti. V hlavičke správy môžu byť dôležité údaje o smerovaní správy a jej ušlej ceste, o odosielateľovi a príjemcovi správy, identifikačné údaje o správe a mnohé ďalšie. 12

13 Telo správy je od hlavičky správy oddelené prázdnym riadkom a často býva prázdne. Pri vytváraní spojenia obsahuje telo správy popis tohto spojenia zakódovaný pomocou protokolu SDP [12]. Takto vyzerá žiadosť INVITE s telom SDP: INVITE sip:user2@example.com SIP/2.0 Via: SIP/2.0/UDP :5060 ;branch=z9hg4bkpj4ccde1c8-f b-95c2-ecf021a578f2 Max-Forwards: 70 From: sip:user1@example.com;tag= f-9f49-4c89 To: sip:user2@example.com Contact: <sip:user1@ :5060> Call-ID: 6842fbea-925b-401f-bc0b-473b9f4022e6 CSeq: INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, norefersub User-Agent: STA PJSUA v0.9.0-trunk/i686-pc-linux-gnu Content-Type: application/sdp Content-Length: 456 v=0 o= IN IP s=pjmedia c=in IP t=0 0 a=x-nat:0 m=audio 4000 RTP/AVP a=rtcp:4001 IN IP a=rtpmap:103 speex/16000 a=rtpmap:102 speex/8000 a=rtpmap:104 speex/32000 a=rtpmap:117 ilbc/8000 a=fmtp:117 mode=30 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=sendrecv a=rtpmap:101 telephone-event/8000 a=fmtp: A toto je odpoveď 180 Zvoním na túto žiadosť: SIP/ Ringing 13

14 Via: SIP/2.0/UDP :5060 ;branch=z9hg4bkpj4ccde1c8-f b-95c2-ecf021a578f2 From: To: Contact: Call-ID: 6842fbea-925b-401f-bc0b-473b9f4022e6 CSeq: INVITE Content-Length: SIP žiadosti Základné metódy SIP-u sú: ACK potvrdzuje prijatie finálnej odpovede BYE ruší spojenie CANCEL ruší pôvodnú žiadosť INVITE vytvára spojenie OPTIONS zisťuje schopnosti užívateľa REGISTER registruje klienta SIP odpovede Hlavné delenie odpovedí SIP-u: 1xx dočasné odpovede; oznamujú príjemcovi, že jeho žiadosť dorazila na miesto, ale výsledok spracovávania ešte nie je známy. Používajú sa hlavne na ukončenie znovu posielania žiadosti, ak jej spracovanie trvá dlhšiu dobu (ako napr. u INVITE) 2xx 6xx finálne odpovede; vyjadrujú konečný výsledok spracovávania žiadosti. Významy jednotlivých skupín: 2xx pozitívne odpovede; vyjadrujú úspešné spracovanie žiadosti 3xx odpovede, ktoré sa používajú na presmerovanie žiadosti 4xx negatívne odpovede; problém na strane klienta 5xx negatívne odpovede; problém na strane servera 14

15 6xx globálne negatívne odpovede; pôvodná žiadosť nemôže byť úspešne spracovaná na žiadnom serveri 2.4 Príklady z prevádzky SIP-u V tejto časti sú popísané príklady z bežnej prevádzky SIP-u, ktorým sa venuje aj analyzátor popisovaný v tejto práci Registrácia klienta Užívateľ sa zaregistruje u registrar servera tak, že mu pošle žiadosť REGIS- TER s údajmi o svojej aktuálnej polohe v hlavičkovom poli Contact a dobou trvania registrácie v hlavičkovom poli Expires. Registrar servery zvyčajne vyžadujú overenie užívateľovej totožnosti, preto mu pošlú odpoveď 407 Neautorizovaný užívateľ. Užívateľ teda znova pošle žiadosť REGISTER, tentoraz spolu s užívateľským menom a heslom. Na to mu server úspešne odpovie 200 OK. registrar.example.com Registrar UA Registrar REGISTER 407 Neautorizovaný REGISTER s údajmi UA OK Obrázok 2.1: Príklad registrácie klienta Na obrázku 2.1 je znázornená táto výmena správ. Dôležité časti správ REGISTER a 200 OK vyzerajú nasledovne: REGISTER sip:registrar.example.com SIP/2.0 From: <sip:user@example.com>;tag=874b7c To: <sip:user@example.com> Contact: <sip:user@ :5060> Expires:

16 SIP/ OK From: To: Contact: Vytvorenie a zrušenie spojenia UA1 Proxy UA2 INVITE 100 Snažím sa proxy.example.com Proxy INVITE 100 Snažím sa 180 Zvoním UA UA Zvoním 200 OK ACK média BYE 200 OK 200 OK Obrázok 2.2: Príklad vytvorenia spojenia Keď chce užívateľ UA1 zavolať užívateľovi UA2 (vytvoriť k nemu teda spojenie), pošle mu žiadosť INVITE. Keďže pravdepodobne nevie, kde sa UA2 práve nachádza, pošle správu proxy serveru. Ten mu hneď odpovie správou 100 Snažím sa, aby nedochádzalo k zbytočnému opätovnému posielaniu žiadosti INVITE. Potom vyhľadá UA2 v lokačnej databáze a pošle mu túto žiadosť INVITE. UA2 na ňu proxy serveru odpovie správou 100 Snažím sa z rovnakých dôvodov ako predtým server jemu. Potom začne volánemu užívateľovi zvoniť telefón a UA2 pošle serveru odpoveď 180 Zvoním. Server ju hneď pošle užívateľovi UA1. Podobne je to s odpoveďou 200 OK, ktorú 16

17 UA2 pošle, keď volaný užívateľ zdvihne slúchadlo. UA1 na to pošle správu ACK priamo užívateľovi UA2, keďže už vie jeho adresu. Touto správou potvrdí, že všetky parametre spojenia súhlasia a hovor je týmto spojený. Keď chce niektorý z užívateľov ukončiť hovor, zloží slúchadlo, čím pošle druhému užívateľovi žiadosť BYE a ten na ňu odpovie správou 200 OK. Celý priebeh tejto komunikácie je znázornený na obrázku 2.2 a správy INVITE a 180 Zvoním sú v zobrazené v časti Transakcie v SIP-e Aj keď sú SIP správy zasielané po sieti nezávisle na sebe, sú koncovými užívateľmi a proxy servermi so zachovaním stavu usporiadávané do transakcií. Preto sa SIP nazýva transakčným protokolom. Transakcia je postupnosť SIP správ, ktorú si vymieňajú SIP prvky medzi sebou. Transakcia sa skladá z jednej žiadosti a všetkých odpovedí na túto žiadosť. To teda zahŕňa nula alebo viac dočasných správ (zo skupiny 1xx) a jednu alebo viac finálnych odpovedí. Viac finálnych odpovedí môže prísť kvôli tomu, že na žiadosť INVITE môžu odpovedať viacerí koncoví užívatelia po rozvetvení tejto žiadosti proxy serverom so zachovaním stavu. 17

18 Kapitola 3 Problémy v komunikácii SIP-u a ich riešenia Od schválenia prvého štandardu SIP-u RFC2543 [2] už ubehlo skoro 10 rokov. Druhý a momentálne aktuálny štandard RFC3261 [4] je na svete už 7 rokov. Napriek tomu sa softvérové telefóny založené na protokole SIP doteraz výraznejšie nepresadili u bežných domácich užívateľov, tak ako sa to podarilo programom založeným na iných protokoloch ako napr. pred niekoľkými rokmi programu Skype alebo nedávno programu Google Talk. Táto kapitola sa zaoberá dôvodmi kvôli ktorým SIP stále dobre nefunguje a ukazuje možné riešenia, ktoré už aspoň teoreticky existujú, ale ešte sú slabo implementované v praxi. Väčšia časť kapitoly sa zaoberá problémami komunikácie SIP-u. Zbytok je venovaný niekoľkým problémom týkajúcich sa prevádzky médií. 3.1 Problémy s NAT-om a firewallmi Asi najväčšou prekážkou pri nadväzovaní spojenia je preklad adries spôsobený zariadeniami NAT (Network Address Translator; prekladač sieťových adries) niekde po ceste. Existujú mnohé implementácie zariadení NAT, ktoré sa ešte rôzne správajú podľa firewallov, s ktorými väčšinou bežia na tom istom zariadení. Pre túto prácu však nie sú podstatné všetky možné detaily, preto kvôli sprehľadneniu budú ďalej v texte firewally aj zariadenia NAT označované súhrnne pojmom NAT. Termínom klient bude označovaný počítač s privátnou IP adresou schovaný za NAT-om a termínom server ľubovoľný počítač s verejnou IP adresou, ku ktorému sa klient pripája. Privátne IP adresy sú popísané v dokumente Pridelenie adries pre privátne siete [1]. Na obrázku 3.1 je zobrazené bežné fungovanie NAT-u. Klient sa so svo- 18

19 Server Verejná IP adresa: :5060 Internet Lokálna sieť Verejná IP adresa: :41287 NAT Privátna IP adresa: :5060 Klient Obrázok 3.1: Fungovanie NAT-u jou privátnou IP adresou a portom :5060 pripája k serveru s verejnou IP adresou a portom :5060. Pri tom sa na NAT-e vytvorí priradenie adresy (angl. NAT binding), ktoré je v našom príklade : Špecifikácia STUN-u [8] rozdeľuje NAT-y podľa toho, ako sa správajú na štyri rôzne typy. Aj keď sa odvtedy zistilo [13], že v praxi dochádza k ďalším možným správaniam sa NAT-ov, tento popis je pre základnú predstavu a túto prácu dostačujúci. Na obrázku 3.2 je zobrazené pripojenie klienta k dvom rôznym serverom. Dvojica X : x symbolizuje IP adresu X a port x. Štyri typy NAT-ov teda sú: Full Cone NAT typu úplný lievik priraďuje klientovej privátnej IP adrese a portu X : x vždy tú istú verejnú IP adresu a port X 1 : x 1. Navyše ľubovoľný server môže poslať paket klientovi na X : x tým, že tento paket pošle na priradenú adresu X 1 : x 1. Restricted Cone NAT typu obmedzený lievik priraďuje klientovej privátnej IP adrese a portu X : x vždy tú istú verejnú IP adresu a port X 1 : x 1. Narozdiel od úplného lievika môže server s IP adresou Y 1 poslať paket klientovi cez priradenú adresu X 1 : x 1 len vtedy, ak klient predtým poslal paket na IP adresu Y 1. Port Restricted Cone NAT typu portovo obmedzený lievik funguje ako NAT typu obmedzený 19

20 Server 1 Server 2 Y 1 : y 3 Y 1 : y 1 Y 2 : y 2 Internet Lokálna sieť X 1 : x 1 NAT X 2 : x 2 X : x Klient Obrázok 3.2: Priradenie adresy NAT-om lievik, pričom obmedzenie sa týka okrem IP adresy aj portu. Server s IP adresou a portom Y 1 : y 1 môže poslať paket klientovi cez priradenú adresu X 1 : x 1 len vtedy, ak klient predtým poslal paket na IP adresu a port Y 1 : y 1. Symmetric Symetrický NAT priraďuje klientovej privátnej IP adrese a portu X : x verejnú IP adresu a port X 1 : x 1 pri zasielaní žiadosti serveru Y 1 : y 1 a verejnú IP adresu a port X 2 : x 2 pri zasielaní žiadosti serveru Y 2 : y 2. Paket klientovi X : x cez priradenie X 1 : x 1 môže následne poslať len server z IP adresy a portu Y 1 : y 1. Žiaden paket s inou zdrojovou adresou sa cez priradenú adresu X 1 : x 1 ku klientovi nedostane, čo je dobre vidieť na obrázku. Prvé tri typy majú v názve slovo lievik (angl. cone). Pre predstavu je to veľmi pekný príklad. Plný lievik totiž prijíma pakety prakticky od hocikoho a obmedzený lievik od tých serverov, ktoré predtým kontaktoval. Nás kvôli ICE-u najviac zaujíma prípad symetrického NAT-u, ktorý je popísaný v časti Bez nejakého riešenia snažiaceho sa o prechod NAT-om sú však problematické všetky z týchto prípadov. Boli vytvorené viaceré riešenia, ktoré mali umožniť funkčný prechod cez NAT. Sú to napr. Application Layer Gateways (ALG; Brány v aplikačnej 20

21 vrstve TCP/IP [14]), Middlebox Control Protocol [7] a pôvodný Simple Traversal of UDP Through NAT (STUN; Jednoduchý prechod UDP paketov NAT-om [8]) spolu s rozšírením popisu spojenia, aby fungovali, akým je napr. SDP attribute for the Real Time Control Protocol (RTCP) [10]. Avšak všetky tieto techniky majú svoje pre a proti, ktoré ich robia optimálnymi v niektorých sieťových topológiách, ale úplne nepoužiteľnými v iných. Výsledkom je, že správcovia sietí si musia dobre zvážiť a odhadnúť, v akých podmienkach bude ich riešenie používané, čo prináša do celej problematiky zbytočnú zložitosť a neprenositeľnosť riešenia do inej situácie. Čo je teda potreba, je jednotné riešenie, ktoré bude dostatočne prispôsobivé, aby fungovalo za akýchkoľvek okolností. Klienti totiž vytvárajú žiadosti SIP-u (napr. INVITE) alebo odpovede SIP-u (napr. 200 OK), ktoré obsahujú privátne (resp. globálne nesmerovateľné) IP adresy a porty vo Via hlavičkovom poli žiadosti ako cieľovú adresu odpovede, v Contact hlavičke metódy REGISTER ako cieľ pre prichádzajúcu žiadosť INVITE a v tele SIP-u v SDP správe ako cieľovú adresu pre prijímanie médií. To následne spôsobuje, že príjemca nie je schopný posielať pakety na tieto adresy, a preto odpovede SIP-u nie sú doručované, prichádzajúce hovory nie sú spojované a nedochádza k prenosu médií, tj. hovor je spojený, ale telefonujúci sa navzájom nepočujú. Tieto problémy teoreticky riešia buď už schválené štandardy (dokumenty RFC) alebo návrhy štandardov, ktorých schválenie sa očakáva v blízkej budúcnosti. Prakticky je zatiaľ implementácia hlavne návrhov štandardov veľmi malá. V nasledujúcich častiach sa na tieto problémy a ich možné riešenia pozrieme trošku bližšie Nemožnosť prijímania odpovedí Keď SIP používa UDP protokol, funguje podľa špecifikácie RFC3261[4] nasledovne. Odpovede sú posielané na zdrojovú adresu odkiaľ prišla žiadosť a na port, ktorý bol uvedený v prvom Via hlavičkovom poli žiadosti. Výsledkom je teda 21

22 celkom hybridné určenie cieľovej adresy odpovede. Polovica informácie IP adresa je získaná z hlavičiek IP paketov a druhá polovica port je získaná z hlavičiek SIP-u. SIP takto funguje preto, aby server mohol očakávať všetky správy, žiadosti aj odpovede, na jedinej IP adrese a porte, čo malo napomáhať jeho prípadnej rozšíriteľnosti. Táto funkčnosť však nie je vždy žiadúca, špeciálne keď je klient schovaný za NAT-om. V tom prípade totiž odpoveď nemôže prejsť cez NAT, pretože nebude súhlasiť s priradením adresy, ktoré bolo vytvorené pri prechádzaní žiadosti. V pôvodnej špecifikácii nebola možnosť ako by klient mohol z došlej správy zistiť zdrojový port, z ktorého došla žiadosť serveru. Klient mal možnosť zistiť zdrojovú adresu, z ktorej došla žiadosť serveru vďaka parametru received v prvom Via hlavičkovom poli odpovede. Táto vedomosť bola užitočná k základnému prechádzaniu NAT-om, ladiacim účelom a k fungovaniu na počítačoch s viacerými sieťovými rozhraniami (angl. multi-homed hosts). Bez znalosti čísla portu však nebola úplná a dostatočná k prechádzaniu zložitejších NAT-ov. Riešenie problému rport Ako reakcia na tento problém vznikla špecifikácia RFC3581 [9]. Tá definuje nový parameter hlavičkového poľa Via rport, ktorý umožňuje klientovi požadovať od servera, aby poslal odpoveď späť na tú istú IP adresu aj port, z ktorých k nemu prišla žiadosť. Parameter rport je teda analogický k parametru received, akurát rport obsahuje číslo portu a nie IP adresu Nemožnosť prijímania nových žiadostí Zavedenie parametru rport pomohlo klientom, ktorí sú za NAT-om vyriešiť prijímanie odpovedí na predtým nimi odoslané žiadosti. Nepomohlo to však vyriešiť prijímanie nových žiadostí. Keď je klient ukrytý za NAT-om, tak môže vytvárať nové spojenia k Registrar alebo Proxy serverom, ale spojenia opačným smerom ku klientovi väčšinou nie sú možné. Je to ešte zložitejší problém ako nemožnosť prijímania odpovedí, lebo v tomto prípade klient pred prijatím žiadosti narozdiel od prijímania odpovede nečaká, že nejaká žiadosť k nemu dôjde. Tento problém sa snaží vyriešiť novovznikajúca špecifikácia Managing Client Initiated Connections in the SIP (Využitie spojení vytvorených klientom v SIP-e [15]). Tá umožňuje klientovi ukrytému za NAT-om prijímať správy zvonku. Hlavná myšlienka spočíva v tom, že klient tým, že pošle REGISTER žiadosť alebo žiadosť vytvárajúcu dialóg, vytvorí sieťový tok (angl. flow), ktorý je buď obojsmerným prúdom UDP datagramov alebo TCP spojením 22

23 alebo niečím analogickým pri inom transportnom protokole. Proxy server môže neskôr využiť tento tok k tomu, aby klientovi preposlal prichádzajúce žiadosti. Aby mohol klient prijímať tieto žiadosti, musí sa pripojiť k serveru. Keďže sa server nemôže pripojiť ku klientovi, musí sa klient sám starať o to, aby bol tok stále aktívny. Preto musí byť schopný zistiť, či tento sieťový tok nebol prerušený. Keďže táto detekcia vyžaduje nejaký čas, počas ktorého by mohlo dôjsť k neprijímaniu prichádzajúcich žiadostí, môže sa klient zaregistrovať cez viaceré toky zároveň. Aby nedochádzalo k strate priradení adries pri prechode NAT-om, vysiela klient pravidelne keep-alive pakety, ktoré udržiavajú toto priradenie nažive. Tento mechanizmus takisto slúži k tomu, aby mohol klient zistiť, či sieťový tok nezlyhal. Ako sa píše vyššie, táto špecifikácia je zatiaľ v štádiu návrhu a nie je ešte implementovaná v praxi. Ak sa však dotiahne do konca a následne rozšíri mala by spolu s predošlými špecifikáciami vyriešiť skoro všetky problémy s prechodom SIP-u cez NAT Nepriechodnosť médií Avšak to, že bude zaistený prechod SIP-u cez NAT ešte nevyrieši všetky problémy. V rámci vytvárania multimediálnych spojení dochádza k dvojfázovej výmene správ Session Description Protokolu (SDP; Protokol popisujúci spojenie [12]). Táto výmena nazývaná ako model ponuka/odpoveď (angl. offer/answer model) je bližšie popísaná v RFC 3264 [6]. Keďže je však cieľom tejto výmeny vytvoriť tok mediálnych paketov, obsahujú v tele svojich správ zdrojové a cieľové IP adresy a porty médií. Je známe, že toto vytvára problémy pri prechode NAT-om [3]. Takisto je tu často snaha vytvoriť medzi účastníkmi priamy tok médií, čo pomáha skráteniu dĺžky odozvy, zmenšeniu straty paketov a celkovému zníženiu nákladov na prevádzku aplikácie. Toto je však tiež zložité dosiahnuť pri existencii NAT-u medzi koncovými užívateľmi. Riešenie problému ICE Komplexným riešením problémov nepriechodnosti médií by mohla byť práve schvaľovaná špecifikácia Interactive Connectivity Establishment (ICE; Interaktívne vytvorenie spojenia [17]). Tá popisuje spôsob prechodu multimediálnych dát v UDP paketoch NAT-om (vyvíja sa aj verzia pre TCP pakety [18]). ICE je rozšírením k modelu ponuka/odpoveď a funguje tak, že do ponúk a odpovedí SDP zahŕňa viacero IP adries a portov, ktoré sa potom testujú na dostupnosť pomocou peer-to-peer skúšok spojení (peer-to-peer spojenie 23

24 je spojenie od uzla priamo k druhému uzlu). Tieto skúšky prebiehajú podľa prepracovanej špecifikácie STUN-u, ktorá má zároveň aj nové meno Session Traversal Utilities for NAT (Pomocné utility pre prechod spojení NAT-om [13]). Toto nové meno a nová špecifikácia poukazujú na novú funkciu STUNu ako nástroja, ktorý pomáha celkovým riešeniam na prechádzanie NAT-u, akým je napr. ICE. Nový STUN už teda nie je celkovým samostatným riešením prechádzaniu NAT-u, akým sa snažil byť pôvodný STUN (a nutno podotknúť, že nebol). Okrem STUN-u ešte ICE využíva rozšírenie STUN-u Traversal Using Relays around NAT (TURN; Prechod NAT-om pomocou prekladaných adries [16]). Keďže ICE pri výmene zahŕňa viacero IP adries a portov, rieši aj problém výberu IP adresy u počítačov, ktoré sú vo viacerých sieťach. Ako funguje ICE? V modeli ponuka/odpoveď sa nazývajú agentami strany snažiace dohodnúť sa na parametroch spojenia. Základná myšlienka ICE-u je takáto: Každý agent má viacero kandidátov transportných adries (transportná adresa je kombinácia IP adresy a portu), ktoré by mohol použiť ku komunikácii s druhým agentom. Zoznam týchto kandidátov získa hneď na začiatku tak, že kontaktuje STUN/TURN server a sú následovní (viď obrázok 3.3): transportná adresa sieťového rozhrania pripojeného priamo k sieti (nazývaná ako host adresa), preložená transportná adresa, ktorú je vidieť na verejnej strane NAT-u (server reflexive adresa) a transportná adresa, ktorú agent získa od TURN servera (relayed adresa). Pri vytváraní hovoru pomocou SIP-u si potom agenti vymenia zoznam svojich kandidátov v telách SDP správ. Následne začne každý agent testovať tieto transportné adresy na vzájomnú dostupnosť. Teoreticky ktorákoľvek transportná adresa jedného agenta môže komunikovať s ktoroukoľvek transportnou adresou druhého agenta. V praxi však mnohé kombinácie samozrejme nefungujú. Ak sú napr. obe strany za NAT-om v rôznych sieťach, tak ich host adresy nemôžu navzájom priamo komunikovať ako je vidieť na obrázku 3.4 (kvôli tomu vlastne ICE vznikol). Cieľom ICE je teda zistiť, ktoré dvojice adries sú schopné spolu komunikovať. ICE funguje tak, že systematicky skúša každú dvojicu, pokiaľ nenájde jednu alebo viacero, ktoré spolu fungujú. Z týchto dvojíc potom vyberie tú s najvyššou 24

25 STUN/TURN server Relayed Server reflexive NAT SIP Server SIP komunikácia v tele SDP s ICE STUN/TURN server Relayed Server reflexive NAT Host Host Agent 1 Agent 2 Obrázok 3.3: Kandidáti v ICE STUN/TURN server Relayed Server reflexive NAT SIP Server STUN/TURN server Relayed Server reflexive NAT Host Host Agent 1 Agent 2 Obrázok 3.4: Skúšky spojení v ICE prioritou, kde priorita postupne klesá od host adries k relayed adresám. Na obrázku 3.4 je ešte zobrazené skúšanie server reflexive adresy prvého agenta 25

26 zo všetkými ostatnými adresami druhého agenta Prítomnosť zle naimplementovaných SIP ALG SIP ALG (A SIP Application Level Gateway for Network Address Translation; SIP brána v aplikačnej vrstve TCP/IP pre NAT [14]) je rozšírenie NAT-u o možnosť prekladania adries aj v tele sieťových správ, tj. správ SIP-u a v nich správ SDP. Je to teda snaha ako vyriešiť problém prechádzania SIP-u a médií NAT-om tým, že sa na niektorých miestach zamenia privátne IP adresy a porty za NAT-om priradené adresy. Potom správa, ktorá prechádza NATom, vyzerá ako keby priamo z NAT-u vychádzala, tj. NAT vystupuje v roli SIP klienta. V prichádzajúcej odpovedi zasa zamení sebou priradené adresy za privátne IP adresy a porty klienta. Hlavný problém ALG je v ich neúplnej implementácii SIP protokolu a v tom, že sú vhodné len na volanie smerom vonku a neriešia problém dovolania sa klientovi schovanému za NAT-om. Tým sú ako riešenie na prechádzanie NAT-u viac škodlivé než nápomocné. Vyššie spomínané riešenia sú totiž univerzálne funkčné, avšak za podmienky, že im niekto po ceste nemení správy SIP-u a k tomu ešte tak nešikovne, ako to robí ALG. Pre úplnosť sa poriadne pozrime na problémy, ktoré ALG spôsobuje: Nemožnosť prijímania žiadostí Keďže klient schovaný za NAT-om sa registruje s privátnou IP adresou a portom, ALG ich v hlavičke správy zmení na NAT-om priradenú adresu, aby sa odpoveď a ďalšie žiadosti dostali ku klientovi (aj keď k tomu slúžia už vyššie spomínané riešenia). Bežné NAT-y však držia toto priradenie otvorené len pol minúty až minútu a po vypršaní tohto času sa zruší a nie je možné klienta zvonku kontaktovať. Preto je zo strany klienta nutné posielať v pravidelných intervaloch keep-alive pakety, aby udržiaval toto priradenie otvorené. Lenže klient nevie o tom, že niekde po ceste je prítomná ALG a ani nemá šancu sa o tom dozvedieť. Možným riešením by bolo posielať keep-alive pakety vždy. Pokazenie správ SIP-u Mnohé ALG brány prepisujú hlavičky a telá SIP správ nesprávne (ako je vidieť na obrázku 3.5, kde táto ALG napr. neprepisuje IP adresu a port v protokoloch RTP a RTCP). Tým vlastne úplne narušujú fungovanie tohto protokolu. Kazenie iných možných riešení Dnes už sú skoro hotové iné univerzálne riešenia, ktoré však rozširujú 26

27 INVITE SIP/2.0 Via: SIP/2.0/UDP : :5060 ;rport;branch=z9hg4bkpj4ccde1c8-f b-95c2-ecf021a578f2 Max-Forwards: 69 From: ;tag= f-9f49-4c89-8b4c e706a To: Contact: :5060 Call-ID: 6842fbea-925b-401f-bc0b-473b9f4022e6 CSeq: INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, norefersub User-Agent: STA PJSUA v0.9.0-trunk/i686-pc-linux-gnu Content-Type: application/sdp Content-Length: 462 v=0 o= IN IP s=pjmedia c=in IP t= m=audio 4000 RTP/AVP a=rtcp:4001 IN IP a=rtpmap:103 speex/16000 a=rtpmap:102 speex/8000 a=rtpmap:104 speex/32000 a=rtpmap:117 ilbc/8000 a=fmtp:117 mode=30 a=rtpmap:3 G Obrázok 3.5: Prepísanie adries v správe SIP-u ALG bránou pôvodné špecifikácie SIP-u a SDP. ALG je však starým a neúplným riešením, ktoré o týchto nových rozšíreniach nevie, len ich v dnešnej dobe kazí. Možné riešenia problémov spôsobených ALG bránami Najlepším riešením problémov spôsobených ALG bránou je úplne ju vypnúť, ak je to možné. Ak však zariadenie, na ktorom ALG beží, nie je možné kontrolovať, tak je veľmi pravdepodobné, že komunikácia SIP-u prechádzajúca týmto zariadením bude ALG bránou menená. Jediným v praxi funkčným 27

28 riešením je, že keď klient posiela správy na iný ako štandardný port SIP-u 5060, tak tieto správy ALG ignoruje. To však zasa vyžaduje mať možnosť meniť port, na ktorom počúva server. To u SIP Registrar servera asi nebude možné. Túto funkciu by však mohli zastúpiť SIP proxy servery určené presne k tomuto účelu, než sa počet ALG brán zníži až úplne vymizne. Osobne som zatiaľ nenašiel iné riešenie, ako zastaviť prepisovanie správ SIP-u ALG bránou. 3.2 Zvládanie záťaže Problémom výkonu SIP serverov (tj. proxy, redirect alebo registrar serverov) sa zaoberajú viaceré práce. Za zmienku stojí SIPstone [19], ktorý sa zaoberá výkonnostnou analýzou SIP serverov, a diplomová práca SIP Proxy Server Effectiveness (Efektivita SIP proxy servera [20]) Jana Janáka z ČVUT, ktorá popisuje vývoj rychlého SIP proxy, redirect a registrar servera SER 1, z ktorého časom vznikol ďalší kvalitný projekt OpenSER 2. Hlavným parametrom merania výkonu SIP servera je počet žiadostí, ktoré je systém schopný úspešne spracovať za nejaký čas, pričom dĺžka spracovania samotnej správy nie je až tak podstatná, ak nie je neúmerne dlhá. Napr. pre informatívne odpovede (zo skupiny 1xx) by mala byť dĺžka spracovania dostatočne krátka na to, aby nedochádzalo k zbytočným opakovaným posielaniam žiadostí, teda zhruba 500 ms mínus latencia siete. Výkon SIP servera nezáleží len na implementácii, ale hlavne na veľkosti užívateľskej populácie, ktorú server obsluhuje, a ďalej na počte potrebných DNS vyhľadávaní, použitom transportnom protokole (UDP, TCP alebo TLS nad TCP) a na type prichádzajúcich žiadostí a ich štatistickom rozložení v čase. V tejto časti sa ešte trošku bližšie pozrieme na veľkosť užívateľskej populácie, pretože veľká populácia v praxi najviac zaťažuje server Veľkosť užívateľskej populácie Výkon SIP servera, ktorý si udržiava informácie o užívateľoch, často závisí na veľkosti užívateľskej populácie, pretože typická transakcia SIP-u zahŕňa vyhľadanie kontaktných adries užívateľa v nejakej databáze. Sú minimálne tri rôzne spôsoby, ako je možné navrhnúť a implementovať takúto databázu: len tabuľkou v pamäti bez žiadnej formy ukladania dát na trvalom médiu

29 tabuľkou v pamäti s pravidelným ukladaním na disk databázou umiestnenou na sieťovom serveri Implementácia len tabuľkou v pamäti je najjednoduchšia a najrýchlejšia. Nevyžaduje žiadnu databázu, avšak zaznamenané údaje neprežijú reštart servera. Databáza umiestnená na serveri je najpomalším riešením. Všetky zmeny vo vyrovnávacej pamäti sa totiž hneď zapisujú do databázy. Ziskom v tomto prípade je však to, že zmeny prežijú prípadný reštart servera. Použitie tejto techniky je žiadúce aj v prípade, že chceme spravovať užívateľské účty pomocou webovej aplikácie. Tabuľka v pamäti s pravidelným ukladaním na disk je akýmsi kompromisom medzi týmito dvoma riešeniami. Všetky zmeny sa uskutočňujú vo vyrovnávacej pamäti a update databázy sa robí len v pravidelných časových intervaloch. Takže rýchlosť aj spoľahlivosť tejto implementácie je niekde v strede medzi dvoma vyššie zmienenými riešeniami. Veľkou výhodou oproti priamemu zápisu do databázy je, že dobre absorbuje vysoký počet v krátkom čase prichádzajúcich registrácií. Vzhľadom k tomu, že registrácie klientov prichádzajú periodicky, je celkom možné, že sa tieto lavíny prichádzajúcich žiadostí budú pravidelne opakovať. Nevýhodou je, že pri páde servera sú záznamy, ktoré boli uložené len v pamäti, stratené Relay u Media proxy a TURN serverov Jedným z riešení prechodu médií cez NAT je server s verejnou IP adresou, ktorý slúži ako prostredník medzi dvoma klientami. Všetka mediálna komunikácia teda prechádza cez tento server. Je zrejmé, že pri veľkom počte aktívnych hovorov bude tento server veľmi vyťažený, pretože mediálna komunikácia je omnoho objemnejšia než komunikácia SIP-u. 3.3 Kvalita hovoru Klasické telefonovanie cez PSTN siete (Public Switched Telephone Networks) funguje na princípe garantovania kvality služby (angl. Quality of Service), čo znamená, že telefónny hovor by mal byť stále možný a neprerušovaný. Telefonovanie po Internete (Voice over IP), ktorého jedným riešením je aj SIP, však funguje na princípe čo najlepšej snahy doručenia paketu (angl. Best Effort) tak, ako všetky ostatné služby na Internete. Pri bežnej práci so sieťou ako prezeranie webových stránok alebo čítanie a posielanie pošty to človeku vôbec nevadí. Keď však ide o multimediálny prenos v reálnom čase, 29

30 tak si ľudia hneď všimnú, že sa hovor o sekundu opozdieva alebo že je niekedy chvíľku ticho. Pri praktickom testovaní SIP-u bola kvalita hovorov dobrá. Z toho je vidieť, že pri dostatočnom navýšení kapacity liniek je aj technika Best Effort dostačujúca na prenosy multimediálnych dát. 30

31 Kapitola 4 Existujúce analyzátory SIP-u Medzi existujúcimi analyzátormi SIP-u môžeme nájsť dva hlavné prístupy. Jeden sa zameriava na testovanie existujúcich implementácií a druhý na analýzu prevádzky. 4.1 Testovanie existujúcich implementácií K testovaniu implementácií SIP-u boli uplatňované rôzne prístupy. Hrubo by sa dali rozdeliť do nasledujúcich kategórií: 1. testovanie funkčnosti a spĺňania špecifikácií: systematické skúšanie, či SIP prvky spĺňajú špecifikáciu. Ide o obrovské sady testov, ktoré bod po bode oskúšajú každú správu, jej každé hlavičkové pole a hlásia čo len najmenšie nesplnenie špecifikácie; 2. záťažové testovanie (angl. torture testing): skúšanie SIP prvkov na rôzne nezvyčajné správne aj nesprávne správy; 3. testovanie výkonu: slúžia k meraniu výkonu SIP serverov, hlavne registrar a proxy serverov; 4. testovanie bezpečnosti implementácie: Bezpečnosť informácií je neustále ohrozovaná chybami v súčasných implementáciách SIP-u. Nástroje na testovanie bezpečnosti sa snažia odhaliť aspoň jednoduché chyby zistené z praxe, aby zvýšili základnú laťku kvality testovaného softvéru. 31

32 4.1.1 Analyzátory testujúce funkčnosť Kontrola spĺňania špecifikácie Špecifikácia SIP-u je najdlhším RFC dokumentom v histórii, celkovo má 269 strán. Ak k tomu pripočítame špecifikáciu SDP a rôzne doplňujúce a informatívne RFC dokumenty ako k SIP-u, tak k SDP, dostávame sa na mnohé stovky strán. Preto nie je veľmi prekvapivé, že pri implementácii rôznych SIP aplikácií dochádza k porušovaniu špecifikácie a k následnej vzájomnej nekompatibilite. Z druhého uhlu pohľadu zasa neprekvapí, že niektoré časti špecifikácie buď obsahujú chyby alebo nie sú vhodne navrhnuté vzhľadom k potrebnému výkonu v praxi napr. u proxy alebo registrar serverov [20]. Do tejto oblasti bolo investovaného mnoho času, výsledkom čoho sú aj dve rozsiahle sady testov, ktoré overujú, či SIP prvky spĺňajú špecifikáciu SIP-u. Jedna sada je od NIST [24] (National Institute for Standards and Technology; Národný inštitút pre štandardy a technológie v Spojených Štátoch), druhá od ETSI [25] (European Telecommunications Standards Institute; Európsky inštitút pre telekomunikačné štandardy). SIPit SIPit 1, alebo Session Initiation Protocol interoperability test, je stretnutie tvorcov SIP produktov, kde testujú vzájomnú funkčnosť týchto svojich produktov. Každé SIPit stretnutie je otvorené hocikomu, kto má aspoň základne funkčnú implementáciu nejakého SIP produktu. Cieľom týchto stretnutí je nájsť a vyladiť chyby protokolu ako aj chyby samotných implementácií. SIPit je teda hybnou silou, ktorá pomáha SIP-u, aby sa stal hlavným protokolom pre komunikačné služby na Internete v reálnom čase. Prvé stretnutie SIPit sa uskutočnilo v apríli roku 1999, trvalo dva dni a zúčastnilo sa ho 14 firiem. Potom sa konal zhruba každé štyri mesiace a časom dvakrát ročne, čo trvá až dodnes, pričom dĺžka stretnutia narástla na celý týždeň. Zatiaľ posledné stretnutie SIPit 23 sa konalo deväť rokov neskôr v októbri roku 2008 a zúčastnilo sa ho 97 účastníkov z 37 firiem. Torture testing Jedným z výsledkov SIPit stretnutí je aj informatívny RFC dokument s názvom SIP Torture Test Messages ( Mučiteľské testovacie SIP správy [11])

33 Tento dokument popisuje niekoľko skupín testovacích SIP správ. Niektoré zaťažujú len syntaktický analyzátor aplikácie, niektoré celú aplikáciu. V prvej polovici sú správy, ktoré spĺňajú SIP špecifikáciu, v druhej polovici správy, ktoré ju nespĺňajú aj s presne uvedeným dôvodom, prečo je tomu tak. Tento dokument sa nesnaží popísať všetky možné nesprávne správy, ani nemá za cieľ, aby popísal všetky správne, ale nezvyčajné správy. Je to však výsledok z praktických testov, ktoré spôsobovali problémy v rámci SIPit stretnutí a preto je predpokladateľné, že môžu byť veľmi nápomocné pri vývoji budúcich SIP aplikácií. Tento dokument takisto nie je samostatným testovacím plánom, ale môže byť použitý ako pomôcka pri tvorbe takéhoto plánu. Tak sa aj stalo pri tvorbe testovacieho súboru PROTOS Test-suite: c07-sip, ktorého bližší popis je nižšie v sekcii Analyzátory testujúce výkon Internetové telefónne systémy založené na SIP-e musia byť dostatočne dimenzované, pretože množstvo hovorov a registrácií môže dosahovať tisícky žiadostí za sekundu. Preto bolo potrebné vyvinúť základný balík jednoduchých testovacích metód pre SIP proxy, redirect a registrar servery. SIPstone SIPstone [19] je porovnávací test pre SIP proxy a redirect servery. Tento test meria kapacitu spracovaných žiadostí u týchto serverov. SIPstone je navrhnutý ako porovnávací test s jednou štandardizovanou implementáciou a prácou, ktorú bude vykonávať. Táto práca spočíva v sérii testov, ktoré vytvárajú dopredu nastavenú záťaž. Všetky testy prebiehajú v uzavretom testovacom prostredí vhodnom pre IP telefóniu, ktoré simuluje aktivity mnohých užívateľov vytvárajúcich SIP hovory. Záťažové testy sú vymyslené tak, aby boli jednoduché a opakovateľné a snažia sa pokryť rôznorodosť reálneho prostredia, akou je napr. súbežné vytváranie hovorov viacerými užívateľmi, náhodný príchod týchto hovorov a presmerovávanie žiadostí. Prakticky implementovali SIPstone dve známe riešenia a to SIPp 2 a sipsak 3 SIP swiss army knife Analyzátory testujúce bezpečnosť Bezpečnosť informácií je neustále ohrozovaná chybami v súčasných implementáciách protokolov. Toto nebezpečenstvo si uvedomil aj výskumný tím

34 z univerzity v Oulu vo Fínsku, ktorý vytvoril projekt PROTOS - Security testing of Protocol Implementations 4 (Testovanie implementácií protokolov z pohľadu bezpečnosti). Projekt PROTOS sa zaoberá testovaním implementácií protokolov a používa k tomu testovacie metódy založené na princípe testovania pomocou čiernej skrinky (taktiež nazývané ako funkčné testovanie; ide o testovanie, ktoré sa nezaujíma alebo ani nevie o tom, ako sú aplikácie naprogramované, ale sústredí sa len na výstupy vytvorené ako odpoveď na ním zaslané vstupy). Cieľom PROTOSu je podporovať proaktívne odstraňovanie chýb pri vývoji softvéru s pozitívnym dopadom na informačnú bezpečnosť. Takisto podporuje tlak na kvalitu zo strany zákazníkov, ktorí si takto môžu aspoň trochu otestovať softvér na prípadné chyby. Celkovo teda PROTOS pomáha zvyšovať základnú laťku kvality softvéru implementujúceho ním testované protokoly. PROTOS Test-Suite: c07-sip Autori projektu PROTOS sa rozhodli spomedzi protokolov, ktorým sa venujú, otestovať aj protokol SIP, čoho výsledkom je PROTOS Test-Suite: c07- sip 5. Ako dôvody, ktoré ich k tomu viedli, úvadzajú: SIP dospel od záujmu na akademickej pôde k záujmu komerčných subjektov s výhľadom na jeho široké využitie v budúcnosti. Avšak používanie tohto protokolu v praxi bolo len v počiatkoch. Toto štádium života protokolu je z pohľadu bezpečnosti príležitosťou aj výzvou zároveň. Okrem toho chce SIP používať projekt 3GPP (Third Generation Partnership Project) ako súčasť mobilných sietí tretej generácie. Rodina špecifikácií sa naďalej rozrastá a niektoré časti sú stále vo vývoji. To favorizuje SIP ako prirodzeného kandidáta na experimentáciu s očakávaným postupným vylepšovaním súboru testov. ASCII formát SIP správ podobný správam HTTP môže pritiahnuť viac útokov zo strany začínajúcich hackerov (script-kiddies) ako u konkurenčných protokolov akým je napr. H.323, ktorý používa binárne kódovanie. Stredom záujmu pri testovaní bola INVITE metóda, pretože SIP User Agenti aj SIP proxy servery musia túto metódu podporovať a prijímajú ju bez predošlého vytvárania spojenia. To z tejto metódy vytvára prirodzený smer,

35 odkiaľ by prichádzali možné útoky. Zároveň žiadosť nesúca INVITE metódu obsahuje široký záber hlavičkových polí a môže taktiež obsahovať SDP dáta v tele správy. Súbor testov PROTOS c07-sip obsahuje 4527 testovacích prípadov simulujúcich nepriateľský vstup pre testované implementácie. Prakticky implementuje tento súbor testov program SipBomber Analýza SIP prevádzky Analýza prevádzky SIP-u sa zaoberá samotným fungovaním komunikácie prvkov SIP-u medzi sebou navzájom. Špecializovaný analyzátor k tomuto účelu neexistuje. Ručne sa tieto testy prevádzajú v rámci vyššie spomínaných SIPit stretnutí. Výborným analyzátorom nielen SIP prevádzky, ale celej sieťovej komunikácie je Wireshark. Preto umožňuje nielen odchytávanie správ SIP-u, ale aj správ STUN-u a keep-alive paketov. Wireshark podporuje ako výpis paketov v reálnom čase, tak ich ukladanie do súboru a obe tieto možnosti ako v grafickom, tak aj v textovom režime. Takisto obsahuje základné štatistiky o komunikácii SIP-u, ako je počet SIP metód, SIP stavových kódov a znovuposlaných správ v komunikácii

36 Kapitola 5 Návrh analyzátora Moja práca na analyzátore prebiehala v dvoch fázach: v prvej fáze som vytváral nástroj pre prehľadný záznam komunikácie SIP-u, aby bolo čo analyzovať. Aj keď tento nástroj bol v neskoršom štádiu nahradený už spomenutým Wiresharkom, vývoj mi umožnil podrobne sa zoznámiť s viacerými dostupnými open source nástrojmi s podporou SIP-u. Postup vytvárania tohto nástroja a jeho výstupy dokumentuje časť 5.1. V druhej fázi som vytvoril nástroj pre analýzu zaznamenanej komunikácie SIP-u. Jeho návrh je popísaný v časti 5.2 a zoznam jeho schopností obsahuje časť 5.3. Dokumentáciu vnútorností programu rozoberá ďalšia kapitola. 5.1 História vývoja Kvalitný záznam komunikácie pomocou správ SIP-u je esenciálny pre objavenie prípadných problémov a ich následnú analýzu. Preto som začal s tvorbou logovacieho nástroja. K tomu bolo potrebné nájsť vhodné vývojové prostredie a definovať, aké požiadavky majú kvalitné logy spĺňať Voľba PJSIP stacku SIP stack je softvérová knižnica implementujúca špecifikáciu SIP-u. V súčasnosti je vo vývoji viacero SIP stackov, ako napr. GNU osip stack, PJSIP stack alebo resiprocate. Vzhľadom k aktívnemu vývoju a podpore novovznikajúcich špecifikácií (ako ICE, STUN, TURN a pod.) sa zdali vhodné PJSIP a resiprocate. Dôvody pre zvolenie PJSIP stacku sú následovné: Dobré logovanie s širokými možnosťami nastavenia, ktoré som ešte rozšíril 1 :

37 pridal som podporu farebných logov do linuxu možnosť voľby farieb počas behu programu označenie úrovne logovania slovne (napr. ERROR alebo INFO) farby v logovacích súboroch vo Vime (syntax highlighting plugin) Kvalitný klient pjsua Je naprogramovaný v jazyku C, s ktorým mám praktické skúsenosti Ponúka široké spektrum funkcií od úplne základných nízkoúrovňových až po komplexné Má experimentálnu podporu ICE, nového STUN-u a TURN-u (Podporu ICE som pomáhal testovať 1 ) Dobrá a bohatá dokumentácia Veľká prenositeľnosť Linux, Mac OS X, Windows a ďalšie, aj mobilné, platformy Je stále veľmi aktívne vyvíjaný Upstream je komunikatívny a spolupracuje Okrem toho má PJSIP ďalšie výhody, ktoré však neboli pri rozhodovaní z pohľadu programovania analyzátoru dôležité: Nízke nároky na pamäť Vysoký výkon Vývoj Tento projekt obsahuje niekoľko vzorových programov, ktoré som začal skúmať s úmyslom hlbšieho zoznámenia sa ako s PJSIP stackom a jeho logovacími schopnosťami, tak aj so samotným fungovaním SIP-u. Ako východiskový bod mi slúžili vzorové aplikácie pjsua a stateful_proxy. Aplikácia pjsua je plnohodnotný SIP softvérový telefón pre príkazový riadok s bohatými funkciami 2, ktorý vlastne implementuje väčšinu funkcií, ktoré PJSIP stack podporuje. Pjsua som najskôr začal poznávať z pohľadu uživateľa. Z programátorského hľadiska som sa pustil do stateful_proxy, čo je jednoduchý SIP stateful proxy server. Do tohto programu som neskôr doprogramoval základné funkcie SIP registrara, výsledkom čoho je sta_proxy. Z tohto programovania sa vykryštalizovali moje požiadavky na logy:

38 výpis odchádzajúcich a prichádzajúcich SIP správ výpis rôznych iných dôležitých správ o fungovaní SIP klienta a SIP proxy servera (ako napr. informácia o zmene priradenej IP adresy na NAT-e a následnej preregistrácii SIP klienta) rôzne úrovne logovania podľa dôležitosti informácie správy dobré odlíšenie týchto úrovní ako počas behu programu, tak aj v logovacom súbore PJSIP stack väčšinu z týchto požiadaviek podporoval. Chýbala podpora farieb a označenie úrovne logovania, ktoré som doprogramoval a sú prijaté do tejto knižnice vo vývojovej vetve nasledujúcej po verzii Po zoznámení sa s PJSIP stackom a zároveň hlbším pochopením fungovania SIP-u sa mi začalo dariť uskutočnovať funkčné hovory pomocou SIP-u. Pri podrobnejšom skúmaní a plánovaní sa však ukázalo, že ďalší vývoj týmto smerom nemá zmysel Dôvody pre ukončenie vývoja v PJSIP stacku Tento prístup totiž viedol k manuálnej analýze a môj vývoj mal tejto len pomôcť. Výsledkom programovania v PJSIP stacku bol dobrý prehľad o SIP komunikácii a následné lepšie zoznámenie sa so SIP klientom pjsua, SIP serverom SER a následne OpenSER. Pri ručnej analýze prevádzky sa vyskytol ešte jeden zvláštny problém. Z logov na strane SIP klienta vyplývalo, že posiela žiadosť REGISTER s privátnou IP adresou v hlavičkovom poli Contact a z logov na strane SIP Registrar servera bolo vidieť, že túto správu obdrží s verejnou IP adresou NAT-u medzi ním a SIP klientom. Logicky mohla táto zmena nastať len na jednom z troch miest: pri SIP klientovi, pri SIP serveri alebo niekde po ceste. Nemala by však nastávať nikde; klient ani server o nej v logoch neinformovali a po ceste nebol žiadny SIP prvok, ktorý by mal zasahovať do komunikácie. Domnieval som sa, že SIP klient alebo SIP server nezobrazujú v logoch skutočné správy, ktoré k nim prídu, ale až nimi zmenené správy, čo som chápal ako snahu o prekonávanie NAT-u. Po komunikácii s vývojármi PJSIP stacku som sa dozvedel, že pjsua ani OpenSER tieto problémy v ich prostredí nevytvára a doporučili mi skontrolovať, či nemám v NAT-e ALG (viac informácií o ALG viď 3.1.4). Učinil som tak v následnom kroku. Vedel som, že sledovaním všeobecnej sieťovej komunikácie sa preslávil program Ethereal, ktorý sa z obchodných dôvodov 3 premenoval na Wire

39 shark. Pomocou Wiresharku sa mi podarilo overiť, že problém skutočne nenastáva ani pri SIP klientovi, ani pri Serveri, ale po ceste pri prechode NAT-om. Pri tomto používaní Wiresharku som však zistil, že ponúka podobne kvalitné logy ako logovacie systémy pjsua a OpenSER (dokonca kvalitnejšie, pretože zahŕňa aj IP a UDP hlavičku správ). Okrem toho nie je Wireshark obmedzený použitím konkrétneho SIP klienta alebo SIP servera, ale dá sa použiť univerzálne. Ďalší vývoj bol teda inšpirovaný použitím Wiresharku a jeho schopností zberu sieťových dát. 5.2 Výsledný návrh Vlastný program sta.pl (SIP Traffic Analyzer) je naprogramovaný v jazyku Perl 4. SIP je totiž textový protokol, takže podstata jeho analýzy spočíva v spracovaní textu. Perl je programovací jazyk, ktorý sa veľmi hodí na spracovanie textu, okrem iného kvôli vynikajúcej podpore regulárnych výrazov Formát dát a ich zber Takisto ako Wireshark pracuje aj program sta.pl so súbormi vo formáte libpcap. Tento je základným formátom súborov na ukladanie zachytených sieťových dát a momentálne je de facto štandardom zachytávania sieťových dát vo svete open source. V oblasti closed source žiaden spoločný štandard neexistuje. Dôvody pre voľbu tohto formátu boli následovné: jeho jednoduchosť; fakt, že plne postačuje k potrebám analýzy; rozšírenosť a s tým spojené široké možnosti zberu dát v tomto formáte. Formát súboru libpcap Dnes používaná verzia 2.4 sa nezmenila za posledných desať rokov. Na obrázku 5.1 je znázornená následovná schéma súboru: na začiatku je hlavička súboru popisujúca základné informácie o súbore. Po nej následujú zachytené pakety v dvojiciach hlavička a dáta. Hlavička každého paketu obsahuje nasledujúce informácie:

40 Hlavička súboru Hlavička paketu 1 Dáta paketu 1 Hlavička paketu 2 Dáta paketu 2... Obrázok 5.1: Formát súboru libpcap ts_sec dátum a čas, keď bol paket zachytený; v sekundách od :00:00 ts_usec mikrosekundy k času ts_sec incl_len počet skutočne zachytených bytov paketu orig_len pôvodná dĺžka paketu, akú mal na sieti pri zachytávaní; orig_len je väčšia než incl_len len vtedy, keď bolo pri zbere dát nastavené obmedzenie veľkosti zbieraných paketov Dáta každého paketu obsahujú v tomto prípade po poradí Ethernetovú hlavičku, IP hlavičku, UDP hlavičku a SIP hlavičku s prípadným telom SIP-u. Eth IP UDP SIP Obrázok 5.2: Dáta paketu Ďalšie informácie o tomto formáte je možné nájsť na stránkach Zber dát Zber dát vo formáte libpcap je možný prostredníctvom mnohých aplikácií pod všetkými bežne dostupnými operačnými systémami v domácom prostredí, ako sú Windows, GNU/Linux a Mac OS X. Najjednoduchším spôsobom je použiť program Wireshark, ktorý má prehľadné grafické rozhranie. V programe stačí zvoliť menu Capture -> Start. Takto sa začnú zachytávať všetky pakety, ktoré prechádzajú cez primárnu sieťovú kartu. K tomu je nutné podotknúť, že je potrebné spustiť program Wireshark s dostatočnými právami na to, aby bol prístup k sieťovej karte povolený. V niektorých systémoch je potreba najvyšších, tj. administrátorských práv. Aby sa zbytočne nezachytávali všetky sieťové dáta, je možné toto obmedziť pomocou zachytávacieho filtra. Ak napr. SIP server počúva na UDP 40

41 transporte a porte 5060, nastavíme filter ako udp port Tento filter sa nastaví pomocou menu Capture -> Options. Ukončenie zachytávania sa uskutoční cez menu Capture -> Stop. Následne je potrebné zachytené dáta uložiť cez voľbu menu File -> Save. Rovnaký výsledok je možné dosiahnuť z príkazového riadka pomocou verzie Wiresharku určenej pre textový režim tshark. Všetky vyššie uvedené postupy sa dosiahnu príkazom tshark -f udp port w subor.pcap Vlastný zber dát Keďže nie je možné spustiť Wireshark na jednoduchých hardvérových SIP telefónoch, pokúsil som sa o vlastný zber dát vo forme transparentného proxy servera. Ten by sa SIP klientovi zadal ako outbound proxy server, čím by sa zaistilo, že by všetka SIP komunikácia iniciovaná klientom išla cez tento proxy server. Transparentný v názve naznačuje, že by v libpcap súbore nebolo vidieť, že sú pakety zberané na tomto proxy serveri, a nie priamo pri SIP klientovi. Tento prístup však nebol úspešný z následujúcich dôvodov: Pri SIP metóde INVITE s Record-route hlavičkovým poľom sa vytvorí smerovacia množina, podľa ktorej sa smerujú nasledujúce správy v dialógu vytvorenom touto metódou INVITE. Takto sa transparentný proxy server dostane mimo cestu, po ktorej tečú dáta, čo mu neumožňuje zachytiť všetky správy. Riešením by bolo, keby sám pridal Record-route hlavičkové pole, ale tým by už stratil charakter transparentnosti. Pred zachytením správy je táto pozmenená, čím sa môžu prirobiť umelé problémy, ktoré by v pôvodnej SIP komunikácii inak neboli. V odpovediach sa vo Via hlavičkovom poli vypĺňa received parameter s IP adresou transparentného proxy servera, čo tiež ruší transparentnosť Analýza Analýza je vykonávaná off-line, teda po priebehu samotnej komunikácie SIPu a pracuje s dátami nazbieranými z troch miest: pri SIP klientovi UA1, pri SIP klientovi UA2 a pri SIP serveri. Nevýhodami oproti on-line analýze je, že nie je vidieť, čo sa deje hneď počas komunikácie a nie je možné do nej priamo zasiahnuť. Tieto zásahy by však mohli vyrobiť nové problémy, ktoré v pôvodnej komunikácii neboli a analyzátor by takto fungoval podobne ako ALG. Off-line analýza je naproti 41

42 tomu čisto transparentným riešením, pretože zber sieťových dát je pre aplikácie SIP-u neviditeľný. Okrem toho je jednoduchšia na implementáciu a v prípade potreby by bolo možné ju previesť do on-line stavu (pri viacbodovom zbere dát by sa však vyššie spomenuté výhody on-line analýzy takto stratili). Zber dát na viacerých miestach je samozrejme náročnejší než len na jednom mieste. Výhodami je však úplný prehľad o komunikácii a lepšia identifikácia problémov (napr. detekcia chýbajúcich správ alebo detekcia ALG) Testovacie prostredie Na obrázku 5.3 je znázornené prostredie, v ktorom boli prevádzané testy. Obaja klienti sú schovaní za NAT-om, čo je dnes najbežnejšie usporiadanie v domácom prostredí. Toto usporiadanie prináša teoreticky aj prakticky najviac problémov, preto sa práca zaoberá výhradne ním. Podrobnejší popis týchto problémov a ich možných riešení je v kapitole 3. server.pcap Server NAT1 NAT2 ua1.pcap ua2.pcap UA1 UA2 Obrázok 5.3: Testovacie prostredie Na obrázku sú taktiež bodkovanou čiarou zobrazené miesta, kde sa prevádzajú zbery sieťových dát pre analýzu, ktoré program očakáva na vstupe. 5.3 Vlastnosti a schopnosti programu Výsledný program je určený pre administrátora siete alebo pokročilého užívateľa v domácom prostredí, ktorý sa pokúša nadviazať spojenie prostredníc- 42

43 tvom protokolu SIP a naráža na problémy. Predpokladá sa, že tento užívateľ dokáže pripraviť súbory ua1.pcap, ua2.pcap a server.pcap podľa vyššie uvedeného postupu a odovzdá ich na vstup analyzátoru sta.pl. Ten mu pomôže zorientovať sa v neprehľadných súpisoch správ a farebným zvýraznením napovie, kde by mohli byť problémové miesta v komunikácii. Komunikačným jazykom programu je angličtina z dôvodu jej väčšej rozšírenosti. Program sa spúšťa príkazom./sta.pl ua1.pcap ua2.pcap server.pcap Po spustení sa vypíšu prípadné nájdené chyby a zobrazí sa topológia siete s vyplnenými IP adresami a portami u všetkých sieťových uzlov. Potom program čaká na príkazy z príkazového riadka označeného textom Command:. príkaz popis flow vypíše tok správ topology nakreslí sieťovú topológiu m# alebo # vypíše detaily správy (# je číslo správy z výpisu toku správ) diff # # porovná dve správy a vypíše rozdiely medzi nimi (# sú čísla správ z výpisu toku správ) problems vypíše nájdené chyby a varovania help vypíše túto stručnú nápovedu quit ukončí program Tabuľka 5.1: Popis príkazov programu sta.pl Tabuľka 5.1 obsahuje príkazy, ktorými sa program ovláda a stručne popisuje ich funkcie. Príkazy je možné ľubovoľne skrátiť až na jedno písmenko. Napr. príkaz topology sa dá skrátiť na t. Nasledujúci odsek tieto funkcie vysvetľuje trochu podrobnejšie: výpis topológie siete vyplnenie IP adries a portov pre UA1, UA2, NAT1, NAT2 a Server; farebné zvýraznenie problematického NAT-u výpis toku správ správy sú vypísané prehľadne ako dvojice (typ správy, poradové číslo) spolu so šípkou naznačujúcou, medzi ktorými sieťovými prvkami prebehla. Sieťové prvky sú zakreslené ako zvislé čiary a správy sú znázornené zmienenými vodorovnými šípkami a zoradené odhora nadol tak, ako za sebou chronologicky nasledovali. Toto kostrbaté vysvetlenie najlepšie osvetlí obrázok

44 zobrazovanie jednotlivých správ každú správu je možné celú vypísať po zadaní jej poradového čísla označenie znovu poslaných správ správy, ktoré boli poslané znova, pretože na ne nebola obdržaná odpoveď dostatočne skoro, sú označené menej výraznou farbou farebné označenie problémových správ kvôli lepšiemu prehľadu sú chybné správy vo výpise toku správ označené červene a správy, ktoré by mohli spôsobovať problémy žlte hlásenie chýbajúcich správ v niektorom z *.pcap súborov v prípade, že počty SIP správ v jednotlivých súboroch nesedia, program o tom podá hlásenie zistenie možnej ALG po ceste program vypíše zmenené páry správ a umožní tieto správy porovnať a vypísať rozdiely medzi nimi samostatná analýza správ program zahlási chybu, ak sa server snaží poslať správu na privátnu IP adresu alebo varovanie, ak sa SIP klient registruje s privátnou IP adresou Príklady použitia, ktoré tieto funkcie ilustrujú, popisuje kapitola 7. 44

45 Kapitola 6 Programátorská dokumentácia Táto kapitola popisuje program sta.pl z programátorského hľadiska. Prvá časť stručne popisuje použité moduly Perlu a druhá približuje fungovanie programu. 6.1 Použité moduly Program používa nasledujúce moduly Perlu na tieto účely: Net::Pcap na načítanie a spracovanie vstupných súborov; NetPacket::(Ethernet IP UDP) na rozdelenie Ethernetového rámca na IP a UDP hlavičky a telo, ktorým je samotná SIP správa; Net::SIP na spracovávanie SIP správ; Data::Validate::IP na overovanie privátnych adries; String::Diff na porovnanie a zvýraznenie rozdielov medzi dvoma správami; Time::Format na formátovanie času; Term::ANSIColor na farebné výpisy; Switch na pridanie štandardných switch a case primitív; Data::Dumper na ladiace účely. Všetky tieto moduly sú dostupné na CPAN-e 1 (Comprehensive Perl Archive Network). CPAN je veľkou zbierkou softvéru a dokumentácie Perlu

46 6.2 Popis fungovania programu Funkcie programu môžeme rozdeliť do následujúcich logických blokov: 1. Načítanie a spracovanie vstupných súborov do Pri každej správe si program udržiava informácie o tom, z ktorej časti komunikácie správa je (ua1 nat1, nat1 server, server nat2, nat2 ua2); libpcap hlavičku obsahujúcu čas zachytenia paketu a jeho veľkosť; celý paket aj s UDP, IP a Ethernet hlavičkami a pomocné premenné, akými sú napr. farba správy pri výpise; informácia, či je správa znovu poslaním nejakej predošlej správy alebo prípadné problémy spojené s touto správou. Funkcie process_packet_ua a process_packet_server. 2. Doplnenie IP adries užívateľských agentov, NAT-ov a Servera do topológie siete. Tieto IP adresy sa získajú z adries prítomných v SIP REGISTER žiadostiach, ich IP a UDP hlavičkách a odpovediach na ne. K týmto doplneniam dochádza počas spracovávania súborov ua1.pcap a ua2.pcap. 3. Určenie smeru každej správy pre potreby vykresľovania toku správ. Pre každú správu sa určí pomocou adries z topológie siete a z IP a UDP hlavičiek správ. Funkcia correct_directions. 4. Zoradenie správ v podľa toho, ako postupne prichádzali na server. Keďže na serveri sú správy časovo v správnom poradí, berú sa zo súboru server.pcap. Ku každej správe sa priradí jej pár zo súboru ua1.pcap alebo ua2.pcap. K vyhľadaniu páru pomáha identifikátor transakcie tid. Pre viac informácii o transakciách v SIP-e viď časť 2.5. Tieto dve správy, ktoré tvoria pár sa zoradia v jedinom možnom poradí, v akom mohli po sebe nasledovať. Výsledné zoradené správy sú uložené v Funkcia find_pairs_and_sort_messages_by_server. 5. Detekcia problémov: Chýbajúce správy sa zistia porovnaním počtu SIP správ v príslušných častiach komunikácie. Funkcia check_pcap_sizes. 46

47 Označenie znovu poslaných správ menej výraznou farbou. Pre ich vyhľadanie sa používa podobne ako u hľadania párov identifikátor transakcií tid. Funkcia find_resent_messages. Detekcia ALG skontrolujú sa páry SIP správ, tj. správy pred prejdením NAT-om a po ňom. Tieto správy by mali byť totožné. Ak nie sú, označí sa správa po prejdení NAT-u ako problémová (červene). Funkcia detect_alg. Kontrola jednotlivých správ. Ako vzorový príklad sú uvedené dve kontroly upozorňujúce na pravdepodobnú neprítomnosť riešenia na prechádzanie NAT-om. Funkcia detect_server_to_priv_ip označí správu za chybnú (červene), ak sa server snaží poslať túto správu na privátnu IP adresu. Funkcia detect_register_with_priv_ip označí registračnú správu za potenciálne chybnú (žlte), ak sa snaží zaregistrovať kontakt s privátnou IP adresou. Je možné doprogramovať ľubovoľné množstvo ďalších testov. Vhodnou inšpiráciou môže byť zdrojový kód vyššie uvedených funkcií. 47

48 Kapitola 7 Dosiahnuté výsledky S prácou sú dodané 3 vzorové komunikácie. Jedna plne funkčná, druhá s viacmenej funkčnou komunikáciou SIP-u ale problémami pri hovore a tretia plne nefunkčná. V tejto kapitole je bližší popis týchto komunikácií aj s ukážkami výstupov programu sta.pl. 7.1 Plne funkčná komunikácia Prvá komunikácia je ukážkou toho, keď všetko funguje tak ako má. Analýza sa zjednodušene spúšťa pomocou shell skriptu./funkcna.sh. Prechod NAT-mi je zaistený ako na strane užívateľských agentov, tak aj na Serveri: UA IP adresa a port je verejná, zistená pomocou STUN-u; prechod médií pomocou ICE; Server počúva na porte 50605, aby sa znefunkčnila ALG v NAT-e 1 (viď ďalšia komunikácia); do novovznikajúcich dialógov pridané hlavičkové pole Record-Route, čím sa zaistí priechodnosť všetkej ďalšej SIP komunikácie Výsledkom priebehu komunikácie sú úspešné REGISTER, INVITE a BYE transakcie a funkčný hovor. Program sta.pl nehlási žiadne kritické problémy (viď obrázok 7.1). 48

49 Obrázok 7.1: Funkčná komunikácia bez kritických problémov 7.2 Čiastočne funkčná komunikácia Druhá komunikácia je veľmi podobná tej prvej s tým rozdielom, že server počúva na porte 5060 a ALG v NAT-e 1 je tak aktívna. Prepisuje teda IP adresy a porty ako v SIP hlavičke, tak aj v tele SDP správ, čím prirába problémy a znefunkčňuje hovor. Analýza komunikácie sa spúšťa pomocou shell skriptu./ciastocna.sh. Výsledkom priebehu komunikácie sú stále úspešné (hoci upravované) RE- GISTER, INVITE a BYE transakcie. Hovor je kvôli zlému prepisovaniu IP adries a portov v tele SDP nefunkčný. Prínosom sta.pl je objavenie ALG, ako ukazujú obrázky 7.2 a

50 Obrázok 7.2: Topológia siete s objavenou ALG bránou Obrázok 7.3: Správy prepísané touto bránou 50

51 7.3 Nefunkčná komunikácia Tretia komunikácia je v domácom prostredí za NAT-mi prakticky nefunkčná. Podobne ako u predošlých dvoch sa aj analýza tejto komunikácie spúšťa pomocou shell skriptu./nefunkcna.sh. Minimálny prechod NAT-mi je zaistený vďaka podpore rport parametra hlavičkového poľa Via (viď časť 3.1.1) a pridávaním hlavičkového poľa Record-route do novovznikajúcich dialógov na strane servera. Mimo to sa ani užívateľskí agenti ani server o prekonávanie NAT-u nijako nesnažia. Výsledkom priebehu komunikácie je úspešná žiadosť REGISTER vďaka podpore rport, avšak už transakcia INVITE je neúspešná proxy server sa totiž snaží smerovať žiadosť na privátnu IP adresu. Na obrázkoch 7.4 a 7.5 je vidieť varovanie o klientovej registrácii pomocou privátnej IP adresy a chybu servera, ktorý sa cez verejnú sieť snaží poslať správu na privátnu IP adresu. Obrázok 7.4: Zoznam problémov 51