Tot ce ați vrut să știți despre protocolul SIP
Partea 3
Problema traversal NAT
Totuși, problema ocolirii NAT de către un terapeut media este doar o parte a monedei. În primul rând, vom examina obstacolele pe care NAT creează pentru semnalizarea mesajelor și ce extensii SIP au fost proiectate pentru a le depăși.
Bypass NAT cu semnalizare SIP
A doua problemă este necesitatea de a direcționa corect solicitările SIP primite. SIP nu oferă un mecanism care să permită trimiterea de noi solicitări prin acea conexiune la nivel de transport care a fost creată atunci când utilizatorul a fost conectat. Intrările în tabela de traducere NAT au o durată de viață limitată (astfel încât tabela nu se deplasează) și că cererile de intrare SIP pot ajunge la UA din spatele NAT, intrările din tabelul de traducere NAT ar trebui actualizate periodic. Acest lucru se aplică atât la protocoalele fără conexiune, cât și la protocoalele bazate pe conexiuni.
Figura 1. Rutarea inbound
Dar intrarea în tabela de traducere NAT este șters după o anumită perioadă de timp (de cele mai multe ori câteva minute). Problema este relevantă nu numai în perioada după înregistrarea utilizatorului: în timpul dialogurilor SIP, este posibil ca mesajele noi să nu ajungă pentru o perioadă lungă de timp, ceea ce este suficient pentru a vă asigura că înregistrarea din tabelul de traducere a fost ștearsă. Stivele disponibile SIP rezolvă această problemă prin trimiterea periodică a cererilor SIP de re-INVITE, OPȚIUNI, INFO, NOTIFY sau (dacă se utilizează UDP) datagrame care nu conțin încărcături utile.
O tehnică mai completă și mai avansată este descrisă în SIP a Grupului de lucru pentru Internet Engineering Task (IETF) [2]. Să ne ocupăm mai mult de ea.
La înregistrarea utilizatorului, registratorul stochează datele de pe conexiunea de transport prin care a fost primită cererea. Cei doi parametri specifici instanță-id și reg-id al antetului de contact vă permit să găsiți datele de conectare în baza de date a serverului de înregistrare și să transmiteți cererea de intrare către UA prin conectarea nivelului de transport prin care a fost primit solicitarea de înregistrare. De asemenea, proiectul descrie mecanismele pentru actualizarea constantă a intrărilor în tabela de traducere NAT.
Pentru a rezuma, un mic exemplu de înregistrare a utilizatorilor în spatele NAT și folosind UDP (a se vedea Figura 2).
Figura 2. Bypassing NAT cu semnalizare SIP
Cererea REGISTER conține parametrul antet Viaport care informează UAS despre suportul RFC 3581, precum și parametrii reg-id și + sip.instance din antetul Contact:
ÎNREGISTRARE sip: proxy.example.com SIP / 2.0
WWW-Authenticate: [nu este afișat]
NAT ocolind
Figura 3. Închideți NAT de către suportul media
Traversarea simplă a UDP prin NAT (STUN)
În sfârșit, am ajuns la principalul lucru. STUN nu rezolvă problema transversală NAT în SIP în cazul general. Da, funcționează în scenariile NAT cu constrângere limitată la port și uneori în NAT cu restricție, dar cel mai frecvent tip de NAT a fost și este simetric, iar aici STUN este inutil. În plus, nu toate UA-urile, chiar și în cazul tipurilor NAT mai prietenoase, sunt "prieteni" cu STUN, iar în dispozitive mai vechi, suportul STUN nu a fost utilizat pe scară largă.
O altă "zbor în zbor" - în implementările existente, STUN nu funcționează cu SIP peste TCP, deoarece nu monitorizează corespunzător starea sesiunilor TCP deschise.
Traversal Utilizarea releului NAT (TURN)
Figura 5. Bypass NAT cu semnalizare SIP
Neajunsul acestei metode este evident: datorită proxy-ului întregului trafic, întârzierea într-un singur sens crește, iar probabilitatea pierderii pachetelor crește. Din acest motiv, se recomandă utilizarea TURN numai atunci când metodele de traversare NAT mai puțin "scumpe" sunt neputincioase. Rețineți că, de curând, TURN nu mai este considerat un protocol independent: acum este descris ca o extensie la STUN în [5].
Soluție de conectare interactivă (ICE)
Serverul TURN va proxy tot traficul RTP, chiar dacă un STUN simplu ar fi suficient pentru a ocoli NAT. Pentru a selecta metoda cea mai puțin costisitoare de a traversa NAT prin negocierea opțiunilor posibile între obiectivele finale, asociația IETF a propus o infrastructură ICE (Interactive Connectivity Establishment). Acesta nu este un protocol în sensul obișnuit al cuvântului; ICE este numită o infrastructură și se bazează pe protocoalele STUN și TURN existente și pe extensiile SIP.
În lista rutelor candidate, rutele fără STUN sunt cea mai mare prioritate, rutele cu STUN sunt cea mai mică prioritate, iar rutele cu trafic media proxy prin serverul TURN sunt cele mai scăzute. Prezentarea aici este complicată în mod intenționat: de fapt, un sistem prioritar flexibil vă permite să luați în considerare topologia rețelei, întârzierile de date și variațiile de întârziere, cerințele de securitate etc. Ca rezultat, fiecare rută primește o valoare prioritară unică. Apoi performanța lor este verificată (accesibilitatea părții opuse). Din rutele care au fost testate, unul este selectat cu cea mai mare prioritate.
Pe scurt, specificația ICE arată foarte promițătoare, iar această soluție găsește suport pentru industria VoIP. Descrierea ICE este dată în [6].
Pentru funcționarea acestui mecanism, proprietatea simetriei agentului utilizator este fundamental importantă: utilizarea pentru transmiterea și recepția aceluiași port (UA trebuie să trimită fluxul media din portul pe care la anunțat SDP). Dar această abordare este ideală în sensul acurateței datelor: nimic nu este necesar, cu excepția pachetului propriu-zis, și din moment ce pachetul ajunge la portul de unde va fi trimis fluxul counter, se rezolvă probleme cu toate tipurile de NAT. Într-un astfel de server proxy, puteți implementa orice funcționalitate suplimentară asociată cu modificarea componentei SDP. În același timp, aceasta introduce o întârziere suplimentară în sesiune, crește încărcarea pe serverul proxy și costurile furnizorului de servicii.
Extensiile Cisco COMEDIA
o = client 28908445312 28908445312 IN IP4 10.1.2.23
a = direcția: pasivă IN IP4
La implementarea COMEDIA Cisco puternic ghidate de depășite astăzi proiectul de IETF [8] a patra versiune.
Adesea, ca soluție, se propune utilizarea Gateway Layer Gateway (ALG), care procesează atât anteturile pachetului IP cât și conținutul acestuia. Funcțiile ALG pot fi executate de controlorii de frontieră pentru sesiuni (SBC) sau de routerele care transmit mesaje de control SIP. Din păcate, procesarea fiecărui pachet necesită performanțe ridicate și crește costul soluției. În plus, noile modificări ale protocolului necesită actualizarea constantă a software-ului SIP ALG, iar producătorul său monitorizează toate modificările implementate de furnizorii de dispozitive SIP. Soluția "necinstit" SIP ALG poate afecta funcționarea normală a dispozitivelor din spatele acesteia. Tehnologia UPnP (Universal Plug and Play) este adesea utilizată în segmentul SOHO și în instalațiile mici. Cu toate acestea, nu este specifică pentru VoIP, și pe lângă aceasta este atât de bine luminată pe Web. În cele din urmă, un document sumar valoros cu privire la soluțiile problemei NAT descrise aici este [9].
Membrii Grupului de lucru IETF SIP au elaborat un set exhaustiv de elemente de securitate de bază pentru a preveni audiția, interceptarea sesiunilor și atacurile active ale sistemelor SIP, precum și verificarea autenticității interlocutorului. Restul articolului este dedicat luării în considerare a acestor elemente.
SIP oferă două scheme de autentificare: autentificare digest în stil HTTP (RFC 2617 [10]) și autentificare certificat (pentru SIP peste TLS).
Dacă se utilizează autentificarea prin digitizare HTTP în stil HTTP, serverul proxy răspunde la INVITE cu un răspuns 407 solicitat de autorizare proxy, în care este prezent câmpul de antet al proxy-autentificării, cu date pentru calculul răspunsului la autentificare. După trimiterea mesajului ACK la 407 Proxy Authorization Required, agentul utilizator poate transmite INVITE, dar de data aceasta cu antetul de autorizare proxy care conține identitatea utilizatorului (a se vedea Figura 6).
Figura 6. Autentificarea digestului
Un mesaj digest este un șir de caractere unic de o dimensiune fixă, este rezultatul prelucrării datelor (un nume de utilizator și o parolă criptată), utilizând o funcție hash cu un singur sens MD5. Serverul SIP compară datele antetului de autorizare cu rezultatul aplicării aceleiași funcții hash la datele stocate în baza de date.
Securitatea stratului de transport (TLS)
Pe calea de la agentul utilizator la serverul proxy, se utilizează TLS, iar semnalizarea între servere poate fi protejată cu TLS sau IPSec (care este considerat opțional, dar mai stabil). După autentificarea cu succes, serverele proxy SIP decriptează fiecare mesaj (pe fiecare parte a căii se utilizează o cheie separată), ceea ce le permite să "vadă" toate anteturile și să redirecteze corect mesajele. Cu toate acestea, utilizatorii finali ar trebui să "încredințeze" necondiționat serverele proxy.
Printre punctele slabe ale protocolului TLS, în mod tradițional se menționează susceptibilitatea la atacurile "om-în-mijloc". Există, de asemenea, probleme specifice pentru SIP: deși conexiunea TLS servește ca dovadă a autenticității ambelor părți, acest lucru nu este suficient pentru a fi sigur de autenticitatea (sau de a asigura imposibilitatea abdicării) unui mesaj SIP arbitrar transmis prin acest canal.
TLS este în măsură să furnizeze aceste obiective în cadrul protocolului HTTPS, unde apariția în mod automat a pictogramei de blocare în browser înseamnă că există un canal securizat între browser și serverul web. SIP este mult mai complicat. Imaginați-vă, de exemplu, o conexiune TLS între două servere proxy: traficul poate trece prin acesta, aparținând diferitelor tranzacții sau dialoguri. Prin urmare, un atacator dintr-un domeniu poate efectua un atac prin injectarea traficului către alt domeniu, iar acest lucru nu va fi detectat sau împiedicat de o conexiune TLS. Rădăcina problemei constă în faptul că obiectivele TLS nu sunt "familiare" cu structura mesajelor SIP transmise prin ele, astfel încât să aplice o politică de securitate suficient de stringentă.
În cele din urmă, formarea de relații de încredere în cadrul TLS și chiar instalarea conexiunilor TCP poate deveni o problemă reală pentru un furnizor de servicii care servește deja câteva sute de mii de dispozitive de abonat. Nu este nevoie să aveți o imaginație bogată pentru a vă imagina cum va arăta fluxul de pachete SYN în timpul formării conexiunilor TLS.
Cei interesați de evoluții promițătoare se pot referi la RFC 4347 [12], care descrie protocolul DTLS care funcționează pe lângă UDP. Și versiunea curentă a protocolului TLS este descrisă în RFC 4346 [13].
Secure MIME (S / MIME)
Să vedem ce ar putea deveni cunoscut unui atacator care a interceptat mesajele SIP legate de faza de configurare a sesiunii:
Front (spre deosebire de protocolul TLS, curentul de la un nod la altul), pentru a asigura integritatea, confidențialitatea și autentificare SIP-Mesaje posibile folosind S / MIME tehnologie (RFC 3851 [14]). Rețineți că, în versiunile anterioare ale SIP RFC ca un instrument de autentificare și a vieții private oferite de PGP, dar acum utilizarea sa este învechită. Capitolul 23 al RFC 3261 descrie aplicarea schemei S / MIME. Luați în considerare modul în care se integrează în modelul de utilizare SIP.
Luați în considerare un exemplu de mesaj cu un corp S / MIME (a se vedea Figura 8).
Figura 8. S / MIME
În Fig. 8 arată modul de protejare a corpului unui mesaj SIP utilizând S / MIME. Pentru a proteja-mesaj SIP anteturi pot fi plasate în corpul de tip MIME, cu un «mesaj / SIP», și încapsulate într-un nou SIP-mesaj cu un duplicat al anteturile mesajelor originale cu rutare de informații. La rândul său, semnătura S / MIME poate fi aplicată mesajului containerului. În cele din urmă, aceasta poate fi realizată, și criptare SIP-header: în acest caz, mesajul este încapsulată S / MIME obiect container criptat. Astfel de mesaje nu sunt percepute ca un nou dialog sau tranzacție, ci profită din plin de criptarea și autentificarea de la capăt la celălalt. Antetele-URI, Via, Înregistrați-Route, Route, Max-Atacanți, și Proxy-autorizare nu se iau în considerare la calcularea sumelor de control, deoarece acestea pot (sau ar trebui) să fie modificate prin care trece prin serverele proxy intermediare.
Extensii SIP pentru a asigura confidențialitatea numelui și a numărului abonatului
Un set de extensii RFC 3323 [15] și RFC 3325 [16] oferă intimitate funcții de sprijin abonat: ascunderea și rețea de verificare numele de afișare și numerele implicate în dialogul abonat (identitatea de rețea a apelantului, dacă el este cel pentru care el pretinde a fi).
Sprijinul pentru confidențialitatea în rețeaua SIP este o provocare, deoarece protocolul este bazat pe text, iar participanții la dialog pot schimba mesaje fără implicarea vreunui furnizor de servicii. În același timp, SIP UA necesită cel puțin funcțiile de ascundere a numelui afișat și a numărului de abonat familiarizat în PSTN.
Abordarea cea mai directă - furnizarea de informații limitate în antetul "De la" - poate provoca probleme la terminarea unui apel către rețeaua unui alt operator sau către un serviciu PSTN sau la imposibilitatea furnizării unui număr de servicii. RFC 3325 descrie funcțiile de asigurare a confidențialității datelor personale ale abonatului, păstrând în același timp posibilitatea identificării acestuia.
Un astfel de mecanism de autentificare funcționează în același domeniu. Pentru implementarea sa au fost introduse noi anteturi P-preferate-identitate și P-Asserted-Identity. Antetul P-preferință-identitate este utilizat de UA în tranzacțiile cu un server proxy de încredere. Clientul construiește o cerere INVITE, nu conține date cu privire la identitatea abonatului în From, dar cu SIP URI reale și (opțional), numele afișat în-P Preferred-identitate. Se adaugă, de asemenea, un antet de confidențialitate care ia una dintre următoarele valori:
- "Niciuna" - nu este necesară confidențialitatea; serverul proxy nu trebuie să șterge antetul P-Asserted-Identity;
- "Utilizator" - este necesară confidențialitatea; serverul proxy trebuie să elimine antetul P-Asserted-Identity;
- "Id" - confidențialitatea este necesară numai în acest domeniu.
Un server proxy este necesar pentru a efectua autentificarea digest pentru un nod cu care relațiile de încredere nu sunt stabilite. După aceasta, serverul proxy trebuie să adauge un antet P-Asserted-Identity cu identitatea abonatului care a fost autentificată. Dacă serverul proxy primește o cerere din nodul cu care relația de încredere este deja stabilită, antetul P-Asserted-Identity este deja utilizat.
Procedura de trimitere a mesajului este după cum urmează. Dacă abonatul apelat este localizat în domeniul de încredere (vezi Figura 9), serverul proxy transmite cererea către abonat fără a șterge antetul P-Asserted-Identity.
Figura 9. Mecanismul de asigurare a confidențialității în același domeniu
În cazul în care abonatul se află în afara domeniului de încredere (vezi. Fig. 10), atunci când lăsa mesaje pentru domeniul proxy limitelor de încredere este ștergerea sau modificarea tuturor titlurilor cu informații despre identitatea expeditorului (la, Contact, răspuns, Call-ID, Info-Call, Via, User-Agent, Organizație, Server, Subiect, In-Răspunde la, Route Record și Avertisment. Identitatea P-Aserted este procesată în funcție de valoarea antetului de confidențialitate, iar antetul de confidențialitate trebuie șters.
Figura 10. Mecanismul de asigurare a confidențialității în afara domeniului de încredere
Desigur, imaginea de protecție va fi incompletă fără a asigura integritatea și confidențialitatea datelor din același domeniu de încredere la nivelul rețelei. Nodurile de domeniu trebuie să fie autentificate reciproc, iar tranzacțiile dintre noduri (și între nodurile UA și domeniile) trebuie să fie protejate utilizând TLS sau IPSec.
Există metode alternative de a dovedi identitatea apelantului sau apelatul Astfel, RFC 4474 [17] prevede utilizarea de identitate antete personalizate și identitate-Info pentru identitate al solicitantului de autentificare de trecere, și RFC 4916 [18] - autentificarea beneficiarului dialogoobrazuyuschego cerere cu o cantitate suplimentară interogați UPDATE în direcția inversă.
Luând în considerare toate varietățile de protocoale, având grijă de securitatea secretului, utilizatorii ar trebui să acorde o atenție specială alegerii software-ului sau dispozitivelor client.
Rezumatul principalelor RFC-uri SIP
Numărul și numele specificației
Ce definește?
Articole similare
Trimiteți-le prietenilor: