Securitatea Retelelor de Acces Fara Fir
TEZĂ DE DOCTORAT
Securitatea rețelelor de acces fără fir
– Aplicații pentru rețelele bazate pe tehnologia WiMAX –
-Sistemul de taxare. Protocolul CUANTAX-
CUPRINS
LISTĂ DE FIGURI
LISTĂ DE TABELE
LISTĂ DE ABREVIERI
INTRODUCERE
CAPITOLUL 1
ARHITECTURA REȚELELOR FĂRĂ FIR : STANDARDE, TEHNOLOGII, APLICAȚII
1.1 INTRODUCERE
1.2 STANDARDELE DIN FAMILIA IEEE 802
1.3 STANDARDUL IEEE 802.11
1.4 Standardul IEEE 802.20
1.5 REȚELE CELULARE
1.6 ALTE TIPURI DE TEHNOLOGII PENTRU REȚELELE FĂRĂ FIR
1.7 COMPETIȚIE SAU COMPLEMENTARITATE ?
1.7.1 vs IEEE 802.20
1.7.2 vs rețele celulare
1.7.3 vs IEEE 802.11
1.7.4 vs IEEE 802.15
1.8 CONCLUZII
CAPITOLUL 2
FAMILIA DE STANDARDE IEEE 802.16
2.1 INTRODUCERE
2.2 PRIVIRE GENERALĂ
2.3 NIVELUL FIZIC
2.3.1 Sistemul adaptiv de antene
2.3.2 Modulația adaptivă
2.4 NIVELUL MAC (MEDIUM ACCESS CONTROL)
2.4.1 Subnivelul părților comune
2.4.2 Subnivelul de securitate
2.4.3 Managementul puterii
2.5 ALTE CONSIDERENTE
CAPITOLUL 3
SISTEME WIMAX – ARHITECTURĂ, PROPAGARE, PERFORMANȚE
3.1 INTRODUCERE
3.2 ARHITECTURA SISTEMELOR WIMAX
3.2.1 PMP – Punct la Multipunct
3.2.2 Mesh – arhitectura tip năvod
3.3 PERFORMANȚele SISTEMELOR WiMAX
3.3.1 Servicii și parametrii
3.3.1.1 Modul de alocare a benzii pentru SM/SU
3.3.1.2 Interogarea și mecanismele de interogare
3.3.1.3 Rezolvarea coliziunilor
3.3.1.4 Stabilirea unei conexiuni și menținerea ei
3.3.2 Calitatea serviciului
3.3.3 Nivelul MAC și funcțiile lui
3.3.3.1 Caracteristicile nivelului MAC pentru rețele WiMAX tip „punct la multipunct”
3.3.3.2 Caracteristicile nivelului MAC pentru rețele WiMAX tip „năvod” (mesh)
3.3.3.3 Procesul de retransmisie pentru MAC-PDU
3.4 CONCLUZII
CAPITOLUL 4
SECURITATEA REȚELELOR FĂRĂ FIR (CADRU GENERAL)
4.1 INTRODUCERE
4.2 DEZVOLTAREA UNUI PLAN PENTRU SECURITATEA REȚELEI
4.2.1 Instrumente de detecție și verificare
4.2.2 Instrumente de urgență
4.3 STANDARDUL 802.16 – VULNERABILITĂȚI ȘI RISCURI – CONSIDERENTE GENERALE
4.3.1 Introducere
4.3.2 IEEE 802.16 – Stiva de protocoale
4.3.2.1 Nivelul fizic
4.3.2.2 IEEE 802.16 MAC (Medium Access Control)
4.3.2.3 Formatul mesajului MAC (MAC PDU)
4.3.2.4 Subnivelul de securitate
4.3.2.5 SA pentru DATE
4.3.2.6 SA pentru autentificare
4.3.2.7 Schimbul de date
4.3.3 Vulnerabilități și riscuri de securitate
4.3.3.1 Nivelul fizic și subnivelul de securitate
4.3.3.2 Autentificare mutuală
4.3.3.3 Autorizare neclară
4.3.3.4 Securitatea datelor
4.3.3.5 Alte vulnerabilități
4.4 CONCLUZII
CAPITOLUL 5
SECURITATE ȘI CONFIDENȚIALITATE ÎN REȚELELE BAZATE PE TEHNOLOGIA WIMAX
5.1 INTRODUCERE
5.2 MONOPOLUL BUCLEI LOCALE – PE CALE DE DISPARIȚIE
5.3 ASPECTE GENERALE ALE SECURITĂȚII
5.3.1 Structura cadrului MAC: MAC – PDU
5.4 PROCESUL DE AUTENTIFICARE DIN CADRUL REȚELELOR WiMAX
5.4.1 Introducere
5.4.2 HMAC – Hashed Message Authentication Code
5.4.3 Certificatul X509
5.4.4 EAP – Extensible Authentication Protocol
5.4.5 Descrierea procesului de autentificare
5.5 CONFIDENȚIALITATEA ÎN CADRUL REȚELELOR WIMAX
5.5.1 Definirea cheilor de securitate
5.5.2 Protocolul de management al cheilor – PKM
5.5.2.1 PKM versiunea 1
5.5.2.2 PKM versiunea 2
5.5.3 Criptarea datelor
5.6 PREZENTAREA MODELULUI DE REFERINȚĂ PENTRU ARHITECTURA REȚELELOR WiMAX
5.6.1 Access Service Network – ASN
5.6.2 Conectivity Service Network – CSN
5.6.3 Structura protocoalelor utilizate în modelul de referință
5.6.4 Securitatea în cadrul modelului de referință
5.6.4.1 Proceduri și protocoale de securitate pentru modelul de referință
5.6.5 Suportul pentru mobilitate
5.6.6 Alte considerente
5.7 CONCLUZII
CAPITOLUL 6
DEFINIREA UNUI NOU PLAN DE SECURITATE PENTRU REȚELELE FĂRĂ FIR BAZATE PE TEHNOLOGIA WIMAX
6.1 INTRODUCERE
6.2 CADRUl GENERAL
6.3 OPEN WiMAX – O NOUĂ TENDINȚĂ
6.4 INTERCONECTAREA REȚELELOR WIMAX
6.5 PRINCIPIILE CE INTERVIN ÎN DEFINIREA PLANULUI DE SECURITATE
6.5.1 Principiul modularității
6.5.2 Principiul flexibilității
6.5.3 Principiul varietății
6.5.4 Principiul standardizării
6.5.5 Principiul interoperabilității
6.6 DEFINIREA PLANULUI INTERDEPENDENT DE SECURITATE
6.6.1 Context
6.6.2 Mod de abordare
6.6.3 Construirea planului de securitate – etape exemplificate printr-un studiu de caz
6.6.3.1 Etapa 1 – Nivel utilizator – zona A
6.6.3.2 Etapa 2 – nivelul stațiilor radio (SM/SU) și nivelul stațiilor de bază – zona B
6.6.3.3 Etapa 3 – nivelul generic ASN – zona C
6.6.3.4 Etapa 4 – nivel generic CSN – zona D
6.6.3.5 Etapa finală – rețeaua nucleu – zona E
6.6.3.6 Exemplificarea procesului de autentificare pentru arhitectura propusă de planul de securitate
6.7 SISTEMUL DE TAXARE PENTRU O ARHITECTURA WIMAX OBȚINUTĂ ÎN URMA APLICĂRII PLANULUI DE SECURITATE
6.7.1 Introducere
6.7.2 Preliminarii
6.7.3 Controlul și taxarea utilizatorilor
6.7.4 Protocolul de taxare – CUANTAX
6.7.4.1 Elemente introductive
6.7.4.2 Descrieri procedurale – schimbul de mesaje pentru CUANTAX
6.7.5 Analiza de securitate pentru protocolul CUANTAX
6.7.6 Avantaje și dezavantaje pentru protocolul CUANTAX
6.7.7 Protocolul CUANTAX – limbajul comun pentru sisteme diferite
6.7.7.1 Detaliile și limitările situației curente
6.7.7.2 Soluționarea cerințelor prin folosirea CUANTAX
6.7.8 Analiză experimentală
6.7.8.1 Schimbul de mesaje
6.7.9 Concluzii și comentarii
CONCLUZII ȘI CONTRIBUȚII
PERSPECTIVE
BIBLIOGRAFIE
ANEXA A – ALGORITMUL DOT16KDF
ANEXA B – PSEUDOCODUL ALGORITMULUI RIJNDAEL
ANEXA C – CONFIGURAȚIA PARȚIALĂ PENTRU R1841 DIN EXPERIMENTUL DE LABORATOR (VEZI FIG. 6.16)
ANEXA D – FIȘIERUL DE CAPTURĂ DIN EXPERIMENTUL REALIZAT
LISTĂ DE FIGURI
Figura 1.1 Grupul de standarde IEEE 802 21
Figura 1.2 Arhitectura specifică IEEE 802 21
Figura 1.3 Arhitectura rețelei IEEE 802.11 22
Figura 1.4 Evoluția tehnologiei celulare 24
Figura 2.1 Nivelul MAC și nivelul fizic – împărțirea în subnivele 34
Figura 3.1 Arhitectura 802.16 tip PMP 42
Figura 3.2 Arhitectura 802.16 tip mesh 43
Figura 3.3 Operațiile specifice pentru un flux asociat serviciului de comunicație 49
Figura 3.4 Adăugarea unui flux asociat serviciului: a) dinspre SM/SU ; b) dinspre SB 49
Figura 3.5 Procesul de programare distribuită (coordonat central sau ad-hoc) 54
Figura 3.6 Stările unei conexiuni de date 55
Figura 3.7 Procesul de retransmisie pentru MAC-PDU 56
Figura 4.1 Stiva de nivele pentru IEEE 802.16 – 2004 63
Figura 4.2 Formatul MAC-PDU 65
Figura 4.3 IEEE 802.16 SA (Security Associations) 66
Figura 4.4 Procesul de autentificare IEEE 802.16 cu ajutorul SA 67
Figura 4.5 IEEE 802.16 – Schimbul de chei în cazul comunicației de date 69
Figura 5.1 Antetul generic al MPDU pentru pachetele diferite de cele de cerere de bandă 79
Figura 5.4 Antetul pentru mesajul de cerere de bandă 81
Figura 5.6 Procesul de creere al HMAC 83
Figura 5.8 Etapele procesului de autentificare 86
Figura 5.9 Procesul de criptare a TEK 89
Figura 5.10 Descrierea subnivelului de securitate 90
Figura 5.13 Procesul de derivare a cheilor 91
Figura 5.14 Schimbul de mesaje pentru transmiterea TEK între SM/SU și SB 91
Figura 5.15 Procesul de autentificare mutuală între SB și SM 93
Figura 5.16 Piramida obținerii cheilor in cazul PKMv2 94
Figura 5.17 Procedeul de obținere a cheii de autentificare AK prin metoda bazată pe EAP 95
Figura 5.18 Procesul de obținere a cheii de autentificare prin metoda bazată pe algoritmul de criptare RSA 96
Figura 5.20 Procesul de criptare al MPDU bazat pe DES-CBC 98
Figura 5.21 Cadrul de ocazie pentru AES-CCM 99
Figura 5.22 Blocul CBC 100
Figura 5.23 Bloc contor pentru modul CCM 100
Figura 5.24 Crearea mesajului criptat de autentificare în cadrul AES-CCM 101
Figura 5.25 Procesul de creare a unei MPDU cu informația utilă criptată prin metoda bazată pe AES-CCM 103
Figura 5.26 Modelul de referință pentru arhitectura rețelelor WiMAX propus de Forumul WiMAX 105
Figura 5.28 Ilustrarea operațiilor logice pentru fiecare modul al modelului de referință propus de Forumul WiMAX 112
Figura 5.30 Stiva de protocoale și de nivele (comunicație IP) pentru fiecare modul al modelului de referință propus de Forumul WiMAX 115
Figura 5.31 Stiva de protocoale și de nivele (comunicație Ethernet) pentru fiecare modul al modelului de referință propus de Forumul WiMAX 116
Figura 5.32 Etapele procesului de autentificare pentru modelul de referință (ținând cont de cadrul creat pentru procesul de AAA) 119
Figura 5.33 Stiva de protocoale utilizată în procesul de autentificare în cadrul modelului de referință propus de Forumul WiMAX 121
Figura 5.34 Etapele și schimbul de mesaje pentru procesul de autentificare în cadrul modelului de referință propus de Forumul WiMAX 122
Figura 5.35 Micromobilitatea și macromobilitatea în cadrul arhitecturii de rețea propusă de modelul de referință 125
Figura 6.1 Construirea unui plan de securitate utilizând o abordare de tip concentric 138
Figura 6.2 Ilustrarea modului de abordare pentru implementarea unei rețele nucleu pentru operator și/sau furnizor de servicii 139
Figura 6.3 Arhitectura specifică planului interdependent de securitate 143
Figura 6.4 Studiu de caz – interconectarea locațiilor pentru un client prin intermediul unei rețele WiMAX dezvoltate de un operator 146
Figura 6.5 Studiu de caz – interconectarea locațiilor pentru un client prin intermediul unei rețele WiMAX dezvoltate de un operator – arhitectură finală (rezultată în urma aplicării planului interdependent de securitate) 154
Figura 6.6 Pașii pe care îi urmează un nou utilizator mobil care dorește să beneficieze de servicii de bandă largă prin intermediul noii rețele WiMAX 157
Figura 6.7 Arhitectura de rețea propusă de planul de securitate (detalii de autentificare) 159
Figura 6.9 Procesul de autentificare (pentru un nou utilizator) 161
Figura 6.10 Reautentificarea unui utilizator înainte de deconectare 162
Figura 6.11 Reautentificare utilizatorului după deconectare 163
Figura 6.12 Amplasarea (zonei) platformei de taxare în cadrul unei rețele – pentru rețele fără fir 167
Figura 6.13 Colectarea evenimentelor pentru platforma de taxare oferită de AMDOCS 169
Figura 6.14 Pașii pe care îi urmează un nou utilizator mobil care dorește să beneficieze de servicii de bandă largă prin intermediul noii rețele WiMAX – partea de autentificare 172
Figura 6.15 Schimbul de mesaje pentru protocolul CUANTAX pentru o rețea ce se bazează pe tehnologia WiMAX (pentru un utilizator autentificat) 176
Figura 6.16 Arhitectura de laborator pentru o rețea WiMAX 184
LISTĂ DE TABELE
Tabel 5.2 Tabel descriptiv pentru câmpurile componente ale antetului generic al MPDU 80
Tabel 5.3 Exemple de pachete diferite în funcție de componența câmpului Type 80
Tabel 5.5 Tabel descriptiv pentru câmpurile componente ale antetului specific mesajelor de cerere de bandă 81
Tabel 5.7 Tabel descriptiv pentru câmpurile prezente în certificatul X509 84
Tabel 5.27 Tabel de prezentare a funcțiilor principale îndeplinite de modulul ASN 108
Tabel 5.29 Descrierea punctelor de referință prezentate în modelul de referință 113
Tabel 6.8 Pașii din procesul de autentificare 160
Tabel 6.17 Parametrii fluxului de pachete (pentru WiMAX) 196
LISTĂ DE ABREVIERI
3GPP – 3rd generation partnership project – Proiectul de Parteneriat al celei de-a treia Generații
AAA – Authentication, Authorization, Accounting – Autentificare, autorizare, contabilitate
ACK – Acknowledge – Confirmare
ADSL – Asymmetric digital subscriber line – Linie de abonat digital asimetrica
AES – Advanced Encryption Standard – Standard avansat de criptare
AK – Authentication Key – Cheie de autentificare
AP – Access Point – Punct de acces
ASCII – American Standard Code for Information Interchange – Cod standard american folosit în schimbul de informații
ASN – Access Services Network – Rețea de acces definită de modelul de referință pentru rețele WiMAX propus de Forumul WiMAX
ATM MAC-PDU 56
Figura 4.1 Stiva de nivele pentru IEEE 802.16 – 2004 63
Figura 4.2 Formatul MAC-PDU 65
Figura 4.3 IEEE 802.16 SA (Security Associations) 66
Figura 4.4 Procesul de autentificare IEEE 802.16 cu ajutorul SA 67
Figura 4.5 IEEE 802.16 – Schimbul de chei în cazul comunicației de date 69
Figura 5.1 Antetul generic al MPDU pentru pachetele diferite de cele de cerere de bandă 79
Figura 5.4 Antetul pentru mesajul de cerere de bandă 81
Figura 5.6 Procesul de creere al HMAC 83
Figura 5.8 Etapele procesului de autentificare 86
Figura 5.9 Procesul de criptare a TEK 89
Figura 5.10 Descrierea subnivelului de securitate 90
Figura 5.13 Procesul de derivare a cheilor 91
Figura 5.14 Schimbul de mesaje pentru transmiterea TEK între SM/SU și SB 91
Figura 5.15 Procesul de autentificare mutuală între SB și SM 93
Figura 5.16 Piramida obținerii cheilor in cazul PKMv2 94
Figura 5.17 Procedeul de obținere a cheii de autentificare AK prin metoda bazată pe EAP 95
Figura 5.18 Procesul de obținere a cheii de autentificare prin metoda bazată pe algoritmul de criptare RSA 96
Figura 5.20 Procesul de criptare al MPDU bazat pe DES-CBC 98
Figura 5.21 Cadrul de ocazie pentru AES-CCM 99
Figura 5.22 Blocul CBC 100
Figura 5.23 Bloc contor pentru modul CCM 100
Figura 5.24 Crearea mesajului criptat de autentificare în cadrul AES-CCM 101
Figura 5.25 Procesul de creare a unei MPDU cu informația utilă criptată prin metoda bazată pe AES-CCM 103
Figura 5.26 Modelul de referință pentru arhitectura rețelelor WiMAX propus de Forumul WiMAX 105
Figura 5.28 Ilustrarea operațiilor logice pentru fiecare modul al modelului de referință propus de Forumul WiMAX 112
Figura 5.30 Stiva de protocoale și de nivele (comunicație IP) pentru fiecare modul al modelului de referință propus de Forumul WiMAX 115
Figura 5.31 Stiva de protocoale și de nivele (comunicație Ethernet) pentru fiecare modul al modelului de referință propus de Forumul WiMAX 116
Figura 5.32 Etapele procesului de autentificare pentru modelul de referință (ținând cont de cadrul creat pentru procesul de AAA) 119
Figura 5.33 Stiva de protocoale utilizată în procesul de autentificare în cadrul modelului de referință propus de Forumul WiMAX 121
Figura 5.34 Etapele și schimbul de mesaje pentru procesul de autentificare în cadrul modelului de referință propus de Forumul WiMAX 122
Figura 5.35 Micromobilitatea și macromobilitatea în cadrul arhitecturii de rețea propusă de modelul de referință 125
Figura 6.1 Construirea unui plan de securitate utilizând o abordare de tip concentric 138
Figura 6.2 Ilustrarea modului de abordare pentru implementarea unei rețele nucleu pentru operator și/sau furnizor de servicii 139
Figura 6.3 Arhitectura specifică planului interdependent de securitate 143
Figura 6.4 Studiu de caz – interconectarea locațiilor pentru un client prin intermediul unei rețele WiMAX dezvoltate de un operator 146
Figura 6.5 Studiu de caz – interconectarea locațiilor pentru un client prin intermediul unei rețele WiMAX dezvoltate de un operator – arhitectură finală (rezultată în urma aplicării planului interdependent de securitate) 154
Figura 6.6 Pașii pe care îi urmează un nou utilizator mobil care dorește să beneficieze de servicii de bandă largă prin intermediul noii rețele WiMAX 157
Figura 6.7 Arhitectura de rețea propusă de planul de securitate (detalii de autentificare) 159
Figura 6.9 Procesul de autentificare (pentru un nou utilizator) 161
Figura 6.10 Reautentificarea unui utilizator înainte de deconectare 162
Figura 6.11 Reautentificare utilizatorului după deconectare 163
Figura 6.12 Amplasarea (zonei) platformei de taxare în cadrul unei rețele – pentru rețele fără fir 167
Figura 6.13 Colectarea evenimentelor pentru platforma de taxare oferită de AMDOCS 169
Figura 6.14 Pașii pe care îi urmează un nou utilizator mobil care dorește să beneficieze de servicii de bandă largă prin intermediul noii rețele WiMAX – partea de autentificare 172
Figura 6.15 Schimbul de mesaje pentru protocolul CUANTAX pentru o rețea ce se bazează pe tehnologia WiMAX (pentru un utilizator autentificat) 176
Figura 6.16 Arhitectura de laborator pentru o rețea WiMAX 184
LISTĂ DE TABELE
Tabel 5.2 Tabel descriptiv pentru câmpurile componente ale antetului generic al MPDU 80
Tabel 5.3 Exemple de pachete diferite în funcție de componența câmpului Type 80
Tabel 5.5 Tabel descriptiv pentru câmpurile componente ale antetului specific mesajelor de cerere de bandă 81
Tabel 5.7 Tabel descriptiv pentru câmpurile prezente în certificatul X509 84
Tabel 5.27 Tabel de prezentare a funcțiilor principale îndeplinite de modulul ASN 108
Tabel 5.29 Descrierea punctelor de referință prezentate în modelul de referință 113
Tabel 6.8 Pașii din procesul de autentificare 160
Tabel 6.17 Parametrii fluxului de pachete (pentru WiMAX) 196
LISTĂ DE ABREVIERI
3GPP – 3rd generation partnership project – Proiectul de Parteneriat al celei de-a treia Generații
AAA – Authentication, Authorization, Accounting – Autentificare, autorizare, contabilitate
ACK – Acknowledge – Confirmare
ADSL – Asymmetric digital subscriber line – Linie de abonat digital asimetrica
AES – Advanced Encryption Standard – Standard avansat de criptare
AK – Authentication Key – Cheie de autentificare
AP – Access Point – Punct de acces
ASCII – American Standard Code for Information Interchange – Cod standard american folosit în schimbul de informații
ASN – Access Services Network – Rețea de acces definită de modelul de referință pentru rețele WiMAX propus de Forumul WiMAX
ATM – Asynchronous Transfer Mode – Mod de transfer asincron
BACKBONE – Magistrală
bps – bits per second – biți pe secundă
BSA – Basic Service Area – zonă pentru realizarea serviciului – SBA
BSS – Basic Service Set – Setul de bază pentru realizarea serviciului – SBS
CATV – Cable Television – Televiziune prin cablu
CBC – Cipher Block Chaining – Înlănțuirea blocurilor de date codate
CDMA – Code Division Multiple Access – Metodă de acces multiplu care folosește o secvență de cod pseudo-arbitrară pentru fiecare utilizator
CID – Connection Identifier – Identificator de conexiune
CSMA-CD/CA – Carrier Sense Multiple Access-Collision Detection/Collision Avoidance – Protocol la nivel MAC în care un nod verifică absența unei alte transmisiunii înainte de a transmite (Detectare de coliziune / Evitarea coliziunii)
CSN – Core Services Network – Rețea principală definită de modelul de referință pentru rețele WiMAX propus de Forumul WiMAX
DES – Data Encryption Standard – Standard de criptare a datelor
DHCP – Dynamic Host ConFig.tion Protocol – Protocol utilizat pentru configurarea dinamica a echipamentului (pentru obținerea unor parametrii cum ar fi adresa IP)
DLP – Data Loss Prevention – Prevenire a pierderii datelor
DOCSIS – Data Over Cable Service Interface Specifications – Standard internațional folosit pentru reglementarea comunicațiilor prin cablu
DSL – Digital Subscriber Line – Linie digitală pentru utilizator
EAP – Extensible Authentication Protocol – Protocol de autentificare extensibil
EDGE – Enhanced Data Rates for GSM Evolution – Rate de transfer îmbunătățite pentru evoluția sistemului global de comunicații mobile
ESS – Extended Service Set – Set de servicii extinse
ETSI – European Telecommunications Standards Institute – Institutul european de standarde pentru telecomunicații
EUL – Enhanced Uplink – Denumire folosită pentru HSUPA în unele organizații
EVDO – Evolution Data Optimized – Standard pentru comunicațiile fără fir
FCS – Frame Check Sequence – Secvență de control adăugată unui cadru pentru a fi folosită de codurile corectoare/detectoare de erori
GPCS – Generic Packet Convergence Sublayer – Subnivel de convergență a pachetelor
GSM – Global System for Mobile Communications – Sistem global de comunicații mobile
HMAC – Hash-based message authentication code – Cod de autentificare al mesajului construit cu ajutorul unei funcții de criptare de tip hash în combinație cu o cheie secretă
HSPA – High-Speed Packet Access – Set de protocoale de comunicații folosit în telefonia mobilă (cu variantele HSDPA pentru download și HSUPA pentru upload)
IDS – Intrusion Detection System – Sistem de detecție a breșelor
IEEE – Institute of Electrical and Electronics Engineers
IP – Internet Protocol – Protocol utilizat pentru identificarea diferitele dispozitive ale rețelelor, pe ce rețea se găsesc și care sunt elementele ce descriu acele dispositive
ISP – Internet Service Provider – Furnizor de servicii Internet
KEK – Key Encryption Key – Cheie de criptare a cheilor
LAN – Local Area Network – Rețea locală
L2TP – Layer 2 Tunnelling Protocol – Protocol folosit pentru încapsularea cadrelor necesare conexiunilor tip PPP
LDPC – Low Density Parity Check – Cod corector de erori
LOS – Line-of-Sight – Arată faptul că mediul de transmisiune dintre emițător și receptor este unul liber, lipsit de obstacole
MAC – Media Access Control – Nivelul de control al accesului la mediu
MBWA – Mobile Broadband Wireless Access – Acces mobil fără fir de bandă largă
MESH – rețea tip năvod (sau plasă)
MIB – Management Information Based – Bază de date conținând informațiile necesare administrării echipamentelor dintr-o rețea
MIMO – Multiple Input Multiple Output – Mai multe intrări și mai multe ieșiri (pentru un sistem de antene)
NAP – Network Access Provider – Furnizor de conectivitate de nivel 2 pentru un NSP
NAT – Network Address Translation – Mecanism (schemă) ce asigură translatarea mai multor adrese IP private într-o singură adresă publică
NSP – Network Service Provider – Furnizor de servicii de nivel 3
NIST – National Institute of Standards and Technology – Institutul național de standarde și tehnologii
NRM – Network Reference Model – Model de referință pentru rețeaua WiMAX propus de Forumul WiMAX
OFDM – Orthogonal Frequency Division Multiplexing – Metodă de modulare cu mai multe purtătoare și cu divizare în frecvențe ortogonale
OSI – Open System Interconnection – Model de interconectare a sistemelor deschise
PAN – Personal Area Network – Rețea personală de mici dimensiuni
PCMCIA – Personal Computer Memory Card International Association – Card de memorie folosit la calculatoarele personale
PDA – Personal Digital Assistant – Asistente personale digitale
PDU – Protocol Data Unit – Unitate informațională a protocolului
PHY – Physical Layer – Nivelul fizic din stiva OSI, TCP/IP definit de specificațiile privind conectorii, echipamentele și interfețele, precum și de cerințele privind cablurile folosite pentru transmiterea datelor
PKM – Privacy Key Management – Protocol folosit pentru administrarea cheilor de criptare
PMP – Point to Multipoint) – Rețea punct la multipunct
PPP – Point to Point Protocol – Protocol folosit pentru a oferi suport pentru conexiunile între 2 routere sau între host și rețea (prin intermediul circuitelor sincrone sau asincrone)
RADIUS – Remote Authentication Dial-In User Service – protocol care oferă suport pentru administrarea centralizată a operațiunilor de tip AAA
QAM – Quadrature Amplitude Modulation – Modulație a amplitudinii în cuadratură
QoS – Quality of Service – Denumire generică pentru cerințele cu privire la calitatea serviciului de telecomunicații
REQ – Reques – Cerere
CORE NETWORK – Rețea nucleu
RSA – Ron Rivest, Adi Shamir, and Leonard Adleman – algoritm folosit pentru criptarea cheilor de comunicații (cheile publice, în general)
RSP – Response – Răspuns
MS (SM) – Mobile Station – Stație mobilă (se poate întâlni și sub forma SM)
SSID – Service Set Identifier – Identificator al setului de servicii
SSL – Secure Socket Layer (acum TLS – Transport Socket Layer) – protocol care ajută la securizarea comunicațiilor peste o rețea
TDMA – Time Division Multiple Access – Metodă de acces multiplu cu diviziune în timp
TEK – Traffic Encryption Key – Cheie de criptare a traficului
UMTS – Universal Mobile Telecommunications System – Sistem de telecomunicații mobile
UTRA – Universal Terrestrial Radio Access – Sistem de acces universal terestru
VLAN – Virtual LAN – Definește un grup de echipamente care pot comunica ca și cum ar conectate fizic între ele, deși, de fapt, ele se află în rețele (LAN) diferite
VoIP – Voice over IP – Denumire generică pentru un set de protocoale utilizate pentru transmisiuni de voce peste rețele cu comutație de pachete
vs – versus
WiMAX – Worldwide Interoperability for Microwave Access
WLAN – Wireless Local Area Network – Rețea fără fir locală
WMAN – Wireless Metropolitan Access Network – Rețea de acces fără fir metropolitană
WPAN – Wireless Personal Area Network – Rețea personală fără fir de mici dimensiuni
WRAN – Wireless Regional Area Network – Rețea regională fără fir
INTRODUCERE
Comunicațiile de bandă largă din lumea întreagă au cunoscut o dezvoltare într-un ritm accelerat. Accesul la Internet se realiza (pâna de curând), în mare parte, prin intermediul soluțiilor tradiționale – Ethernet, DSL (Digital Susbcriber Line) sau fibra optică – deci utilizând infrastructuri fixe (rețele cablate structurat). Este dificil pentru un furnizor de servicii să intrețină astfel de rețele (mai ales în zonele rurale sau greu accesibile), iar extinderea unei astfel de infrastructuri presupune costuri ridicate. In plus, odată cu evoluția tehnologiei, s-a pus problema folosirii rețelelor fără fir pentru a oferii servicii de bandă largă.
Dependența de informație a întregii societăți, precum și nevoia permanentă de comunicare rapidă au determinat evoluția fulminantă a serviciilor specifice rețelelor de telecomunicații precum și creșterea numărului de dispozitive mobile (laptop-uri, telefoane mobile, echipamente de tip BlackBerry) folosite de către utilizatori pentru a accesa, în orice moment, informații vitale pentru propriile afaceri și nu numai.
Din acest motiv, rețelele fără fir au cunoscut o dezvoltare fără precedent atât din punctul de vedere al numărului de utilizatori simultani acceptați, cât și din punctul de vedere al ratelor de transfer. Diferența dintre serviciile oferite folosind rețele cablate și cele ce au la bază arhitectura rețelei fără fir este aproape insesizabilă.
În același timp, au fost propuse o multitudine de tehnologii fără fir – standardizate sau nu – pentru a permite accesul utilizatorilor la rețeaua furnizorului de servicii. Una dintre ele, relativ nouă, este WiMAX – Worldwide Interoperability for Microwave Access.
Considerată ca o rudă îndepartată a Wi-Fi, tehnologia WiMAX a avut parte de un paradox încă de la început: argumentele contra și-au făcut loc în cercurile specializate chiar înainte ca tehnologia să funcționeze la capacitate maximă în cadrul unei implementări dedicate! Specialiștii s-au grăbit să analizeze avantajele și dezavantajele acestei tehnologii chiar fără a avea o rețea WiMAX perfect funcțională, independentă sau integrată în rețeaua unui operator de mari dimensiuni. Implementările s-au limitat mai mult, până de curând, la folosirea tehnologiei în sine ca și opțiune pentru ceea ce numim „buclă locală” (local loop), ca și alternativă la tehnologiile tradiționale (Wi-Fi, ADSL etc.). Am spus „până de curând” întrucât, în SUA, Sprint-Nextel a implementat prima rețea WiMAX în totalitate funcțională.
Puse oarecum în plan secund anterior, problemele legate de securitatea rețelei WiMAX – autentificare, autorizare etc., de zona de taxare – protocoale de taxare (billing) etc. au revenit pe tapet. Primul pas a fost făcut – de către Sprint-Nextel – alții urmează, fiind deja anunțați (WiMAX Telekom Austria, Telkom Africa de Sud etc.).
În lucrarea de față îmi propun ca, pornind de la principiile teoretice deja enunțate în teoria de specialitate, să ofer o variantă pentru un plan de securitate valabil pentru rețelele bazate pe tehnologia WiMAX, insistând apoi pe construirea unui protocol de taxare capabil să ofere o integrare mult mai facilă cu platformele deja existente (cum este și platforma de taxare).
Am abordat un astfel de subiect tocmai în ideea că, așa cum menționam, ne aflăm încă la începutul implementărilor dedicate WiMAX, neavând încă un număr însemnat de astfel de rețele dedicate.
Prin urmare, acesta este un moment propice construirii unui plan pentru securitatea rețelei, care să înglobeze principii și recomandări bazate pe teoria din domeniu și pe experiența acumulată în cadrul proiectelor dezvoltate pentru un operator telecom major, și care să ofere, în final, un exemplu de arhitectură posibilă pentru o rețea bazată pe tehnologia WiMAX (construcție care va fi structurată pe un exemplu concret).
De asemenea, bazandu-mă tot pe experiența din domeniu, pot spune că, la momentul actual, nu există definită foarte clar o strategie de taxare pentru rețele bazate pe tehnologia WiMAX. Utilizarea acestei tehnologii mai mult pentru ultima partea a conexiunii către utilizator (așa numita „last mile”) nu a determinat necesitatea abordării problemelor pe care le-ar putea ridica integrarea cu platforma de taxare. Operatorii oferă un serviciu clienților, pe care l-am putea denumi generic „serviciu de date” (VPN, acces Internet etc.) și, pentru implementarea căruia, se folosesc mai multe tehnologii: radio – WiMAX pentru bucla locală și microunde pentru comunicația între site-uri, structurate (așa numite „cu fir”) – Ethernet sau Fibră optică pentru zona de bază a rețelei (core). Taxarea pentru acest serviciu se realizează doar pe baza unor parametrii generali (ex.: bandă, număr de utilizatori, nivel de suport oferit etc.) fără a ține cont de tehnologiile implicate.
Totuși, odată cu dezvoltarea rețelelor de tip WiMAX, serviciile oferite vor putea fi taxate pe baza unor detalii diferite – de exemplu, parametrii specifici de calitate ai serviciului (alții decât banda). Prin urmare, este necesară o integrare a noi rețele cu platformele deja existente (cum este și cea de taxare). Ce ar însemna, de fapt, această integrare?
Eu consider că, până la urmă, totul se rezumă la furnizarea unor informații într-un anumit format, de la noua rețea la platforma de taxare astfel încât aceasta să poată executa corect și complet operațiile necesare taxării clientului. Deci, dincolo de detaliile de conectivitate, pentru că suntem totuși în domeniul telecomunicațiilor, trebuie un protocol capabil să asigure o comunicare corectă între platforma de taxare și noua rețea WiMAX. Protocolul pe care îl voi propune în cadrul acestei lucrări oferă o astfel de facilitate, asigurând, în plus, și ceea ce ne dorim întotdeauna – securitatea comunicației. Refolosind anumite chei din procesul de autentificare din cadrul rețelei WiMAX și bazându-se pe standardele utilizate în cadrul platformelor de taxare recunoscute în domeniu, protocolul va putea contribui din plin la o integrare ușoară a tehnologiei WiMAX în rețeaua operatorului.
Lucrarea este structurată în 6 capitole. Primul dintre aceste capitole l-am scris tocmai în ideea de a ilustra paradoxul de care vorbeam anterior – „loviturile” (argumentele contra) pe care tehnologia WiMAX le-a recepționat încă înainte de vreo implementare serioasă. Astfel, încă din primul capitol am prezentat familia de standarde 802 – familie din care face parte și standardul 802.16 (WiMAX) pentru o mai bună localizare a acestuia din urmă (802.16). Această localizare m-a ajutat apoi în identificare eventualilor competitori precum și a aliaților – atât dintre tehnologiile definite prin standarde din familia 802 cât și dintre alte tehnologii deja consacrate (GSM etc.).
De ce a fost necesar un astfel de capitol? În primul rând, pentru o tehnologie nouă este nevoie de o localizare/plasare a ei printre tehnologiile deja existente. Apoi, orice analiză detaliată (fie ea și de securitate) a unei tehnologii noi trebuie să țină seama de interacțiunea cu ceea ce avem deja – fie că vorbim de o integrare sau de o simplă conlucrare. După această poziționare, în cel de-al doilea capitol, am trecut la o prezentare mai detaliată a standardelor 802.16 (WiMAX), introducând câteva elemente istorice semnificative – evoluția standardului 802.16, detalii legate de certificare etc.
Tot în cadrul acestui capitol, am prezentat și detaliile generale ale nivelelor fizic și MAC – cele mai „afectate” de standardul 802.16 Pentru nivelul fizic m-am concentrat în principal pe descrierea sistemului adaptiv de antene precum și pe modulația adaptivă. Mi s-au părut cele mai relevante în contextul temei globale – securitate – tocmai prin prisma identificării și înțelegerii ulterioare a potențialelor probleme ce pot apărea la acest nivel. De aceea, și prezentarea nivelul MAC s-a concentrat pe acele subnivele aflate în strânsă legătură cu scopul declarat al lucrării – securitatea rețelelor WiMAX.
Din momentul în care am dorit stabilirea unui plan pentru securitatea rețelei precum și un protocol de taxare specific, mi-am dat seama că este necesară o prezentare a arhitecturilor posibile pentru rețelele bazate pe tehnologia WiMAX. Tocmai de aceea, în cel de-al treilea capitol se vor regăsi detaliile semnificative legate de arhitecturile tip PMP și Mesh (construcție, mod de funcționare, tipul de transmisiuni etc.). În același timp, acest capitol prezintă și caracteristicile importante legate de performanța sistemelor WiMAX. Am în vedere, în acest punct, servicii și parametrii – modul de alocare a benzii, mecanismele de interogare, rezolvarea coliziunilor etc. precum și partea legată de calitatea serviciului. Un punct important al expunerii, mai ales din punct de vedere „securitate”, este detalierea procesului de retransmisie utilizat în cadrul tehnologiei WiMAX. Acesta va fi una dintre componentele importante în analiza de securitate efectuată în capitolele următoare.
Odată cu cel de-al patrulea capitol, am început definirea elementelor principale legate de securitatea rețelelor WiMAX. În prima parte a acestui capitol am prezentat cele două instrumente folosite în dezvoltarea unui plan de securitate – instrumente de detecție și verificare (de exemplu: identificatorii de vulnerabilități, instrumentele de verificare a securității aplicațiilor etc.) precum și instrumente de urgență (cum ar fi: instrumentele pentru planificarea riscurilor rețelei etc.). În cea de-a doua parte a capitolului am prezentat câteva considerente generale legate de vulnerabilitățile și riscurile de securitate identificate în cadrul familiei de standarde 802.16. Aceste riscuri sunt fie deja demonstrate – și în cazul în care există o soluție, am prezentat și soluția (vezi cazul autentificării mutuale) – fie le-am identificat ca posibile probleme – și în acest caz soluția va fi prezentată în momentul construirii planului de securitate.
În capitolul al cincilea am detaliat principalele componente de securitate ale familiei de standarde 802.16 – protocoale (EAP, PKM etc.), certificate (X509) etc. Am început acest capitol cu o mică pledoarie legată de monopolul buclei locale – un monopol pe cale de dispariție. Am considerat necesară o astfel de argumentație tocmai pentru a justifica, dacă mai era nevoie, importanța pe care o au tehnologiile fără fir (așa cum este și WiMAX) în contextul liberalizării pieței telecom și a accesului la bucla locală. Chiar și la noi în țară există ceea ce se cheamă „Strategia națională de broadband Romania” [70] care reglementează și această parte a accesului la bucla locală. În contextul unei teze care tratează o nouă tehnologie (fie și numai partea ei de securitate și zona de taxare) nu puteam omite acest subiect.
Unul dintre principalele motive pentru care am ales să construiesc un plan de securitate a fost legat și de faptul că întreg conceptul de securitate (atât în telecomunicații dar nu numai) a evoluat semnificativ.
Am trecut de la securitatea fizică a echipamentelor la securitatea rețelei și la securitatea pentru online. Prin urmare și planurile de securitate existente trebuiau fie revizuite fie reconstruite.
Mai mult, din punctul meu de vedere, la momentul actual, mai ales pentru rețelele WiMAX, există o preocupare pentru imunitatea individuală a elementelor componente ale rețelei și nu o analiză a securității din punct de vedere global. Una dintre contribuțiile mele (prin intermediul acestei teze) se leagă tocmai de această omisiune.
Planul pe care îl construiesc în capitolul al șaselea oferă, de fapt, pas cu pas, etapele pe care ar trebui să le urmeze un operator în momentul în care implementează o rețea bazată pe tehnologia WiMAX. În plus, având în vedere ultimele tendințe din domeniu, planul propus este unul deschis (open) – permițând eventuale contribuții și dezvoltări ulterioare din zona comunității telecom – și nu este legat de un anumit furnizor de echipamente WiMAX (certificat sau nu). Studiul de caz utilizat în construirea acestui plan și în exemplificarea etapelor este unul desprins din realitate și bazat pe experiența pe care acumulată în cadrul implementărilor realizate pentru operatorii majori din România.
Alături de conceptul de global și de cel de open, am mai avut în vedere încă unul: interdependența. Așa cum spuneam, nu putem gândi rețeaua WiMAX ca total independentă de rețeaua deja existentă a operatorului. Nu este recomandabil din punctul meu de vedere să ignorăm acest aspect și, în plus, sunt anumite platforme care nu țin de tehnologia WiMAX și care vor fi folosite în comun de toate rețelele operatorului (GSM, 3G etc.). Una dintre aceste platforme este platforma de taxare cu care noua rețea (WiMAX) – construită într-un mod securizat – va trebui să se integreze.
Integrarea înseamnă, în principal, furnizarea de informații către platforma de taxare într-un format agreat astfel încât aceasta să fie capabilă să proceseze aceste informații și să ofere rezultatul dorit – taxarea coerentă și corectă a clientului. Tot din experiența acumulată în cadrul marilor operatori, trebuie să spun că, în general, platforma de taxare este percepută, mai mult sau mai puțin, ca o „cutie neagră” în care orice modificare trebuie făcută de către furnizorul platformei, cu un cost aferent. Așadar, dezideratul meu a fost ca, alături de planul de securitate, să construiesc și un protocol de taxare care să țină cont de arhitectura unei astfel de platforme de taxare și să poată asigura comunicația între rețeaua WiMAX și această platformă. Studiind documentația unor furnizori recunoscuți (pentru zona de taxare) – AMDOCS – am observat că modulul de colectare al evenimentelor (pe baza cărora se face taxarea propriu-zisă) poate aparține unei terțe părți. În acel punct am ajuns la concluzia că, definind un protocol corect, rolul acestui modul, care comunică direct cu platforma de taxare și furnizează informațiile necesare, poate fi îndeplinit chiar de unul dintre sistemele specifice rețelei WiMAX. Decizia va aparține exclusiv operatorului, însă am definit unul dintre elementele fundamentale – protocolul de comunicație – absolut necesar indiferent de decizia luată : folosirea modulului colector de evenimente actual sau trecerea către un alt echipament.
În finalul capitolului (și al lucrării), am detaliat practic soluționarea cerințelor de integrare prin folosirea protocolului CUANTAX (protocolul de taxare construit) și preluarea de către un echipament aparținând rețelei WiMAX a rolului de modul colector de evenimente pentru platforma de taxare. Este esențial, cred eu, ca dincolo de construcția teoretică, să evidențiem clar și direct zona de aplicabilitate a noilor concepte introduse. În acest mod, stadiul de idee evoluează către concept și, mai apoi, către document de specificații, ajungând la stadiul de implementare. Din păcate, deși am oferit o analiză exhaustivă a ambelor concepte propuse (planul de securitate și protocolul CUANTAX), testarea lor efectivă este mult mai greu de realizat.
CAPITOLUL 1
ARHITECTURA REȚELELOR FĂRĂ FIR : STANDARDE, TEHNOLOGII, APLICAȚII
INTRODUCERE
În acest capitol, voi prezenta câteva dintre cele mai importante standarde din familia 802, cu tehnologiile aferente – fie că sunt folosite la ora actuală, fie că se așteaptă o dezvoltare viitoare a lor – precum și modul în care ele interacționează cu tehnologia de interes – tehnologia WiMAX. Detaliile teoretice prezentate sunt cele mai relevante din literatura de specialitate (vezi [1], [9], [20], [21], [22], [23], [49]), pe care le-am selectat tocmai în ideea de a putea realiza la finalul capitolului o analiză tip „competiție sau complementaritate?” între tehnologiile prezentate și tehnologia WiMAX. Această analiză mă va ajuta în plasarea tehnologiei WiMAX în gama tehnologiile fără fir existente în cadrul rețelelor complexe de telecomunicații (atât din punct de vedere arhitectural cât și din punct de vedere funcționalități).
STANDARDELE DIN FAMILIA IEEE 802
Considerând modelul OSI, grupul de standarde aparținând IEEE 802 operează la nivelul fizic (PHY) și la nivelul de control al accesului la mediu (MAC). În cadrul acestei familii de standarde regăsim standardul IEEE 802.3 (Ethernet), standardul IEEE 802.1 (management), standardul IEEE 802.5 (token ring – comunicație cu jeton) și standardul foarte des folosit în comunicațiile fără fir – IEEE 802.11 (WLAN). Pentru tehnologia WiMAX, standardul de bază este IEEE 802.16 în timp ce pentru comunicațiile de tip Bluetooth sau ZigBee putem găsi detalii în standardul IEEE 802.15 [29].
Fig. 1.1 ilustrează structura acestui grup de standarde pentru cele două nivele OSI menționate.
Fiecare dintre tehnologiile particulare dezvoltate de grupul IEEE 802 a avut ca principal scop satisfacerea unor cerințe specifice (legate fie de aria de acoperire, fie de mobilitate, fie de interconectare).Pentru IEEE 802.16 s-a dorit o tehnologie care să ofere acces de bandă largă pentru un utilizator aflat în mișcare (ca și exemplu).Însă, în majoritatea cazurilor, aplicațiile practice ulterioare au determinat progresul tehnologiei (vezi numeroasele variante pentru IEEE 802.11).O vedere de ansamblu asupra arhitecturii specifice IEEE 802 este ilustrată și in Fig. 1.2.
Figura 1.2 Arhitectura specifică IEEE 802
În Fig. 1.2, o rețea de tip 802.16 este utilizată pentru a interconecta pe o suprafață întinsă (un oraș, spre exemplu), mai multe rețele locale (LAN – Local Area Network), care, la rândul lor, interconectează rețele private (PAN – Private Area Network).
Toate rețelele sunt de tip fără fir (wireless) și dispozitivele folosite de către utilizatori în cadrul acestor rețele pot varia de la telefoane mobile, PDA până la laptopuri sau calculatoare echipate cu interfețe de rețea fără fir. Legăturile între diferitele tipuri de rețele se realizează prin echipamente de tip bridge care pot asigura un transfer eficient al informației în ambele sensuri.
În timp ce Forumul WiMAX promovează standardul IEEE 802.16, produsele certificate au început să își facă loc pe piața telecomunicațiilor. Marii furnizori de servicii au anunțat deja dezvoltarea de rețele care au la bază tehnologia WiMAX mai ales în zonele în care este foarte greu de realizat o infrastructură fixă. Producătorii de echipamente (cum ar fi INTEL, MOTOROLA etc.) au anunțat că dezvoltă plăci de rețea care să suporte atât standardul 802.11 cât și standardul 802.16 [27]. Tendința este clară – tehnologia WiMAX va juca un rol important în dezvoltarea ulterioară a comunicațiilor.
STANDARDUL IEEE 802.11
Până la momentul actual, tehnologia bazată pe standardul 802.11 este cea mai utilizată tehnologie în rețelele fără fir. Suportă rate de transfer între 1Mbps și 54Mbps pentru diferite metode de modulație și codare. Arhitectura specifică standardului IEEE 802.11 este prezentată în Fig. 1.3.
Figura 1.3 Arhitectura rețelei IEEE 802.11
Setul de bază pentru realizarea serviciului SBS (BSS – Basic Service Set) reprezintă fundația întregii arhitecturi. SBS reprezintă un grup de stații care pot comunica una cu cealaltă.
Toate comunicațiile au loc într-o zonă pentru realizarea serviciului SBA (BSA – Basic Service Area).O stație din interiorul SBA poate comunica doar cu alți membri ai aceluiași SBS.
În cazul rețelelor de tip 802.11, există doua tipuri de seturi de bază (SBS) – independent (sau ad-hoc) și structurat [29].
SBS de tip independent permite comunicația directă între stații.Astfel de grupuri create ad-hoc nu au o durată de viață foarte lungă, iar din punct de vedere comercial, acest tip de set de bază este foarte puțin utilizat.
În cazul SBS structurat, comunicația între stații în cadrul aceluiași SBS se desfășoară prin intermediul unor puncte de access (AP – access point). Acest tip de SBS este și cel mai utilizat, permițând interconectarea mai multor SBS într-un set de bază extins (ESS – Extended Service Set).
Identificarea unui ESS sau SBS se realizează prin intermediul unui identificator al setului pentru realizarea serviciului (SSID – Service Set Identifier). SSID poate avea o lungime variabilă între 0 si 32 de biți și conține, de obicei, caractere ASCII. În cazul în care o stație mobilă (SM) dorește să se asocieze unei rețele de tip 802.11, trebuie ca, mai întâi, să detecteze această rețea.Procesul de detecție poate fi unul pasiv sau unul activ.În cazul cautării pasive, SM scanează toate canalele de frecvență disponibile pentru a găsi un semnal de rețea specific denumit beacon, transmis periodic de toate stațiile din rețea. Acest beacon conține informații esențiale despre rețea (printre care și SSID).În momentul detectării beacon-ului, SM poate începe procesul de autentificare necesar asocierii la rețeaua descoperită [29].
Pentru detecția activă, MS va transmite mai multe semnale de tip beacon în care va include și SSID rețelei la care vrea să se asocieze. În momentul în care va primi un răspuns, SM va începe procesele de autentificare și asociere la rețea. Această metodă se folosește exclusiv în situațiile în care transmiterea SSID este suprimată în cadrul SBS sau ESS din motive de securitate.
Standardul IEEE 802.20
Pe data de 11 decembrie 2002, IEEE aproba crearea grupului MBWA – Mobile Broadband Wireless Access – grup ce urma să elaboreze standardul 802.20 pentru a reglementa comunicațiile fără fir de bandă largă desfășurate pe o raza de maxim 15 km, în benzi sub 3,5GHz, cu rate de transfer apropiate de 1Mbps, pentru un utilizator în mișcare cu o viteză de până la 250km/h [27]. Deși activitățile acestui grup au fost suspendate în data de 8 iunie 2006, ele au fost reluate, mai apoi, în septembrie același an, existând la ora actuală o versiune draft a acestui standard.Întrucât standardul nu este încă în versiunea finală, mai multe amănunte voi oferi în următoarele mele lucrări.
REȚELE CELULARE
Deși prevăzute inițial doar pentru a oferi comunicații de voce, rețelele celulare au cunoscut o evoluție rapidă (ilustrată și în Fig. 1.4). Evoluția tehnologiei celulare (de la a doua generație la a treia generație) s-a datorat, în principal, cererii permanente de noi servicii (cum ar fi trimiterea de mesaje de tip text, de e-mailuri, acces la Internet). Vom prezenta în acest subcapitol evoluția celor două tehnologii principale folosite în rețelele celulare : CDMA (Code Division Multiple Access) si GSM (Global System for Mobile Communications), tehnologie ce poate fi considerată de tip TDMA (Time Division Multiple Access).
Figura 1.4 Evoluția tehnologiei celulare
În decembrie 1998 s-au pus bazele unei colaborări denumită 3GPP (3rd generation partnership project) între mai multe grupuri regionale ce lucrau la standardizarea comunicației mobile: ARIB și TTC- Japonia, ATIS – USA, CCSA – China, TTA – Korea și ETSI – Europa. Pe baza acestui acord, semnatarii se obligau să contribuie la dezvoltarea specificațiilor tehnice pentru un sistem 3G (bazat pe nucleul existent GSM) precum și pentru dezvoltarea unor noi servicii – cum ar fi EDGE (Enhanced data rates for GSM evolution) sau UTRA (Universal terrestrial radio access). Alături de 3GPP2 (acord ce are la bază aproape aceeași actori menționați anterior, mai puțin ETSI), 3GPP nu reprezintă o entitate cu un rol recunoscut în domeniul standardizărilor.Totuși, partenerii din aceste acorduri au putut oferi câteva sfaturi legate de tendința de evoluție a pieței, stabilind un curs ascendent al dezvoltării standardelor 3G [29].
Pentru aceste standarde, s-au stabilit două categorii de tehnologii: TDMA și CDMA.
În cazul tehnologiei TDMA, se consideră că fiecare utilizator are alocat o porțiune de timp din canalul de transmisiune. Pentru rețeaua celulară, utilizatorul ocupă periodic (cu perioada T), pentru porțiunea de timp alocată, toată banda canalului alocat.Pe durata T, pot fi mai mulți utilizatori care ocupă banda canalului, singura condiție fiind ca să nu avem o suprapunere între cadrele de timp aparținând de utilizatori diferiți.Prin urmare, în cazul TDMA, sincronizarea perfectă, atât pentru stațiile de bază, cât și pentru utilizatori este una dintre condițiile absolut necesare unei funcționări corecte.
De obicei, pentru sistemele tip GSM-TDMA, banda canalului este de 200 kHz. Fiecare canal poate suporta până la șase utilizatori simultan. În momentul în care canalul este la capacitate maximă, nici un alt utilizator nou nu mai poate fi acceptat până când unul dintre cei curenți nu se deconectează. Avantajul tehnologiei TDMA este calitatea foarte bună a sunetului; dezavantajul – evident – refuzul unui nou serviciu în momentul în care canalul este folosit la capacitate maximă.
În cazul CDMA, lucrurile sunt diferite. Fiecare canal de date este multiplicat cu ajutorul unei secvențe ortogonale binare unice la o rată mult mai rapidă decât rata de simbol specifică modulației utilizate. În acest mod are loc o lărgire a spectrului astfel încât banda alocată poate ajunge pana la 1 MHz, iar utilizatorii pot folosi întreg spectrul la același nivel al puterii de transmisie. Problemele de interferență sunt minimizate prin două metode: alegerea secvențelor ortogonal (secvențe de codare Walsh) si folosirea unui mecanism adaptiv de control al puterii la stația de bază (SB) și la stațiile mobile (SM). Acest mecanism permite menținerea unui nivel aproximativ egal al puterii recepționate pentru toți utilizatorii, fără discriminari.Ba mai mult, SB poate comanda SM să și ajusteze nivelul de semnal emis astfel încât să fie apropiat de cel al celorlalte SM. Avantajul CDMA este strâns legat de degradarea capacității. Dacă în TDMA, accesul unui utilizator adițional era clar restricționat în momentul în care canalul era folosit la capacitate maximă, CDMA permite degradarea calității semnalului pentru utilizatori curenți astfel încât să poată oferi serviciu și noului utilizator. Totuși, acest lucru poate determina o variație importantă în calitatea sunetului și, în unele situații, imposibilitatea unei comunicații corecte [29].
În ceea ce privește rata de transfer a datelor, generația a doua de rețele celulare permitea o rată de până la 14,4 kbps (CDMA) și 9,6 kbps (TDMA). La momentul actual, însă, astfel de viteze sunt deja istorie.În condițiile în care un card de access PCMCIA permite utilizatorulului să se conecteze (folosind rețeaua celulară) la Internet, rata de transfer trebuie să fie în concordanță cu serviciile oferite.
În acest caz, tehnologii ca 1xEVDO asigură rate de transfer de până la 2,4 Mbps pentru download și 150 kbps pentru upload. În viitor, o versiune îmbunătățită a acestei tehnologii va oferi rate de până la 3,1 Mbps (down) și 1,8 Mbps (up).
Standardul HSDPA pentru tehnologia UMTS-WCDMA permite rate de transfer de până la 7,2 Mbps (pentru download) și chiar mai mult prin introducerea unui canal dedicat de comunicație cu utilizatorul mobil (canal de download).
Pentru uplink, HSUPA poate oferi rate de transfer de până la 5,76 Mbps. Trebuie menționat că standardele HSDPA si HSUPA aparțin de familia de standarde HSPA, iar că 3GPP nu recunoaște denumirea de HSUPA ci folosește denumirea de EUL [29].
Totuși, nu pot să nu subliniez că, în ciuda acestor noi tehnologii, rețele celulare au ca scop primar furnizarea de servicii de voce. Dezvoltarea unor oferte adiționale a venit ca răspuns la provocarea lansată de noile tehnologii wireless (Wi-Fi sau WiMAX) dedicate exclusiv (în prima fază) accesului de bandă largă. Interesant este că, dacă pentru rețelele celulare, s-a accentuat dezvoltarea serviciilor adiționale (e-mail, acces Internet etc.), în cazul rețelelor de tip 802.11 sau 802.16, principala preocupare este integrarea ofertei de voce în gama de servicii furnizate. Ținta, în acest caz, este posibilitatea de a suporta comunicații de voce prin intermediul rețelei fără fir locale (reducând costurile) și convergența fix-mobil (comutația fără întrerupere din rețeau mobilă în rețeaua fixă pentru un utilizator mobil) cât mai rapidă și mai simplă.
ALTE TIPURI DE TEHNOLOGII PENTRU REȚELELE FĂRĂ FIR
Deși mi-am propus să mă ocup, în acest capitol, de tehnologiile de același nivel cu tehnologia WiMAX, astfel încât să vedem când discutăm de competiție și când de o co-existență, nu pot să nu amintesc, pe scurt, și de tehnologii precum Bluetooth, WiBro (Wireless Broadband) – ratificată de un standard coreean înglobat în IEEE 802.16 sau tehnologia tip 802.22 – WRAN (Wireless Regional Area Network) – ce dorește comunicații radio în bandă licențiată pentru transmisiunile TV.
Toate aceste tehnologii nu au cunoscut, însă, cel puțin deocamdată, o evoluție care să le anunțe ca potențiale alternative la comunicațiile tip WiMAX. Prin urmare, mă voi limita în a le menționa, urmând, ca în cazul unor schimbări importante, să le tratez separat în lucrările mele viitoare.
COMPETIȚIE SAU COMPLEMENTARITATE ?
Toate tehnologiile prezentate anterior pot constitui, la un moment dat, fie o alternativă pentru WiMAX, fie un “aliat” de nădejde. Voi analiza, pentru început, care sunt competitorii și care sunt aliații. Deși nu pot separa mereu cele doua tabere, voi încerca să prezint caracteristicile (descrise detaliat anterior) prin comparație cu specificațiile standardului 802.16 (toate variantele sale).
vs IEEE 802.20
Cele doua grupuri ale IEEE (802.16 și 802.20) au fost mereu considerate ca dezvoltând tehnologii concurente. Totuși, există câteva diferențe notabile între cele două tehnologii propuse:
pentru 802.16 viteza maximă propusă pentru utilizator este 150 km/h, în timp ce în cazul 802.20 – se dorește dezvoltarea unei tehnologii care să suporte date de transfer de până la 1 Mbps la o viteză a utilizatorului mobil de până la 250 km/h,
frecvențele de operare în cazul 802.16 sunt între 2 – 6 GHz, în timp ce pentru 802.20, țintele sunt frecvențele din banda de 3,5GHz sau mai jos,
în cazul 802.16 – există o întreagă familie de standarde (802.16a, d, e) în timp ce standardul 802.20 are o singură versiune,
standardul 802.16e este deja ratificat, în timp ce pentru standardul 802.20 nu avem decât versiuni draft. Ba mai mult, urmărind ultimele vești legate de problemele întâmpinate de acest grup, versiunea finală pare, pentru moment, un obiectiv irealizabil.
Întrucât standardul 802.20 nu va putea oferi rate de transfer la nivelul celor oferite de 802.16, ținta principală a grupului dezvoltator a fost suportul pentru o viteză crescută de deplasare pentru utilizatorul mobil.Totuși, odată cu evoluția tehnologiei WiMAX, este de așteptat ca diferența aceasta legată de viteza de deplasare suportată să fie eliminată. În plus, standardul 802.16 / tehnologia WiMAX au fost deja adoptate ca următorul pas în oferta de servicii de bandă largă, chiar dacă 802.20 poate constitui o soluție în acest caz.
vs rețele celulare
Nivelul investițiilor și al dezvoltării infrastructurii pentru rețelele celulare este unul dintre cele mai ridicate din domeniul telecomunicațiilor globale. De fapt, rețelele celulare pot fi considerate principalul concurent al tehnologiei WiMAX. Posibilitățile de extindere către servicii de date, precum și suportul mobilității încă de la început, au determinat o extindere fără precedent a rețelelor celulare. Există, totuși, câteva dezavantaje care se pot dovedi hotărâtoare în anumite situații [29]:
Scopul original al rețelelor celulare a fost furnizarea serviciilor de voce ceea ce înseamna necesitatea migrării către comunicații de tip IP pentru rețelele CDMA și GSM în cazul în care dorim extinderea ofertei de servicii (de date etc.). Pe de altă parte, tehnologia WiMAX are la bază comunicația tip IP ceea ce presupune suport pentru aplicații de voce și date încă de la început.
Evoluția către tehnologii cum ar fi HSDPA sau 1xEVDO determină creșteri ale costului pentru dezvoltarea rețelelor celulare, un cost mult mai ridicat decât în cazul dezvoltării unei rețele tip WiMAX.
Performanțele pentru serviciile de date sunt, în mult situații, net inferioare în rețelele celulare față de rețelele tip WiMAX , măsurătorile efectuate sugerând chiar diferențe de până la 96% (în avantajul WiMAX) în situații similare.
Nu putem ignora totuși avantajul clar pe care îl oferă rețelele celulare – nivelul mare de acoperire. Deși, majoritatea operatorilor GSM și-au anunțat disponibilitatea de a crea rețele tip WiMAX la nivelul celor celulare, deocamdată situația este net în favoarea GSM.
vs IEEE 802.11
Încă de la început, tendința clară este de a cataloga tehnologia tip 802.11 ca fiind complementară tehnologiei WiMAX. Oare așa să fie?
Standardul IEEE 802.11 a fost conceput pentru a permite dezvoltarea rețelelor fără fir de tip local (WLAN), spre deosebire de standardul IEEE 802.16, ce are în vedere rețele fără fir de mari dimensiuni (WMAN).Tehnologia WiMAX are la bază metode de acces tip TDD sau FDD, în timp ce pentru 802.11 – accesul la mediu este realizat prin intermediul metodei CSMA-CA/CD.În plus, pe distanțe mici, este de așteptat ca performanțele IEEE 802.11 să le depășească pe cele ale tehnologiei tip IEEE 802.16 (ca rată de transfer, ca număr de utilizatori etc.). Până acum am prezentat numai diferențe. De ce am susține totuși complementaritatea acestor două tipuri de tehnologii?
În primul rând, standardul IEEE 802.11 a fost cel care a determinat dezvoltarea unei tehnologii capabile să asigure accesul la servicii de bandă largă prin intermediul rețelelor fără fir.Cronologic, acest standard este primul apărut și îl putem chiar considera precursorul standardului 802.16.
În al doilea rând, o rețea tip WiMAX nu ar putea asigura necesarul de bandă pentru toți utilizatorii, la nivelul unui oraș spre exemplu. De fapt, nici măcar nu își propune acest lucru. Arhitectura ideală, în acest caz, presupune acoperirea unor zone mai mici cu ajutorul unor rețele tip 802.11, urmând ca interconectarea între aceste rețele (între punctele de acces) să se realizeze prin intermediul unei rețele tip WiMAX. Prin urmare, pot susține complementaritatea, diferențele prezentate anterior contând mult mai puțin.
vs IEEE 802.15
Deși standardul IEEE 802.15 are în vedere rețele fără fir de foarte mici dimensiuni (WPAN) (fiind în evidentă contradicție cu scopul standardului 802.16), tehnologiile descrise în acest standard (Bluetooth, Zigbee) se pot dovedi utile în anumite situații permițând accesul la rețelele fără fir a telefoanelor mobile, PDA-urilor etc. Rata de transfer în aceste situații este mică, astfel încât folosirea unei rețele tip WiMAX nu își are rostul [29].
CONCLUZII
Evoluția permanentă a rețelelor fără fir determină includerea în gama platformelor utilizate dispozitive din ce în ce mai variate – de la telefonul mobil, PDA până la laptop și desktop. Așadar, „alianțele” tehnologiei WiMAX cu alte tehnologii (concurente sau complementare) sunt absolut necesare în foarte multe situații.
Cred că este evidentă o soluție arhitecturală concentric multi-tehnologie – Bluetooth->Wi-Fi->WiMAX – care poate acoperi cererile pentru orice tip de topologie geografică (oraș, cartier etc.) fără costuri ridicate sau probleme legate de bandă.
CAPITOLUL 2
FAMILIA DE STANDARDE IEEE 802.16
INTRODUCERE
În cadrul acestui capitol voi prezenta detalii generale legate de familia de standarde 802.16. Voi face o scurtă istorie a grupului fondat de IEEE pentru dezvoltarea acestei familii de standarde, oferind, în același timp, și etapele pe care acesta le-a parcurs (cu standardele aferente – 802.16a, 802.16b etc.). Apoi voi expune principalele caracteristici ale nivelului fizic și ale nivelului MAC pentru IEEE 802.16. Voi include pentru nivelul fizic caracteristici ale metodelor de transmisiune, descrierea sistemului adaptiv de antene și a modulației adaptive. Pentru nivelul MAC voi prezenta subnivelul părților comune, subnivelul de securitate și câteva detalii importante legate de managementul puterii.
Toate acestea sunt necesare în perspectiva dezvoltărilor ulterioare legate de securitatea rețelelor WiMAX. Detaliile oferite sunt cele regăsite în cadrul literaturii de specialitate (de ultimă apariție) – vezi [4], [16], [21], [22], [45], [65], [68] – cu mențiunea că le-am selectat și accentuat pe cele relevante pentru scopul lucrării mele.
PRIVIRE GENERALĂ
Grupul IEEE 802.16 a fost inființat în anul 1999 de către IEEE cu scopul de a defini în mod formal specificațiile necesare dezvoltării comunicațiilor de bandă largă pentru zonele metropolitane (WirelessMAN). Aparținând de divizia IEEE 802 LAN/MAN grupul nou creat urma să se ocupe de partea teoretică a standardului nu și de testarea specificațiilor.
Un grup format din cei mai importanți furnizori mondiali de echipamente de telecomunicații (Intel®, Samsung®, Motorola®, Cisco® etc.) a fost ales pentru a promova adoptarea tehnologiei WiMAX. Împreună, ei au pus bazele Forumului WiMAX (WiMAX Forum), care a dezvoltat un program de certificare a echipamentelor WiMAX [67].
Practic, scopul acestui forum este asigurarea unei certificări WiMAX care să ofere siguranța unei interoperabilități între echipamente provenind de la producători diferiți.
Se păstrează astfel „tradiția” impusă de Alianța Wi-Fi (Wi-Fi Alliance), care a certificat echipamentele folosite în dezvoltarea rețelelor tip 802.11.
Diferența dintre cele două organizații este dată de faptul că procesul de certificare WiMAX are înglobat în el criteriile certificării oferite de ETSI (European Telecommunication Standard Institute) pentru rețelele metropolitane (MAN – Metropolitan Area Network). Astfel, echipamentele WiMAX vor putea fi folosite atât în Europa cât și pe continentul american [45].
În ceea ce privește gama de frecvențe, inițial, familia de standarde 802.16 prevedea un interval între 10 și 66 GHz. Avantajul folosirii acestor frecvențe înalte constă în faptul că sunt mai puțin afectate de interferențe și că oferă mai multă bandă de transfer. Dezavantajul este că, pentru a avea comunicație, este necesară existența unei linii vizuale directe între cele două antene – receptor <-> emițător (LoS – Line of Sight).
Datorită acestei limitări, gama de frecvențe a fost redusă. Astfel, prima variantă – IEEE 802.16a – a stabilit un interval între 2 și 11 GHz. Modul de operare putea fi acum și în NLOS (Non LoS), bazat pe reflexii.
Dezvoltările ulterioare au arătat că, în funcție de zonă, frecvența de operare a rețelelor tip WiMAX poate fi stabilită în mod diferit (în intervalul specificat). Astfel, în statele europene, s-a stabilit ca pentru accesul fix fără fir (FWA) să se aloce benzi de frecvență între 3,4GHz și 3,6GHz [45].
Primul standard din acest grup, standardul 802.16 – 2001, a fost aprobat în decembrie 2001 și publicat în 2002. IEEE 802.16 – 2001 oferă specificațiile pentru accesul la rețele fără fir de bandă largă în care comunicația se realizează prin intermediul unor legaturi punct la multipunct și în care modemul radio de la client se conectează la o stație de bază. Frecvența utilizată în acest caz este între 10 și 66 GHz, iar rata de transfer este, în medie, de 70 Mbps cu vârf de sarcină de pană la 268 Mbps.
Oferită ca o alternativă la rețelele cablate de tip CATV sau DSL, rețeaua de tip 802.16 – 2001 are totuși două limitări foarte importante: frecvența de comunicație aparține unui spectru licențiat iar propagarea nu poate avea loc decât în LOS (Line-of-sight) deci cu vedere directă între antena de la utilizator și antena stației de bază. În plus, acest standard specifică folosirea unei singure purtatoare la nivel fizic. Datorită acestor constrângeri, a fost nevoie de câteva modificări ce s-au concretizat în amendamente la standardul inițial [27].
Prima versiune modificată a fost 802.16c.Aceasta avea în vedere asigurarea unei interoperabilități cu sistemele radio deja existente (în gama de frecvențe 10-66 GHz), însă tot în condiție de LOS.Aria maximă de acoperire a fost stabilită la 5 km.
Există, însă, o adăugire foarte importantă în IEEE 802.16c și anume stabilirea unui profil de sistem.Acest element oferă producătorilor un set de reguli privind componentele necesare și cele opționale ce trebuie adăugate în sistem pentru a asigura interoperabilitatea între echipamente provenind de la furnizori diferiți dar aflate în aceeași rețea.
Discuția despre interoperabilitate este una extrem de delicată. Practic, în procesul de certificare impus de forumul WiMAX, verificarea interoperabilității este un pas important și foarte contestat.Tocmai de aceea, IEEE 802.16c s-a dorit a fi un standard independent de tehnologie. Prin urmare, să aibă aplicabilitate fie ca avem tehnologie ATM , frame-relay sau IP.
Cronologic, cea de-a doua variantă modificată a fost IEEE 802.16b (denumită generic și WirelessHUMAN – Wireless High-Speed Unlicensed Metropolitan Area Network) [27]. Cele două caracteristici speciale ale acestei versiuni sunt:modificarea domeniului de frecvențe (intre 5 și 6 GHz) și descrierea QoS (Quality of Service) – pentru a putea permite modele diferite de prioritizare pentru trafic.Această varianta nu mai există.
În Aprilie 2003, apare cea mai importantă dintre variantele standardului 802.16 – și anume 802.16a. Această variantă oferă suport pentru comunicații de tip NLOS (Non Line-of-sight) la frecvențe din gama 2-11GHz (gamă ce include și frecvențe nelicențiate). Aria de acoperire este de până la 50 km iar rata de transfer de până la 75 Mbps.De subliniat este și faptul că, în IEEE 802.16a, este prevazută pentru prima oară și comunicația între clienții aceluiași sector (prin intermediul SB evident).
Proiectul IEEE 802.16d a fost lansat pentru a defini specificațiile de interoperabilitate și pentru a lămuri aspectele neclare din varianta anterioară 802.16a. Totuși, la final, acest proiect s-a dovedit a fi o revizie pentru IEEE 802.16-2001 și a căpătat, ca și denumire finală, IEEE 802.16-2004.
Versiunea ce definește mobilitatea (802.16e) a fost prezentată în anul 2005, fiind urmată de 802.16f (Management Information Base – MIB) pentru definirea comunicației SNMP[65]. La momentul actual, versiunile 802.16g (Management Plane and Procedures), 802.16k (Bridging) și 802.16h (Improved Coexistence Mechanism for License-Exempt Operation) se afla în stadiile finale pentru definitivare iar 802.16i (Mobile MIB) și 802.16j (Mobile Multihop Relay) sunt în faza incipientă (câteva pre-versiuni au fost deja lansate în 2006 si 2007)[65].
Voi încerca să ofer în urmatoarele două capitole specificațiile pentru nivelul fizic și nivelul MAC pentru standardele IEEE 802.16-2004 și IEEE 802.16-2005. Am ales aceste două standarde întrucât sunt cele mai importante din întregul grup, definind atât WiMAX-ul fix cât și WiMAX-ul mobil, iar toate celelate standarde au la bază (pentru aceste două nivele) aceleași specificații ca și cele două versiuni selectate.
NIVELUL FIZIC
Pentru a asigura suportul fizic propagării în LOS și NLOS (Non Line-of-sight), au fost introduse trei specificații dedicate: modulația cu o singură purtătoare (pentru comunicația tip LOS), transformata Fourier rapidă în 256 puncte și transformata Fourier rapidă în 2048 de puncte.Aceste ultime două specificații se referă la comunicații tip multicanal în NLOS și introduc, ca metode de transmisiune, multiplexarea ortogonală cu divizare în frecvență (OFDM – Orthogonal Frequency Division Multiplexing) și OFDMA (Orthogonal Frequency Division Multiple Access).
Pentru cazul OFDM, se folosesc 256 de subpurtătoare pentru a transmite simultan semnale diferite. Subpurtătoarele vecine sunt ortogonale una față de cealaltă pentru a minimiza interferențele inter-canal. De altfel, utilizarea multiplexării cu divizare în frecvență determină și minimizarea interferențelor inter-simbol datorate efectelor multicale. Este evident că și banda de transmisiune este mult mai mare decât în situația folosirii unei singure purtătoare. Prin urmare, ratele de transmisiune în cazul OFDM sunt de până la 72 Mbps per canal la o bandă de 20 MHz cu o eficiență spectrală de 3,6 bps / Hz.
OFDMA reprezintă, de fapt, o tehnică OFDM dar cu 2048 de subpurtătoare. Diferența între OFDM și OFDMA este dată de faptul că OFDMA organizează resursele de timp și frecvență (simboluri și subpurtătoare) în sub-canale alocate per utilizator, permițând accesul multiplu la mediu de transmisiune. Prin urmare, OFDMA operează pe 2 nivele: timp și frecvență.
Formarea subcanalelor de transmisiune se poate realiza în două moduri: prin diversitate sau prin continuitate. În cazul diversității, alegerea subpurtătoarelor pentru a forma un subcanal se face în mod aleator.Pentru cel de-al doilea mod, alegerea subpurtătoarelor se face la rând, creându-se blocuri care mai apoi se constituie ca și un subcanal.
Forumul WiMAX a adoptat OFDM cu 256 de subpurtătoare în toate recomandările și specificațiile sale, motivând această alegere prin lipsa unei sincronizări riguroase între frecvențe și prin calculele reduse datorate transformatei Fourier rapide.Totuși, tehnica OFDMA nu a fost exclusă, urmând ca în dezvoltările ulterioare să fie, în funcție de necesități,adoptată total sau parțial.
Mai mult, în cazul 802.16e-2005 (mobilitate), se consideră o nouă tehnică derivată denumită S-OFDMA (Scalable-OFDMA) – OFDMA scalabil. S-OFDMA folosește transformata Fourier rapidă cu 128, 512, 1024 sau 2048 de subpurtătoare. Varietatea este necesară, în acest caz, pentru a avea scalabilitate și adaptabilitate pentru banda folosită astfel încât durata simbolului și distanța dintre subpurtătoare să rămână constante chiar dacă banda se schimbă. Prin urmare, stația de bază (SB) va forța subcanalul să se adapteze condițiilor de transmisiune specifice fiecărei stații mobile (SM)/SU (stații utilizator) în parte [27].
Trebuie să menționez că diferențele sesizate între specificațiile celor două standarde (802.16-2004 și 802.16-2005) sunt date de cerințele mobilității – și anume managementul puterii și mecanismele de predare-primire ale informațiilor despre utilizatori între SB, pe măsură ce aceștia se deplasează de-a lungul mai multor celule.
Alături de aceste tehnici de transmisiune, voi expune în continuare alte câteva caracteristici generale pentru nivelul fizic în cazul familiei de standarde 802.16, subliniind eventualele diferențe ce apar în cazul mobilității.
Sistemul adaptiv de antene
Acest tip de sistem este unul de tip MIMO (Multiple Input Multiple Output) – Intrări Multiple Ieșiri Multiple – utilizat pentru a crește capacitatea pe canal prin refolosirea frecvențelor în cadrul aceleiași celule.În același timp, necesarul de putere scade prin folosirea unor fascicule de semnal create de antene adaptive și cu posibilitate de redirecționare.
Modulația adaptivă
Atât pentru comunicația de la SB la SM/SU cât și invers, se pot folosi (conform standardelor) următoarele scheme de modulație: BPSK (Binary Phase Shift Keying) sau 2QAM (Quadrature Amplitude Modulation), QPSK (Quadrature Phase Shift Keying) sau 4QAM, 16QAM, 64QAM și 256QAM. De asemenea, în standardele 802.16 sunt descrise și metode de combinație între schemele de modulație menționate anterior și diferite scheme de codare.
Pentru IEEE 802.16-2004, se utilizează fie o codare tip Reed-Solomon alături de un cod convoluțional, fie o codare Turbo.În cazul mobilității (IEEE 802.16e-2005), se mai include în toate aceste scheme și o verificare a parității – LDPC (Low Density Parity Check) – prin intermediul căreia se realizează o codare mai puternică tip 5/6 (5 biți de date sunt codați în 6 biți transmiși) [23].
NIVELUL MAC (MEDIUM ACCESS CONTROL)
Nivelul MAC poate suporta diferite specificații ale nivelului fizic folosind multiplexarea cu diviziune în timp (TDD) sau cu diviziune în frecvență (FDD). Comunicația între SB și SM/SU poate oferi diferite nivele de calitate a serviciului (QoS), asigurând răspunsuri diferite la cererile de bandă venite din partea utilizatorilor.
Suportând atât TDD cât și FDD, familia de standarde IEEE 802.16 a fost creată pentru a permite comunicație la nivel de protocol pentru orice protocol utilizat la momentul actual sau prevăzut pentru a fi dezvoltat în viitor. Această afirmație este valabilă fie că vorbim de IPv4 sau IPv6, VoIP , Ethernet, ATM sau VLANs.
Acest lucru este posibil datorită faptului că IEEE 802.16 împarte nivelul MAC în mai multe subnivele separate cu funcțiuni separate (vezi Fig. 2.1)
Nivel
MAC
Nivel
fizic
Principala funcție a acestui nivel este de a transforma pachetele specifice protocoalelor de nivel superior în pachete specifice serviciilor nivelului MAC al 802.16. De asemenea, subnivelul de convergență este responsabil cu alocarea de bandă, cu asigurarea calității serviciului (QoS) și cu suprimarea antetului pachetelor pentru a crește eficiența transmisiuni radio.
Subnivelul părților comune
Nivelul MAC al IEEE 802.16 este un nivel orientat pe conexiune (connection-oriented). Comunicațiile de tip connectionless („fără conexiune”) – cum ar fi transmisiunile IP spre exemplu – se realizează tot prin intermediul unor comunicații radio de tip connection-oriented. Conform cu standardele IEEE 802.16, fiecare stație utilizator este identificată prin intermediul unei adrese MAC unice. Această adresă este folosită și în etapa de autentificare din procesul de stabilire a unei legături. Fiecare din aceste conexiuni radio stabilite are un identificator ce acționează ca un pointer, ca o referință pentru informațiile transmise și pentru stația care le transmite. Identificatorul poartă denumirea de CID – Connection Identifier (Identificator de conexiune) și este pe 16 biți.
În momentul în care o SM/SU s-a conectat la rețeaua unei SB, se stabilesc automat trei conexiuni de management și cel puțin una de transfer a datelor. Cea de a treia conexiune de management este opțională. Standardul a stabilit ca fiecare conexiune să se adreseze unui anumit nivel de calitate a serviciului.
Prin urmare, prima – și anume conexiunea de bază (basic connection) – va fi folosită pentru a transmite mesajele de management pentru nivelul MAC, cea de-a doua – conexiunea primară (primary management connection) – va fi suportul pentru a transmite mesaje de management tolerante la întărzieri (deci cu prioritate mai mică) și, în sfârșit, cea de-a treia – conexiunea secundară (secondary management connection) va fi utilizată pentru a transmite mesaje de management standard – tip DHCP, SNMP etc.[27].
Trebuie menționat că nivelele de calitate a serviciului pot fi diferite pentru cele două direcții de comunicație – uplink și downlink, iar, în plus față de conexiunile menționate anterior, mai avem trei conexiuni rezervate pentru operațiuni speciale – una pentru procesul de autentificare al SM/SU, iar celelalte două pentru interogări tip multicast și unicast.
În același timp, standardul IEEE 802.16 – 2004 definește un nou concept – cel de service flow (sau fluxul asociat serviciului de comunicație). În momentul în care SB primește o cerere de conectare de la o SM/SU, are loc procesul de autentificare/autorizare în care se stabilește dacă SM are dreptul la serviciu de comunicație. SB va determina apoi dacă există resurse fizice (bandă radio, spre exemplu) pentru a da curs cererii venite de la SM/SU. Dacă răspunsul este unul pozitiv pentru această verificare, SB va asocia cererii de conectare un serviciu (denumit service flow sau fluxul asociat serviciului de comunicație) care va avea parametrii ceruți pentru calitatea serviciului.
Trebuie să remarcăm faptul că, în cazul standardelor IEEE 802.16, adresa MAC (sursă și destinație) nu apare în cadrele MAC transmise. Serviciul fluxului de comunicație are următorii parametrii [8]:
Identificatorul fluxului asociat serviciului – SFID (Service Flow Identifier) – fiecare serviciu are un SFID în funcție de direcția transmisiunii (de la SB la SM/SU sau invers)
CID – identificatorul de conexiune este atașat unui SFID după ce conexiunea este admisă (după autentificare/autorizare)
Parametrii admiși pentru calitatea serviciului – pe baza acestora, SB face rezervarea resurselor necesare. (prima din acest șir va fi bineînteles banda radio)
Parametrii activi pentru calitatea serviciului – reprezintă parametrii efectivi ai unui serviciu activ (atașat unui flux de comunicație activ)
Prin intermediul mesajelor MAC de control, se pot adăuga noi utilizatori, se pot modifica serviciile pentru utilizatorii existenți sau se pot crea tipare noi pentru calitatea serviciului (QoS) prin care să mărim, spre exemplu, banda alocată unui serviciu sau să împărțim resursele rămase nealocate. Toate operațiile se pot face fără a afecta comunicațiile active.
Din punctul de vedere al calității serviciului, standardul IEEE 802.16d („fix”) propune patru tipuri de clase de servicii: [23]
uGS – unsolicited Grant Service – clasă alocată transmisiunilor de voce (necomprimată) precum și pentru transmisiunile tip comutație de circuite (cum ar fi pentru circuitele T1). Această clasă de servicii permite garantarea debitului precum și a întârzierii maxime, dar necesită transmiterea unei cantități constante de date la un interval fix de timp.
rtPS – real-time Polling Service – această clasă se recomandă pentru transmisiunile de streaming (video, audio) precum și pentru alte aplicații în timp real unde banda poate varia în orice moment. Implementarea unui serviciu de acest tip necesită adăugarea unui mecanism prin care SB să poată interoga SM/SU la un interval de timp fix și periodic. Fiecare interogare va solicita SM/SU să specifice lărgimea de bandă necesară până la următoarea interogare.Solicitarea resursei are loc doar pentru direcția de downlink (SB–>SM/SU). În cadrul acestei clase de servicii se garantează întârzierea maximă.
nrtPS – nonreal – time Polling Service – așa cum se poate observa și din denumire, această clasă de servicii se adresează cerințelor specifice aplicațiilor care nu rulează în timp real. SB va interoga SM/SU dar intervalul de timp dintre interogări nu va mai fi atât de rigid, astfel încât, dacă SM/SU nu răspunde după n interogări, SB va „plasa” SM/SU într-un grup de așteptare. În momentul în care SB va interoga tot grupul acesta, toate SM/SU din grup se vor „lupta” pentru a solicita acces la rețea și, implicit, bandă radio. Acest tip de mecanism previne situația în care SM/SU cu trafic redus (și rar) vor irosi resurse valoroase.
BE – Best Effort – această clasă de servicii are prioritatea cea mai mică și nu beneficiază de un mecanism de interogare.SM/SU, care beneficiază de servicii din această clasă vor solicita aleatoriu accesul la mediu. Există șanse să apară coliziuni, care vor fi rezolvate cu ajutorul unui algoritm asemănător celui din Ethernet.
Pentru varianta IEEE 802.16e – 2005 se definește încă o clasă de servicii derivată întrucâtva din cele inițiale. Este vorba de ErtPS – Extended real-time Polling Service – clasă derivată din uGS și rtPS, dar care, spre deosebire de acestea, oferă suport pentru transmisiuni periodice la intervale fixe dar cu dimensiuni variabile pentru pachete. Prin urmare, ErtPS se recomandă pentru VoIP (Voice over IP) întrucât îmbunătățește latența și jitterul și oferă management pentru ratele de transfer.
Subnivelul de securitate
Acest subnivel asigură criptarea, incluzând aici și transferul cheilor de securitate. În cadrul acestui subnivel acționează două protocoale principale:
un protocol de criptare pentru pachetele care circulă în rețea
un protocol de management al cheilor de securitate – PKM (Privacy Key Management) care va facilita schimbul de chei (certificate) folosite și în procesul de autentificare/autorizare al SM/SU.
Protocolul PKM folosește algoritmul RSA, certificatul X509 și alți algoritmi de criptare foarte puternici pentru a securiza schimbul de chei între SM/SU și SB. Practic, cele două protocoale au la bază specificațiile DOCSIS BPI+ care oferă posibilități de criptare foarte puternice utilizabile în IEEE 802.16 MAC.
În cadrul standardului se definesc SA (Security Associations), care reprezintă un grup de identificatori de securitate pentru algoritmii de criptare și pentru cheile de securitate. Acești identificatori pot fi primari (când se alocă în timpul procesului de autentificare / autorizare al SM/SU), statici (alocați pe tot parcursul comunicației SM/SU cu SB) și dinamici (alocați pentru fiecare flux al serviciului de comunicație) [27]. Ultima categorie de identificatori (dinamici) sunt considerați temporari, fiind alocați serviciului doar cât timp acesta este operațional.Conexiunile primară și de bază nu au SA. Conexiunea secundară poate avea, opțional, SA iar conexiunile de transport au obligatoriu SA. În general, un SM/SU folosește două sau trei SA – una pentru conexiunea secundară, iar una sau doua pentru uplink (UL) și downlink (DL) (se pot folosi SA separate pentru UL și DL). SB se asigură ca fiecare SM/SU are acces doar la SA asociat lui.
În același timp, putem separa grupurile de identificatori de securitate în două categorii în funcție de domeniul de utilizare a lor. Astfel, avem SA pentru:
DATE – grupul va conține un identificator de 16 biți, un cifru pentru a proteja datele în timpul comunicației și două chei de criptare a traficului (TEK – Traffic Encryption Key) – una operațională și una rezervată pentru reinițializare – TEKi (initialisation). Cum durata de folosință a cheii curente este limitată, în momentul în care aceasta expiră, cheia TEKi intervine ca și identificator (2 biți) și, cu ajutorul vectorului de inițializare (IV), se generează o nouă cheie operațională. Durata de viață pentru TEKi este între 30 de minute și 7 zile.
AUTENTIFICARE – în acest caz, grupul de identificatori va conține o cheie de autorizare de 60 biți (AK – Authorization Key) și o cheie de identificare pentru AK de 4 biți. Pentru identificarea SM/SU se folosește certificatul X509. Durata de viață pentru un AK este de la 1 la 70 de zile, 7 zile fiind durata cea mai folosită.
În cadrul ambelor grupuri menționate anterior se mai folosește, de asemenea, o cheie de criptare a cheilor schimbate între SB și SM/SU. Aceasta poartă denumirea de KEK (Key Encryption Key), este pe 112 biți și folosește criptarea 3DES. Această cheie este cea care furnizează lista cu SM/SU autorizate și care autentifică cheile de criptare folosite în comunicația dintre SB și SM/SU. KEK folosește, atât pentru UL cât și pentru DL, o funcție de autentificare denumită HMAC (Hash funcțion-based message authentication code). Cu ajutorul acestei funcții, schimbul de mesaje (în special cele de management) este securizat. În plus, SB folosește și SA de autorizare pentru a conFig. SA de date de pe SM/SU.
Managementul puterii
Tot în cadrul nivelului MAC se definesc și scheme de management al puterii pentru IEEE 802.16e – 2005 – deci pentru mobilitate. Asigurarea unei comunicații eficiente în cazul SM necesită managementul puterii consumate (ne referim evident la puterea electrică).
Astfel, pentru o SM identificăm trei stări specifice, față de legătura cu SB:
Starea activă – în care SM comunică permanent cu SB, transferând și primind informații
Starea de repaus (sleep) – starea specifică SM în momentul în care aceasta nu dorește să se asocieze nici unei SB pe măsură ce se află în aria de acoperire a acesteia. Avantajul acestei stări este dat de faptul că se evită procesul complex al „predării – primirii” informației despre utilizator din punctul de vedere al SB. SM aflat în această stare va verifica doar, din când în când, dacă SB a trimis mesaje de broadcast pentru a anunța ca există pachete destinate acestei SM.
Starea de inactivitate (idle) – reprezintă starea în care SM „îngheață”. Practic, SM anunță SB că, pe o anumită perioada, va fi indisponibilă pentru orice fel de transmisiune. Avantajul este evident – minimizarea consumului de energie mai ales când nu mai avem nimic de transmis.
ALTE CONSIDERENTE
Alături de cele două versiuni – IEEE 802.16 – 2004 și IEEE 802.16e – 2005 – care se regăsesc permanent în specificațiile rețelelor tip WiMAX dezvoltate în lume, familia de standarde IEEE 802.16 mai cuprinde și alte versiuni – fie finalizate, fie în lucru – care au fost create (sau inițializate) pentru a acoperi cât mai bine toate nivelele caracteristice dezvoltării unei noi rețele sau interconectării unor rețele deja existente.
În acest scop, în august 2004 a luat ființă grupul de studiu al managementului rețelei ( IEEE 802.16 Network Management Study Group) care, prin intermediul standardului IEEE 802.16f a avut ca scop definirea MIB – Management Information Base – bazei de date cu informațiile de management pentru nivelele MAC și fizic. Amendamentul din 2005 a „adus” practic standardul IEEE 802.16f în versiunea sa finală care oferă un model de referință pentru managementul rețelelor 802.16. Modelul conține mai multe componente: un sistem de management al rețelei (NMS – Network Management System), noduri de management și o bază de date cu datele tuturor serviciilor asociate fluxurilor de date.
Toate informațiile necesare sunt colectate prin intermediul conexiunii secundare, utilizând SNMP (Simple Network Management Protocol) ca și protocol de comunicație. Pentru acest protocol, IEEE 802.16f oferă suport și pentru versiunea 3 (SNMPv3) [8].
Tot în august 2004, IEEE 802.16 a creat – ca parte componentă a grupului IEEE 802.16f – un subgrup – IEEE 802.16g – care are ca scop îmbunătățirea procedurilor specifice IEEE 802.16-2004 și IEEE 802.16e-2005. Toate aceste îmbunătățiri au ca scop final oferirea unei scheme eficiente de comisionare și, apoi, de management pentru toate resursele unei rețele (inclusiv procesele implicate în mobilitate, spectrul etc.) precum și standardizarea interfeței de management atât pentru dispozitivele „atașate” WiMAX-ului fix cât și pentru cel mobil.
IEEE 802.16g definește un nou subnivel – GPCS Generic Packet Convergence Sublayer – subnivel de convergență a pachetelor, care are rolul de a facilita transferul informației de management de la nivelele superioare către cele inferioare, fără a decoda, însă, antetul pachetului. GPCS oferă și o posibilitate de a multiplexa mai multe tipuri de fluxuri (cu protocoale diferite) în interiorul aceleiași conexiuni 802.16. În plus, GCPS nu se vrea ca un înlocuitor pentru nici un alt subnivel tradițional (descris anterior).
IEEE 802.16g a fost aprobat la data de 27 septembrie 2007 de către IEEE și este în curs de publicare.
La nivel de comunicație SB – SB, IEEE a inițiat un grup denumit LE – License-Exempt – Task Group [27] care urmează să definitiveze versiunea IEEE 802.16h (aflată la momentul actual la stadiul de proiect). În cadrul acestei versiuni, se dorește definirea unui mecanism de îmbunătățire a comunicației la nivel MAC prin introducerea următoarelor specificații:
capacitate de negociere – pentru a permite SB să afle caracteristicile SM/SU asociate
numerotare extinsă a canalelor de comunicație – pentru a minimiza interferențele (printr-un management mai bun al canalelor)
capacități de măsurare și raportare – pentru a verifica și raporta nivelul de interferențe și gradul de utilizare al benzii.
Deoarece discutăm de un standard aflat la nivel de proiect, evident că specificațiile se pot modifica sau pot apărea altele (în funcție de cereri).
Alături de aceste versiuni, mai putem regăsi în familia IEEE 802.16 și alte câteva versiuni (IEEE 802.16i, IEEE 802.16k, IEEE 802.16j) aflate în stadii incipiente, care nu permit încă o definire exactă a procedurilor înglobate.
Remarcăm totuși o evoluție continuă a întregului grup IEEE 802.16, evoluție centrată pe cele doua standarde principale – IEEE 802.16-2004 și IEEE 802.16e-2005 – și care ține cont de punctele slabe sau insuficient definite din versiunile de bază.
CAPITOLUL 3
SISTEME WiMAX – ARHITECTURĂ, PROPAGARE, PERFORMANȚE
INTRODUCERE
Odată cu acest capitol, am intrat deja în descrierea detaliată pentru rețelele bazate pe tehnologia WiMAX. Voi grupa caracteristicile prezentate în 3 mari secțiuni: arhitectură, propagare și performanță. Pentru a putea aborda problema securității în cadrul rețelelor fără fir (cu aplicabilitate, mai ales, pentru rețelele WiMAX), am nevoie să detaliez tipurile de arhitectură folosite – astfel încât să pot analiza structurat (din punct de vedere securitate), fiecare zonă.
Apoi, voi grupa sub secțiunea „performanță” detalierea serviciilor fluxului de comunicație, așa cum sunt ele menționate în cadrul standardului IEEE802.16. Voi prezenta modul de alocare a benzii, mecanismele de interogare și rezolvare a coliziunilor, precum și, cel mai important, modul de stabilire a unei conexiuni (SM –> SB). Fiind vorba de o comunicație de nivel 2 (din punct de vedere al stivei OSI), specificațiile pentru securitate se vor regăsi tot la acest nivel. Acesta este și motivul pentru care voi accentua trăsăturile specifice nivelului MAC. Deși secțiunea „propagare” nu are un subcapitol dedicat, trebuie să menționez că detaliile aferente se regăsesc atât la partea de arhitectură, cât și la partea de performanță (fiind menționate ca atare). Acesta este și motivul pentru care nu am dorit să omit din titlul capitolului această secțiune.
Detaliile oferite în cadrul acestui capitol sunt extrase din literatura de specialitate (vezi [4], [8], [15], [21], [27], [45], [53], [54], [65], [66], [68], cu mențiunea că sunt prezentate structurat pentru a servi scopului final – definirea unui plan pentru securitatea rețelelor WiMAX (și definirea protocolului de taxare).
ARHITECTURA SISTEMELOR WIMAX
Trebuie menționat, încă de la început, că, la momentul redactării aceste lucrări, există două tipuri de arhitecturi utilizate în cadrul sistemelor WiMAX: PMP (Point to Multipoint) – Punct la Multipunct și MESH – tip năvod (sau plasă). În plus, cele două tipuri de arhitecturi au la bază mecanisme de împărțirea mediului de transmisiune (media sharing).
PMP – Punct la Multipunct
Un exemplu de arhitectură punct la multipunct se poate regăsi în Fig. 3.1.
În cadrul acestui tip de arhitectură, legătura de la SB la SM/SU (downlink) funcționează după principiul punct la multipunct. Într-un anumit sector al SB, pentru o anumită frecvență, toate SM/SU primesc aceeași transmisiune. SB este singurul emițător pentru această direcție. Deci poate transmite fără a avea nevoie de coordonare cu alte stații de bază. Prin urmare, transmisiunea SB poate fi una de tip broadcast sectorial. În același timp, SB poate transmite și pentru un grup de SM/SU, în acest caz transmisiunea este una de tip multicast.
În cazul în care nu se specifică în mod explicit (prin intermediul DL-MAP) că un anumit cadru este pentru un anumit SM/SU, toate SM/SU pot „asculta” transmisiunea. SM/SU verifică CID din cadrul fiecărui pachet MAC-PDU (Protocol Data Unit) și reține doar PDU adresate ei.
Pentru legătura de la SM/SU la SB (uplink), transmisiunea se supune regulilor specifice clasei de servicii asociate. Cum SM/SU primește acces la mediu de transmisiune pe baza cererilor adresate către SB, clasa de servicii alocată devine extrem de importantă. O SM/SU poate primi dreptul de a transmite foarte des în cazul în care traficul „transportat” este unul marcat cu prioritate mare (voce, spre exemplu).
În fiecare sector, controlul SM/SU se face prin intermediul unor protocoale de transmisiune ce lucrează la nivel MAC. În cadrul acestui nivel, transmisiunile sunt de tip connection-oriented (orientate pe conexiune) astfel încât fiecare comunicație de date se asociază unei conexiuni. Serviciile pentru fluxurile de comunicație sunt configurate pentru fiecare SM/SU în parte și definesc parametrii legați de calitatea serviciului pentru PDU care se transmit prin fluxul asociat.
De fapt, conceptul de flux asociat serviciului de comunicație (service flow) reprezintă cheia tuturor operațiilor ce se desfășoară la nivel MAC. Prin intermediul acestui concept se pot defini mecanisme de management pentru QoS atât pentru downlink cât și pentru uplink.[23] SB este cea care decide accesul la mediu pentru fiecare SM/SU în parte. Deși, la nivel de SM/SU cererile de acces la mediu (precum și pentru necesarul de bandă de transmisiune) se fac pentru fiecare conexiune în parte (conexiune identificată prin identificatorul de conexiune CID), SB tratează toate aceste cereri per SM/SU ca un tot unitar. Prin urmare, are loc, la nivel de SB, o „agregare” a tuturor cererilor venite din partea unui SM/SU.
De asemenea, pentru fiecare legătură între SB și SM/SU avem cele trei funcții de management de bază – adăugarea unei noi conexiuni, modificarea uneia deja existente sau ștergerea totală a conexiunii. În acest ultim caz, trebuie menționat că și SB și SM/SU au implementate mecanisme specifice pentru a stimula închiderea unei conexiuni în momentul în care nu mai este nimic de transmis, tocmai pentru a elibera mediul de transmisiune.
Figura 3.1 Arhitectura 802.16 tip PMP
Mesh – arhitectura tip năvod
Un exemplu de astfel de arhitectură este prezentat în Fig. 3.2
În cadrul arhitecturii tip 802.16 de tip mesh sunt specificate două tipuri de protocoale de programare a accesului la mediu și de asignare a benzii cerute de fiecare SM/SU în parte. Aceste două tipuri sunt – protocoale centralizate și descentralizate [66].
Prima categorie – protocoalele centralizate sunt cele folosite de stațiile de bază (denumite și stații coordonatoare ale rețelei) pentru a stabili o schemă clară de programare pentru toată rețeaua. În opoziție, protocoalele descentralizate sunt folosite pentru a negocia asignarea resurselor între legăturile pereche dintre două noduri adiacente (routere sau stații de bază). În plus, dacă protocoalele centralizate sunt utilizate și la stabilirea unor mecanisme de asigurare a calității serviciului (între două puncte terminale), cele descentralizate nu au în vedere deloc QoS pentru legătura între două noduri adiacente.
Ca și la arhitectura tip PMP, și în acest caz protocoalele utilizate sunt connection-oriented tocmai pentru a îmbunătăți eficiența întregii rețele mesh.
Ca și exemplu pentru această afirmație putem aduce modul de identificare al unei transmisiuni asociate unui anumite conexiuni fizice – este vorba de o combinație între identificatorul de rețea de 8 biți, identificatorul specific unei rețele mesh de 16 biți și identificatorul legăturii fizice (tot de 8 biți și acesta). Putem constata, astfel, foarte ușor diferența față de rețelele 802.11, unde, pentru o astfel de identificare, se foloseau adresele Ethernet pereche de 48 de biți.
Prin urmare, referindu-mă la caracteristicile protocoalelor orientate pe conexiune, trebuie să remarc faptul că, pentru arhitectura 802.16 tip mesh, nu mai regăsim capabilitățile specifice nivelului 2 (așa cum era cazul pentru rețelele 802.11).
În cazul 802.16, subnivelul de convergență este cel care asigură multiplexarea pachetelor IP în cadrul unei conexiuni. Apoi, într-o arhitectura tip năvod (mesh) 802.16 nodurile rețelei trebuie să funcționeze permanent. Dacă în rețelele tip 802.11, durata de funcționare era unul din factorii de bază în asigurarea securității (exista o cheie specială de sincronizare între două noduri adiacente), pentru 802.16 se va utiliza un protocol special de distribuție a cheilor de securitate, un protocol inițiat de stația de bază [66].
Faptul că, la nivelul arhitecturii 802.16 tip mesh se utilizează mecanisme (protocoale) centralizate (pe zone) pentru programarea resurselor, determină o estompare a graniței între nivelul MAC și nivelul IP pentru nodurile centrale ale rețelei. Astfel, funcțiile care își regăsesc caracteristicile în ambele nivele (așa numitele funcții inter-nivel) vor ajuta la asigurarea unei calități a serviciului mai bună (așa cum voi arăta în secțiunile următoare) precum și la o funcționare mai corectă a întregii rețele.
Figura 3.2 Arhitectura 802.16 tip mesh
PERFORMANȚele SISTEMELOR WiMAX
În cadrul acestui subcapitol, voi prezenta schemele generale de provizionare ale serviciilor în cadrul unei rețele 802.16 precum și categoriile de parametrii asociați calității serviciului.
De ce este nevoie de o astfel de prezentare într-o lucrare dedicată securității rețelei?
În primul rând, orice breșă de securitate identificată (alături de măsura reparatorie) contribuie la îmbunătățirea funcționării rețelei și la creșterea randamentului ei aducând, implicit, o creștere a calității comunicației așa cum este ea resimțită de către utilizator. Apoi, aplicarea unor tipare pentru asigurarea QoS poate determina apariția unor potențiale vulnerabilități care nu se manifestă decât prin intermediul acestor scheme de provizionare.
Așadar, între asigurarea securității unei rețele și asigurarea calității serviciului există o legătură foarte strânsă, și, prin urmare, trebuie expuse (și pentru sistemele WiMAX) caracteristicile importante legate de performanța acestor sisteme.
Servicii și parametrii
Fiecare conexiune realizată între SM/SU și SB este asociată cu un flux asociat serviciului de comunicație (așa numitul service flow de care deja am mai discutat). Fiecare din aceste servicii conține o listă de parametrii QoS care cuantifică, practic, comportarea serviciului la recepționarea unor pachete de date. Parametrii QoS sunt controlați cu ajutorul unor funcții dinamice specifice serviciilor – funcția de adăugare a unor servicii, funcția de modificare a serviciului, funcția de ștergere etc..
Așa cum am menționat, pentru standardul 802.16e sunt suportate 5 tipuri de servicii: unsolicited grant (uGS), real-time polling service (rtPS), extended Real-time Polling Service (ertPS), nonreal-time polling service (nrtPS) și best-effort (BE). Întrucât am discutat deja, pentru fiecare categorie în parte, caracteristicile importante (vezi capitolul dedicat subnivelului părților comune), mă voi referi în continuare la modul de alocare a benzii precum și la mecanismele de control al cererilor din partea SM/SU pentru SB.
Modul de alocare a benzii pentru SM/SU
În momentul în care un SM/SU „intră” în rețea, în timpul procesului de autentificare, îi sunt asignate 3 CID-uri [29] dedicate numai schimbului de mesaje de control. Practic, cu ajutorul acestor mesaje se va realiza și modificarea benzii alocate fiecărei conexiuni de date dintre SM/SU și SB în funcție de necesități și de cereri.
Pentru serviciile din categoria uGS, schimbarea benzii alocate nu este necesară, banda rămânând constantă pe tot parcursul comunicației (aceasta reprezentând una dintre caracteristicile acestui tip de serviciu).
Pentru toate celelalte categorii, banda alocată se modifică în funcție de cereri dar și în funcție de prioritate. Un flux cu un serviciu din categoria rtPS va fi „deservit” prioritar față de unul din categoria BE.
În momentul în care un SM/SU cere accesul la resurse (deci o anumită bandă pentru a transmite informația), va trimite un mesaj către SB care va conține detaliile cererii. Caracteristicile QoS ale serviciului sunt fixate din momentul în care se stabilește conexiunea între SM/SU și SB și se realizează autentificarea/autorizarea.
Cererile pot fi incluse, prin urmare, într-un mesaj dedicat independent, dar se pot insera și într-un mesaj de răspuns la interogarea din partea SB. Cum profilul legături de uplink (SM/SU către SB) se poate schimba într-un mod dinamic, este recomandat ca toate cererile de bandă să conțină numărul de biți necesari SM/SU pentru a transmite antetul MAC și informația utilă, însă fără antetul specific nivelului fizic. Cererile de bandă pot fi de incrementare sau de agregare.
În momentul în care SB primește o cerere de incrementare a benzii, va adăuga cantitatea de bandă cerută adițional la banda deja alocată anterior. Când SB primește o cerere de agregare de bandă, va înlocui cantitatea de bandă alocată până la cel moment cu noua cantitate cerută. Pentru ca alocarea resurselor să se realizeze cât mai bine, este necesar ca SM/SU să folosească, periodic, cereri de agregare (alături de cele de incrementare). Perioada de trimitere a acestor cereri se decide în funcție de parametrii QoS ai serviciului și de calitatea legăturii.
În toate cazurile, însă, pe baza informațiilor primite de la SB, SM/SU poate decide fie repetarea cererii (în cazul în care resursele primite nu sunt suficiente) fie renunță la a mai transmite pachetele (discard de pachete) – pe baza faptului că nu are acces la resurse.
Trebuie să ținem cont de faptul că toate aceste cereri de bandă nu sunt transmise aleator (cel puțin nu pentru categoriile de servicii prioritate – rtPS și nrtPS). Ele sunt controlate cu ajutorul mecanismelor de interogare [29] aplicate prin intermediul SB. Singura excepție este dată de clasa tip BE în care modul de trimitere a cererilor se bazează pe „competiție” – primul SM/SU care apucă să trimită cererea va fi și primul servit. Se aplică, practic, un algoritm recursiv pentru rezolvarea eventualelor conflicte – algoritm pe care îl vom explica în cele ce urmează. Dar, mai întâi, să vedem ce presupune interogarea unei SM/SU de către SB.
Interogarea și mecanismele de interogare
Interogarea reprezintă procesul prin care SB alocă SM/SU o anumită bandă pentru a permite transmiterea cererilor de bandă. Alocarea acestei benzi se poate face pentru o singură SM/SU sau pentru un întreg grup. Deși interogarea, precum și alocarea benzii necesare au loc la nivel de SM/SU (sau grup de SM/SU), cererile de bandă se realizează pentru fiecare conexiune în parte.
Când o SM/SU este interogată individual, vorbim de așa numitul mecanism de interogare unicast.[66] Prin intermediul acestuia, SM/SU îi este alocată, în cadrul UL-MAP, o bandă suficientă pentru a răspunde cu o cerere de bandă necesară transmisiunii. O SM/SU care nu are decât conexiuni tip uGS sau nu necesită bandă la un moment dat, nu va fi interogată individual decât dacă bitul de interogare (PM – „poll-me”) din antetul pachetului transmis prin intermediul conexiunii tip uGS va avea valoarea 1. Acest mod de lucru reduce simțitor resursele pierdute (timp, bandă) prin interogarea individuală a unei SM/SU care nu necesită alocare de bandă.
În cazul în care banda disponibilă pentru interogare este insuficientă, se va aplica un mecanism de interogare multicast sau unul broadcast [66]. În acest mod, se realizează interogarea unui grup de SM/SU inactive, după care oricare din aceste SM/SU poate trimite cerere de bandă. Pentru a minimiza eventualele coliziuni, vor trimite cereri numai SM/SU care au semnalat că au nevoie de bandă. Totuși, există posibilitatea de a avea coliziuni, existând șansa ca mai multe SM/SU să trimită cereri de bandă folosind resursa alocată per grup în acest scop. În acel moment, se va folosi algoritmul de rezolvare a coliziunilor de care vorbeam anterior – și anume, un algoritm recursiv.
Rezolvarea coliziunilor
Principala metodă de rezolvare a coliziunilor are la bază algoritmul de recursivitate binară exponențială care conține o fereastră inițială de recursivitate și o fereastră maximă de recursivitate (dictată de SB).
În momentul în care SM/SU are de trimis o informație si vrea să beneficieze de rezultatele acestui algoritm, va avea valoarea ferestrei interne de recursivitate egală cu valoarea maximă a ferestrei controlate de SB. Trebuie menționat că există o diferență între valoarea maximă a ferestrei de recursivitate (dictată de SB și care rămâne nemodificată pe tot parcursul procesului) și valoarea maximă a ferestrei utilizate la un anumit moment în cadrul algoritmului (controlată de SB). Practic, SM/SU va „intra” în tot acest proces recursiv preluând ultima valoare a ferestrei de recursivitate (care se modifică în funcție de numărul de posibile surse de coliziune) și adoptând pentru fereastra internă această valoare.
SM/SU va alege apoi aleator o valoare din interiorul ferestrei interne de recursivitate. Aceasta valoare va reprezenta numărul de cicluri de transmisiune pe care SM/SU îl va aștepta înainte de a încerca să-și transmită cererea. Un ciclu de transmisiune este egal cu numărul de interogări (individuale și/sau în grup) pe care le suportă SM/SU.
Dacă în momentul în care SM/SU dorește să transmită, nu găsește resurse libere (vorbim de cazul unei arhitecturi distribuite în care banda alocată de către SB pentru transmiterea cererii este deja ocupată), SM/SU va intra iar în procesul de așteptare recursivă dar fereastra internă de recursivitate își va dubla valoarea. Totuși, această valoare nu are voie să depășească valoarea maximă a ferestrei dictată de SB.
SM/SU va alege apoi o nouă valoare aleatoare din cadrul ferestrei interne și întregul proces se va repeta. Dacă această repetare depășește valoarea admisă (adică dublarea valorii ferestrei de recursivitate va însemna depășirea valorii maxime admise), va avea loc o renunțare la pachete (se va face dropping de pachete).
Așa cum am menționat, dreptul de a transmite îl poate primi o SM/SU individuală sau un grup de SM/SU. Acest grup poate include fie toate SM/SU care doresc să se asocieze sectorului (celulei) respective fie toate SM/SU deja înregistrate aparținând de acel sector.
Stabilirea unei conexiuni și menținerea ei
Din punctul meu de vedere, mecanismul de stabilire a unei legături între SB și un SM/SU este foarte important în analiza eventualelor breșe de securitate. Orice autentificare greșită (a unei stații pirat) poate duce la compromiterea întregului sistem. De aceea, voi prezenta în acest punct al tezei, câteva aspecte generale, urmând ca în capitolele dedicate efectiv securității, să tratez acest proces mult mai pe larg.
Pentru o SM/SU nouă care dorește să se înregistreze la SB, pașii sunt următorii:
Scanarea frecvențelor canalului de downlink și sincronizarea cu SB
Obținerea parametrilor de transmisiune (din mesajele descriptive ale canalului de uplink)
Negocierea parametrilor de bază
Autorizarea SM/SU și realizarea schimbului de chei (de autentificare, de transmisiune etc.)
Înregistrarea SM/SU
Stabilirea conectivității IP (utilizator din spatele SM/SU – utilizator din rețeaua SB)
Sincronizarea mărcii de timp între SM/SU și SB
Transferul parametrilor operaționali (utilizați pentru transferul de date)
Stabilirea conexiunii
Etapele f), g) și h) sunt opționale pentru SM/SU. Vor fi implementate numai dacă SM/SU a cerut specific acest lucru prin intermediul mesajului inițial de cerere de înregistrare (REG-REQ – Registration Request).
Conform standardului IEEE 802.16, fiecare SM/SU ar trebui să conțină (direct de la producător):
adresă MAC de 48 de biți folosită pentru a identifica într-un mod unic SM/SU
parametrii de securitate folosiți de diferite tipuri de servere pentru a autentifica atât SM/SU în cadrul acestor servere cât și răspunsul de la aceste servere către SM/SU.
Odată stabilită legătura, SM/SU și SB vor schimba mesaje care vor ajuta la menținerea unei conexiuni de calitate între ele, din punct de vedere radio. Cele două direcții – uplink și downlink – vor fi tratate separat (mesaje separate, parametrii separați etc.). Pentru fiecare canal în parte (fie de uplink, fie de downlink), există așa numiți descriptori de canal [66] care sunt transmiși la intervale regulate. Fiecare descriptor conține – printre altele – parametrii transmisiunii fizice (modulație, SNR etc.) precum și un bit ce semnalează eventualele modificări de configurație. Acest bit va rămâne neschimbat atât timp cât descriptorul de canal nu va suferi modificări. Profilele de servicii utilizate la recepție și la emisie vor rămâne neschimbate (ele fiind conținute în descriptorul de canal) și vor fi asociate cu bitul de configurație (pe care l-am menționat anterior). Orice schimbare a valorii acestui bit va determina și schimbarea acestor profile. Prin urmare, transmiterea acestor descriptori de canal este extrem de importantă pentru a asigura o funcționare bună a legăturii radio.
Revenind puțin la metodele de interogare (din partea SB catre SM/SU), trebuie spus că SB își va crea un grup de interogare de tip multicast.
Adăugarea unei noi SM/SU la acest grup se va face prin intermediul unui schimb de mesaje specifice – MCA-REQ (Multicast Channel Adition – Request) de la SB și MCA-RSP (Multicast Channel Adition – Response) de la SM/SU.
Grupul de multicast va avea asociat, la rândul lui, un serviciu specific pentru downlink, iar CID folosit pentru această conexiune tip multicast va fi același pentru toate SM/SU. SM/SU nu trebuie să „știe” că primesc informații prin intermediul unei conexiuni multicast. Datele transmise prin intermediul acestei conexiuni vor fi procesate doar de SM/SU care regăsesc în pachete MAC-ul asociat lor. Toate detaliile legate de această conexiune tip multicast (pentru downlink) se vor regăsi într-un descriptor de canal specific.
Din punct de vedere al securității, dacă ne dorim criptarea acestei transmisiuni (multicast pe downlink), fiecare dintre SM/SU din grupul către care se face transmiunea va trebui să aibă un SA (un grup de identificatori de securitate) adițional, care va permite criptarea utilizând alte chei independente de cele pe baza cărora se face criptare pentru alte mesaje schimbate între SB și SM/SU.
Calitatea serviciului
În cadrul unui capitol legat de performanțele sistemului WiMAX nu puteau lipsi (măcar) câteva considerații generale legate de calitatea serviciului. Pentru standardul IEEE 802.16 există câteva concepte legate de calitatea serviciului (QoS) bine definite.
Aceste concepte ajută la descrierea unor operații cum ar fi stabilirea dinamică a unui serviciu de flux, aplicarea modelului de activare în două etape a calității serviciului pentru un anumit serviciu etc. Voi detalia, pe parcursul acestui subcapitol, aceste operații precum și mecanismele de stabilire a schemelor de QoS pentru un serviciu.
În primul rând, pentru a putea asigura calitatea serviciului, toate pachetele ce sosesc de pe o anumită interfață (cu un anumit MAC) vor fi asociate unui serviciu de comunicație identificat prin intermediul unui CID și având un flux asociat. Fluxul este unidirecțional astfel încât vom avea servicii diferite pentru uplink și downlink.
Putem afirma, deci, că un flux asociat serviciului de comunicație (service flow) reprezintă un serviciu ce asigură transportul unidirecțional al pachetelor [66] fie că este vorba de direcția SM/SU către SB (uplink) fie că este vorba de downlink (SB către SM/SU). Serviciul acționează la nivel MAC și are un set de parametrii QoS asociat. Acest set include parametrii ca latență, jitter sau bandă garantată. Trebuie menționat că fiecare flux al serviciului de comunicație este identificat prin intermediul unui identificator de flux asociat serviciului – SFID (Service Flow Identifier) – pe 32 de biți. Fluxurile active mai au în plus și un CID pe 16 biți. Acest lucru survine faptului că, deși pot fi declarate, anumite fluxuri pot să nu fie active întrucât nici legătura fizică asociată nu este activă (vezi cele 3 stări ale SM descrise anterior).
Pentru a gestiona cât mai eficient resursele rețelei, standardul 802.16 a adoptat un model de activare în două etape a calității serviciului. Aceasta presupune definirea unui flux asociat serviciului (în prima etapă) și activarea lui (în cea de a doua etapă), cu alocarea resurselor doar în momentul activării. Se evită, astfel, ocuparea nejustificată a unor resurse, mai ales când nu există trafic asociat.
Pe baza acestui model, se poate realiza o ierarhie a fluxurilor (asociate serviciilor de comunicație):
Fluxuri provizionate (definite) – servicii doar declarate care vor trebui să fie admise și, eventual, activate. Au totuși SFID alocate din partea rețelei
Fluxuri acceptate (admise) – se bazează pe modelul preluat din telefonie, unde apelurile sunt mai întâi acceptate și abia apoi, după ce se încheie negocierea „end-to-end”, sunt activate. În acest mod, resursele rețelei sunt nefolosite până în momentul în care conexiunea a fost stabilită (fără erori de înregistrare, autentificare etc.).
Fluxuri active – pentru aceste servicii, există un parametru (denumit QoSParamSet) diferit de zero. Astfel, trecerea de la un flux admis la unul activ se realizează prin setarea acestui parametru cu o valoare nenulă. Practic, activarea fluxului reprezintă ultima etapă a modelului de activare a calității serviciului pentru un serviciu de comunicație.
Standardul IEEE 802.16 suportă schimbări dinamice ale unui flux asociat serviciului, permițând renegocierea parametrilor. Prin urmare, fluxurile asociate serviciilor pot fi adăugate, modificate și șterse. Toate aceste operații se vor realiza prin intermediul unor mesaje MAC de management denumite DSA – Dynamic Service Addition, DSC – Dynamic Service Change și DSD – Dynamic Service Delete. Așa cum este de așteptat, mesajul DSA determină crearea unui nou flux asociat serviciului, DSC – modificarea unui flux asociat unui serviciu existent iar DSD duce la suprimarea unui flux asociat unui serviciu. În Fig. 3.3 sunt reprezentate grafic aceste operații.
Figura 3.3 Operațiile specifice pentru un flux asociat serviciului de comunicație
O cerere de flux asociat serviciului poate fi inițiată atât de SB cât și de SM/SU. În cazul când cererea este inițiată de SM/SU, un mesaj DSA-REQ (request), însoțit de o referință a fluxului asociat serviciului (și un set de parametrii QoS asociați), sunt trimise către SB din partea SM/SU.
Când SB primește mesajul, trimite un mesaj DSA-RVD (received) pentru a informa SM/SU de recepționarea mesajului de cerere. Apoi, SB va trimite un mesaj DSA-RSP (response) pentru a indica dacă refuză sau acceptă cererea. SM/SU va trimite un mesaj confirmare a primirii acestui răspuns – mesajul DSA-ACK (acknowledge). Tot acest schimb de mesaje este prezentat și în Fig. 3.4 a).
Pentru situația în care SB va iniția cererea, procesul este similar, exceptând mesajul DSA-RVD de care nu mai este nevoie. Schimbul de mesaje este ilustrat în Fig. 3.4 b).
Figura 3.4 Adăugarea unui flux asociat serviciului: a) dinspre SM/SU ; b) dinspre SB
Pentru toate celelalte operații (modificare, ștergere), procesele au la bază același mod de lucru – cerere, răspuns, confirmare (așa numitul protocol 3-way handshaking).
Totuși, de obicei, există deja tipare pentru fluxurile asociate serviciilor, tipare ce includ anumiți parametrii de QoS (bandă, prioritate etc.) și care se regăsesc în fluxurile active finale. Evident că deosebirea va fi dată tocmai de elementele de identificare specifice fiecărei SM/SU (adresă MAC, spre exemplu), astfel încât, deși parametrii QoS pot fi aceeași, fluxurile vor fi întotdeauna diferite. Ținând cont și de separarea prin intermediul CID, o astfel de situație este normală, permițând din partea SB un management mult mai ușor al fluxurilor asociate serviciilor precum și o implementare mai sigură (din punct de vedere al securității rețelei) pentru un anumit SM/SU.
Nivelul MAC și funcțiile lui
Deși am prezentat în capitolul despre arhitectura rețelei fără fir structura generală a nivelului MAC, în cadrul acestui sub-capitol voi detalia caracteristicile și funcțiile acestui nivel, cu aplicabilitate pentru cele două tipuri de rețele – năvod (mesh) și punct la multipunct. Toate aceste detalii sunt foarte importante din punct de vedere al securității rețelei. Formatul mesajului MAC-PDU, descrierea câmpurilor din interiorul acestuia, mecanismele de transmisiune – toate vor ajuta la identificarea eventualelor breșe de securitate, precum și la găsirea soluțiilor de rezolvare pentru acestea.
Caracteristicile nivelului MAC pentru rețele WiMAX tip „punct la multipunct”
Așa cum am menționat deja, în momentul în care producătorul va furniza SM/SU, acesta va avea o adresă MAC unică pe 48 de biți. Această adresă va identifica, în mod unic, fiecare SM/SU și va fi folosită atât în procesele inițiale – de înregistrare, autentificare etc. cât și în transmisiunile ulterioare (de date sau informații de management).
În cadrul acestor transmisiuni se folosesc pachete care poartă denumirea de MAC-PDU – Media Access Control Packet Data Unit (MPDU). De fapt, MAC-PDU reprezintă o unitate de bază creată la nivel MAC, folosită pentru a transmite informația către nivelul fizic.
Orice pachet (folosit în telecomunicații) este constituit dintr-un antet (header) și o informație utilă (payload). Pentru MAC-PDU, antetul este specific nivelului MAC și are o lungime fixă. Informația utilă (payload-ul) poate consta în zero sau mai multe sub-pachete, constituite fiecare, la rândul lor, dintr-un antet și zero sau mai multe unități de serviciu – SDU – Service Data Unit sau fragmente. Lungimea informației utile poate varia. Prin urmare, un MAC-PDU poate varia ca și lungime. Această caracteristică permite nivelului MAC să creeze tunele de transport pentru diferite tipuri de trafic fără a știi neapărat ce tip de trafic va transporta.
Există două tipuri de antete pentru nivelul MAC. Primul dintre ele este un tip de antet generic MAC conținut în fiecare pachet MAC-PDU care va transmite fie mesaje de management specifice nivelului MAC, fie date specifice subnivelului de convergență. Cel de-al doilea tip este antetul specific pachetelor prin care se realizează cererile de bandă (pe care le-am descris in sub-capitolul anterior).
În același timp, antetele regăsite în sub-pachetele componente ale unui MAC-PDU (și care urmează, în alcătuirea pachetului, imediat antetului principal), pot fi de cinci tipuri.
Primul tip (care, de obicei, se regăsește ca și primul antet al primului sub-pachet dacă acesta există) este antetul specific rețelei tip mesh (năvod). El va fi urmat de antetul specific sub-pachetelor de management al alocării benzii, de antetul specific răspunsului la o cerere de bandă, de antetul pentru sub-pachetele în care se specifică alocarea benzii și, în final, de antetul pentru fragmentare sau concatenare a informației (nu amândouă în același pachet). Evident că toată această înșiruire poate fi și exclusivistă în sensul în care un anumit sub-pachet va fi sau nu transmis la un moment dat.
Mesajele de management ale nivelului MAC vor fi incluse în câmpul de informație utilă al MAC-PDU. Toate aceste mesaje au la început un câmp denumit Management Message Type care arată tipul mesajului și ajută și la identificarea mult mai ușoară a unui mesaj de management.
Fragmentarea și concatenarea mesajelor este, așa cum am menționat, prezentă în cadrul transmisiunilor. Astfel, mai multe MAC-PDU pot fi concatenate într-o singură unitate de transmisiune, fiecare fiind mai apoi identificate de receptor prin intermediul CID. În cazul fragmentării, un MAC-SDU va fi divizat în mai multe MAC-PDU. Acest proces este folosit pentru a permite o utilizare cât mai eficientă a resurselor fizice disponibile în concordanță, însă, cu cerințele de calitate a serviciului. Fragmentare poate fi inițiată atât de SB cât și de SM/SU. Trebuie să spunem că procesele de fragmentare și concatenare sunt menționate în standard ca fiind obligatorii pentru orice echipament care vrea să respecte acest standard.
În ceea ce privește (re)transmiterea MAC-PDU, există mai multe tehnici de transmisiune. Sunt suportate atât tehnici full-duplex, cât și half-duplex. În plus, mai apare o diferență în funcție de tipul de sistem utilizat – FDD sau TDD.
Pentru cazul FDD, canalele de uplink și downlink folosesc frecvențe diferite și cadre de durată fixă pentru transmiterea informației. Acest lucru facilitează utilizarea de modulații diferite pentru cele două canale, iar utilizarea unor cadre de durată fixă simplifică mult algoritmul de alocare a benzii. În cazul FDD, SB este doar full-duplex în sensul că poate transmite și recepționa în același timp, în timp ce SM/SU pot fi full sau half duplex.
În general, aproape toate echipamentele WiMAX furnizate la momentul actual au, ca și opțiune, posibilitatea de a alege modul în care va lucra SM/SU – full sau half-duplex În cazul în care se optează pentru o funcționare half-duplex, SB (care controlează modul de alocare a benzii) nu va mai aloca bandă pentru uplink pentru un SM/SU de la care se așteaptă să recepționeze date (pe downlink). [29] Un SM/SU care lucrează în mod full-duplex este capabil să „asculte” permanent canalul de downlink, în timp ce un SM/SU în mod half-duplex poate „asculta” canalul de downlink doar dacă nu transmite date pe canalul de uplink.
Situația se schimbă pentru transmisiunile TDD. În acest caz, canalele de downlink și de uplink folosesc aceeași frecvență de transmisiune, însă transmisiunile în sine au loc la momente diferite de timp. Un cadru TDD conține atât un subcadru de downlink cât și unul de uplink și are o durată fixă.
În ceea ce privește alocarea benzii, trebuie menționat de la început că, pentru TDD, împărțirea în cadre este adaptivă din punctul de vedere al benzii alocate pentru downlink sau pentru uplink. Mai mult, cadrul este împărțit într-un număr întreg de părți (Physical Slots – PS) care ajută algoritmul de împărțire a benzii. Împărțirea între downlink și uplink este controlată de nivelele superioare ale sistemului prin intermediul unui parametru de sistem dedicat.
Caracteristicile nivelului MAC pentru rețele WiMAX tip „năvod” (mesh)
Deși topologia tip „năvod”(mesh) are caracteristicile sale distincte, câteva dintre funcțiile prezentate anterior pentru „punct la multipunct” sunt valabile și în acest caz. Diferențele apărute se datorează, în principal, modului diferit în care este structurat acest tip de rețea, precum și necesității de comunicare totală între toate nodurile rețelei.
Astfel, pentru adresarea și identificarea fiecărui nod de rețea se folosește, pentru început, un identificator de 8 biți pentru conexiune. Fiecare nod de rețea va atribui fiecărei legături stabilite cu vecinii săi un astfel de identificator. Va exista, în fiecare nod, o tabelă virtuală în care vor fi menținuți acești identificatori. Tabela va suporta toate operațiile necesare acestui tip de comunicație – pe măsură ce topologia se va modifica, informațiile din tabelă vor suferi și ele modificări. Va apărea o informație nouă dacă apare un nou link, se va modifica una existentă dacă un link dispare (un nod dispare) sau dacă se mai creează o conexiune între noduri existente în rețea. Identificatorul de link se transmite ca parte a CID (identificatorul de conexiune), în antetul generic al cadrului MAC dintr-un mesaj unicast.
În ceea ce privește adresarea unui nod de rețea, aceasta se realizează cu ajutorul rezultatului obținut din combinarea unui identificator de rețea pe 16 biți și un identificator de conexiune (CID) tot pe 16 biți. Rezultatul va fi, evident, tot un parametru tip identificator, care va ajuta și stabilirea destinației unei anumite transmisiuni. [29]
Identificatorul de rețea este unic pentru fiecare nod în parte și este obținut în timpul procesului de autentificare, fiind asignat de SB. Pentru identificatorul de conexiune avem un mod de calcul dinamic, care depinde de tipul canalului pe care are loc transmisiunea.
Pentru canalul de date, CID este o combinație între link ID (identificatorul de conexiune pe 8 biți) și un parametru pe 8 biți care conține specificațiile de calitate a serviciului (QoS) ale link-ului respectiv.
Pentru canalul de bază (pe care se transmit mesajele de administrare) precum și pentru canalul de broadcasting, CID-ul va fi o combinație între identificatorul de conexiune și 0xFF (care înseamnă, de fapt, orice identificator de conexiune).
În cazul algoritmului de alocare a benzii, situația este diferită față de cea prezentată la rețeaua „punct la multipunct”.
În figura 3.2, am figurat o rețea tip „mesh” în care SM nu pot comunica între ele decât prin intermediul SB. Aceasta este situația preferată de către majoritatea producătorilor de echipamente WiMAX (din considerente de securitate). Trebuie să menționez că pentru topologia tip „năvod”, fiecare stație va putea comunica nu numai cu SB ci și cu un număr de alte stații adiacente.
Totuși, experiența arată că, pentru structura unei rețele mesh, s-a aplicat principiul conform căruia numai anumite noduri vor avea rol de SB (cu legătură la rețeaua de interconectare – backhaulling), iar aceste noduri vor avea aceleași funcții ca și pentru cazul rețelei „punct la multipunct”. Prin urmare, diferența majoră este dată de faptul că, pentru rețeaua mesh, SM/SU vor avea legături și cu alte SM/SU nu numai cu SB. Aceasta înseamnă că nu va mai fi nevoie ca SB și SM/SU să aibă o legătură directă, aceasta putând fi realizată și prin intermediul altor SM/SU.
Comunicarea între toate aceste noduri va fi controlată cu ajutorul unui algoritm care va fi proiectat să ruleze într-un mod distribuit în fiecare nod al rețelei.
Ce înseamnă, de fapt, programare distribuită?
În primul rând, toate stațiile legate printr-o legătură directă vor fi denumite „vecini” și vor forma o „vecinătate”. „Primul hop”, în cazul unei transmisiuni, va fi constituit din vecinul sursei de transmisiune. Pentru cel de-al „doilea hop”, practic, putem considera toate stațiile din vecinătate. În acest caz, modul de programare distribuită a transmisiunii va presupune ca toate stațiile – fie ele SB sau SM/SU – să își controleze singure transmisiunile până la cel de al doilea hop.
Astfel, utilizând câmpul de control (sau parte din acesta) dintr-un cadru, stația va semnala fiecărui vecin programarea proprie a următoarei transmisiuni, precum și eventualele schimbări suferite. Această informare se va face pe principiul „punct la multipunct” – de la stația care anunță către vecini.
Canalul pe care se vor transmite aceste informații va fi același pentru toate stațiile, iar formatul va fi unic. Practic, algoritmul de care discutam anterior este instrumentul care va asigura că toate transmisiunile se supun programărilor și că programările (ca și transmiterea acestor programări) respectă tipicul impus pentru toate nodurile din rețea.
Există posibilitatea de a avea și transmisiuni ad-hoc – agreate direct între 2 noduri vecine, fără intervenția algoritmului. Acest mod fără coordonare se bazează pe cerere și răspuns – două operații ce vor fi executate doar între două noduri direct legate (vecine). Singura intervenție a algoritmului va fi în a programa aceste transmisiuni astfel încât să nu apară coliziuni – o altă transmisiune să se desfășoare deja.
Indiferent că este vorba de o programare coordonată sau nu, întregul proces se bazează pe același mod de lucru – cerere, răspuns, confirmare (așa numitul protocol 3-way handshaking), însoțite de o etapă adițională – programarea mesajelor de comandă. Trebuie spus că aceste mesaje poartă denumirea de MSH-DSCH – Mesh Distributed Schedule [66].
Astfel, avem următoarele etape:
Programare – se include următorul mesaj MSH-DSCH în următoarea transmisiune și se anunță acest lucru
Transmiterea cererii – în care se anunță transmisiune și se cere rezervare de resurse
Răspuns la cerere – în care se comunică disponibilitatea resurselor (în general, a canalului asociat nodului respectiv)
Confirmare a transmisiunii – în care se alocă respectivele resurse și transmisiunea este iminentă (în cazul în care resursele sunt disponibile).
În Fig. 3.5 este prezentat întregul proces. De menționat că transmisiunea are loc numai dacă resursele sunt disponibile. Dacă nu, are loc o reprogramare la un moment ulterior în care pașii se vor repeta.
Figura 3.5 Procesul de programare distribuită (coordonat central sau ad-hoc)
Dincolo de această programare distribuită, există și posibilitatea de a coordona totul central. Situația este asemănătoare, numai că algoritmul va fi coordonat de SB.
SB va fi cea care va programa transmisiunile pentru SM/SU, le va coordona si va superviza întregul proces. Practic, SB „capătă” aceleași funcții pe care le avea și în cazul rețelei PMP, cu singura diferență (menționată și anterior) – SM/SU nu trebuie să fie conectată direct cu SB. Acest lucru constituie un avantaj al rețelei mesh.
În plus, coordonarea centralizată a programărilor de transmisiune va determina și o optimizare a întregii comunicații – nu numai evitarea coliziunilor, ci și folosirea mult mai bună a resurselor rețelei și eliminarea traficului redundant.
Mențiune – și în acest caz, procesul prezentat în Fig. 3.5 este valabil, singura diferență fiind că mesajul de comandă transmis va purta denumirea de MSH-CSCH – Mesh Centralized Schedule [66].
Prezentam în capitolul 2 (subcapitolul 2.3.3 – „Managementul puterii”) cele 3 stări în care se poate afla un SM/SU (activă, inactivă și repaus). Mai mult, menționam apoi că și pentru conexiunile radio avem aceleași stări, ceea ce ajută la conservarea resurselor rețelei. Ba chiar și serviciile atașate unei conexiuni sunt în așa fel construite încât contribuie la același scop comun – optimizarea utilizării resurselor rețelei. Putem avea un serviciu provizionat, dar neactivat însă.
Adăugând și informațiile de programare (centralizată sau distribuită) a transmisiunii, pe care le-am prezentat anterior, putem concluziona că o conexiune de date tip unicast (între două noduri vecine) se poate afla în trei stări (după creare).
Mai întâi, prima stare – fără bandă alocată (corespunzătoare, ca și exemplu, unui serviciu provizionat dar inactiv). În această stare, conexiunea nu poate fi utilizată pentru a transmite date. Apoi poate primi drept de a transmite (și bandă alocată) prin intermediul unei programări centralizate (CSCH) și va trece în starea ACTIV – centralizat. Sau programarea se poate face prin mod distribuit și atunci va trece în starea ACTIV – distribuit. Ultima stare – transmisiunea în sine – este starea ACTIV [29]. Datele sunt transmise și se poate face o nouă programare a unei noi transmisiuni (prin cele două metode prezentate). Aceste stări sunt prezentate și în Fig. 3.6.
Figura 3.6 Stările unei conexiuni de date
Procesul de retransmisie pentru MAC-PDU
Considerat inițial ca o componentă opțională, mecanismul de retransmisie s-a dovedit una dintre cerințele cele mai des solicitate către producătorii de echipamente WiMAX.
Datorită acestui aspect, s-a stabilit implementarea unui mecanism de retransmisie automat (ARQ – Automatic Repeat Request) ca parte componentă a nivelului MAC.
Mecanismul de ARQ se va aplica separat pentru fiecare conexiune. Inițializarea și negocierea mecanismului de ARQ între emițător și receptor se realizează chiar în momentul în care se stabilește conexiunea. Trebuie menționat că, odată activat mecanismul de retransmisie, nu vom putea avea, pentru aceeași conexiune, retransmisii doar pentru un anumit trafic. Tot ceea ce se transmite între cele două entități va fi protejat de acest mecanism.
Din punctul de vedere al securității rețelei, mecanismul de ARQ ridică multe probleme. În primul rând, o eventuală retransmisie a unui cadru crește riscul de interceptare a acestuia. Retransmisia este, de obicei, determinată de degradare comunicării radio, degradare care poate fi indusă de un eventual atacator. Prin introducerea unei surse de bruiaj, atacatorul determină emițătorul să retransmită (folosind mecanismul de ARQ) cadre în urma faptului că receptorul nu mai primește informația și nu mai trimite confirmări de primire.
Mai mult, folosirea mecanismului de ARQ determină schimbări și în procesul de fragmentare/pachetizare prezentat în capitolele anterioare. Împărțirea (sau concatenarea) pachetelor va trebui să țină seama, în această situație, și de parametrii necesari ARQ. Blocurile rezultate în urma fragmentării (concatenării) pachetelor trebuie să fie de dimensiunea maximă acceptată pentru un pachet de date în cazul utilizării ARQ.
În plus, informația de management al întregului mecanism nu poate fi fragmentată, ceea ce induce o nouă limitare și un nou risc. Mesajul de control ce conține această informație poate dezvălui amănunte confidențiale pentru un eventual atacator care ar intercepta mesajul. Mesajul poate descrie numărul de pachete transmise, recepționate, retransmise, dimensiunea ferestrei de transmisiune, etc. Astfel, cum mesajul nu poate fi fragmentat, atacatorul va putea decripta mult mai ușor întregul mesaj.
Figura 3.7 Procesul de retransmisie pentru MAC-PDU. În cazul în care nu are loc retransmisia unui pachet pentru o perioadă lungă de timp, practic pachetul este considerat pierdut
CONCLUZII
Prezentarea celor două tipuri de topologii a fost extrem de necesară, mai ales din prisma faptului că ele constituie primele două opțiuni în momentul în care se dorește dezvoltarea unei rețele WiMAX. Descrierea nivelului MAC – la nivel de funcții și caracteristici, precum și detalierea performanțelor sistemelor WiMAX – la nivel de servicii, sunt două aspecte care vor contribui la expunerea corectă a posibilelor breșe de securitate apărute, precum și la identificarea soluțiilor de acoperire a acestora.
În capitolele ce vor urma, voi face referire la aceste aspecte de design și de funcționare pentru a putea justifica anumite probleme descoperite, precum și eventualele decizii luate pentru rezolvarea acestora.
CAPITOLUL 4
SECURITATEA REȚELELOR FĂRĂ FIR (CADRU GENERAL)
INTRODUCERE
Termenii precum „securitate”, „confidențialitate”, „protecție a datelor” se regăsesc în tot ceea ce înseamnă strategie de dezvoltare a unei infrastructuri de telecomunicații. Ei definesc (sau, cel puțin, încearcă să definească) un mod de abordare care, până la începutul deceniului, nu era considerat a fi necesar.
Anterior evoluției fulminante a domeniului telecomunicațiilor, ideea de securitate se confunda cu ideea de securitate fizică a echipamentelor ce conțineau date importante. Singura metodă de „furt” sau de „atac” era strâns legată de prezența „atacatorului” la locul „faptei” mai ales pentru că nu exista comunicare cu lumea exterioară (prin intermediul unei rețele, spre exemplu).
Odată cu apariția rețelei INTERNET și, în același timp, cu dezvoltarea conceptului de comunicare la distanță (la nivel tehnic și nu numai), situația s-a schimbat radical.
Totuși, de-a lungul evoluției rețelelor de telecomunicații, ideea de securitate, de perimetru de securitate a luat diverse forme, în funcție de schimbările apărute la nivel de domeniu al telecomunicațiilor.
Când schimbările au avut loc gradual, ele au trecut, de multe ori, „neobservate”.Dar, în final, ele au determinat o schimbare în esență a întregii viziuni asupra securității rețelei.
Ca exemplu (pentru a putea defini și mai bine această evoluție în timp a conceptului de securitate a rețelei) putem analiza ce s-a întâmplat cu rețeaua Internet și cu perimetrul de securitate.
La început, companiile au avut „o conexiune la Internet”, o singură ieșire către lumea exterioară a comunicațiilor. Având o singură conexiune, perimetrul era clar delimitat și foarte ușor de gestionat.Și astfel, perimetrul de securitate a cunoscut o evoluție nesperată – fiind o metodă foarte apreciată și aplicată la nivel de companie.
De-a lungul timpului, companiile au adăugat din ce în ce mai multe conexiuni, modificându-și gradual arhitectura de rețea de la o singură „ieșire” către Internet la o rețea de tip mesh (năvod) cu o conectivitate aproape omniprezentă. Ceea ce a pornit ca o schimbare graduală a devenit o schimbare în esență.
Companiile nu mai aveau doar o singură „țeavă” către Internet, ci o întreagă rețea ce asigura conectivitatea, iar un procent semnificativ din propriile afaceri se desfășurau „acolo”, în Internet. Prin urmare, ca rezultat al acestei schimbări, și perimetrul de securitate s-a modificat trecând de la cerință fundamentală la cerință depășită.
Cea mai apropiată paralelă cu lumea reală pentru perimetrul de securitate este dată de comparația cu un castel medieval cu zidurile și șanțurile sale de protecție. Cu o singură poartă de acces, tot traficul către castel este redirecționat prin această poartă unde pot fi aplicate măsuri de control al accesului. Comparați mai apoi castelul cu un oraș modern în care există zeci sau sute de puncte de acces (intrare / ieșire). Există posibilitatea de a monta baraje de control la fiecare punct de acces, dar acest lucru ar fi total nepractic.
Nu numai că toată schema de securitate ar fi ineficientă, dar ar determina și blocarea căilor de comerț, de aprovizionare precum și oprirea fluxului de oameni din și spre oraș. Observăm astfel de măsuri în orașele moderne doar în vreme de război și chiar și așa aceste măsuri sunt condamnate întrucât produc multe neajunsuri populației civile.
Așadar, dacă extindem acest exemplu pentru securitatea informației, putem spune că în cazul companiilor de mari dimensiuni, spre exemplu, nu se poate „susține” un perimetru strict de securitate așa cum nu se poate securiza un oraș modern în modul descris anterior.
Totuși, dacă ne uităm la măsurile de securitate cele mai des utilizate, putem observa o ignorare a faptului că „mai multe conexiuni” nu reprezintă doar o schimbare graduală de la o singură conexiune ci o schimbare importantă în esență.
Un exemplu din domeniul biologic ne va ajuta să demonstrăm această afirmație.Haideți să presupunem că izbucnește o epidemie.Vom încerca să construim un balon de plastic în care să înfășurăm un oraș întreg? Sau vom depinde de imunitatea fiecărui individ și de vaccinuri pentru a proteja locuitorii? Un balon ar avea aceeași problemă ca și un perimetru de securitate. Cei din interior ar muri de foame din cauza lipsei de aprovizionare, iar virusul oricum va reuși să „iasă” cumva. Multe dezavantaje, prea puține avantaje!
Tema unificatoare este aceeași: nu putem depinde doar de vechile măsuri de securitate (asigurarea unui perimetru de securitate, limitarea simplă a accesului etc.) într-o lume unde conectivitatea și mobilitatea sunt omniprezente.Mai mult, sunt cazuri în care nu se observă că lumea rețelelor s-a schimbat fundamental și încă se încearcă adaptarea ideii de perimetru de securitate la această nouă realitate.
Prin urmare, cerem imunitate individuală – fiecare server, desktop, telefon inteligent, router sau alt dispozitiv de rețea trebuie să aibă înglobat un set de reguli de apărare Securitatea trebuie să fie distribuită, omniprezentă și atotpătrunzătoare. Acesta va fi principiul pe baza căruia voi structura prezentarea legată de aspectele de securitate pentru familia de standarde IEEE 802.16 și pentru soluțiile aferente.
Totuși, în contextul actual, ideea de imunitate individuală (prezentată și în această introducere) nu mai este suficientă, fiind necesară o abordare de tip global. Definiția propusă pentru securitatea rețelei (și care va fi reluată în capitolele următoare) conține tocmai principiul pe care mi-am bazat toată această expunere (urmărirea țintei – securitatea).
Apoi, tot în cadrul acestui capitol voi detalia și instrumentele de detecție și verificare specifice pentru asigurarea securității unei rețele, urmând ca, în continuare, să prezint câteva considerente generale pentru securitatea IEEE 802.16. În final, voi prezenta cele mai importante (așa cum le-am considerat eu) vulnerabilități și riscuri de securitate – tocmai ca un punct de plecare pentru construirea planului de securitate.
Noțiunile teoretice prezentate pe parcursul capitolului sunt preluate din literatura de specialitate (din nou cu mențiunea că au fost structurate specific și aduse la zi) – vezi [2], [8], [10], [14], [27], [30], [41], [45], [52]. Însă, structurarea conceptului (extinderea de la imunitatea individuală, definirea noului perimetru de securitate, abordarea globală etc.) precum și zona de vulnerabilități și riscuri sunt contribuție proprie, necesară ca și fundament pentru întreaga dezvoltare ulterioară – plan de securitate și protocol de taxare.
DEZVOLTAREA UNUI PLAN PENTRU SECURITATEA REȚELEI
Ce reprezintă, în primul rând, securitatea unei rețele (fie că vorbim de rețele fără fir sau rețele fixe)?
Securitatea unei rețele reprezintă o țintă în permanentă mișcare, o țintă care trebuie urmarită continuu astfel încât rețeaua să asigure confidențialitatea, integritatea și disponibilitatea serviciilor și sistemelor care sunt critice pentru orice rețea de comunicații.
Ultimele articole în care se anunțau pierderile de informații confidențiale despre clienți (informații bancare sau medicale) sau chiar informații proprietare (brevetate) ne-au determinat să reevaluăm întregul concept de securitate a rețelei precum și instrumentele ce asigură securitatea rețelei.
Așa cum am arătat în subcapitolul anterior, ideea de securitate va trebui să includă, de acum încolo, conceptul de imunitate individuală, dar să se bazeze pe o abordare globală în ceea ce privește întreaga securitate.. Pentru acest lucru, politicile de securitate, precum și instrumentele de creere și aplicare ale acestor politici vor trebui definite atât la nivel individual cât și la nivel global.
Este evident că vom căuta să vedem cum putem aplica planul de securitate dezvoltat pentru întreaga rețea și pentru a asigura securitatea fiecărei componente de rețea , cum putem folosi instrumentele ce asigură securitatea individuală pentru a dezvolta politici de nivel global.
Astfel, procesul se va simplifica, având un atu în plus legat de administrarea centralizată a întregului nivel de securitate precum și de conclucrarea între diferitele instrumente de securizare folosite local sau global.
Îmi pun totuși întrebarea cum ne pot ajuta aceste instrumente să dezvoltăm politici de securitate noi și mult mai adaptate cerințelor actuale.
În primul rând, instrumentele pot produce rapoarte de activitate care se pot constitui într-un feedback permanent ce ajută la modificarea și întărirea politicilor de securitate. Cu alte cuvinte, cunoscând bine instrumentele și ce parte a rețelei acoperă ele, infomațiile oferite de acestea ajută la evoluție (sau aducerea la zi ) a politicilor de securitate. O astfel de susținere este foarte importantă în momentul în care avem în vedere rețele complexe de telecomunicații (in care sunt implementate numeroase tehnologii).
Există câteva instrumente de bază care nu sunt atât de puternice precum cele strict legate de dezvoltarea politicilor. Totuși, multe dintre ele pot juca un rol important în configurarea propriei strategii de securitate, mai ales dacă sunt folosite în acest scop.
Instrumente de detecție și verificare
Aceste tip de instrumente sunt folosite mai ales în etapa de prevenire a eventualelor atacuri, precum și în procesul de întreținere și verificare periodică a rețelei pentru eventuale breșe de securitate apărute.
Din categoria acestor tipuri de instrumente pot aminti [2][4][11][55]:
a) Identificatorii de vulnerabilități – pot determina implementarea unor politici de „peticire” (acoperire) a eventualelor breșe de securitate. Odată ce cunoaștem vulnerabilitățile sistemului, putem decide ce tolerăm sau ce este necesar să schimbăm în strategia de securitate.
b) Instrumente de verificare a securității aplicațiilor – ne pot furniza informații legate de standardele de codare a informației alese, dacă trebuie schimbate sau dacă oferă protecția necesară datelor transmise.
c) Instrumente de detecție a anomaliilor apărute în transmiterea fluxurilor de date sau în funcționarea rețelei – cunoașterea comportamentului tipic al propriei rețele poate scoate în evidență mult mai ușor activitățile ce necesită o politică de securitate mai strictă și o atenție sporită din acest punct de vedere. Detecția anomaliilor oferă o vizibilitate mult mai bună asupra traficului din rețea.
d) IDS – Sistemul de detecție al intruziunilor – foarte bine pus la punct poate oferi informații legate de atacurile ce pot surveni în rețea. Aceste informații ajută apoi la alegerea tehnologiilor pentru dezvoltarea arhitecturii de rețea.
Putem observa atacuri îndreptate către un anumit sistem în special și, astfel, să fie nevoie de o nouă strategie în sistemul de apărare orientată către acel sistem sau chiar de un nou sistem cu noi funcții. În acest mod, putem descoperi și eventualele amenințări („viermi”) ce se pot propaga de la o rețea la alta și putem opri aceste treceri, îmbunătățind politicile de securitate pentru întreaga rețea sau numai pentru un segment al retelei.
Toate aceste instrumente si tehnologii prezentate nu sunt singurele utilizate în segmentul securității rețelei. Pe măsură ce voi detalia aspectele legate de securitatea rețelei, voi mai prezenta și alte instrumente din această categorie.
Instrumente de urgență
Alături de categoria prezentată anterior, are loc o dezvoltare permanentă de instrumente noi. Unele sunt folositoare și au succes pe piață, altele sunt sortite eșecului și, cea de-a treia categorie, cele care merită luate în seamă chiar dacă sunt încă în faza de dezvoltare.
Câteva exemple la îndemână sunt cele legate de aplicațiile pentru planificarea riscurilor unei rețele și pentru evitarea pierderilor de date:
a) Instrumentele pentru planificarea riscurilor rețelei examinează configurațiile echipamentelor din rețea și vulnerabilitățile descoperite și ajută la prioritizare în procesul de rezolvare a problemelor apărute. Datele folosite de aceste produse pentru a genera rapoarte de prioritizare sunt legate de gradul de importanță al fiecarui nod din rețea, de vulnerabilitatea directă a fiecărui echipament, de securitatea fiecărei configurații și de slăbiciunea echipamentului supus unui atac (gradul de compromitere al acestuia).
b) Instrumentele pentru prevenirea pierderilor de date (cunoscute si ca DLP – „Data Loss Prevention”) pot oferi informații foarte detaliate legate de activitatea fiecărui utilizator, de nevoia de educație în sensul prevenirii pierderii de informații precum și despre riscurile la care este supusă rețeaua în urma activității utilizatorilor. Instrumentele DLP descriu o categorie largă de soluții și oferă securitatea informațiilor și conceptelor utilizate. Implementarea acestor instrumente se realizează, de obicei, în trei etape diferite: pentru datele aflate în curs de transfer, pentru datele ce urmează a fi transmise și pentru datele folosite la un moment dat.
DLP pentru datele în curs de transfer se implementează folosind senzori plasați fie în punctul cel mai depărtat al rețelei fie în punctele de agregare ale traficului. Senzorii examinează informațiile în tranzit pentru a vedea dacă traficul se supune regulilor de prevenire a proliferării sau compromiterii datelor confidențiale. De exemplu, o regulă poate permite raportarea tuturor încercărilor de a trimite informații confidențiale către o destinație în afara rețelei. Similar, pot fi create reguli care să semnaleze orice încercare de a trimite în exterior informații financiare legate de clienți. Acești senzori se pot integra, în general, în orice sistem de securitate cum ar fi proxi-urile sau agenții de mail pentru a bloca orice transmisiune neconformă.
DLP pentru datele ce urmează a fi transmise sunt implementate folosind echipamente adiționale care scanează nodurile rețelei pentru a determina și bloca transferul de informații confidențiale. Aceste echipamente atașate rețelei pot oferi administratorului moduri de autentificare ale documentelor importante precum și posibilitatea de a scana nodurile rețelei pentru depistarea existenței unor astfel de documente. De asemenea, aceste sisteme DLP sunt capabile să transmită informații legate de amprenta digitală pentru anumite documente importante (cum ar fi cele pentru datele în curs de transfer) către sisteme DLP adiacente pentru a întări controlul în scopul detectării și prevenirii scurgerilor de informații secrete în afara rețelei.
DLP pentru datele folosite la un moment dat sunt implementate cu ajutorul unor agenți software, instalați pe calculatorul utilizatorului, complementari cu celelalte instrumente de securitate (cum ar fi firewall-ul, antivirusul etc.). Acești agenți permit administratorului să se asigure că informațiile confidențiale nu părăsesc interiorul companiei prin canale neautorizate (cum ar fi USB sau conturi de WEBMAIL ale utilizatorului).
Conceptul DLP înglobează un set evoluat de tehnologii care conlucrează pentru a oferi securitatea informației.
Concluzionând, în momentul evaluării pașilor în adoptarea unei strategii legate de securitatea rețelei, trebuie ținut cont dacă sistemele DLP, instrumentele de planificare a riscurilor rețelei sau alte tehnologii pot juca un rol important în dezvoltarea protecției și detecției mai ales în zonele unde nu avem control deloc sau un control foarte superficial.
Trebuie remarcat că toată această prezentare de strategie nu a ținut cont de tipul rețelei (cu sau fără fir) sau de arhitectura ei. Convingerea mea este că, planul pentru asigurarea securității unei rețele nu trebuie, în prima etapă, să țină cont de tehnologiile folosite – mai ales când ne referim la rețele de comunicație de mari dimensiuni. Trebuie mai întâi să înțelegem modul de alcătuire (pe unul sau mai multe nivele, ierarhic etc.), scopul rețelei (comunicație inter sau intra – geografică, spre exemplu) precum și principiile de funcționare, mai exact de comunicare pentru acea rețea (funcționare temporară, la cerere, permanentă etc.). Această etapă reprezintă, de fapt, formularea unei strategii de securitate la nivel global.
Abia în cea de-a doua etapă va trebui să ținem cont de specificul tehnologiilor utilizate, de echipamentele folosite și așa mai departe. Această a doua etapă încearcă să descrie ceea ce am putea numi strategie de securitate la nivel individual.
Întrebarea firească în acest moment ar fi – „Cum pot eu gândi securitatea la nivel global pentru o rețea la care, evident, nu voi putea, neapărat, estima în timp evoluția sau gradul de extindere?”
Răspunsul la acestă întrebare l-am anticipat deja enunțând cele trei criterii pe care trebuie să le avem în vedere în prima etapă și anume (le reamintesc) – modul de alcătuire, scop, principii de funcționare. După cum se poate observa, nici unul dintre aceste criterii nu depinde în vreun fel de dimensiunea rețelei. Este evident că, dacă se va dori o rețea de tip intranet-de comunicare în interiorul unei companii (scopul) – dimensiunea acestei rețele nu va fi una exagerată. Scopul și felul rețelei se vor afla, astfel, în legătură strânsă, însă nu vor manifesta o dependență lucrativă.
În plus, abordarea strategiei în două etape descrisă mai sus, va ajuta ca, indiferent de evoluția ulterioară a rețelei, adaptarea planului de securitate să fie mult mai simplă, iar pentru orice nou echipament din rețea să putem aplica strategia de securitate la nivel individual.
În continuare, voi prezenta câteva aspecte generale legate de securitatea rețelelor tip 802.16. Aceste considerente mă vor ajuta să introduc cadrul necesar înțelegerii și dezvoltării ulterioare a subiectului dorit – securitatea rețelelor fără fir.
STANDARDUL 802.16 – VULNERABILITĂȚI ȘI RISCURI – CONSIDERENTE GENERALE
Introducere
“Worldwide Interoperability for Microwave Access” (WiMAX) reprezintă deja una dintre tehnologiile cele mai des utilizate în momentul în care vorbim de asigurarea accesului de bandă largă în cazul conexiunilor fără fir.
Dacă, pentru cazul 802.11, problemele de securitate au fost tratate dupa finalizarea standardului, pentru 802.16, aceste probleme au constituit o prioritate. Cum WiMAX-ul reprezintă totuși o tehnologie nouă, implementările curente nu sunt încă suficiente pentru a evidenția eventualele vulnerabilități, riscuri sau amenințări ce pot afecta comunicația în cazul unui trafic real.
IEEE 802.16 – Stiva de protocoale
Nivelul fizic
WiMAX folosește tehnologia OFDM (Orthogonal Frequency-Division Multiplexing) – Multiplexarea cu divizare în frecvențe ortogonale. OFDM permite asignarea de sub-purtătoare către diferiți utilizatori. În standardul IEEE 802.16 din 2004, semnalul OFDM poate folosi 256 purtătoare, iar pentru versiunea 802.16e (mobilitate) se va folosi OFDMA Scalabil („Orthogonal Frequency Division Multiple Access”). Standardul 802.16 suportă, de asemenea, un interval foarte larg de frecvențe, iar la nivel fizic regăsim multiple tehnici de modulație și multiplexare. Nivelele de modulație folosite atât pentru comunicația de la utilizator la stația de bază (UL – UpLink) cât și pentru comunicația inversă (DL – DownLink) sunt BPSK (Binary Phase Shift Keying) sau 2-QAM (Quadrature Amplitude Modulation), QPSK (Quaternary PSK) sau 4-QAM, 16-QAM, 64-QAM și 256-QAM.
Figura 4.1 Stiva de protocoale pentru IEEE 802.16 – 2004
Standardul 802.16 suportă două tipuri de duplexare: TDD (Time Division Duplexing) – duplexarea cu diviziune în timp și FDD (Frequency Division Duplexing) – duplexare cu diviziune în frecvență. Cadrul pentru transmisiunea de tip TDD este adaptiv și are o durată fixă. Ambele transmisiuni (UL și DL) folosesc aceeași frecvență dar sunt separate în timp.
Pentru FDD, transmisiunea este programată folosind UL-MAP și DL-MAP, astfel încât transmisiunile pentru UL și DL au loc la același moment de timp, dar folosind frecvențe diferite.
Durata cadrului poate fi fixată la 0.5, 1 sau 2 milisecunde. În transmisiunea TDD, durata alocată pentru UL și durata alocată pentru DL pot varia.
Pentru UL, comunicația este de tip TDMA (Time Division Multiple Access) – unde banda este împărțită în segmente de timp. Fiecare din această diviziune este alocată unui singur utilizator. Un sub-cadru pentru DL conține 2 părți – una pentru informația de control (ce include preambulul de sincronizare) și una pentru date.Un MAP de DL oferă informații legate de atributele transmisiunii și de momentul de început al acesteia. Pentru UL, MAP-ul descrie alocarea benzii pentru comunicație pentru un utilizator mobil (SM).
IEEE 802.16 MAC (Medium Access Control)
Acest nivel (în cazul standardului 802.16) este un nivel orientat pe conexiune (connection oriented). Nivelul MAC al IEEE 802.16 a fost proiectat pentru comunicații fără fir de bandă largă de tip punct la multipunct (PMP) sau de tip năvod (MESH). S-a luat în considerare existența unei stații de bază (SB) – asemănătoare AP (Access Point) din 802.11 – și a mai multor abonați (utilizatori ficși sau mobili – SM/SU).
Interconectarea între SB și rețeaua de access (alte SB sau alte noduri de rețea) se realizează prin legături cu fir, în timp ce comunicația SB-SM/SU se face la nivel fără fir (wireless). Față de 802.11, unde se folosea metoda CSMA/CD (Carrier Sense Multiple Access / Collision Detection) pentru evitarea coliziunilor – în cazul standardului 802.16 acest rol este preluat de Uplink și Downlink MAP. SS folosește TDMA pentru a transmite către SB, iar pentru comunicația SB->SS se utilizeaza TDM. Controlul ambelor transmisiuni se realizeaza prin intermediul MAP-urilor pe care le-am menționat anterior.
Nivelul MAC conține 3 subnivele – MAC CS (Service Specific Convergence Sublayer), MAC CPS (MAC Common Part Sublayer) și subnivelul de securitate (the privacy sublayer). Primul subnivel menționat – MAC CS – ajută la comunicația cu nivelele superioare nivelului MAC transformând informațiile primite de la acestea în fluxuri specifice nivelului MAC. Subnivelul MAC CS are la rândul lui două subnivele: unul este subnivelul de convergență ATM (Asynchronous Transfer Mode) pentru rețelele și serviciile de tip ATM, iar cel de-al doilea este subnivelul de convergență al pachetelor pentru serviciile cu pachetizare (Ethernet, IP, VLAN, PPP). Prin urmare, funcția de bază a subnivelului MAC CS este că primește date de la nivele superioare pe care, apoi, le clasifică fie ca și celule ATM, fie ca și pachete pe care le va trimite subnivelului MAC CPS.
Subnivelul principal pentru IEEE 802.16 MAC este MAC CPS întrucât el definește toate metodele pentru managementul conexiunii, distribuția benzii, rezolvarea cererilor de access la mediu, controlul conexiunii etc.. Comunicația între subnivelul CS și CPS se realizează prin MAC – Service Access Point (SAP). Crearea unei noi conexiuni, modificarea uneia existente, ștergerea conexiunii și transportul datelor peste o conexiune deja existentă sunt cele patru funcții ce pot interveni în cadrul unui proces de comunicație.
Subnivelul de securitate este responsabil pentru criptarea și decriptarea fluxurilor de date ce vin dinspre sau ce trec spre nivelul fizic. De asemenea, acest subnivel se ocupă și de autentificare precum și de schimbul cheilor de criptare pentru diferite metode ( cum ar fi DES – 3 DES sau 56 DES și AES). În rețelele de tip 802.16, SB conține un identificator de 48 de biți (care nu este o adresă MAC), iar SM/SU are o adresă MAC tip 802.3 tot de 48 de biți.
Identificatorul de conexiune (CID) pe 16 biți folosit în MAC PDU (Protocol Data Unit) funcționează ca și o referință pentru conexiune și, prin urmare, îi este alocată bandă la fiecare cerere în acest sens. Exista doua tipuri de conexiune MAC: una de management și una pentru transportul datelor. Conexiunile de tip MAC sunt asemănătoare cu cele TCP (Transport Control Protocol). Spre exemplu, un SM/SU poate avea mai multe conexiuni cu SB pentru servicii diferite, fie că este vorba de managementul rețelei sau transmiterea efectivă de date.
Pentru nivelul MAC, fiecare flux de date conține parametrii diferiți pentru prioritizare, securitate și alocare a benzii. [14] SB alocă un nou CID pentru fiecare comunicație cu SM/SU.
Imediat ce SM/SU s-a asociat în rețeaua SB-ului, îi sunt alocate trei CID diferite din oficiu. Mai mult, fiecare CID presupune parametrii diferiți pentru conexiunea pe care o identifică (parametrii de tipul celor menționați anterior). De asemenea, fiecare CID presupune nivele de calitate ale serviciului (QoS – Quality of Service) diferite. Astfel, avem conexiune primară (în care are loc autentificarea și realizarea conexiunii), conexiune de bază (folosită pentru a transfera mesaje de control atât ale legăturii radio cât și pentru nivelul MAC) și conexiune secundară (pentru transferul mesajelor standard de management pentru DHCP, TFTP sau SNMP). Primele doua conexiuni (primară și de bază) se realizează imediat ce SM/SU este asociat în rețeaua SB-ului. Conexiunile de transport se inițializează numai la cerere, fiind folosite pentru transmiterea fluxurilor de date. Se vor mai rezerva, de asemenea, câteva canale în plus astfel încăt să se poată transmite UL și DL MAP pentru programarea accesului la mediu.
Formatul mesajului MAC (MAC PDU)
MAC PDU are trei părți: un bloc de început (antet) fix care conține informații de control, corpul mesajului (payload) de dimensiuni variabile și o secvență de verificare a mesajului (FCS – Frame Check Sequence) care conține un cod corector pe 32 de biți [9].
Exceptând mesajul pentru cererea de bandă, MAC PDU poate conține fie mesaje de management pentru nivelul MAC, fie mesaje ale subnivelului de convergență – MSDU (MAC Service Data Unit). Blocul de început conține un indicator care arată dacă payload-ul este criptat sau nu.
Figura 4.2 Formatul MAC-PDU
Conform standardului IEEE 802.16 – 2001, antetul MAC precum și corpul mesajului nu sunt criptate. Această decizie a fost luată pentru „a facilita inregistrarea și operațiunile specifice nivelului MAC”(IEEE). Dar, din acest motiv, sunt permise generarea de mesaje false de autentificare astfel încât riscurile și amenințările sunt mari, iar vulnerabilitățile evidente.
În cazul în care vulnerabilitatea se manifestă la nivelul mesajelor de management, autentificarea poate fi compromisă și expusă atacurilor active. În cea mai nouă versiune a IEEE 802.16e, corpul MAC PDU este criptat utilizând fie DES fie AES. Se introduce în această versiune și un mecanism de protecție a integrității datelor.
În momentul apariției într-o rețea a unui SM/SU, are loc un proces în mai mulți pași. SM/SU își anunță prezența printr-un mesaj RNG-REQ – Range-Request. SM/SU și SB continuă comunicația folosind CID noi prin intermediul mesajelor RNG-REQ și RNG-RSP (Response).
SB răspunde folosind mesaje REG-RSP (Registration RSP), anunțând autentificarea SM/SU și oferind informațiile legate de caracteristicile comunicației (tipul de serviciu asociat, parametrii etc). SM/SU trimite ACK (confirmări) la toate aceste mesaje.
Subnivelul de securitate
În acest subnivel există două protocoale importante de comunicație: unul de încapsulare pentru criptarea pachetelor de date, iar al doilea – PKM (Privacy Key Management Protocol) – pentru asigurarea schimbului sigur de chei de criptare între SB și SM/SU. Acest al doilea protocol ajută și SB în selecția accesului la mediu [9].
Protocolul PKM folosește algoritmul RSA, certificatul X509 și alți algoritmi de criptare foarte puternici pentru a securiza schimbul de chei între SM/SU și SB. Practic, cele două protocoale au la bază specificațiile DOCSIS BPI+ care oferă posibilități de criptare foarte puternice utilizabile în IEEE 802.16 MAC.
De altfel, caracteristicile de securitate pentru IEEE 802.16 sunt definite în subnivelul de securitate. Funcția principală a acestui subnivel este de a asigura controlul accesului la mediu și confidențialitatea schimbului de date. Conexiunile primară și de bază nu au SA (Security Associations) – grup de identificatori pentru algoritmii de criptare și pentru cheile de securitate. [14] Conexiunea secundară poate avea, opțional, SA iar conexiunile de transport au obligatoriu SA. În Fig. 4.3, este prezentat modul de interacțiune al SA cu nivelul fizic și cu nivelul MAC.
Figura 4.3 IEEE 802.16 SA (Security Associations)
SA pentru DATE
SA pentru date conține un identificator de 16 biți, un cifru pentru a proteja datele în timpul comunicației și două chei de criptare a traficului (TEK – Traffic Encryption Key) – una operațională și una rezervată pentru reinițializare – TEKi (initialisation).
Cum durata de folosință a cheii curente este limitată, în momentul în care aceasta expiră, cheia TEKi intervine ca și identificator (având 2 biți) și, cu ajutorul vectorului de inițializare (IV), se generează o nouă cheie operațională. Durata de viață pentru TEKi este între 30 de minute și 7 zile.
Exista trei tipuri de SA pentru date: SA primare – folosite în momentul inițializării legăturii radio, SA statice și SA dinamice [9] configurate atât pe SB cât și pe SM/SU. SA primare sunt unice pentru fiecare legătură SB – SM/SU, în timp ce SA statice și dinamice pot fi impărțite între diferitele SM/SU. În general, o SM/SU folosește două sau trei SA – una pentru conexiunea secundară, iar una sau doua pentru UL și DL (se pot folosi SA separate pentru UL și DL). SB se asigură că fiecare SM/SU are acces doar la SA asociată lui.
SA pentru autentificare
SA pentru autentificare conține o cheie de autorizare de 60 biți (AK – Authorization Key) și o cheie de identificare pentru AK de 4 biți. Pentru identificarea SM/SU se folosește certificatul X509. Durata de viață pentru un AK este de la 1 la 70 de zile, 7 zile fiind durata cea mai folosită.
Se mai folosește, de asemenea, o cheie de criptare a cheilor schimbate între SB și SM/SU. Aceasta poartă denumirea de KEK (Key Encryption Key), este pe 112 biți și folosește criptarea 3DES. KEK este cea care furnizează lista cu SA autorizate și care autentifică cheile de criptare folosite în comunicația dintre SB și SM/SU. KEK folosește, atât pentru UL cat și pentru DL, o funcție de autentificare denumită HMAC (Hash funcțion-based message authentication code). Cu ajutorul acestei funcții, schimbul de mesaje (în special cele de management) este securizat. În plus, SB folosește și SA de autorizare pentru a conFig. SA de date de pe SM/SU.
Figura 4.4 Procesul de autentificare IEEE 802.16 cu ajutorul SA
În cazul autentificării pentru SM/SU, se folosesc certificatul X509 și protocolul PKM (Privacy key Management) pentru a negocia nivelul de securitate al comunicației SB-SM/SU și pentru a stabili ce SA și AK asociat se vor utiliza. AK se poate folosi și ca jeton de autentificare (criptat cu ajutorul RSA). Autentificarea se realizează numai în momentul în care și SB și SM/SU au primit jetonul.
Schimbul de date
În cazul schimbului efectiv de date, criptarea necesită o cheie denumită TEK (Transport Encryption Key). Aceasta folosește AK din procesul de autentificare pentru a obține KEK și cheia de autentificare a mesajului (cheia HMAC). Trebuie reținut ca toate aceste chei sunt acum pentru comunicația de date (și nu pentru management). TEK este generată de SB și este criptată fie cu ajutorul tehnicii 3DES (se utilizează un KEK de 112 biți), fie cu RSA (folosind cheia publică a SM/SU), fie cu AES (KEK de 128 de biți).
Mesajul pentru schimbul de chei de criptare în acest caz este autentificat cu ajutorul HMAC-SHA-1 care poate asigura verificarea integrității mesajului și confirmarea AK. Fig. 4.5 prezintă schimbul de chei în cazul comunicației de date. Figura are la bază ilustrarea procesului de cerere de TEK așa cum a fost prezentat în [45] (pagina 238 – capitolul 12). Eu am adăugat însă cheile inițiale, dimensiunile aferente și o listă completă de parametrii din cerere.
Figura 4.5 IEEE 802.16 – Schimbul de chei în cazul comunicației de date
Vulnerabilități și riscuri de securitate
În cazul rețelelor fără fir, confidențialitatea, protejarea traficului pentru evitarea eventualelor interceptări precum și regulile de autentificare reprezintă cerințele principale pentru a avea o transmisiune sigură.
Există câteva atacuri tipice asupra rețelelor wireless (atacuri ce pot surveni în momente diferite ale comunicației), cum ar fi: „omul la mijloc” (man-in-the-middle) – care apare în cazul lipsei autentificării în ambele părți, atacul cu mesaje de tip răspuns (Message reply attack) – în cazul cand cheile de identificare au durata mare de viață și pot fi depistate mai ușor în timp, atacul cu sesiuni paralele de comunicație, atacuri ce apar în urma lipsei criptării etc.
Nivelul fizic și subnivelul de securitate
În standardul 802.16, subnivelul de securitate este situat deasupra nivelului fizic. Prin urmare, rețelele de tip 802.16 sunt vulnerabile atacurilor la nivel fizic cum ar fi atacuri de bruiaj (interferență) sau de blocare.
Bruiajul se poate realiza prin folosirea unui semnal de zgomot foarte puternic ceea ce ar determina întreruperea transmisiunii (mai ales în cazul comunicației fără fir). Totuși, interferențele (zgomotul) pot fi depistate cu ajutorul unui analizor spectral și anihilate.
Principalul obiectiv al subnivelului de securitate era să protejeze împotriva furtului de servicii mai degrabă decât protejarea utilizatorilor în sine. De remarcat faptul că subnivelul de securitate protejeaza la nivel 2 OSI (nivel legătură de date) și prin urmare nu asigură criptarea schimbului de date între utilizatori [9]. Mai mult, nici nu protejează nivelul fizic impotriva interceptării. Sunt necesare tehnologii adiționale pentru a securiza atât nivelele superioare cât și nivelul fizic.
Furtul de identitate reprezintă o altă amenințare foarte frecventă ce constă în reprogramarea unui echipament pirat cu datele de identificare (adresa MAC etc.) ale unui echipament autentic din rețea. Adresa MAC poate fi furată prin interceptarea mesajelor de management. Astfel, introducând în rețea un SB pirat (fals), se pot păcăli SM/SU astfel încât acestea sa trimită datele de identificare (pe care le trimiteau la SB real pentru a obține servicii) iar comunicația sa fie compromisă. Totuși, în cazul 802.16, care folosește tehnologia TDMA, acest tip de atac este mult mai dificil. SB falsă ar trebui să transmită în același timp cu SB reală, cu un semnal mult mai puternic și cu aceeași durată ca și semnalul original. Prin urmare, foarte greu de realizat.
De asemenea, pentru rețeaua fără fir intâlnim și atacuri generale (care se pot aplica oricărei rețele). Unul din atacurile clasice este legat de secătuirea resurselor emițătorului prin emiterea unei serii foarte lungi de cadre din partea atacatorului [14]. Chiar dacă toate aceste cadre nu conțin datele de identificare necesare, resursele consumate pentru respingerea lor sunt foarte mari, astfel încât SB poate atinge nivelul maxim la care poate opera și, prin urmare, traficul real este afectat. Mecanismele actuale de protecție nu asigură nivelul de securitate dorit în rețeaua 802.16a de tip MESH (năvod) întrucât nu oferă garanția că hopul următor este „de încredere” (nu este un punct pirat de comunicație). Mai mult, odată cu 802.16e (mobilitatea), atacatorul nu mai depinde de poziția lui fizică (intr-o anumită parte a rețelei),iar mesajele de management sunt mult mai ușor de interceptat decat în cazul rețelelor 802.11. Prin urmare, este necesară menținerea unei conexiuni sigure pe măsură ce SM comunică cu SB asociate rețelelor prin care trece.
Cu ajutorul unui emițător RF bine configurat, un atacator poate capta anumite cadre de management, le poate clona și apoi retransmite ca și cum comunicația ar veni din partea unui utilizator autorizat. Este, deci, necesar ca fiecare planificare a unei rețele fără fir sa descrie și un mecanism de autentificare cât mai sigur. În cazul unor transmisiuni pe distanțe lungi, interferențele și distanța pot permite unui atacator sa rearanjeze și să selecteze cadrele astfel încăt comunicația directă între doi utilizatori autorizați să nu mai poată avea loc iar punctul fals (atacatorul) să fie cel care asigură legătura între cele doua puncte (filtrând tot ceea ce înseamnă trafic). Prin urmare, rețeaua trebuie să ofere și un mecanism de detecție a cadrelor false de răspuns.
Autentificare mutuală
Standardul IEEE 802.16 introduce doua tipuri de certificate: unul al producătorului și unul legat de SM/SU. Nu există nimic legat de provizionarea unui certificat pentru SB.
Certificatul producătorului identifică producătorul echipamentului conform standardului IEEE 802.16. Poate fi un certificat propriu producătorului sau unul eliberat de o altă autoritate recunoscută.
Certificatul pentru SM/SU identifică un anumit SM/SU și include și adresa MAC a acestuia. De obicei, producătorii sunt cei care realizează și acest certificat, pe care mai apoi îl înregistreaza la autoritatea în domeniu. În general, SB folosește o cheie publică (legată de un certificat public) pentru a autentifica un SM/SU ca fiind echipamentul original. Însă, acest tip de certificare presupune că SM/SU reține cheia sa privată intr-o locație software foarte bine securizată și foarte greu accesibilă.
Totuși, cea mai mare vulnerabilitate în cazul acestor certificări o reprezintă lipsa certificatului pentru SB [9]. Și, prin urmare, singura metoda de a proteja utilizatorul de falsuri și de atacuri brute este de a oferi o soluție de autentificare mutuală – ambele părți (SM/SU și SB) sa se autentifice reciproc sau o entitate din exterior sa realizeze procesul de autentificare atât pentru SB cat și pentru SM/SU și abia mai apoi sa permită comunicația.
Putem spune, deci, că în cazul IEEE 802.16 certificarea nu oferă decat o securizare aparentă, fiind limitată de lipsa certificatului pentru SB. Adăugând, însă, autentificarea mutuală – prin intermediul EAP – TLS spre exemplu, protecția este mult mai puternică iar riscurile mai mici.
Autorizare neclară
IEEE 802.16 nu oferă o definire exactă a procesului de autorizare prin SA- spre exemplu, stările prin care trece SA nu sunt clar diferențiate astfel încăt acestea sunt vulnerabile atacurilor în orice moment. Această problemă se va accentua în momentul în care va fi finalizată implementarea rețelelor tip 802.16e (mobil).
De asemenea, SM/SU nu poate identifica SA refolosite. Prin urmare, schema de criptare este vulnerabilă la atacuri ce se bazează pe refolosirea cheilor de criptare.
Mai mult, SA de autorizare nu conține și identificatorul SB-ului, deci SM/SU nu poate face diferența între SB autorizate și cele pirat.
Lipsa acestui identificator se poate pune însă pe seama faptului ca nu s-a dorit ca el să ajungă la SM/SU de unde poate fi piratat mai ușor (ceea ce ar fi adus în discuție încă o vulnerabilitate în plus).
O solutie împotriva atacurilor de tip răspuns (primirea de răspunsuri false din partea unei stații pirat) poate fi introducerea unui generator aleator de valori (atât la SB cat și la SM/SU), valori care apoi sa fie incluse în SA. Practic, schema de autentificare ar rămâne la fel, dar ar fi mult mai greu de identificat în urma interceptării cadrelor.
Standardul (în varianta sa finală) permite astfel de modificări, care, în opinia mea, ar reduce mult vulnerabilitatea sistemului în fața atacurilor menționate mai sus.
Securitatea datelor
În IEEE 802.16, criptarea datelor se face utilizând DES (Data Encryption Standard) în mod CBC (Cipher Block Chaining) . Acest mod presupune că fiecare bloc de date, înainte de a fi criptat, este trecut prin operația logică de sau exclusiv (disjuncție exclusivă) cu blocul anterior.
Prin urmare, DES în modul CBC folosește o cheie (TEK) de 56 de biți și un vector de inițializare CBC-IV (Initialization Vector). Modul CBC cere ca vectorul să fie inițializat aleator pentru o securizare mai bună a schemei de criptare.
S-a constat, totuși, că vectorul poate fi reprodus și este vulnerabil atacului tip „forță brută” care poate duce la recuperarea textului inițial.În plus, nu există nici o metodă de verificare a integrității mesajului, ceea ce crește posibilitatea atacului activ.
Deci, datorită faptului că vectorul de inițializare al SA este constant și public (pentru aceeași cheie TEK) iar câmpul de sincronizare al nivelului fizic este repetitiv și ușor de intuit, vectorul de inițializare al MPDU poate fi reprodus. Astfel, IEEE 802.16 nu oferă tehnici sigure de autentificare ale datelor.
Totuși IEEE 802.16e a adoptat AES-CCM cu o cheie de 128 biți (TEK) pentru criptarea datelor care asigură integritatea mesajelor și protecția împotriva atacurilor de tip răspuns folosind PN (Packet Number – numar de pachet). Emițătorul introduce un număr unic de pachet care asigură unicitate și oferă un mecanism de autentificare al pachetului.
Alte vulnerabilități
S-a prevăzut că, în momentul definirii SA, un AK poate avea durata de viață până la 70 de zile, în timp ce pentru TEK durata de viață nu poate fi mai mare de 30 minute ceea ce permite unui atacator să intercepteze TEK refolosite.
Un SA de date poate consuma aproape 3,360 de TEK pe durata de viață a unui AK. Pentru IEEE 802.16, SM/SU presupune că SB va genera totdeauna un nou AK (ceea ce reprezintă o altă vulnerabilitate).
De asemenea, SM/SU nu poate verifica dacă mesajul de autorizare a fost primit de la un SB autentic sau de la unul pirat. SB răspunde SM/SU folosind informații publice (chei, certificate) astfel încăt răspunsul poate fi creat și de către o stație pirat (un SB fals). Prin urmare, protocolul de autorizare este vulnerabil fiind expus atacurilor de tip răspuns.
În acest fel securitatea întregii rețele este amenințată, chiar dacă ne referim la vulnerabilități punctuale care, teoretic, sunt cunoscute și pot fi adresate la fel de punctual. Totuși, un avantaj important este, că spre deosebire de rețele Wi-Fi, toate aceste breșe au fost deja identificate încă din stadiile incipiente ale definirii standardului aferent.
CONCLUZII
Noul standard 802.16e a schimbat câteva mecanisme de securitate , spre exemplu, generarea aleatoare pentru fiecare cadru a vectorului de inițializare (IV) sau folosirea numărului de pachet PN. Se va folosi (conform acestui standard) AES (Advanced Encryption Standard) ca metodă principală de criptare, iar, în privința autentificării, standardul este destul de flexibil introducând o metodă bazata pe EAP (Extensible Authentication Protocol) – și variantele EAP-TLS, EAP-TTLS, EAP-SIM etc. Astfel, se poate utiliza pentru autentificare și un server AAA (Accounting, Authorization, Authentication) [9].
Un alt mod de criptare a informației este și AES-CCM (criptarea și autentificare la nivel de bloc) – introdus de NIST (National Institute of Standards and Technology). Standardul 802.16e oferă (pe langă această nouă metodă – AES-CCM) și un înlocuitor pentru criptarea 3DES a cheilor (de management sau de securitate) și anume AES-ECB (Electronic Code Book) – în care fiecare text este criptat cu ajutorul unui bloc de criptare [14]. Acest mod de criptare reduce mult costurile de implementare și este mult mai sigur mai ales pentru cazul mobilității.
Mecanismele de securitate sunt, însă, în continuă dezvoltare. Este necesară o evaluare exactă a implementărilor realizate până acum precum și a vulnerabilităților apărute astfel încât soluția de securitate să acopere cât mai multe breșe. Imaginația atacatorilor nu are limite, iar în momentul în care vorbim de mobilitate, riscurile cresc.
CAPITOLUL 5
SECURITATE ȘI CONFIDENȚIALITATE ÎN REȚELELE BAZATE PE TEHNOLOGIA WiMAX
INTRODUCERE
Deși tehnologia WiMAX a fost gândită cu scopul de a înlocui tehnologii precum T1, DSL sau bazate pe cablu – CATV, segmentul de rețea cel mai potrivit pentru a aplica această tehnologie rămâne, deocamdată, bucla locală.
Oferind suport pentru implementarea calității serviciului, tehnologia WiMAX permite dezvoltarea unor aplicații și servicii „pretențioase” în legătură cu întârzierile introduse de rețea. Comunicația tip WiMAX este una orientată pe conexiune, astfel încât calitatea serviciului se poate oferi diferențiat per conexiune, pornind de la un nivel ridicat și ajungând, prin degradare, la nivel de cel mai bun serviciu posibil (best effort).
La momentul actual, foarte mulți furnizori de servicii folosesc, pentru bucla locală, soluții derivate/extinse bazate pe „vechea” tehnologie Wi-Fi – familia de standarde IEEE 802.11.Fie că vorbim de versiunea IEEE 802.11b sau de versiunea IEEE 802.11g, soluțiile găsite sunt costisitoare și, cel mai adesea, inflexibile. Există situații în care furnizorii de servicii au încercat să dezvolte rețele Wi-Fi la nivel de oraș, deși scopul inițial pentru care erau prevăzute acest tip de rețele ținea mai mult de comunicația fără fir a unui echipament (calculator, laptop etc.) cu altele asemănătoare aflate la distanțe scurte.
Am tot amintit de buclă locală – practic una dintre cele mai importante segmente ale unei rețele din perspectiva clientului. Cum subiectul tezei mele este legat de securitatea rețelelor fără fir – cu aplicabilitate directă asupra rețelelor ce utilizează tehnologia WiMAX, și cum, așa cum am menționat deja, tehnologia WiMAX este folosită, de cele mai multe ori, pentru bucla locală, voi încerca, în continuare, să definesc ceea ce a însemnat inițial bucla locală, care este sursa și care este evoluția întregului concept.
Motivele pe care le-am menționat anterior (cum ar fi distanța scurtă de conectare oferită de rețelele tip 802.11 precum și capacitatea rețelelor tip WiMAX de a oferi calitatea serviciului), alături de explicația conceptului de buclă locală, justifică, încă o dată, alegerea mea în ceea ce privește focalizarea asupra securității rețelei tip WiMAX. Experiența acumulată de-a lungul timpului privind acoperirea breșelor de securitate depistate în cazul rețelelor tip 802.11 reprezintă un ajutor substanțial în stabilirea mult mai clară a unui plan de dezvoltare a securității rețelelor ce folosesc tehnologia WiMAX.
În același timp, gradul de acoperire oferit de rețelele tip 802.11, precum și capacitatea de transfer obținută au demonstrat că noua tehnologie WiMAX va căpăta prim-planul, devenind una dintre cele mai utilizate (dacă nu cea mai utilizată) tehnologii pentru asigurarea buclei locale.
Prin urmare, în cadrul acestui capitol – ultimul cu noțiuni teoretice – voi prezenta detaliat procesele de autentificare și de criptare, cu toate elementele componente – certificate, chei, cadrul MAC-PDU etc. Totodată, voi prezenta detaliat și modelul de referință pentru arhitectura rețelelor WiMAX (NRM – Network Reference Model) tocmai ca, în momentul definirii planului de securitate, să pot evidenția diferențele și îmbunătățirile aduse. Ca și referințe, amintesc [3], [8], [12], [14], [27], [28], [45], [49] din literatura de specialitate, precum și lucrările și articolele proprii publicate de-a lungul timpului (pe marginea aceluiași subiect) – [53], [54], [55], [57] (care se referă la monopolul buclei locale), [62].
Înainte de a continua, voi mai face o mențiune importantă: din punctul meu de vedere, securitatea și confidențialitatea unei rețele sunt două chestiuni separate (chiar dacă, unii autori consideră ca primul concept îl include pe cel de-al doilea). De aceea, și pe parcursul capitolului, am grupat separat detaliile prezentate, incluzând descrierea cadrului MAC-PDU la partea de securitate, iar criptarea (cu chei de criptare etc.) la partea de confidențialitate. Chiar dacă uneori numim generic „securitatea” unei rețele, părerea mea este că totuși cele două concepte (strâns înrudite) pot fi (și ar trebui) diferențiate. O rețea securizată nu asigură neapărat și confidențialitatea datelor, în timp ce, chiar dacă se asigură confidențialitatea datelor (din punct de vedere criptare etc.) nu înseamnă că rețeaua în sine este securizată (este de ajuns să amintim faptul că bruiajul în sine poate fi un atac la rețea fără a afecta datele care pot rămâne perfect confidențiale dar nu pot ajunge la destinatar). Astfel, după părerea mea, titlul acestui capitol este perfect justificabil (și indicat), chiar dacă pentru cele două concepte pe care le evocă (securitate/confidențialitate) avem o relație strânsă.
MONOPOLUL BUCLEI LOCALE – PE CALE DE DISPARIȚIE
Conceptul de buclă locală a fost utilizat inițial în cadrul rețelei publice de telefonie (PSTN) și el definea legătura între primul echipament al utilizatorului și primul hop al furnizorului de servicii (al firmei de telecomunicații).
Folosind, în mod tradițional ca suport fizic liniile de cupru, bucla locală a fost monopolizată de către companiile de telefonie publică care nu s-au preocupat aproape deloc de asigurarea calității serviciului (QoS) la nivelul cerut. Lipsa unei alternative viabile la acel moment, precum și costurile ridicate de interconectare pe care le-ar fi plătit orice operator privat au determinat închiderea pieței și crearea unui monopol extrem de profitabil pentru companiile de stat din domeniul telecomunicațiilor.
Totuși, dezvoltarea noilor tehnologii fără fir (wireless) – Wi-Fi și, apoi, WiMAX – a readus în discuție problema „liberalizării” acestei „ultime borne” dintr-un circuit – bucla locală fiind cunoscută și sub numele de last mile. Privită inițial ca o problemă politică (mai ales datorită implicării autorităților în asigurarea supremației companiilor de stat în domeniul telecomunicațiilor), liberalizarea buclei locale a adus în discuție și crearea unor scenarii competitive din punct de vedere tehnologic. Analiza soluțiilor alternative – DSL, cablu coaxial, linii de tensiune, conexiune radio etc. – a relevat faptul că sunt foarte multe situațiile în care alegerea unei opțiuni de conectare de tip fără fir este mult mai avantajoasă.
Sistemul de conectare a capătat denumirea de Acces fix fără fir (FWA – Fixed Wireless Access)[44]. Principalele sale avantaje pot fi sumarizate astfel:
Instalare rapidă
Costuri reduse de întreținere
Reconfigurare facilă
Care ar fi, totuși, situațiile în care alegerea FWA se dovedește mai inspirată decât instalarea (sau chiar păstrarea) aceleiași „vechi” bucle locale cablate (îmbunătățită mai nou prin introducerea suportului prin fibră optică)?
În primul rând, apariția unui nou furnizor de servicii de telecomunicații reprezintă oportunitatea perfectă pentru dezvoltarea unui sistem FWA. Operatorul nou apărut poate oferi o nouă modalitate de conectare, evitând situațiile neplăcute legate de realizarea unei alte cablări structurate (alături de cea existentă aparținând concurenței). De cele mai multe ori, aceasta ar implica lucrări civile (montarea unor noi canale de cabluri etc.) care nu sunt dorite de nimeni. În plus, montarea unui acces fix fără fir se poate face într-un timp mult mai scurt decât în cazul sistemele fixe cablate, ajutând, în acest mod, la susținerea unei oferte comerciale foarte atractive.
În situația în care zona de interes (sau de expansiune a unui operator deja existent) este una rurală sau una care nu permite dezvoltarea unei rețele cablate (vezi cazul locațiilor geografice mai puțin propice), bucla locală tip FWA reprezintă aproape unica soluție, atât tehnologic, dar mai ales economic. Gruparea mai multor utilizatori într-un cluster radio, ce va fi asociat unei stații de bază capabilă să deservească o asemenea suprafață, reprezintă modalitatea cea mai utilizată la momentul actual pentru zonele pe care le menționam anterior. În aceste situații, o rețea cablată nici nu intră în discuție, fiind aproape imposibil de oferit o astfel de soluție de conectare. Totuși, există și în aceste locații proiecte pentru dezvoltarea unor rețele metropolitane de fibră optică, în principal, care nu vor putea însă substitui prea curând sistemul de acces fix fără fir ca și metodă de interconectare pentru utilizatorul rezidențial.
Mai mult, tehnologia fără fir este văzută ca și alternativă la creșterea capacității unei rețele cablate existente. În cazul în care rețeaua funcționează la capacitatea maximă, este necesară, evident, o extindere a acesteia. De multe ori, însă, acest lucru nu este posibil – datorită unor motive obiective : trasee de cablu deja pline, imposibilitatea, din punct de vedere civil, a execuției unor lucrări de amenajare a unor trasee noi etc. În acest moment, o conexiune radio constituie singura soluție pentru a crește capacitatea furnizată. Interconectarea între cele două tipuri de rețele este simplă, permițând chiar și alte opțiuni cum ar fi: load-balancing, în cazul în care traficul atinge valori ridicate sau chiar posibilități de back-up pentru traficul foarte important – în cazul în care rețeaua fixă se întrerupe, o parte din trafic poate fi redirecționat prin legatura radio.
Prin urmare, bucla locală ce are la bază sistemul FWA cunoaște o dezvoltare fără precedent, elimininând vechiul monopol și aducând sistemul concurențial și în această parte a ofertei furnizorilor de servicii de telecomunicații.
Care ar fi componentele sensibile în cazul implementărilor ce folosesc pentru conectarea utilizatorului rezindențial accesul fix fără fir?
Fiind vorba de tehnologie radio, nu pot să nu menționez, încă de la început, problemele legate de acoperire. Prin apariția tehnologiei WiMAX – tehnologie ce permite stabilirea unei legături chiar și în condiții de NLOS adică fără vizibilitate directă între utilizator și stația de bază – o parte din aceste probleme au dispărut. Totuși, bazându-se pe reflexii, semnalul obținut nu este întotdeauna stabil și sunt posibile situații în care legătura este fluctuantă iar rata de transfer asemenea. Producătorii de echipamente oferă, însă, facilități software (cum ar fi ARQ – Automatic Repeat Request) care ajută în cazurile extreme menționate, îmbunătățind foarte mult calitatea transmisiunii.
O altă limitare ar putea fi considerată și lipsa unei rețele de interconectare între stațiile de bază (denumită și rețea de backhauling). Comunicația între stațiile de bază este foarte importantă și, prin urmare, interconectarea trebuie să se realizeze la viteze mari de transfer.Deși se poate opta tot pentru o soluție tip wireless, de cele mai multe ori, operatorii preferă rețele cablate de fibră optică. Această opțiune nu ridică prea mari probleme în zone urbane, însă, pentru zonele rurale (sau zonele greu accesibile) o rețea de fibră optică poate fi aproape imposibil de implementat. Evident că și în acest caz există soluții fără fir (tip PDH sau SDH) care însă nu oferă încă nivelul de fiabilitate dorit.
Așadar, alegerea celei mai bune variante (atât din punct de vedere tehnologic, cât și din punct de vedere economic) pentru bucla locală și, deci, pentru interconectarea utilizatorului rezidențial la rețeaua furnizorului de servicii, reprezintă un proces destul de interesant, cu „răsturnări de situație”. Pe de o parte, „aripa dură” a companiilor de stat nu agreează ideea sistemului FWA, beneficiind totuși de experiența acumulată de-a lungul timpului precum și de o rețea națională foarte bine dezvoltată. Pe de altă parte, „aripa tânără” a companiilor private, cu o rețea în continuă dezvoltare, au de partea lor dorința de implementare a noilor tehnologii (față de conservatorismul primei tabere).
Urmărind ultimele oferte prezentate de furnizorii de serviciu, observăm că tehnologia WiMAX este principala componentă a acestor oferte. Așadar, cum securitatea și confidențialitatea comunicațiilor reprezintă o prioritate indiferent de tehnologia utilizată, este absolut necesar să identificăm corect și să încercăm să oferim soluții pentru corectarea vulnerabilităților rețelelor tip WiMAX. Definiția pe care am dat-o buclei locale mă va ajuta în realizarea acestui scop.
ASPECTE GENERALE ALE SECURITĂȚII
Așa cum am prezentat și în capitolele anterioare, tehnologia WiMAX poate suporta comunicații atât punct-la-punct (P2P), cât și punct-la-multipunct (PMP).
În general, cea mai utilizată schema de comunicație este cea PMP – în care o SB poate transmite/recepționa către/de la mai multe SM/SU (în sensul că la un moment de timp t poate fie transmite fie recepționa). Totuși, P2P este un tip de comunicație utilizat mai ales pentru interconectarea SB (așa-numitul backbone al rețelei), reușind să asigure o stabilitate foarte bună, precum și rate de transfer ridicate.
Menționez încă o dată că, la fel ca și în cazul IEEE 802.11, unde regăseam comunicații P2P, PMP și mesh, și pentru IEEE 802.16 se folosește topologia tip mesh (năvod), ceea ce permite furnizorilor de servicii să interconecteze direct toate SM/SU aflate în rețeaua proprie. Totuși, așa cum am precizat în capitolul 3 (subcapitolul 3.2.2), preferința operatorilor este de a nu permite comunicarea între SM decât prin intermediul SB (tot din considerente de securitate).
Flexibilitatea (în ceea ce privește arhitectura rețelei) de care dă dovada tehnologia WiMAX permite integrarea acestei tehnologii în medii diferite, aparținând diferiților operatori.
Mai mult, soluțiile proiectate de operatori includ înlocuirea vechilor hot-spot-uri cu rețele WiMAX capabile să ofere acces la Internet utilizatorilor în orice colț al orașului nu numai în zone dedicate – așa cum se întâmpla până acum în cazul rețelelor tip 802.11.
Totuși, acest tip de soluție poate avea o aplicabilitate mult mai redusă datorită unei utilizări ineficiente a benzii alocate. Algoritmul de alocare a benzii se va dovedi, în acest caz, un instrument ineficient pentru managementul benzii alocate. Situația se va schimba în momentul implementării WiMAX-ului mobil (IEEE 802.16e – 2005), însă și datele problemei vor fi altele. Algoritmul de alocare a benzii va căpăta o formă mult mai avansată, fiind însoțit de un mecanism de power-saving [29] (economie de energie). În lucrările mele viitoare voi detalia acest subiect, realizând o comparație între cele două versiuni din familia de standarde IEEE 802.16 – versiunile 802.16d și 802.16e.
Pentru moment, cea mai eficientă soluție se dovedește a fi soluția hibrid – 802.11&802.16d.
Astfel, utilizatorii vor folosi pentru accesul la Internet local tot conexiuni Wi-Fi. Laptop-urile, PDA sau alte echipamente folosite vor comunica tot cu AP prin intermediul tehnologiei definită în standardul IEEE 802.11 b/g. Mai apoi, aceste AP se vor lega la o SB prin intermediul tehnologiei WiMAX.
Practic, AP vor îngloba, astfel, ambele tehnologii, beneficiind de avantajele oferite dar și de problemele întâmpinate din ambele părți. Din punctul de vedere al securității, riscurile cresc întrucât AP poate fi supus unor atacuri combinate – Wi-Fi – WiMAX – care pot fi mult mai puternice și mai variate. Vom vedea, în capitolele următoare, cum putem contracara această nouă amenințare.
Structura cadrului MAC: MAC – PDU
Am oferit anterior o descriere a cadrului MPDU. În acest subcapitol, însă, voi detalia, câmpurile prezente în antetul acestui cadru, evidențiind diferențele pentru cele două arhitecturi – PMP și Mesh.
Așa cum am ilustrat fiecare MPDU este compus dintr-un antet (denumit antet generic), un câmp ce conține informația utilă – câmp opțional și un câmp ce conține un cod detector sau corector de erori – denumit CRC (Cyclic Redundancy Check) – opțional, de asemenea.
Antetul generic definește ce tip de informație este conținută în mesaj și este delimitat pornind de la bitul cel mai semnificativ (MSB). Așa cum am arătat anterior, câmpul cu informația utilă poate conține zero, unul sau mai multe sub-antete precum și MAC-SDU (Service Data Units). Cum atât câmpul de CRC, precum și câmpul cu informația utilă pot lipsi sau pot avea dimensiuni variabile (cazul informației utile), întreaga dimensiune a MPDU poate varia.
Există două formate definite pentru antetul generic. Unul este atribuit mesajelor de management sau mesajelor trimise de subnivelul de convergență. Cel de-al doilea este cel folosit pentru mesajele prin care se solicită bandă pentru transmisiune – este vorba de mesajele de tip incremental, nu cele de agregare (considerate a fi de management)
Cele două tipuri de antete sunt diferențiate prin intermediul câmpului denumit tip antet (HT – Header Type), care conține valoarea 1 pentru mesajele de cerere de bandă adițională și 0 pentru restul.[29] Antetul generic al MPDU (mesajele de management) este prezentat în Fig. 5.1, iar semnificația câmpurilor în tabelul 5.2.
Fig. 5.1 Antetul generic al MPDU pentru pachetele diferite de cele de cerere de bandă
Tabelul 5.2 Tabel descriptiv pentru câmpurile componente ale antetului generic al MPDU
În funcție de valoarea unor anumiți biți din câmpul Type, putem avea mai multe tipuri de sub-antete sau de informații prezente în câmpul de informație utilă.
Câteva exemple în acest sens sunt prezentate în tabelul 5.3[29].
Tabelul 5.3 Exemple de pachete diferite în funcție de componența câmpului Type
Pentru cazul în care HT devine 1 – deci este vorba de un mesaj de cerere de bandă adițională – antetul are o componență schimbată – așa cum se poate observa și din Fig. 5.4.
Explicația câmpurilor se poate regăsi în tabelul 5.5
Figura 5.4 Antetul pentru mesajul de cerere de bandă
Tabel 5.5 Tabel descriptiv pentru câmpurile componente ale antetului specific mesajelor de cerere de bandă
Trebuie menționat că, pentru acest tip de mesaj, nu avem informație utilă și nici CRC incluse.
PROCESUL DE AUTENTIFICARE DIN CADRUL REȚELELOR WiMAX
Introducere
În cadrul procesului de asigurare a securității rețelei tip WiMAX , etapa specifică autentificării este una dintre cele mai importante. Fundamentul întregii comunicații ulterioare se bazează pe autentificarea corectă a părților implicate.
Pe de-o parte, SB trebuie să autentifice numai utilizatori autorizați pentru că, altfel, riscă să transmită informații către un posibil atacator, oferind o breșă de securitate nesperată pentru acesta.
Pe de altă parte, SM/SU trebuie să autentifice la rândul său că SB cu care comunică este una corectă și nu una falsă (aparținând unui eventual atacator), pentru a nu transmite acesteia informații confidențiale cum ar fi certificate specifice, mesaje de management etc.
Din punctul de vedere al autentificării, rețelele tip IEEE 802.11 au avut mult de suferit. În versiunile inițiale ale standardului, procesul de autentificare a fost neglijat, iar urmările au fost dezastruoase. Definirea ulterioară a acestui proces – diferențiat pentru rețele tip infrastructură și pentru rețele tip ad-hoc – a rezolvat o parte din aceste probleme. Totuși, lipsa (inițială) unei criptări a mesajelor de control ce intervin în autentificare a adus cu sine alte breșe de securitate. Treptat, introducerea unor metode de criptare (alături de metodele de autentificare) a determinat crearea așa-numitului sistem WPA – Wireless Protected Access – sistemul de acces protejat la rețeaua fără fir [45].
Acest sistem a îmbunătățit întregul proces de securitate dar a demonstrat că, fără o pregătire prealabilă a tuturor aspectelor legate de evoluția unei rețele, există riscul de a expune întreaga comunicație unor atacuri neprevăzute.
Acesta a fost și motivul pentru care, la construcția standardelor din familia IEEE 802.16, procesul de autentificare a ocupat un loc important și a fost dezvoltat ca atare.
HMAC – Hashed Message Authentication Code
Funcția care creează HMAC este componenta care oferă autentificarea mesajului. Cu ajutorul acestei funcții, receptorul poate verifica dacă sursa mesajului este cea știută de el (sursa corectă). Acest lucru este posibil datorită faptului că emițătorul creează un cod de autentificare specific fiecărui mesaj – denumit HMAC – folosind o cheie specifică cunoscută doar de emițător și de receptor.
În momentul în care receptorul primește mesajul, creează propriul cod pentru mesaj folosind aceeași cheie comună, pentru ca apoi să compare acest cod cu codul recepționat. Dacă se constată o potrivire, se confirmă faptul că emițătorul este „de încredere” și mesajul este acceptat.
Funcția care creează acest cod are, practic, doi parametrii de intrare – cheia comună de codare și mesajul de transmis.
Mai întâi, cheia de codare, definită în cadrul SA de autorizare, este trecută printr-o operație de sau exclusiv (XOR) cu un mesaj de control de intrare (un mesaj dummy) – compus din octetul 0x36 multiplicat de 20 ori pentru a avea aceeași dimensiune cu cheia de codare [29]. Valoarea obținută în urma aceste operații logice (care are 160 de biți) este, apoi, atașată la începutul mesajului, iar rezultatul este dispersat. Această operație se va realiza utilizând conform standardului IEEE 802.16d, funcția criptografică de tip hash SHA-1.
Așa cum se știe deja, funcțiile SHA au fost definite de Agenția Națională de Securitate din S.U.A (NSA), sunt în număr de cinci și sunt folosite în codarea mesajelor [45].
Cheia de codare este, mai apoi, trecută din nou printr-o operație de sau exclusiv cu un mesaj de control de ieșire, de această dată, compus din octetul 0x5C multiplicat tot de 20 de ori. Valoarea obținută (tot pe 160 de biți) este atașată la rezultatul obținut la pasul descris anterior. Mesajul obținut este din „amestecat” cu ajutorul aceleiași funcții SHA-1. Se va obține astfel mesajul codat (codul – HMAC – pentru mesajul original) care ajută la întregul proces de autentificare dintre emițător și receptor. Toți acești pași sunt descriși în Fig. 5.6.
Figura 5.6 Procesul de creere al HMAC
Certificatul X509
Certificatul X509 este folosit de SB pentru identificare SM/SU. Standardul IEEE 802.16d -2004 descrie câmpurile componente ale certificatului, fără a oferi însă o limitare în ceea ce privește eventualele informații adiționale pe care un anumit producător dorește să le adauge.
Descrierea câmpurilor prezente în certificatul X509 este ilustrată în tabelul 5.7. Voi oferi atât denumirile în limba engleză – așa cum sunt ele prezentate în standard [29]– cât și traducerea specifică în limba română.
Tabelul 5.7 Tabel descriptiv pentru câmpurile prezente în certificatul X509
Există două tipuri de certificate – certificate de producător și certificate specifice SM/SU.
Certificatul de producător identifică producătorul și poate fi un certificat proprietar sau un certificat emis de o altă entitate abilitată în acest sens.
Certificatul specific SM/SU este creat de producătorul echipamentului și conține adresa MAC a stației în câmpul de subiect (Subject).
SB folosesc certificatele de producător pentru a verifica, pentru fiecare SM/SU, certificatul specific acestora.
În felul acesta, SM/SU sunt autentificate și din punct de vedere al legitimității producătorului.
Orice fals (și potențial atacator) va trebui, astfel, să mai treacă printr-o etapă de autentificare – una care se dovedește, însă, a fi destul de sigură la prima vedere, mai ales prin prisma algoritmului specific de marcare și a parametrului folosiți (identificatori unici, adresa MAC etc.).
EAP – Extensible Authentication Protocol
Bazându-se pe experiența căpătată în cazul rețelelor tip IEEE 802.11, IEEE a hotărât ca, pentru rețelele tip WiMAX să introducă, alături de schema de autentificare bazată pe certificatele X509, o nouă metodă de autentificare.
Această nouă metodă este considerată a fi mult mai flexibilă și se bazează pe protocolul extensibil de autentificare (EAP).
Acest protocol a dat naștere (prin diferite combinații cu diferite tehnologii) la mai multe metode de autentificare – EAP-MD5, EAP-TLS, EAP-SIM etc.(menționate deja de noi în primul capitol al tezei). Toate aceste metode sunt folosite pe scară largă mai ales pentru rețelele fără fir. Standardele WPA și WPA2 au adoptat metodele bazate pe EAP ca și metode agreate de autentificare.
În cazul rețelelor IEEE 802.16, mesajele EAP sunt codate și încapsulate în cadrele de management. Vom vedea în momentul în care vom vorbi despre protocolul de management al cheilor (PKM) că, prin folosirea EAP, au mai apărut două mesaje de management denumite PKM EAP cerere și PKM EAP răspuns, necesare pentru a putea transporta informația necesară EAP.
Trebuie spus că, deși IEEE 802.16 specifică folosirea EAP pentru autentificare, nu menționează o anumită metodă (din cele amintite anterior) ce trebuie utilizată în procesul de autentificare, lăsând la libera alegere a operatorului ce dezvoltă rețeaua respectivă.
Descrierea procesului de autentificare
După descrierea elementelor folosite în cadrul procesului de autentificare, putem schița, în acest moment, etapele acestui proces.
În primul rând, scopul acestui proces este autentificare identității unei SM/SU de către SB, în momentul în care aceasta dorește să intre în rețea.
SM/SU inițializează procesul de autentificare, trimițând către SB un mesaj ce conține informațiile necesare autentificării. Acest mesaj va avea în componență și certificatul specific – emis de producător sau de o autoritate competentă din domeniu.
Imediat după trimiterea acestor informații, SM/SU va trimite un mesaj-cerere de autentificare. În cadrul acestei cereri adresate SB, SM/SU va solicita o cheie de autentificare. Cheia va trebui să conțină certificatul X509 trimis anterior, identificatorul SA asociat conexiunii primare a SM/SU precum și o descriere a algoritmului de criptare (tot prin intermediul SA asociat acestuia).
Reamintesc, SA reprezintă un set de identificatori de securitate pentru algoritmii de criptare și pentru cheile de securitate.
Întregul proces de autentificare este prezentat în Fig. 5.8.
Figura 5.8 Etapele procesului de autentificare
Așa cum am menționat la început (și după cum se poate observa și în Fig. 5.7), SM/SU va trimite cele două mesaje – informal și cerere. SB verifică apoi certificatul specific SM/SU (ajutată de certificatul X509 pe care îl deține). Tot în cadrul acestei etape de verificare, SB va determina mai întâi dacă SM/SU îi este permis accesul la rețea, iar mai apoi va stabili ce algoritm de criptare și ce protocoale va folosi în comunicarea cu aceasta.
După toate aceste verificări, SB va activa o cheie de autentificare (AK – Authentication Key) unică pentru SM/SU ce a solicitat autentificarea, o va cripta utilizând cheia publică (recepționată de la SM/SU) și o va trimite către SM/SU în cadrul unui mesaj de răspuns la cererea de autentificare.
Prin urmare, mesajul de răspuns va conține o cheie de autentificare (criptată cu cheia publică), un număr de secvență pe 4 biți (folosită pentru a face distincția între AK succesive), durata de viață a cheii precum și o listă de SA (cu proprietățile aferente).
În urma procesului de autentificare, SB va asocia SM/SU autentificată cu un utilizator plătitor și cu serviciul asociat acestuia. Așadar, transmiterea cheii de autentificare este foarte importantă, SM/SU urmând să folosească această cheie pentru a accesa serviciile destinate. Autentificare SM/SU elimină posibilitatea de a avea o stație falsă în cadrul rețelei, care să aibă acces la informații confidențiale.
Întrebarea care se pune în acest punct este legată de posibilitatea ca un atacator să aibă un echipament clonat (care conține un certificat specific unui producător) și să dorească să se autentifice într-o rețea aparținând unui anumit operator.Cu SB aparținând aceluiași producător, se va autentifica echipamentul atacatorului? Va fi primit în rețea?
Răspunsul este simplu – nu! Chiar dacă, presupunând că atacatorul știe detaliile aferente SB (frecvență, identificatori etc.), stația clonă nu va fi primi o cheie de autentificare validă pentru a accesa serviciile aferente.SB va transmite un răspuns la cererea de autentificare care va conține o cheie invalidă și, în plus, nu va avea SA (pentru că SB nu știe de acest SM/SU și nu va ști ce identificatori de conexiune și de criptare să transmită).
Trebuie să menționez că tot acest raționament este valabil în situația în care stația aparținând atacatorului nu este o clonă perfectă – aceeași adresă MAC, același certificat – a unei SM/SU din rețea și, în plus, SM/SU clonat să fie oprit la acel moment. În cazul nefericit în care există totuși această copiere perfectă, intruziunea va trebui oprită la un nivel superior (nivel rețea sau chiar nivel aplicație) – cu ajutorul altor parametrii de identificare (adresă IP, parolă etc.).
Teoretic, situația nu este una destul de comună, fiind destul de greu ca o persoană din exterior să cunoască exact toți parametrii unei rețele (atât radio, cât și de identificare), iar adresa MAC (în cazul acestor echipamente) încă este destul de greu de schimbat (astfel încât să putem clona un echipament). Totuși, așa cum evoluția tehnicii este de netăgăduit, tot așa imaginația și priceperea atacatorilor au un ritm evolutiv la fel de accelerat. Prin urmare, situația descrisă anterior nu trebuie în nici un caz ignorată [44].
Așa cum am menționat deja, în realizarea unui plan de securitate a rețelei, va trebui să ținem seama de asigurarea imunității individuale pentru fiecare componentă, dar și de perfectarea unui plan gândit la nivel global. În același timp, trebuie să luăm în considerare și caracteristicile fiecărei tehnologii în parte (WiMAX, Wi-Fi etc.) dar și interoperabilitatea necesară pentru o funcționare uniformă și corectă.
Toate aceste elemente ne vor ajuta să dezvoltăm un plan de securitate, care, aplicat corect, va elimina foarte multe din breșele de securitate descoperite în cazul studierii atente a IEEE 802.16.
Acest plan l-am numit plan de securitate interdependent tocmai datorită relației de dependență dintre securitatea individuală și securitatea la nivel global, precum și a relației absolut necesare între diferitele tehnologii ce pot apărea într-o rețea. Deși planul propus este specific rețelelor tip WiMAX, este evident că va trebui să țină seama și de alte tehnologii (datorită unei evidente integrări a rețelei tip WiMAX în rețeaua mare a operatorului). În plus, cred eu, tot acest concept poate fi aplicat și pentru alte tipuri de rețele (cu modificările de rigoare).
CONFIDENȚIALITATEA ÎN CADRUL REȚELELOR WIMAX
Alături de autentificare, subnivelul de securitate din cadrul nivelului legătură de date este responsabil și cu schimbul de chei (de criptare, autentificare, autorizare etc.) precum și cu criptarea informației transmise. Acest subnivel se află chiar deasupra nivelului fizic, transmițând și recepționând de la acesta MAC-PDU (MPDU).
Practic, acest subnivel se ocupă și de confidențialitatea rețelelor WiMAX – având în componență două elemente esențiale pentru acest lucru – protocoale de încapsulare și protocolul de management al schimbului de chei de securitate (PKM – Protocol Key Management). În categoria cheilor de securitate am inclus toate acele chei menționate anterior (de criptare, autentificare etc.).
Protocoalele de criptare se ocupă de criptarea datelor din cadrul rețelei tip WiMAX, iar protocolul de management al cheilor asigură o distribuție sigură a cheilor folosite în toate procesele de securitate.Voi prezenta, mai întâi, această a doua categorie, urmând ca, mai apoi, să mă ocup de procesul de criptare a datelor în cadrul rețelelor tip WiMAX.
Definirea cheilor de securitate
Înainte de a prezenta protocolul, trebuie să definesc care sunt cheile utilizate în cadrul proceselor de securitate și în ce moment sunt ele transmise. Am prezentat deja AK – Authentication Key, cheia folosită în procesul de autentificare.
Am stabilit că, în prima etapă a autentificării, SM/SU transmite un mesaj informativ ce conține certificatul specific (al producătorului echipamentului) către SB. Cel de-al doilea mesaj, trimis tot de SM/SU către SB, imediat după primul, va conține o cerere de autentificare.
În cadrul celui al doilea mesaj, se va solicita, alături de alți parametrii, și AK. SB va determina (cu ajutorul certificatului X509) dacă SM/SU este o stație autentică și, utilizând cheia publică, va cripta și, mai apoi, va transmite AK în cadrul unui mesaj de răspuns la cererea anterioară.
Deci, o primă cheie folosită este cheia de autentificare și este transmisă în mesajul de răspuns al SB la cererea de autentificare emisă de SM/SU.
O altă cheie utilizată în cadrul comunicațiilor din rețelele tip WiMAX este TEK – Traffic Encryption Key.
Imediat ce SM/SU a fost autorizat, pentru fiecare conexiune stabilită cu SB va avea un grup de parametrii de securitate asociați (SA). Alături de acești parametrii se află și TEK, ce se definește la începutul stabilirii SA, pentru ca, apoi, să fie retransmisă, periodic, cu scop informativ. Transmiterea acesei chei se va face cu ajutorul PKM printr-o serie de etape pe care le vom descrie ulterior.
Există însă o cheie de criptare care va fi folosită numai pentru criptarea cheilor de securitate. Aceasta poartă denumirea de cheie de criptare a cheilor (KEK – Key Encryption Key) și este folosită permanent în cadrul proceselor ce țin de securitatea rețelei.
În Fig. 5.9 ilustrăm, ca exemplu, procesul de criptare a TEK folosind KEK. Am notat cu KEKs partea compusă din primii 64 de biți ai KEK pornind de la stânga la dreapta și cu KEKd partea compusă din ultimii 64 de biți. Cu ajutorul acestor derivate și folosind metoda de criptare 3DES , vom obține TEK criptată astfel:
pasul 1: TEK este criptată folosind metoda 3DES și KEKs
pasul 2: Rezultatul de la pasul 1 este decriptat folosind KEKd
pasul 3: Rezultatul de la pasul 2 este criptat din nou cu KEKs și aceași metodă.
pasul 4: Rezultatul de la pasul 3 reprezintă TEK criptată ce se va transmite.
Figura 5.9 Procesul de criptare a TEK
Cele trei chei reprezintă cele mai importante chei utilizate în procesul de securizare a comunicației. Voi detalia, în continuare, protocoalele de management al acestor chei, urmând ca, în cazul în care mai identificăm în cadrul unui proces și alte chei, să evidențiez eventualele amănunte specifice ce intervin pentru fiecare nouă cheie în parte.
Protocolul de management al cheilor – PKM
Fig. 5.10 ilustrează poziția pe care o ocupă, în cadrul subnivelului de securitate, acest protocol.
Figura 5.10 Descrierea subnivelului de securitate
Așa cum se poate observa, poziția acestui protocol este una centrală în cadrul subnivelului. Acest lucru este normal, PKM susținând distribuția sigură a cheilor de securitate, precum și procedurile de criptare și autentificare pentru MPDU.
PKM are însă două versiuni care corespund celor două versiuni ale IEEE 802.16 – PKM versiunea 1 a fost definit în IEEE 802.16d-2001, iar PKM versiunea 2 în IEEE 802.16e-2005.
PKM versiunea 1
Așa cum am stabilit anterior, există 3 chei principale folosite în cadrul comunicației dintre SM/SU și SB – AK, TEK și KEK. Alături de acestea mai avem și două chei specifice celor două direcții de transmisiune – cheile DL-HMAC și UL-HMAC.
Așa cum specifică și numele, ultimele două chei sunt utilizate la generarea codului de autentificare (HMAC) a mesajelor (funcția și codul l-am descris deja în subcapitolul 5.4.2).
În cadrul specificațiilor PKM este descris și procesul de obținere a cheilor prin derivare. Prin urmare, KEK se obține prin derivare din AK utilizând ecuația (5.11):[29]
(5.11)
Conform acestei ecuații, AK este concatenată cu , iar rezultatul este trecut printr-o operație logică de sau exclusiv cu . Rezultatul obținut este dispersat cu ajutorul funcției de dispersie SHA-1. Funcția Trunc(128) reține doar primii 128 de biți din rezultatul final, restul fiind înlăturați.
Cheile UL-HMAC și DL-HMAC sunt obținute în același mod ca și KEK cu diferența că funcția Trunc va fi Trunc(160) – astfel încât se vor reține primii 160 de biți din rezultat. Ecuația (5.12) exemplifică modul de derivare, iar Fig. 5.13 oferă viziunea de ansamblu asupra întregului proces de obținere a cheilor din cheia de autentificare [29].
(5.12)
Figura 5.13 Procesul de derivare a cheilor
Cum procesul de transmitere a cheii de autentificare l-am descris deja în capitolul dedicat autentificării, voi descrie în continuare etapele procedurii schimbului de TEK (ilustrat în Fig. 5.14).
Figura 5.14 Schimbul de mesaje pentru transmiterea TEK între SM/SU și SB
Așadar, SM/SU trimite o cerere de TEK numai după ce s-a autentificat. Se elimină astfel posibilitatea ca o stație să primească această cheie fără a avea însă dreptul să o facă.
În mesajul cerere, SM/SU va include numărul de secvență folosit în procesul de autentificare (numărul care asigură separarea între două AK succesive). Alături de acesta, tot în cadrul acestui mesaj se vor trimite și identificatorii pentru parametrii SA vizați pentru a fi criptați cu ajutorul cheii cerute.
Prin urmare, vom avea câte o cheie de criptare a traficului pentru fiecare SA. Deși, inițial, se agrease pentru o singură cheie la nivel de trafic per SM/SU, grupul IEEE pentru 802.16 a ajuns la concluzia că este mai bine, din punct de vedere al securității, să existe o TEK pentru fiecare SA, deci pentru fiecare conexiune realizată de SM/SU cu SB. Practic, fiecare conexiune (cu CID propriu) realizată de SM/SU cu SB va avea propria cheie de criptare pentru traficul asociat.
Răspunsul SB la cererea adresată va conține TEK criptată după metoda descrisă de mine anterior, durata de viață a TEK, vectorul de inițializare utilizat de criptarea în modul CBC (proces prin care fiecare bloc dintr-un mesaj este supus unei operații de sau exclusiv cu blocul anterior) precum și codului de autentificare HMAC deja explicat în subcapitolul dedicat acestei funcții din cadrul autentificării.
Trebuie spus că tot acest proces de cerere/răspuns pentru TEK se desfășoară periodic pentru a se asigura o reîmprospătare a cheii de criptare a traficului. În cazul acesta (de periodicitate), singura valoare care se modifică este cea a contorului legat de timpul de viață al cheii (contor a cărui valoare, evident, se va micșora).
Problema care apare în acest punct este legată tocmai de această periodicitate a schimbului de TEK.
Scenariul este relativ simplu – dacă un atacator reușește să își dea seama de perioada cu care se repetă procesul și va captura mesajele ca atare, teoretic, va putea să își dea seama, eliminând câmpul cu durata de viață, care sunt celelalte câmpuri componente. Odată identificate, aceste câmpuri pot fi supuse decriptării și, implicit, dezvăluirii informației [44].
Am spus teoretic pentru că, așa cum am văzut, criptarea TEK se realizează cu ajutorul KEK, care la rândul ei este derivată din AK.
Cheia de autentificare (AK) este dependentă de certificatele (X509) și, mai apoi, de parametrii reuniți sub numele de SA.
Dacă toate certificatele sunt unice per SM/SU, SA este unic per conexiune, iar o SM/SU poate avea multe conexiuni cu SB.
Prin urmare, este extrem de greu ca atacatorul să izoleze, mai întâi, mesajele trimise către o anumită SM/SU, apoi să izoleze conexiunea, pentru ca mai apoi să identifice AK și, urmând etapele descrise anterior în ordine inversă, să poată decripta și afla TEK. Plus că durata de viață pentru o cheie de criptare a traficului poate fi între 30 de minute și maxim 7 zile, reducând și mai mult posibilitățile atacatorului.
Totuși, în tot acest proces de schimb de chei asigurat de PKM versiunea 1, trebuie luată în calcul și posibilitatea ca stația client să fie una mobilă.
Deși, pe tot parcursul descrierii acestui protocol, nu am făcut distincția între SM și SU, trebuie menționat faptul că IEEE 802.16e-2005 (pentru mobilitate) definește o nouă versiune pentru acest protocol – denumită PKM versiunea 2 – care, pornind de la versiunea anterioară, oferă câteva modificări necesare pentru cazul unui utilizator mobil.
Așadar, deși am considerat că PKMv1 se poate aplica și pentru SM (în cazul special – cum ar fi deplasarea la viteză mică), pentru varianta de mobilitate totală, PKMv2 este cel care asigură toate operațiunile necesare schimbului de chei și algorimului de criptare a MPDU.
PKM versiunea 2
Pentru această versiune, mă voi referi doar la stații mobile SM ca fiind implicate în procesul de comunicație coordonat de acest protocol – definit doar în varianta IEEE 802.16e-2005.
Una dintre cele mai importante modificări pe care le aduce această versiune este legată de autentificarea mutuală între SM și SB. Acest nou proces este ilustrat în Fig. 5.15.
Figura 5.15 Procesul de autentificare mutuală între SB și SM
Etapele acestui proces sunt următoarele:
SB verifică identitatea SM și mai apoi autentifică SM
SM verifică identitatea SB și mai apoi autentifică SB
SB trimite SM o cheie de autentificare AK, iar apoi KEK și cheile UL-HMAC și DL-HMAC sunt derivate din AK
SB trimite lista de SA pentru conexiunile stabilite, precum și identificatorii necesari pentru SM pentru a obține TEK
De fapt, care sunt elementele care apar în plus față de procesul de autentificare valabil pentru PKMv1?
În primul rând, după cum îi spune și numele, este vorba de un proces de autentificare mutuală.[45] Aceasta înseamnă că și SM va trebui să autentifice SB. Prin urmare, certificatul SB va trebui transmis și către SM.
După cum se poate observa și din Fig. 5.14, în mesajul de răspuns SB va include și propriul certificat, pentru ca apoi SM să poată autentifica SB.
Mesajul inițial de informare (în care SM trimite propriul certificat) va rămâne nemodificat. Mesajul cerere va conține, în plus, un număr generat aleator (NAs) pe 64 de biți. Acest număr va fi returnat către SM, în mesajul de răspuns, alături de un alt număr generat aleator (NAb), de certificatul X509 al SB și de semnătura electronică a SB (SGN(SB)). Cele două numere generate aleator sunt incluse în ambele mesaje tocmai pentru a fi verificate atât de SB cât și de SM pentru a asigura veridicitate mesajului. În plus, vom avea întâi o cheie de autorizare primară – Primary AK (PAK), urmând ca, din aceasta, să se obțină AK final prin două metode de derivare – unul bazat pe EAP (Extensible Authetication Protocol) și unul bazat pe algoritmul de criptare RSA.
Procesul de derivare al cheilor se schimbă și el, aceasta fiind o altă modificare pe care versiunea 2 a PKM o aduce față de versiunea 1.
În acest caz, PKMv2 introduce un mod de tratare al cheilor și anume modul ierarhic.[45] Procesul de autentificare va duce la generarea unei chei (PAK) care va fi considerată ca fiind nivelul de bază, „rădăcina” întregului eșafodaj de chei, așa cum este ilustrat și în Fig. 5.16.
Figura 5.16 Piramida obținerii cheilor în cazul PKMv2
Cheia următoare din piramidă – AK – se va obține cu ajutorul algoritmului Dot16KDF (descris în Anexa A).
Așa cum menționam, există două metode de derivare. Voi prezenta în continuare modul de obținere a AK cu ajutorul acestor două metode. AK va constitui următorul nivel din ierarhia de obținere a cheilor. Practic, obținerea AK este încă o noutate introdusă de PKMv2, toate celelalte chei obținându-se, mai apoi, la fel ca în cazul PKMv1.
Înainte de a prezenta cele două metode, trebuie să fac o mențiune – în unele cărți de specialitate, se vorbește despre existența unei a treia chei apăruta în procesul de autentificare. Este vorba de o pre-cheie de autorizare primară. Standardul nu menționează specific acest lucru și majoritatea documentațiilor pentru implementări nu fac referire la această pre-cheie. Prin urmare, este și convingerea mea că nu avem decât o singură cheie anterioară cheii de autentificare – cheia primară de autorizare (PAK).
Voi prezenta mai întâi metoda bazată pe protocolul extensibil de autentificare (EAP).
În cadrul acestei metode, se va folosi o nouă cheie specifică de 160 de biți, denumită cheie de integritate pentru EAP (EIK – EAP Integrity Key). Această cheie este derivată din PAK și este folosită pentru a proteja primul grup de mesaje de control pentru EAP schimbate între SM și SB [45].
În urma acestui schimb, mai apare o nouă cheie de 512 biți – MSK – Master Session Key – utilizată atât de SB și SM, cât și, eventual, de un server de AAA. Această cheie este folosită și în procesul generării unei noi chei denumită PMK – Pairwise Master Key -, o cheie specifică autentificărilor mutuale. Ea este cea care permite realizarea așa-numitului mod pereche [45], care precede etapa finală de stabilire a unei legături autentificate între SB și SM. PMK se obține prin trunchierea MSK la 160 de biți. Întreaga procedură este prezentată în Fig. 5.17.
Figura 5.17 Procedeul de obținere a cheii de autentificare AK prin metoda bazată pe EAP
În final, așa cum se poate observa și din figură, utilizând cheia PM (PMK) și aplicând același algoritm Dot16KDF, vom obține cheia de autentificare – AK, și, implicit, prin procedeele deja cunoscute, toate celelalte chei – KEK, Ul-HMAC Key, DL-HMAC Key.
Cea de-a doua metodă de obținere a cheii de autentificare, cea bazată pe algoritmul de criptare RSA, nu mai necesită chei suplimentare așa cum s-a întâmplat pentru metoda descrisă anterior.
După finalizarea procesului de autentificare mutuală, se va obține cheia primară de autorizare – PAK. Utilizând același algoritm Dot16KDF, cu parametrii PAK, adresa MAC a SM și identificatorul SB, vom afla, prin derivare, mai întâi, cheia de autentificare și, mai apoi, toate celelalte chei.
Etapele acestui proces de derivare sunt prezentate în Fig. 5.18.
Figura 5.18 Procesul de obținere a cheii de autentificare prin metoda bazată pe algoritmul de criptare RSA
Criptarea datelor
Din cadrul procesului de asigurare a confidențialității rețelelor WiMAX nu putea lipsi, evident, etapa de criptare a datelor. Versiunea IEEE 802.16d-2001 a stipulat folosirea standardului de criptare a datelor DES (Data Encryption Standard) alături de modul CBC ( Cipher Block Chaining).
Ce înseamnă, de fapt, acest mod de criptare – DES-CBC?
Datele de intrare (ce trebuie criptate) vor trebui multiplicate până când dimensiunea lor va deveni un multiplu de 8 octeți. Biții de umplutură se vor adauga conform unor pași bine definiți.
Astfel, să presupunem că n reprezintă lungimea inițială (în octeți) a datelor de intrare. La sfărșitul mesajului, vom adăuga m octeți unde
m=8-(n mod 8) (5.19)
Fiecare octet va avea ca valoare chiar valoarea lui m. În hexazecimal, aceste valori pot fi 01, 0202, 030303, 04040404, 0505050505, 060606060606, 07070707070707 și 0808080808080808.
Pentru a avea un multiplu de 8 ca și dimensiune, datele inițiale pot primi de la 1 la 8 octeți adiționali. Acești octeți pot fi eliminați fără probleme în cadrul procesului de decriptare.
Procesul de criptare conform DES-CBC necesită folosirea unei chei de criptare de 64 de biți. Din acești 64 de biți, 56 sunt folosiți efectiv de procesul de criptare, iar 8 biți sunt biți de paritate, cu câte un bit de paritate în fiecare octet, aflat la sfârșitul acestuia (ultimul bit din dreapta). Folosirea acestor biți este recomandată mai ales pentru depistarea eventualelor erori ce pot surveni în procesul de decriptare. În cazul în care erorile pot fi semnalate și cu ajutorul altor mijloace (spre exemplu, PKCS – Public Key Cryptography Standard, standard creat și publicat de RSA, divizia responsabilă cu inventarea metodei de criptare cu același nume), atunci cei 8 biți menționați anterior nu vor mai avea nici o semnificație. Însă, ei vor fi în continuare transmiși în cadrul cheii de criptare astfel încât aceasta își va păstra dimensiunea de 64 de biți.
Alături de această cheie, procesul de criptare bazat pe DES-CBC necesită și un vector de inițializare – IV (Initialization Vector) – tot pe 64 de biți. Acest vector va fi calculat în mod diferit în funcție de datele ce vor fi criptate.
Pentru cazul nostru – rețelele WiMAX, respectiv versiunea IEEE 802.16d-2001 a standardului – criptarea bazată pe DES-CBC se va folosi doar pentru criptarea informației utile a MPDU, nu și a antetului generic sau a câmpului de CRC.
Vectorul de inițializare – IV – se va obține prin intermediul unei operații logice de sau exlusiv între vectorul de inițializare al grupului SA și conținutul câmpului de sincronizare de la nivel fizic. Procesul de criptare bazat pe DES-CBC va folosi acest IV alături de cheia de criptare a traficului (TEK) din cadrul SA pentru a cripta informația utilă a MPDU. Bitul de control al criptării (EC) din cadrul antetului va avea valoarea 1 pentru a semnala că informația utilă este criptată. Câmpul corespunzător EKS (tot din antet) va lua valoarea indexului TEK pentru a semnala că, în cadrul criptării, a fost folosită și cheia de criptare a traficului. Dacă se va folosi și CRC – cod detector/corector de erori, acest lucru va fi semnalat tot în cadrul antetului folosind valoare 1 pentru câmpul CI.
Procesul de criptare bazat pe DES-CBC este prezentat în Fig. 5.20.
Figura 5.20 Procesul de criptare al MPDU bazat pe DES-CBC
Versiunea IEEE802.16e-2005 a standardului introduce un nou proces de criptare, bazat pe AES – Advanced Encryption Standard (Standard Avansat de Criptare). S-a definit utilizarea AES în patru moduri. Este vorba de modul CBC – prezentat anterior- modul de criptare pe bază de contor (CTR – Counter Encryption), modul CTR combinat cu modul CBC – care poartă denumirea de CCM – Counter CBC-MAC și modul ECB (Electronic Code Book) [67][45].
Modul CTR este considerat ca fiind mai bun decât modul CBC – folosit inițial datorită unei implementări mult mai ușoare precum și a capacității de a lucra pe mai multe direcții (procese) paralele simultan. Astfel, încărcarea procesorului care asigură suportul criptării bazate pe AES este mult mai mică, iar numărul de operații efectuate – și, implicit, numărul de blocuri procesate – crește. Modul CCM adaugă avantajelor oferite de CTR încă unul – posibilitatea de a verifica autenticitatea unui mesaj obținut în urma procesului de criptare bazat pe AES-CTR. Acesta este și modul cel mai des utilizat în rețelele WiMAX.
Ultimul mod – ECB – este folosit pentru criptarea cheilor de criptare a traficului.
Înainte de a prezenta cum funcționează efectiv criptarea bazată pe AES-CCM, voi prezenta considerentele ce au stat la baza deciziei de a adopta un nou standard, precum și caracteristicile generale ale acestuia.
Deoarece DES devenise vulnerabil datorită lungimii prea mici a cheii, NIST a recomandat utilizarea 3DES, un algoritm care constă în esență în aplicarea de trei ori a DES. Deși 3DES s-a dovedit a fi un algoritm puternic, el a fost relativ lent în implementări, motiv pentru care NIST a lansat în 1997 o cerere de propuneri pentru un algoritm care să-l înlocuiască. Criteriile pe baza cărora au fost evaluate propunerile pentru AES au fost securitatea (rezistența la atacuri criptanalitice), costurile (eficiența computațională, complexitatea spațială, precum și licențierea liberă și gratuită) și particularitățile algoritmului (flexibilitatea, simplitatea, și ușurința de realizare a implementărilor).
Algoritmul care a îndeplinit, în viziunea NIST, toate aceste criterii este algoritmul propus de doi criptografi belgieni, Joan Daemen și Vincent Rijmen. Denumit de autorii săi Rijndael, acesta este un algoritm de criptare pe blocuri în care lungimea blocului și a cheii puteau fi independente, de 128 de biți, 192 de biți sau 256 de biți.
Specificația AES standardizează toate cele trei dimensiuni posibile pentru lungimea cheii, dar restricționează lungimea blocului la 128 de biți. Astfel, intrarea și ieșirea algoritmilor de criptare și decriptare este un bloc de 128 de biți, iar operațiile AES sunt definite sub formă de operații pe matrice, unde atât cheia, cât și blocul sunt scrise sub formă de matrice. La începutul rulării cifrului, blocul este copiat într-un tablou denumit stare (state), primii patru octeți pe prima coloană, apoi următorii patru pe a doua coloană, și tot așa până la completarea tabloului. Algoritmul modifică la fiecare pas acest tablou de numere denumit stare, și îl furnizează apoi ca ieșire. Pseudocodul algoritmului este prezentat în Anexa B.
Din descrierea realizată prin acest pseudocod, se poate observa că o anumită secvență este realizată iterativ, de un număr Nr. de ori. Acest Nr depinde de lungimea cheii și este 10, 12 sau 14, pentru chei pe 128, 192, respectiv 256 biți.
Acest lucru este foarte important întrucât atacul cel mai realizabil împotriva AES este îndreptat împotriva variantelor Rijndael cu număr redus de iterații. AES are 10 iterații la o cheie de 128 de biți, 12 la cheie de 192 de biți și 14 la cheie de 256 de biți. La nivelul anului 2008, cele mai cunoscute atacuri erau accesibile la 7, 8, respectiv 9 iterații pentru cele trei lungimi ale cheii.
Prin urmare, AES se dovedește a fi o alegere inspirată mai ales când vine vorba de schimbul de date realizat de un utilizator mobil, pentru care transferul de informații de identitate de la o SB la alta este extrem de important și de aceea necesită o criptare foarte puternică.
Revenind la prezentarea funcționării modului CCM pentru AES, trebuie menționat că, pentru acest mod, este necesar ca emițătorul să construiască și să transmită un cadru de ocazie (nonce) folosit o singură dată, unic pentru fiecare pachet. Acest cadru va fi necesar în crearea blocului-contor (necesar pentru CTR).
În cazul IEEE 802.16e-2005, acest cadru, care are 13 octeți, este construit în felul următor: primii 5 octeți (de la 0 la 4) sunt de fapt primii 5 octeți ai antetului MPDU, octeții de la 5 la 8 sunt rezervați și au valoarea 0, iar ultimii 4 octeți (de la 9 la 12) reprezintă numărul pachetului – NP. NP depinde de grupul SA și are valoarea 1 pentru prima conexiune cu primul grup de identificatori de securitate (SA) stabilită.
Componența cadrului de ocazie este prezentată în Fig. 5.21. Cum acest cadru este dependent de antetul generic al MPDU prin intermediul primilor 5 octeți, orice modificare în antet va fi imediat sesizată de receptor – SM.
Figura 5.21 Cadrul de ocazie pentru AES-CCM
Așa cum menționam, unul dintra avantajele acestui mod de criptare îl reprezintă posibilitatea de a autentifica mesajele primite. Acest lucru se realizează prin intermediul unui cod de autentificare specific fiecărui mesaj.
Pentru a crea acest cod, se folosește o variantă a modului CBC. Astfel, în locul folosirii vectorului de inițializare (specific funcției HMAC), în componența codului de autentificare se va regăsi (la începutul acestuia) un bloc specific CBC. Acest bloc este descris în Fig. 5.22 și constă dintr-un marcaj (flag), cadrul de ocazie și un câmp în care este trecută lungimea câmpului de informație utilă al pachetului.
Figura 5.22 Blocul CBC
Pentru a cripta atât informația utilă a MPDU, cât și mesajul ce conține codul de autentificare, se va utiliza modul CTR. Ne aflăm tot în cadrul metodei de criptare bazate pe AES-CCM, însă, așa cum am menționat deja, acest mod este unul extins derivat din modul CTR.
În cadrul acestui mod (CCM), se vor crea un număr de n blocuri-contor, unde n va avea o dimensiune egală cu valoarea lungimii mesajului de criptat plus încă un bloc în plus necesar criptării mesajului de autentificare. Trebuie spus că în cadrul criptării bazate pe AES se folosesc blocuri pe 128 de biți – așa cum a fost restricționat la adoptarea acestui standard.
Primul bloc va fi folosit pentru criptarea mesajului ce conține codul de autentificare, iar toate celelalte blocuri pentru criptarea mesajului de transmis.
Așa cum se poate vedea și din Fig. 5.23, fiecare bloc constă dintr-un marcaj (flag), urmat de cadrul de ocazie și apoi de un contor care arată numărul blocului – contorul poate lua valori de la 0 la n.
Figura 5.23 Bloc contor pentru modul CCM
Fig. 5.24 prezintă crearea codului de autentificare, precum și a mesajului ce va criptat și apoi transmis.
Figura 5.24 Crearea mesajului criptat de autentificare în cadrul AES-CCM
Primul pas în crearea codului de autentificare constă în extragerea câmpului cu informație utilă din MPDU. Acestui câmp îi va fi apoi alipit, la început, primul bloc CBC.
Rezultatul va fi apoi criptat utilizând modul AES-CBC cu ajutorul cheii de criptare a traficului din grupul SA. Din noul rezultat se vor reține numai ultimii 128 de biți (dimensiunea standard a unui bloc AES). Acesta va fi, de fapt, codul de autentificare.
Pentru a obține mesajul propriu-zis de autentificare criptat, se va realiza o operație logică de sau exclusiv cu blocul contor 0 (primul bloc-contor) criptat la rândul lui prin modul AES-CTR.
Emițătorul va cripta apoi mesajul de transmis cu mesajul de autentificare și îl va transmite. Receptorul va primi mesajul și îl va decripta, realizând apoi, în sens invers, operațiile pe care le-am expus deja. Va compara apoi codul de autentificare cu cel recepționat. Dacă sunt identice, mesajul este autentificat. Dacă nu mesajul este șters.
Criptarea informației utile se realizează cu ajutorul blocurilor-contor (de la 1 la n) criptate pe baza modului AES-CTR, folosind aceeași cheie de criptare a traficului care s-a utilizat și la criptarea codului de autentificare.
Câmpul de informație utilă este supus unei operații logice de sau exclusiv cu blocurile criptate, obținându-se un câmp cu informație criptată. Acestuia i se alipește, la început, câmpul cu numărul pachetului. Înaintea acestuia se va pune antetul generic, cu EC=1, iar cu biții de EKS indicând TEK folosită.
În cazul în care se va folosi și cod corector/detector de erori, câmpul de CRC și câmpul specific din antet (CI) vor fi la rândul lor modificate în acest sens. De remarcat că, pentru CRC, el va fi adaptat pentru noua informație utilă.
Procesul de crearea a noii MPDU cu informația utilă criptată prin metoda bazată pe AES-CCM este prezentat în Fig. 5.25.
Figura 5.25 Procesul de creare a unei MPDU cu informația utilă criptată prin metoda bazată pe AES-CCM
PREZENTAREA MODELULUI DE REFERINȚĂ PENTRU ARHITECTURA REȚELELOR WiMAX
Pentru a dezvolta un plan de securitate, trebuie să reținem atât aspectele legate de imunitatea individuală a fiecărei componente, cât și perspectiva globală asupra securității rețelei. În ambele situații, avem nevoie de un model (cum altfel?) de arhitectură a rețelei, care să includă o detaliere a fiecărui modul cât și o prezentare cap-coadă a întregului proces de comunicație.
La începutul acestei lucrări, menționam faptul că tocmai abordarea bazată pe o imagine de ansamblu este cea care a lipsit din procesul de dezvoltare al întregii tehnologii WiMAX și nu numai al aspectelor legate de securitate. Crearea unor specificații (mai mult sau mai puțin complete) pentru nivelul fizic sau pentru nivelul MAC al unei rețele fără fir nu este de ajuns pentru a permite crearea unei arhitecturi operaționale, atât din punctul de vedere al comunicațiilor cât și din punctul de vedere al serviciilor oferite.
Este nevoie de un cadru foarte bine definit al unei arhitecturi de rețea care să permită asigurarea conectivității dorite (IP, ATM etc.), a securității cerute sau a mobilității necesare unor anumite categorii de utilizatori. Sesizând această omisiune, Forumul WiMAX a finalizat în martie 2007 definirea unui model de referință pentru arhitectura rețelelor bazate pe tehnologia WiMAX [27][67]. Tendința către mobilitate era evidentă astfel încât Forumul WiMAX a ales să dezvolte acest model pe baza versiunii IEEE 802.16e-2005 a standardului (cea dedicată WiMAX-ului mobil).
Conform Forumului, dezvoltarea acestui model se face în trei etape. Prima dintre aceste etape înseamnă definirea cerințele atât din punct de vedere utilizator cât și din punct de vedere al serviciilor furnizate, urmând ca în cea de-a doua etapă, pe baza acestor cerințe, să se dezvolte arhitectura de rețea potrivită. În ultima etapă (cea de-a treia) se vor detalia protocoalele de comunicație utilizate în cadrul acestei arhitecturi.
La momentul la care scriu această teză, Forumul WiMAX a finalizat toate cele trei etape pentru prima versiune a acestui model (denumit și Release 1), trecând deja la finalizare primei etape pentru cea de-a doua versiune a modelului (denumită Release 1.5).
În Fig. 5.26 este prezentată această primă versiune a modelului, cu ilustrarea clară a tuturor conexiunilor realizate între diferite interfețe. Forumul WiMAX a folosit în definirea acestui model conceptul de punct de referință (RP – Reference Point) [27]. Acesta desemnează o conexiune virtuală între două grupuri de funcții aparținând de două entități diferite. Aceste puncte de referință nu definesc obligatoriu conexiuni între două interfețe cu funcții diferite (aflate în sisteme diferite). Ele pot „conecta” două entități de același fel.
Figura 5.26 Modelul de referință pentru arhitectura rețelelor WiMAX propus de Forumul WiMAX
Arhitectura prezentată de modelul de referință se poate împărți în 3 module. Primul modul este cel care cuprinde SM – folosite de utilizatori pentru a se conecta la rețea. Cel de-al doilea modul – denumit și ASN (Access Service Network) – cuprinde una sau mai multe SB alături de unul sau mai multe echipamente (ASN GATEWAY) ce asigură legătura între rețeaua radio și rețeaua de interconectare. Acest modul face parte din așa numita rețea de acces a operatorului.
Cel de-al treilea modul – denumit CSN (Connectivity Service Network) – este cel care oferă conectivitate către Internet sau către rețeaua IP de backbone și este deținut de furnizorul de servicii de rețea. Utilizatorul (deci și primul modul) aparține tot acestui furnizor.
Tot în cadrul modelului de referință pentru arhitectura rețelei WiMAX se definesc următoarele conexiuni marcate prin puncte de referință [27]:
R1: SM -> SB
R2: SM -> Server SIP (sau orice alt server de autentificare – H323 – pentru realizarea unor convorbiri de tip IP Multimedia)
R3: ASN -> CSN – conexiune între două module realizată prin intermediul unui server de autentificare (server AAA)
R4: ASN-GW 1 -> ASN-GW 2 – conexiune între două module de același fel realizată prin intermediul celor două gateway-uri
R5: CSN -> CSN – conexiune între două module de legătură cu rețeaua IP de backbone
R6: SB -> ASN-GW
R8: SB -> SB
Voi detalia aceste conexiuni în subcapitolul dedicat descrierii celei de-a treia etape pentru acest model – cea a protocoalelor de comunicație utilizate.
Voi prezenta, în continuare, cele două module (ASN și CSN) din punctul de vedere al funcțiilor pe care ar trebui să le regăsim în cadrul acestora, precum și din punctul de vedere al elementelor componente și al legăturilor dintre ele.
Access Service Network – ASN
În definirea acestei prime versiuni a modelului, Forumul WiMAX a avut în vedere trei profile: [27][67]
Profilul A – în care funcțiile de administrare ale resurselor radio, precum și funcțiile specifice mobilității sunt împărțite între ASN-GW și SB, cu un rol mai important pentru ASN-GW (care va deține controlul de ansamblu)
Profilul B: – în care SB și ASN-GW fac parte din aceeași entitate care va asigura toate funcțiile necesare
Profilul C: – în care funcțiile de administrare ale resurselor radio, precum și funcțiile specifice mobilității, sunt împărțite între ASN-GW și SB, cu un rol mai important pentru SB (care va deține controlul de ansamblu)
Aceste profile au avut în vedere felul în care se va alcătui acest modul de ASN, tocmai pentru a permite o mai mare flexibilitate a întregului model în sine. Observăm că toate aceste profile se referă la alocarea funcțiilor pentru fiecare entitate componentă în parte și nu la funcțiile în sine.
Prin urmare, putem enumera cele mai importante funcții pe care trebuie să le asigure întreg modulul de ASN:
inițierea procesului de descoperire de noi SM (network discovery)
stabilirea conexiunii cu SM (pentru comunicație de nivel 2)
asigurarea comutației pentru conexiunile IP stabilite între SM și CSN
administrarea resurselor radio și a politicilor de alocare a acestor resurse pe baza criteriilor stabilite (criterii de care deja am discutat în capitolele anterioare și care erau bazate pe cerințele de bandă, de QoS etc.)
asigurarea transferului de profil al utilizatorului către serverul de AAA – profil ce va conține informațiile necesare autentificării și autorizării
asigurarea transferului de informații necesare unei comunicații mobile – informații de locație, informații necesare procesului de „predare-primire” (handover) al unei stații dintr-o celulă în alta, dintr-o arie de acoperire în alta etc.
Acestea sunt cele mai importante funcții pe care trebuie să le regăsim în ASN. Este evident faptul că, alături de acestea, celelalte elemente caracteristice nivelului radio se vor regăsi în alte funcții aparținând acestui modul.
Modulul de ASN poate conține una sau mai multe stații de bază (SB) și una sau mai multe ASN-GATEWAY (ASN-GW).
SB este definită ca având unul sau mai multe sectoare cu frecvențe diferite. Ea este cea care realizează comunicația cu SM, bazându-se pe regulile definite de familia de standarde IEEE 802.16. Printre funcțiile pe care SB le îndeplinește sunt cele legate de politicile de alocare de bandă radio, de clasificarea traficului, de aplicarea profilelor pentru calitatea serviciului precum și funcțiile ce țin de procesul de autentificare și autorizare a SM. SB poate fi implicată activ în aceste procese – atunci când vorbim de schimbul de chei de criptare, spre exemplu – sau poate asigura doar funcția de comutator între SM și ASN-GW – pentru mesajele de autentificare, spre exemplu. O SB poate fi conectată la unul sau mai multe ASN-GW.
Printre funcțiile pe care le îndeplinește ASN-GW pot menționa managementul mobilității, stocarea temporară a profilelor pentru utilizatori, administrarea tunelelor stabilite peste rețeaua WiMAX, routarea (atât pentru pachete IPv4 cât și pentru pachete IPv6) către CSN și multe altele. Practic, ASN-GW se comportă ca un administrator al întregii sesiuni – asigurând suportul necesar și funcțiile specifice (client/proxy etc.).
În cazul ASN-GW, funcțiile se pot împărți în două categorii – decizionale (FD) și executorii (FE).
Categoria FD poate include funcții de administrare a resurselor radio, a sesiunii, funcții de management al mobilității, funcții de stocare temporară a cheilor de criptare etc.
Pentru FE, exemplele pot include administrarea tunelelor, managementul politicilor de QoS, routarea pachetelor către CSN.
În tabelul 5.27, sunt prezentate funcțiile îndeplinite de SB si de ASN-GW, împărțite pe categorii generale, precum și în funcție de cele 3 profile adoptate – indicând cine are rolul important pentru funcția și profilul respectiv.
Tabelul 5.27 Tabel de prezentare a funcțiilor principale îndeplinite de modulul ASN
În coloana specifică profilului B, am trecut ASN întrucât SB și ASN-GW vor face parte din aceeași entitate și nu vom mai avea separarea rolurilor precum și o împărțire a responsibilităților.
Toate funcțiile vor fi îndeplinite în cadrul acestei entități.
În plus, am prezentat, așa cum am menționat deja, doar o parte dintre funcții, cele mai importante, considerate de mine esențiale pentru modulul ASN.
Conectivity Service Network – CSN
Acest modul se constituie ca o interfață virtuală pentru întreaga rețea WiMAX către rețeaua magistrală IP sau chiar către Internet. Componența acestui modul este una dinamică și depinde de specificul operatorului care administrează și rețeaua de acces WiMAX.
Astfel, CSN poate conține servere SIP care vor face legătura către întreg sistemul IMS (IP Multimedia), cel care asigură comunicații multimedia și nu numai. De asemenea, în cazul VPN –urilor, putem regăsi în CSN ca și parte componentă un server de e-mail. În plus, în majoritatea cazurilor, serverul AAA nu va lipsi din modulul de care discutăm.
Prin urmare, așa cum ilustrează și numele, acest modul – CSN – este cel care asigură conectivitatea cu rețeaua magistrală, constituindu-se ca un filtru pentru întreaga comunicație
Printre funcțiile pe care le va îndeplini acest modul pot menționa:
alocarea de adrese IP pentru utilizatorii conectați la SM
realizarea operațiunilor de taxare pentru utilizatori (poate conține sistemul de taxare)
asigurarea suportului pentru crearea de tunele care să permită migrarea unui utilizator și comunicația în roaming pentru același utilizator
administrarea accesului pentru diferite categorii de utilizatori la anumite servicii și rețele – pe bază de politici de acces
asigurarea suportului pentru cele trei operații specifice – AAA (Authentication, Authorization, Accounting)
După cum se poate observa, rolul CSN este unul foarte important, fiind asemănător cu rolul firewall-ului dintr-o rețea. Acest modul este cel care asigură un acces corect și structurat din și în afara rețelei WiMAX, oferind și posibilități de personalizare specifice fiecărui operator în parte.
Structura protocoalelor utilizate în modelul de referință
Arhitectura completă propusă de modelul de referință pentru o rețea bazată pe tehnologia WiMAX seamănă foarte mult, din punct de vedere al separării pe nivele logice de protocoale, cu o rețea de acces de tip IP. De fapt, acesta a fost și dorința Forumului WiMAX – tocmai pentru a răspunde tendinței generale de migrare către comunicația de tip IP.
Mai mult, urmărind ultimele conferințe ale unor companii importante din domeniul telecomunicațiilor, nu puteam sa nu observ accentul pus pe migrarea către rețelele IP („Internet Protocol”). S-a vorbit, de fiecare dată, de avantajele pe care le implică aceasta schimbare, toată lumea fiind de acord că rețelele IP reprezintă cea mai buna soluție, indiferent de bucla locală instalată pentru fiecare client în parte.
În acest caz, prin bucla locală înțelegem soluția de legătura între rețeaua clientului și rețeaua principală a furnizorului de servicii de telecomunicații, soluție care poate însemna comunicare fără fir, prin intermediul cablului etc.
Prin urmare, „fundația” unei rețele principale (de „core”) pentru un furnizor de servicii de telecomunicații va fi construită pe „lumea IP” și pe tot ce presupune aceasta. Nu vom insista asupra avantajelor – deja binecunoscute – ale acestei migrări. Ne vom opri, însă, asupra unui aspect foarte interesant, care a fost ignorat, o perioadă, de mai toate companiile de telecomunicații: posibilitatea de a extinde „fundația” IP asupra altor tipuri de rețele. Spre exemplu, rețeaua WiMAX.
Cu ajutorul unei arhitecturi de rețea distribuită, rețeaua WiMAX devine, pentru un utilizator mobil, o extensie a rețelei IP. Utilizând conexiunile de tip IP, furnizorii de servicii pot dezvolta rețele tip „miriapod” (cu un punct de bază principal și multe ramificații) de dimensiuni variate, cu capacități diferite pentru diverse medii – fixe sau mobile.
Ce ar însemna, însă, o arhitectură de rețea WiMAX distribuită și care sunt avantajele unei astfel de implementări?
Trăsătura ei distinctivă este simplitatea. Astfel, o rețea WiMAX distribuită reprezinta o rețea simplă, in care toate elementele sunt „conectate” la un punct central (retea „punct la multipunct”). Acest echipament central este și cel care asigură comunicarea între toate elementele de rețea. Așa cum am menționat deja, este vorba de o comunicație bazată pe IP, acesta fiind și motivul pentru care am considerat rețeaua WiMAX distribuită ca o extensie a modelului rețelei IP.
Două aspecte trebuie subliniate în acest moment:
Comunicația bazată pe IP se regăsește doar la nivelul nodurilor principale ale rețelei – spre exemplu, între stațiile de bază (din reteaua WiMAX) și echipamentul central (router, switch etc) care controlează întreaga rețea și care poate juca rol de ASN-GW.
Comunicația între stațiile de bază și clienți este, evident, una de tip „fără fir” (wireless) și nu depinde în nici un fel de legătura IP pe care am menționat-o anterior.
Avantajele sunt evidente. In primul rând, instalarea unei astfel de rețele se simplifică foarte mult în condițiile migrării către rețele de tip IP. Furnizorii de servicii pot folosi rețelele principale ale marilor operatori de telecomunicații – rețele care sunt sau vor deveni, în cel mai scurt timp posibil, rețele IP.
Apoi, extinderea unei rețele WiMAX distribuite este foarte ușor de realizat. Se pot adăuga oricât de multe noduri principale ale rețelei, singura problemă fiind legată de capacitatea echipamentului central. Însă, și în acest caz, mai apare o soluție foarte simplă, folosită deja în rețelele actuale și anume segmentarea, împărțirea rețelei mari în subrețele. Dacă am glumi puțin, aș putea spune ca se va folosi vechiul principiu „Divide et Impera” – în momentul în care echipamentul central nu mai poate gestiona rețeaua datorită complexității, aceasta se poate diviza în mai multe subrețele, „conduse” la rândul lor de alte elemente centrale (de mai mici dimensiuni). Astfel, echipamentul central principal nu va mai trebui să facă față unui număr foarte mare de cereri, multe dintre ele fiind rezolvate de către „aghiotanți”.
In acest mod, se vor evita congestiile, pierderile și întârzierile de trafic care pot apărea. In plus, controlul unei astfel de rețele divizate se face mult mai ușor fiind vorba de o singură platformă de administrare (asociată nodului central) pentru toate modulele importante ale rețelei.
Acest mod de organizare este specific unei componențe a ASN de tipul „mai multe SB și un ASN-GW”, alături de o rețea de legătură între acestea.
Un alt avantaj foarte important este cel legat de mobilitate. Principala problemă care apare în cazul mobilității este legată de transferul informațiilor de autentificare pentru un utilizator „în mișcare” între stațiile de bază în raza cărora se află, la un anumit moment, utilizatorul. Pentru rețeaua WiMAX distribuită (ce are la baza comunicația de tip IP), prezența unui echipament central care poate distribui mult mai ușor aceste informații (profile de utilizator etc.) între elementele rețelei (stațiile de bază – în cazul nostru) se constituie ca un atu. Procesul de transfer al informațiilor este mult simplificat si, cu ajutorul unor proceduri deja descrise în nodul central al rețelei, se pot dezvolta scenarii optimizate de comunicare, reducându-se astfel latența și timpul de transfer.
Nu am putea omite, în momentul descrierii avantajelor unei astfel de arhitecturi, posibilitatea implementării și controlului riguros al calității serviciului.
În condițiile dezvoltării continue a tipurilor de servicii oferite, parametrii de calitate ce însoțesc aceste servicii au devenit foarte complecși și foarte variați. Obligațiile contractuale ale furnizorului de servicii (în ceea ce privește calitatea serviciului) – SLA (Service-Level Agreement) – sunt foarte stricte și clare astfel încât controlul total și permanent al QoS este absolut necesar.
Prin urmare, alegerea Forumului WiMAX referitoare la similitudinile dintre modelul oferit și arhitectura unei rețele de acces tip IP este îndreptățită.
În ambele arhitecturi va exista un nivel de legătură care va fi folosit pentru concentrarea traficului provenit de la utilizatorii individuali. Acest nivel va conține și o entitate care se va ocupa de alocarea adreselor IP pentru acești utilizatori astfel încât aceștia să poată accesa aplicații și servicii specifice IP.
Pentru modelul de referință, ASN va fi modulul ce va îndeplini rolul de concentrator de trafic [27][67], iar CSN este cel care va face managementul adreselor IP, asigurând și accesul la aplicații și servicii. Legătura dintre ASN și CSN se va face, așa cum am arătat, prin intermediul ASN-GW și a unei rețele IP de conexiune între ASN-GW și modulul de CSN. Fig. 5.28 ilustrează tocmai structura pe nivele a arhitecturii propuse de modelul de referință, ținând cont și de conceptul de arhitectura de rețea distribuită pentru rețeaua WiMAX.
Figura 5.28 Ilustrarea operațiilor logice pentru fiecare modul al modelului de referință propus de Forumul WiMAX
Înainte de a prezenta efectiv protocoalele folosite pentru toate cele trei nivele considerate, voi detalia în tabelul 5.29 punctele de referință ilustrate în Fig. 5.26, ținând cont de specificul interfețelor între care se asigură conexiunea [27].
Tabelul 5.29 Descrierea punctelor de referință prezentate în modelul de referință
Așa cum menționam anterior, arhitectura rețelei WiMAX, prezentată de modelul de referință, se focalizează, în principal, pe comunicații tip IP (cu pachete IP). Totuși, ea este capabilă să transporte și pachete Ethernet. Pentru cazul IP, transportul se realizează prin intermediul subnivelul de convergență IP (IP-CS – IP Convergence Sublayer) peste IEEE 802.16e. Pentru cel de-al doilea caz (pachete Ethernet), rolul de bază îl va avea ETH-CS – subnivelul de convergență Ethernet peste IEEE 802.16e.
În figurile 5.30 și 5.31 sunt prezentate stivele de protocoale, precum și nivele implicate în comunicația IP (vezi Fig. 5.30) și Ethernet (vezi Fig. 5.31).
Trebuie menționat că, în interiorul ASN, direcționarea pachetelor se realizează prin intermediul rețelei de legătură (care se poate observa și în Fig. 5.28) dintre SB și ASN-GW, iar această rețea poate conține router-e sau bridge-uri. În figurile prezentate de mine, în cazul unei rețele cu bridge, nivelele reprezentate prin linie punctată pot lipsi.
În plus, pentru primul modul al arhitecturii (cel care conține SM), am făcut o diferențiere clară între planul de control și cel de transmisiune al datelor.
Figura 5.30 Stiva de protocoale și de nivele (comunicație IP) pentru fiecare modul al modelului de referință propus de Forumul WiMAX
Figura 5.31 Stiva de protocoale și de nivele (comunicație Ethernet) pentru fiecare modul al modelului de referință propus de Forumul WiMAX
Combinațiile sunt posibile astfel încât putem avea situația ca pachetele Ethernet să fie transportate către CSN utilizând subnivelul de convergență Ethernet și un protocol de încapsulare (cum ar fi GRE – Generic Routing Encapsulation). Acest tip de comunicație poate fi folosit pentru furnizarea serviciilor tip VLAN (Virtual Local Area Network).
Securitatea în cadrul modelului de referință
Din prezentarea arhitecturii oferite de modelul de referință (versiunea 1) nu putea să lipsească, evident, componenta esențială care face și obiectul acestei teze – și anume, securitatea. Din acest punct de vedere, modelul de referință a fost proiectat în conformitate cu toate cerințele prezente în versiunea IEEE 802.16e-2005. Interesant este faptul că, deși are la bază această versiune, așa cum am arătat în capitolele anterioare, din punct de vedere al securității, modelul de referință acoperă și specificațiile versiuni IEEE 802.16d-2001. Este un fapt demonstrat că toate noile caracteristici adăugate în versiunea dedicată mobilității se constituie ca o continuare a cerințelor inițiale dezvoltate pentru versiunea 802.16d („WiMAX fix”).
Prin urmare, chiar dacă arhitectura prezentată de modelul de referință se axează pe conceptul de mobilitate, pentru partea de securitate, cel puțin, o putem considera valabilă și în cazul unui stații utilizator fixe (ca un caz particular).Tot la începutul capitolului menționam că definiția acestei versiuni a modelului are la bază și regulile menționate de unele RFC (Request For Comment) aparținând IETF. Este cazul procesului de autentificare – autorizare, care are la bază cadrul AAA creat de IETF prin intermediul RFC-urilor (RFC 5154, RFC 5181, RFC 2904 etc.) [23][67]. Așadar, datorită acestui lucru, există câteva funcții pe care cadrul de lucru pentru procesele de AAA (bazat pe RFC) trebuie să le îndeplinească pentru a fi în concordanță (compliant) cu cerințele impuse de Forumul WiMAX. Printre aceastea menționez [29][67]:
Să asigure suport pentru autentificarea mutuală, bazată pe PKMv2 (așa cum este acest protocol în IEEE 802.16e-2005)
Să ofere suport pentru autentificare bazată pe mecanisme multiple – cum ar fi carduri SIM (Subscriber Identity Module), parole specifice, certificate X.509 etc.
Să asigure suport pentru mobilitate – incluzând transferul detaliilor de autentificare și autorizare între server-ele AAA aparținând de CSN diferite
Să ofere suport pentru atât pentru IPv4 cât și pentru IPv6
Să asigure transferul profilelor de securitate (politici, informații de identificare) de la server-ul AAA către echipamentele specifice din ASN și CSN (cum ar fi ASN-GW)
Forumul WiMAX a ajuns la concluzia că, pentru prima versiune a modelului de referință, cadrul pentru procesul AAA este definit cel mai bine în RFC 2904. Acest cadru se construiește în 4 etape [23], ce se regăsesc și ca pași de bază în procesul de autentificare.
Etapele sunt următoarele:
SM va trimite o cerere de autentificare către un server de acces aflat în ASN
Server-ul de acces va trimite apoi cererea către server-ul de AAA aflat în CSN. Server-ul de acces va deveni astfel client pentru server-ul de AAA.
Server-ul de AAA evaluează cererea și va trimite răspunsul către client – server-ul de acces
Server-ul de acces activează serviciul (în caz de răspuns afirmativ) rezervat pentru SM și anunță SM.
Fig. 5.32 ilustrează cele patru etape pentru modelul de referință.
Figura 5.32 Etapele procesului de autentificare pentru modelul de referință (ținând cont de cadrul creat pentru procesul de AAA)
Trebuie menționat faptul că server-ul de acces reprezintă, de fapt, o entitate care va îndeplini mai multe funcții, printre care cea de autentificator, de client pentru protocolul MIP (Mobile IP), de administrator pentru fluxurile asociate serviciilor de comunicație (service flow) etc. Această entitate se va afla în ASN, dar poate fi compusă din mai multe echipamente specifice.
În plus, datorită acestor funcții, procesul de AAA susținut de cadrul prezentat anterior va fi folosit nu numai în autentificare, ci și în managementul mobilității precum și în control calității serviciului.
Proceduri și protocoale de securitate pentru modelul de referință
În cadrul rețelei WiMAX, așa cum am arătat deja, vom regăsi procese de autentificare atât pentru utilizatorul în sine cât și pentru echipamentul pe care acesta îl folosește pentru comunicație. Operatorii pot decide să implementeze ambele categorii sau numai una, la alegere (utilizator sau echipament).
În cadrul versiunii IEEE 802.16e-2005, procesul de autentificare (vezi subcapitolul 5.4) folosește ca și protocol combinația dintre PKMv2 și EAP (Extensible Authentication Protocol) denumită PKMv2-EAP.
Schimbul de mesaje bazat pe acest protocol se realizează între SM și SB. Dacă vorbim de alte profile decât profilul B (în care SB și ASN-GW sunt parte din aceeași entitate), iar autentificarea nu se realizează în SB, SB se va comporta ca și agent al echipamentului care va face autentificarea. Prin urmare, utilizând un protocol de autentificare compatibil cu conexiunea definită de punctul de referință R6, SB va trimite cererea de autentificare provenită de la SM către echipamentul ce îndeplinește această funcție. Mesajul este încapsulat într-un mesaj specific AAA și va ajunge, în final, la server-ul de AAA din CSN.
Se pot utiliza (vezi subcapitolul 5.4.4) mai multe metode de autentificare bazate pe mai multe variante pentru EAP – EAP-AKA (Authentication and Key Agreement), EAP-TLS, EAP-SIM etc. Mai mult, se poate folosi și varianta securizării întregului proces de autentificare prin crearea unui tunel de la utilizator până la server-ul de autentificare. În Fig. 5.33 este prezentată stiva de protocoale utilizată în procesul de autentificare în cadrul modelului de referință propus de Forumul WiMAX [27][23][67]. Am realizat, în această figură, o diferențiere după echipamentul implicat în fiecare pas. Menționăm că server-ul de acces (de care am mai discutat) este o entitate, care poate conține unul sau mai multe echipamente propriu-zise.
Consecutiv, în Fig. 5.34, sunt ilustrați pașii întregului proces – pași pe care i-am prezentat deja în detaliu în acest capitol al tezei. Prin intermediul acestei figuri, vom putea observa și entitățile, din cadrul arhitecturii definite de modelul de referință, implicate în schimbul de mesaje.
Figura 5.33 Stiva de protocoale utilizată în procesul de autentificare în cadrul modelului de referință propus de Forumul WiMAX
Figura 5.34 Etapele și schimbul de mesaje pentru procesul de autentificare în cadrul modelului de referință propus de Forumul WiMAX
Suportul pentru mobilitate
Una dintre caracteristicile fundamentale ale acestui model o reprezintă suportul pentru WiMAX mobil. Așa cum am menționat pe tot parcursul tezei, mobilitatea aduce câteva cerințe cu impact puternic în securitatea întregii rețele.
Prin urmare, cred că este necesară descrierea suportului pentru mobilitate oferit de către modelul de referință, astfel încât să putem observa limitele de încadrare în ceea ce privește definirea planului de securitate.
Printre cerințele legate de mobilitate, pe care trebuie să le îndeplinească arhitectura definită prin intermediul modelului de referință, putem regăsi:
Minimizarea pierderilor de pachete și a latenței
Respectarea regulilor de securitate definite de IETF prin intermediul RFC
Asigurarea suportului pentru transferul rapid de informație între SB din aceeași rețea
Asigurarea suportului pentru transferul rapid de informație între două rețele diferite (ASN sau CSN)
Oferirea suportului pentru separarea controlului pentru transferul informațiilor față de controlul pentru transmiterea informației. Deși, inițial, aceasta cerință era considerată obligatorie, Forumul WiMAX a revenit și a trecut-o la capitolul recomandări.
Asigurarea suportului pentru IPv4 și IPv6, cu posibilitatea ca un singur server de acces să deservească mai multe SB, folosind mai multe domenii de alocare a adreselor IP (publice sau private)
Asigurarea suportului pentru aplicarea de politici de securitate dinamice astfel încât să fie posibilă aplicarea unor strategii de avarie în caz de compromitere a unei părți din sistem
Arhitectura propusă de modelul de referință are în vedere două categorii pentru mobilitate: [27][29]
Mobilitate intra-ASN sau micromobilitate – în acest caz, SM se va asocia pe rând la mai multe SB aflate în interiorul aceluiași ASN. Practic, calea de comunicație stabilită între utilizator și „ținta” sa din Internet (un server de e-mail, spre exemplu) va rămâne în mare parte acceași, ultimele segmente (legătura radio și cea dintre SB și ASN-GW) fiind singurele care suferă modificări. Transferul informațiilor (așa-numitul handover) se va realiza prin intermediul conexiunilor definite prin punctele de referință R6 și R8
Astfel, transferul datelor va migra pe noua conexiune (R6) specifică noii SB, în timp ce conexiunea dintre cele două SB (R8) va fi folosită pentru a transmite eventualele pachete rămase nelivrate datorită asocierii SM la noua SB.
Mobilitate inter-ASN sau macromobilitate – în acest caz, SM se va asocia la o SB aflată într-un alt ASN. În acest caz, calea de comunicație se va schimba, iar CSN va prelua informațiile pentru această cale. Transferul informațiilor (handover-ul) se va realiza cu predilecție prin intermediul conexiunilor definite prin punctele de referință R3 și R4.
Transferul datelor se va face utilizând conexiunea definită prin R3, iar conexiunea tip R4 va fi utilizată pentru transferul pachetelor rămase nelivrate datorită procesului de migrație.
În Fig. 5.35 este reprezentat acest proces de migrație al SM, structurat în funcție de cele două categorii de mobilitate (micro și macromobilitate) enunțate anterior.
Se poate observa legătura dintre cele două căi de comunicație pentru mobilitatea intra-ASN (punct comun – ASN-GW), precum și diferența dintre căile de comunicație pentru mobilitatea inter-ASN (punct comun – în interiorul CSN).
Figura 5.35 Micromobilitatea și macromobilitatea în cadrul arhitecturii de rețea propusă de modelul de referință
Trebuie menționat că mobilitatea unui utilizator nu are la bază doar criteriul deplasării în spațiu. Scenariile prezentate în Fig. 5.35 pot avea la bază și schimbarea SB pentru un anumit SM datorită condițiilor radio care nu mai permit comunicația în bune condițiuni.
În acest caz, mobilitatea este dictată de alte rațiuni decât cele spațiale și poate fi indusă prin procese de administrare. SM i se va permite să-și aleagă SB la care se va asocia (prin introducerea unor parametrii generali la comisionare), această alegere putându-se modifica în timp (datorită unor factori externi). Această schimbare face parte tot din categoria micromobilității.
Tot datorită unor criterii de management, am putea avea anumite schimbări aparținând mobilității inter-ASN. Cel mai bun exemplu în acest sens este cel al operațiunii de optimizarea încărcării rețelei (load-balancing), care face parte din procesul de optimizare a utilizării resurselor întregii rețele.
În acest caz, calea de comunicație se va modifica (bineînteles și dacă legătura radio o permite), SM fiind redirecționată spre o SB aflată în alt ASN, mai ales dacă ASN-GW este deja supraîncarcat în rețeaua de bază a SM. Operatorul poate alege să preia acest client pe o altă SB mai liberă, evitând astfel congestiile de trafic [29].
Prin urmare, deși percepția este că mobilitatea este strâns legată de deplasarea spațială a utilizatorului, există și alte situații care pot fi considerate ca făcând parte din categoriile enunțate (pentru mobilitate) și pentru care arhitectura definită de modelul de referință trebuie să asigure suport.
Alte considerente
Definirea modelului de referință de către Forumul WiMAX a ținut cont, permanent, de toate aspectele legate de tehnologie și de mobilitate în sine.
În cadrul tezei, eu am prezentat însă detaliile principale strâns legate de partea de securitate, rezervându-mi dreptul ca, pentru anumite amănunte tangențiale scopului nostru, să prezint la momentul respectiv corespondența cu modelul de referință.
Vom regăsi, spre exemplu, aspecte legate de administrarea resurselor radio [27], una dintre funcțiile care trebuie să asigure utilizarea eficientă a resurselor. Sistemul care va îndeplini această funcție va trebui să aibă două componente: un agent de colectare a informațiilor (aflat în fiecare SB din interiorul unui ASN) și o componentă de control aflată fie în SB, fie în ASN-GW, fie într-un echipament separat din interiorul ASN. Practic, agenții vor fi cei care vor transmite informații legate de nivelului semnalului pentru ambele direcții de comunicație (de la SB către SM și viceversa), precum și informații legate de SB vecine. Componenta de control va menține o bază de date cu toate informațiile primite de la agenți, alcătuind o „hartă” a resurselor pentru fiecare zonă acoperită de câte o SB.
Din punctul de vedere al securității, acest aspect va fi important doar din perspectiva depistării zonelor supuse unor atacuri la nivel fizic. Este vorba de atacuri tip bruiaj (interferențe) sau de atacuri tip încărcare excesivă (overload) în care SB este bombardată cu mesaje, depășind astfel capacitatea de procesare și fiind incapabilă să mai comunice cu alte SM. Ajutându-ne de componenta de control a resurselor, precum și de informațiile primite de la agenți, putem aproxima zona atacată și putem decide anumite măsuri în consecință. Trebuie să ținem seama că vorbim de un proces manual, care va face parte din planul pe care mi-am propus să-l definesc.
Un alt aspect poate fi cel legat de managementul puterii [27][29]. Așa cum menționam în capitolele anterioare, un SM se poate afla într-una din următoarele 3 stări: activă, inactivă și de repaus.
Modelul de referință specifică anumite caracteristice legate de toate aceste stări ale unei stații mobile, mai ales din perspectiva faptului că, pentru mobilitate, administrarea puterii este extrem de importantă. Din punctul de vedere al securității, trecerea prin aceste stări poate avea repercusiuni asupra bazei de date aflate la SB cu toate SM asociate.
Există posibilitatea ca, pentru perioada în care o SM autentificată este inactivă, o stație pirat să preia eventualele mesaje primite de la SB. Deși pare o breșă destul de puțin probabilă, trebuie să ținem cont de faptul că tranziția între cele 3 stări este foarte probabilă, ceea ce necesită o sincronizare foarte bună între mesajele de control schimbate de SB și SM aferentă. Prin urmare, componenta de control care face parte din sistemul de management al puterii trebuie să țină cont și de aceste detalii.
Toate aceste aspecte menționate (precum și altele ca ele) vor contribui, mai mult sau mai puțin, la dezvoltarea unui plan de securitate corect și complet.
În același timp trebuie ținut cont de faptul că modelul de referință constituie un punct de plecare de la care se pot obține foarte multe rezultate pentru toate componentele unei arhitecturi de rețea – fie că vorbim de sisteme, fie că vorbim de servicii. În plus, având acest punct de plecare, orice demonstrație se va construi pe un fundament care respectă standardele în vigoare (IEEE 802.16 în cazul nostru), eliminând multe din problemele legate de interoperabilitate sau de extindere.
Acesta este și motivul pentru care, pe parcursul prezentării mele, voi face referiri dese la acest model, urmând, până la un punct, modul de organizare, precum și structura propusă de Forumul WiMAX pentru prima versiune a modelului de referință.
CONCLUZII
În cadrul rețelelor bazate pe tehnologia WiMAX, amenințările din punct de vedere securitate se pot aplica atât la nivel fizic, cât și la nivel MAC.
La nivel fizic, vorbim de atacuri de bruiaj (prin intermediul interferențelor), precum și de atacuri ce duc la blocarea SB – prin trimiterea unei avalanșe de mesaje care determină o creștere a nivelului de procesare al SB până la 100%. Așa cum am menționat și în capitolele anterioare, astfel de atacuri nu pot fi respinse sau prevăzute prin intermediul unor implementări la nivel de tehnologie [44].
Soluțiile de răspuns se bazează pe procese adiacente (triangulația, spre exemplu), pe instrumente adiționale (cum ar fi analizorul spectral) și pe regulile impuse de autoritățile din domeniu – care se ocupă de licențiere și alocare a frecvențelor.
Prin urmare, din punctul de vedere al standardului IEEE 802.16, toate eforturile de asigurare a securității s-au „concentrat” asupra nivelului MAC.
Astfel, măsurile impuse, inițial, în versiunea IEEE 802.16d-2001 au vizat, în primul rând, asigurarea securității proceselor de autorizare și autentificare pentru un nou utilizator ce dorește să intre în rețea, precum și confidențialitatea schimbului de date dintre stația utilizatorului și stația de bază.
În cadrul acestor măsuri s-au identificat, totuși, destule probleme care, în final, determinau breșe și vulnerabilități capabile a fi exploatate de atacatorii mai mult sau mai puțin experimentați. Mă gândesc, în acest caz, la lipsa unei autentificări mutuale ceea ce însemna că SU nu putea verifica SB de la care primise mesajul, fiind expus posibilității de a recepționa și procesa mesaje trimise de o SB falsă. Apoi, dimensiunea cheii de criptare a traficului TEK – pe 2 biți – ridică mari probleme legate de faptul că un atacator ar putea descoperi o breșă datorată reutilizării acestei chei. Durata de viață asociată acestei chei – care poate fi între 30 de minute și 7 zile – în cazul în care este una scurtă, poate aduce cu sine vulnerabilități [44].
Spre exemplu, dacă s-ar considera o durată de viață maximă pentru AK (70 de zile) și minimă pentru TEK (30 minute), ar fi necesare 3360 de TEK diferite, ceea ce ar însemna că TEK ar trebui reprezentată pe 12 biți.
Așa cum s-a demonstrat, modul de criptare DES-CBC devine nesigur în momentul în care operează asupra unui număr de blocuri egal cu , unde n este dimensiunea blocului de date. Din moment ce DES folosește blocuri de 64 de biți, după blocuri, criptarea se va dovedi vulnerabilă. Considerând ratele ridicate de transfer din cazul rețelelor tip WiMAX, criptarea poate deveni una dintre probleme.
Introducerea metodelor de criptare bazate pe AES a determinat găsirea de soluții pentru aceste cazuri, acoperind mare parte din breșe.
De fapt, noua versiune dedicată mobilității – IEEE 802.16e-2005 – a adus cu sine îmbunătățiri în mai multe domenii ale securității rețelelor tip WiMAX.
Autentificarea mutuală, flexibilitatea administrării cheilor, mai ales datorită noii versiuni a protocolului de management (PKMv2), toate au determinat creșterea nivelului de securitate. Totuși, și în acest caz, există breșe, identificate ulterior, care pot determina probleme de funcționare.
Pot da exemplu în acest sens lipsa criptării în cazul mesajelor MAC de management. Astfel, un atacator poate urmări schimbul de mesaje de management dintre SM/SU și SB, poate identifica poziția utilizatorului și, mai apoi, poate exercita un atac asupra acestuia.
Dependența mecanismului de management al cheilor de câmpul EKS, care are 2 biți – deci, teoretic, doar 4 valori posibile – duce iarăși la formarea unei breșe de securitate. Atacatorul poate depista refolosirea cheilor și poate proceda în consecință.
Apoi, dacă pentru criptarea bazată pe modul DES-CBC se utiliza un vector de inițializare generat aleator, pentru PKMv2, vectorul de inițializare se obține, așa cum am arătat, în urma unei operații logice de sau exclusiv între IV din SA și câmpul de sincronizare al nivelului fizic – deci într-un mod predictibil. Și cum predicția crește riscurile de securitate – fapt deja demonstrat – PKMv2 nu se dovedește a fi atât de infailibil cum se spera.
Totuși, dincolo de aceste detalii legate de eventualele breșe de securitate – identificate la o analiză punctuală a fiecărei componentă a nivelului MAC – mai există un aspect, ignorat în mare parte, legat de tot acest domeniu al securității rețelelor fără fir (în special, rețele tip WiMAX). Este vorba de perspectiva globală asupra securității rețelei, perspectivă ce se poate traduce, în final, într-un plan de securitate.
De ce ar fi nevoie de această perspectivă, de acest plan de securitate? Care sunt componentele lui – specifice rețelelor fără fir și, mai ales, rețelelor tip WiMAX?
Răspunsul la aceste întrebări și la multe altele le voi da în ultima parte a lucrării mele, care va oferi o viziune completă asupra a ceea ce eu am numit – plan de securitate interdependent.
CAPITOLUL 6
DEFINIREA UNUI NOU PLAN DE SECURITATE PENTRU REȚELELE FĂRĂ FIR BAZATE PE TEHNOLOGIA WiMAX
INTRODUCERE
Acest ultim capitol oferă cea mai importantă parte a tezei – construirea planului de securitate pentru o rețea WiMAX și definirea unui protocol de taxare necesar integrării rețelei WiMAX cu platforma de taxare existentă a operatorului. Dincolo de toate aceste rezultate, am înglobat tot în cadrul acestui capitol și mai multe considerente legate de interconectarea rețelelor WiMAX precum și de un subiect actual – Open WiMAX. Aceste ultim subiect este unul dezbătut, fiind destul de sensibil mai ales din perspectiva marilor producători de echipamente.
Capitolul oferă și un exemplu concret al unei rețele al cărei plan de securitate a fost construit tocmai pe baza etapelor descrise de mine. În același timp, mutând discuția de la un nivel mai mare (construire plan pentru rețea) la componente, am adresat zona de taxare (una sensibilă pentru orice rețea și orice tehnologie) în cazul unei noi rețele WiMAX. Utilizând arhitectura unei platforme de taxare (vezi [59], [60]), am imaginat și construit un protocol de taxare (CUANTAX) care să permită unui echipament dedicat WiMAX să devină un sistem (modul) colector de evenimente necesare platformei de taxare (pentru taxarea propriu-zisă a clientului).
În cadrul capitolului, pentru a observa și mai bine avantajele planului de securitate și eficacitatea protocolului de taxare construit, am exemplificat, pe rând, pașii procesului de autentificare pentru un utilizator nou în rețea, oferind, în final, și rezultatele unui experiment realizat în laborator pe baza unei arhitecturi similare celei propuse de planul de securitate. Tot în cadrul prezentării acestor rezultate, am oferit și o mostră de mesaj pentru protocolul CUANTAX sub rezerva (evidentă) a schimbărilor datorate implementării detaliate pe care mi-o propun ca și pas următor.
CADRUl GENERAL
Securitatea unei rețele reprezintă o țintă în permanentă mișcare, o țintă care trebuie urmarită continuu astfel încât rețeaua să asigure confidențialitatea, integritatea și disponibilitatea serviciilor și sistemelor care sunt critice pentru orice rețea de comunicații. Pentru a obține acest deziderat, este necesară definirea unui plan de securitate foarte bine conturat și cât mai complet.
De fapt, această definiție pe care o ofer pentru securitatea unei rețele sintetizează scopul unui plan de securitate. Prin urmare, definiția nu limitează și nu introduce reguli. Ci doar specifică rezultatul final al planului de securitate.
De ce am ales acest fel de abordare, în care să conturez clar doar scopul, nu și mijloacele?
Simplu – planul pe care îl voi construi va fi unul deschis (open). Prin urmare, va putea fi preluat și dezvoltat ulterior de către specialiștii interesați de această arie.
Mai mult, planul de securitate va ține seama doar de regulile impuse de IEEE (prin standarde) și de IETF (prin RFC) și nu de soluțiile proprietare oferite de anumiți producători.
De ce am dorit prezentarea unui nou plan de securitate (pentru rețelele bazate pe tehnologia WiMAX)?
În primul rând, trebuie menționat că majoritatea abordărilor (pentru domeniul securității) au avut în prim plan identificarea eventualelor probleme legate de tehnologia WiMAX în sine. Descoperirea eventualelor breșe de securitate, a vulnerabilităților a avut în vedere doar elementul individual (nivelul MAC în cazul nostru). Același lucru se poate spune și din punct de vedere al soluțiilor și îmbunătățirilor aduse. Ca și exemplu, putem considera versiunea a doua a protocolului de administrare al cheilor (PKMv2).
Deși toată această abordare este lăudabilă, asigurând imunitate individuală (pentru SM/SU și pentru SB), ea nu poate oferi răspunsuri și la probleme legate de securitatea globală a întregii rețele. În plus, experiența arată că, foarte rar, securitatea individuală a fiecărui element component asigură și securitatea întregii rețele.
De cele mai multe ori, planul global de securitate reține ca și fundament toate aceste aspecte ale securității individuale, însă, mai apoi, necesită o construcție foarte elaborată pentru a-și îndeplini scopul pe care îl menționam la începutul capitolului.
Tocmai această latură a lipsit până de curând pentru rețelele bazate pe tehnologia WiMAX. Definirea de către IEEE, în martie 2007, a unui model de referință pentru arhitectura rețelelor WiMAX, urmat de alcătuirea a trei profile standard de interconectare – au constituit primele semnale și în ceea ce privește abordarea unei viziuni globale referitoare la planul de securitate al rețelei. La momentul actual, acest tip de abordare este în plină dezvoltare, iar opinia mea este că planul interdependent de securitate propus va aduce o contribuție în obținerea unor rețele bazate pe tehnologia WiMAX mult mai sigure.
De ce l-am numit interdependent?
Așa cum se poate bănui, rețelele bazate pe tehnologia WiMAX (rețele WiMAX) nu pot fi izolate de restul rețelelor deja implementate – IP, GSM (2G/3G).
Prin urmare, planul de securitate va trebui să țină seama de modul de interacțiune dintre tehnologia WiMAX și celelalte tehnologii, precum și de influența reciprocă pe care acestea o exercită. Există, astfel, o interdependență (dependență reciprocă) între aspectele legate de securitatea rețelelor bazate pe aceste tehnologii.
În plus, același tip de relație îl putem considera și la nivel de elemente componente ale rețelei WiMAX. Asigurarea securității SM/SU depinde de ceea ce am numit securitatea SB (și reciproc).
Așasar, planul de securitate nu poate fi decât unul interdependent, în care elementele individuale sunt în relație de dependență reciprocă cu ele însele, precum și cu elemente din exterior.
De ce un plan deschis (open)?
Tendința generală (atât la nivel de tehnologii, cât și la nivelele superioare – aplicații, arhitecturi) este una de migrare de la soluțiile proprietare, închise și, de multe ori, foarte costisitoare, la soluții open-source. Este evident că nici tehnologia WiMAX nu putea fi ocolită de această tendință, fiind una dintre noile direcții de urmat în dezvoltarea rețelelor WiMAX.
OPEN WiMAX – O NOUĂ TENDINȚĂ
Din punct de vedere strategic, producătorii importanți de echipamente de telecomunicații s-au axat pe implementarea unor tehnologii conforme cu standardele în vigoare, oferind însă soluții “închise”, proprietare – care aduc cu sine mari probleme de interoperabilitate la toate nivelele (fizic, operațional, al serviciilor). Astfel de soluții nu au oferit răspunsul la toate cererile operatorilor, fiind destul de puțin adaptive și, în plus, au creat și o dependență față de furnizorul de echipamente.
Nu exista, totusi, o posibilitate de a realiza un sistem adaptabil care să permită evoluția pentru un operator de la un mediu centrat pe furnizor la unul centrat pe servicii – un mediu în care alegerea echipamentelor se va face exclusiv pe baza dinamicii ofertei de servicii a operatorului?
Ca și răspuns la aceasta întrebare s-a lansat conceptul de “mediu de telecomunicații deschis” si, prin analogie, “tehnologie deschisă” (open). Putem, astfel, vorbi de “Open WIMAX” – o idee revoluționară ce permite operatorilor să aleagă combinația cea mai potrivită de furnizori și parteneri pentru a satisface cât mai bine cerințele propriilor clienți. În acelasi timp, Open WIMAX oferă garanția unei interoperabilități mult mai bune între furnizorii de echipamente (ca și orice tehnologie deschisă), ceea ce nu poate fi decât în avantajul operatorului.
Ce este, însă, Open WIMAX ?
În primul rând, arhitectura de acest tip este una bazată pe IP ce folosește, bineînțeles, ca și tehnologie de acces – tehnologia WiMAX. Această arhitectură de rețea asigură simplitatea, extinderea facilă și controlul riguros al calității serviciului (QoS) – ca să enumer numai câteva din avantajele arhitecturii bazate pe IP. In plus, fiind vorba de WiMAX, este conformă cu standardele IEEE 802.16 și cu normele Forumului WiMAX și asigură nivele de interoperabilitate si adaptabilitate ridicate.
Se oferă, în acest mod, posibilitatea realizării unui ecosistem deschis și complet, care nu va afecta doar echipamentele de telecomunicații ci și interacțiunea tuturor elementelor componente – servicii, echipamente, chiar și experiența utilizatorilor finali.
Apare, evident, necesitatea unor interfețe comune care să asigure comunicarea între diferitele componente ale unui astfel de ecosistem. De asemenea, pentru Open WIMAX nu putem vorbi decât despre WiMAX mobil întrucât partea “fixă” a tehnologiei WIMAX nu asigură nivelul de adaptabilitate dorit.
Interfețele de care vorbeam anterior au fost definite de către grupul NWG (Networking Working Group) [67] aparținând de Forumul WiMAX și iau în considerare necesitatea existenței unui echipament (ASN-GW – “Access service Network Gateway”) care să permită atât interconectarea rețelei de acces radio WiMAX cu reteaua IP a furnizorului de servicii precum și transferul rapid al informațiilor între stațiile de bază din rețele radio diferite. Aceaste caracteristici sunt necesare pentru a asigura atât mobilitatea precum și separarea clară a funcțiilor între rețeaua radio (RAN – Radio Access Network) și rețeaua IP.
Trebuie menționat faptul că NWG subliniază necesitatea ca interfețele ASN-GW să nu fie specifice (proprietare) unui anumit furnizor ci numai conforme cu standardul tocmai pentru a nu ridica probleme de interoperabilitate. Aceste lucruri le-am detaliat deja în momentul în care am prezentat modelul de referință pentru arhitectura rețelei WiMAX – model stabilit, așa cum spuneam, de IEEE în martie 2007.(vezi subcapitolul 5.6)
Care sunt avantajele unei arhitecturi de tip Open WIMAX?
Eliminarea dependenței operatorilor de către un anumit producător reprezintă unul dintre avantajele principale ale sistemului tip Open WIMAX. Se creează astfel o concurență benefică între producători de echipamente, iar operatorii pot alege soluții multi-vendor, apelând la mai multe produse certificate fara a-și face probleme legate de integrarea echipamentelor provenite de la furnizori diferiți.
În același timp, se oferă accesul pe piață și noilor producători de echipamente care, inițial, nu puteau trece de bariera companiilor consacrate în domeniu. Integrarea facilă a oricărui nou echipament permite tocmai eliminarea acestui monopol virtual, încurajând dinamica pieței atât din punctul de vedere al producătorilor cât și din punctul de vedere al operatorilor.
Și, nu în ultimul rând, ca orice sistem “deschis” – putem spune ca încurajează creativitatea și inovația. Așa cum s-a experimentat și în domeniul software, o tehnologie de tip open (deschisă) cunoaște un nivel de dezvoltare mult mai bun decât una proprietară. Contribuțiile aduse de specialiști independenți determină un ritm alert de îmbunătățire a tehnologiei precum și de eliminare a eventualelor slăbiciuni descoperite.Prin urmare, tehnologia în sine nu are decât de caștigat prin abordarea unui astfel de concept.
Evident, alături de toate aceste avantaje specifice, arhitectura tip Open WiMAX oferă și avantajele unei arhitecturi normale. Dintre acestea, amintesc scalabilitatea, optimizarea costurilor în funcție de nivelul implementării, precum și planificarea exactă a etapelor de dezvoltare a rețelei. Integrarea aplicațiilor provenite din surse diferite este simplă și rapidă, oferind posibilitatea implementării de servicii variate ce pot duce la creșterea profitului.
Revenind la definiția planului de securitate, trebuie spus că nu puteam alege o altfel de fundamentare a unui astfel de plan decât una open, care să ofere gradul de generalitate necesar unor astfel de abordări. Cum pasul următor în dezvoltarea rețelelor este cel al sistemelor deschise, orice fel de relaționare la acestea trebuie să țină cont de acest aspect.
În plus, acest plan poate fi îmbunătățit, supunându-se regulii menționate anterior – a ritmului alert de dezvoltare pentru aplicațiile tip open.
INTERCONECTAREA REȚELELOR WIMAX
Nu puteam ignora, ca și parte a fundamentului de construire a unui plan de securitate, metodele de interconectare între rețele WiMAX diferite. Interdependența pe care am tot menționat-o, se va manifesta și în cazul unor rețele WiMAX diferite (aparținând de operatori diferiți, dar folosind aceeași tehnologie), influențând orice încercare de definire a planului de care vorbeam.
De aceea, ar trebui să vedem ce tip de interconectare (din punct de vedere al mediului fizic) ar trebui să folosim între nodurile rețelei (soluția de “backhauling”) astfel încât să putem satisface orice constrângere legată de bandă, QoS (calitatea serviciului), distanță, cost, etc.?
Care sunt avantajele si problemele ce pot apărea in cazul diferitelor soluții alese?
In primul rând, putem grupa opțiunile de realizare a interconectărilor în două mari categorii:
Soluții de tip “wireless (fără fir)”
Soluții cu cablare structurată.
Reprezentative pentru prima categorie sunt soluțiile “punct-la-punct” de bandă largă. In această categorie putem încadra legăturile tip PDH (“Plesiochronous Digital Hierarchy”) care folosesc ca și mediu fizic microundele. Acest tip de legătură permite transportul unor cantități mari de date la rate aproximativ egale la emițător și la receptor. Avantajul este evident – riscul unei supraîncărcări a rețelei de interconectare este foarte mic. Pentru soluțiile WIMAX oferite la ora actuală, capacitatea asigurată de o legătură PDH este suficientă.
Dezavantajul major pentru conexiunile PDH este legat de managementul greoi al echipamentelor. Sistemele de management prezentate de către furnizorii principali de echipamente s-au imbunătațit considerabil de-a lungul timpului. Totuși, timpul de reacție în cazul apariției erorilor este încă mare iar monitorizarea legăturii dificilă.
În același timp, apare așa-numită “problemă a frecvențelor”. Fiind vorba de legături radio, nu putem ignora planificarea spectrului de frecvențe (în cazul nostru fiind vorba de frecvențe de 15GHz, 23 GHz, etc). Din acest motiv, apar probleme legate de interferențe radio ce pot determina fluctuații importante de semnal sau chiar întreruperea temporară a legăturii.
În ciuda dezavantajelor prezentate, comunicațiile PDH sunt folosite pentru asigurarea interconectării rețelelor WIMAX (prin magistrală) în principal datorită capacității de transfer ridicate precum și a scalabilității excelente – creșterea capacității necesită doar un upgrade software ceea ce reduce foarte mult costurile. De asemenea, nu putem ignora avantajul major al comunicațiilor fără fir și anume lipsa unei cablări care se poate dovedi imposibilă în anumite zone datorită condițiilor geografice.
Totuși, în țările în care deja există rețele fixe acoperitoare, sunt preferate, pentru backhauling, soluții din a doua categorie prezentată – și anume, soluții cu cablare structurată.
Fie că este vorba, din punct de vedere al mediului fizic, de cablu ethernet sau de fibra optică, avantajele sunt evidente: fiabilitate crescută, monitorizare în timp real, rata de transfer ridicată (pentru cazul fibrei optice) etc.
Se pune întrebarea, evidentă de-altfel, dacă discutăm numai de avantaje, de ce am luat în considerare și soluțiile radio?
Răspunsul este strâns legat de costuri. Dacă în țările europene sau pe continentul american, rețelele metropolitane de fibră optică sunt deja foarte bine dezvoltate, pentru zonele cu relief nu foarte “primitor” – cum ar fi țările africane, implementarea unei rețele structurate de interconectare ar implica eforturi și costuri foarte mari. De altfel, acesta este și unul din motivele pentru care tehnologia WiMAX a cunoscut o evoluție atât de rapidă.
Prin urmare, în cazul realizării unei rețele magistrală, soluțiile fără fir (radio) sunt apreciate, însă tendința evidentă este de a folosi cât mai mult cablarea structurată.
Dacă, în cazul unui utilizator independent, întreruperea temporară a legăturii radio (datorată unor condiții meteo spre exemplu) cu stația de bază poate determina, eventual, pierderi acceptabile din punct de vedere financiar sau logic (date etc), în cazul întreruperii unei rețele magistrală, pot fi afectate comunicațiile a mii de utilizatori ceea ce ar duce la pierderi masive atât pentru furnizorul de servicii cât și pentru utilizatori.
În cazul unei arhitecturi de rețea distribuită, comunicația (prin magistrală) între nodurile principale ale rețelei este vitală, ea fiind cea care asigură transferul de date între diferite rețele sau părți ale aceleași rețele.
Întreruperea acestor comunicații ar determina izolarea rețelelor ceea ce ar fi similar cu inutilitatea lor – în condițiile în care majoritatea transferurilor nu se fac local ci la distanță. Prin urmare, datorită fiabilității ridicate, soluțiile cu cablare structurată sunt preferate în detrimentul celor fără fir.
Totuși, forțați de evoluția dinamică a pieței telecomunicațiilor, producătorii de echipamente radio au îmbunătățit foarte mult performanțele atât ale echipamentelor cât și ale sistemelor de management.
Prin urmare, așa cum vom vedea, unul dintre elementele esențiale în dezvoltarea unui plan de securitate va fi tocmai legătura dintre SB și următorul element de rețea (un alt SB sau un alt echipament), tocmai prin prisma modului în care se va realiza această legătură precum și prin modul în care se va asigura securitatea acestei conexiuni.
În final, trebuie să menționez că, pentru definirea acestui plan de securitate, vom avea ca parametrii de intrare elementele de securitate prevăzute de standard și deja prezentate în capitolele anterioare, elementele ce țin de securitatea individuală a SM/SU și SB, vulnerabilitățile și breșele deja identificate, precum și altele ce pot apărea pe parcurs, soluțiile oferite deja la aceste amenințări (la nivel MAC). Iar ca rezultate, vom obține o arhitectură de rețea precum și principii de funcționare pentru rețelele WiMAX care se vor baza pe această arhitectură.
PRINCIPIILE CE INTERVIN ÎN DEFINIREA PLANULUI DE SECURITATE
Pentru ca un anumit plan (mai ales unul de securitate) să aibă succes, trebuie ca, atât în definirea lui, cât și în construcția și aplicarea lui, să se respecte câteva principii de bază.
Ținând cont de faptul că printre „produsele” finale va fi și o arhitectură de rețea, devine și mai evident faptul că principiile vor trebui să includă și pe cele importante folosite în definirea unei arhitecturi.
Principiul modularității
Majoritatea descrierilor realizate până acum pentru tehnologia WiMAX (și, evident, și pentru rețelele bazate pe această tehnologie) s-au axat și pe proprietatea acesteia de a suporta o partajare pe nivele și module. Fie că a fost vorba de nivele definite deja de ISO sau de subnivele în cadrul acestor nivele (definite de IEEE), fie că a fost vorba de module de rețea (stabilite convențional), analiza tehnologiei și a rețelelor WiMAX s-a dovedit mult mai ușoară prin intermediul acestei abordări.
În plus, modularitatea permite o varietate de implementări și dezvoltări pentru aceeași tehnologie, obținându-se arhitecturi de rețea distribuite, centralizate sau hibride (o combinație între cele două categorii anterioare).
Pentru un plan de securitate, posibilitatea de a suporta mai multe tipuri de implementări sau dezvoltări reprezintă unul dintre avantajele care nu trebuie să lipsească la evaluarea performanțelor acestuia. Iar pentru un plan deschis (așa cum voi propune în cadrul acestei lucrări), modularitatea este esențială pentru dezvoltarea ulterioară a acestuia. Fiecare categorie de dezvoltatori sau contributori se va putea axa pe modulul la care consideră că poate aduce îmbunătățiri sau modificări, urmând ca integrarea ulterioară a acestuia să fie facilitată tocmai de această structură modulară.
Principiul flexibilității
Orice arhitectură de rețea trebuie să permită personalizări necesare adaptării la specificul unei anumite categorii de clienți. Fie că este vorba de considerente geografice sau de alte considerente, arhitectura rețelei necesită o anumită flexibilitate care, din punctul nostru de vedere, trebuie să se regăsească și în planul de securitate.
Prin urmare, definirea și construirea planului vor ține seama de acest principiu – al flexibilității – pentru ca rezultatele obținute să se încadreze în noile tendințe menționate anterior.
Principiul varietății
La momentul actual, varietatea modelelor reprezintă una dintre trăsăturile de bază pentru orice domeniu (printre care și cel al telecomunicațiilor).
Inițial, construirea unui model care să acopere multe dintre situațiile reale nu s-a dovedit a fi o problemă. Pe măsură ce tehnologiile au evoluat, iar categoriile de utilizatori s-au diversificat, modelul în sine a ajuns să acopere o parte din ce în ce mai redusă a cazurilor reale. Prin urmare, numărul de modele a crescut, alături de varietatea și complexitatea lor.
Planul de securitate pe care eu îl voi propune se dorește a fi un astfel de model pentru domeniul pe care îl reprezintă. Totuși, așa cum vom observa pe parcursul tezei, este destul de greu să găsești numitorul comun – în acest caz modelul general valabil – pentru un plan de securitate. Așadar, este absolut necesar ca planul de securitate să se supuna principiului varietății, permițând ca, prin modificări specifice în anumite zone, să acopere o categorie cât mai largă de situații și cazuri reale. În acest mod, utilitatea planului va crește, iar planul în sine va constitui punctul de plecare pentru dezvoltări ulterioare specifice anumitor implementări din acest domeniu.
Principiul standardizării
Acest principiu poate fi considerat mai mult o cerință. Orice implementare din domeniul telecomunicațiilor, fie că este vorba de o implementare software (aplicații) sau una hardware (rețele) trebuie să se supună standardelor în vigoare. Acest lucru este necesar pentru ca soluția finală oferită să poată fi aplicată indiferent de circumstanțe – producători, zonă geografică etc.
Soluțiile proprietare nu pot conlucra decât în anumite zone specifice, ceea ce determină o arie restrânsă de acoperire pentru acestea. Dorința mea este de a oferi un plan de securitate care să funcționeze indiferent că echipamentele WiMAX aparțin unui anumit producător, iar echipamentele de interconectare unui alt producător.
Prin urmare, standardele IEEE sau RFC (Request For Comment) IETF vor trebui respectate și aplicate în construirea acestui plan.
Este evident faptul că specificul anumitor componente (anumitor tehnologii proprietare) își va pune amprenta asupra întregului edificiu, însă influența lor va fi una limitată.
În plus, așa cum am menționat încă de la început, planul se dorește a fi unul deschis, ceea ce înseamnă reducerea aproape totală a „intervenției” tehnologiilor specifice anumitor producători (și numai lor).
Principiul interoperabilității
Acest principiu reprezintă o continuare a celui anterior. Dacă standardele sunt respectate, interoperabilitatea aplicațiilor va fi în mare parte asigurată.
Tehnologia WiMAX s-a lovit încă de la începuturi de această problemă a interoperabilității. Acesta este și motivul pentru care Forumul WiMAX oferă certificarea WiMAX.
Unul dintre criteriile pentru obținerea acestui certificat îl reprezintă tocmai asigurarea interoperabilității cu alte echipamente atât la nivel hardware cât și la nivel de servicii.
Așadar, și în cazul planului de securitate, trebuie să regăsim același principiu al interoperabilității, mai ales că rețelele WiMAX pot face parte din rețele mult mai mari ce înglobează multe tehnologii (cum ar fi tehnologia GSM) și care au deja o strategie de securitate bine definită. Planul va trebui să fie capabil să se integreze în această strategie și să conlucreze foarte bine cu toate celelalte componente deja existente. Prin urmare, acest principiu este unul foarte important.
Am considerat cele cinci principii prezentate ca fiind cele mai importante pentru definirea unui nou plan de securitate interdependent. Evident, nu sunt singurele principii care ajută la structurarea demonstrației.
Pot aminti și principiul funcționalității – care menționează, printre altele, nevoia unei eficiențe crescute a noului plan -, principiul inovației – care se referă la noile abordări – și multe altele. Au lipsit însă din prezentare tocmai pentru că nu sunt principii noi pentru un plan de securitate, ci fac parte din categoria celor deja cunoscute și care nu pot lipsi din nici o implementare aparținând domeniului telecomunicațiilor.
DEFINIREA PLANULUI INTERDEPENDENT DE SECURITATE
Context
Tot cadrul general pe care l-am creat anterior va contribui la atingerea scopului propus – prezentarea unui plan de securitate, deschis, care să poată constitui un punct de plecare pentru toți operatorii care doresc să dezvolte rețele de tip WiMAX.
La momentul redactării acestei teze, în România, operatorii și furnizorii de servicii au început folosirea tehnologiei WiMAX fără însă a numi oficial rețeaua creată rețea WiMAX. Acest lucru se datorează, în principal, frecvenței folosite. Operatorii au preferat să folosească o parte din banda deja alocată pentru a oferi servicii prin intermediul echipamentelor WiMAX. Autoritatea în domeniu a scos la licitație dreptul de a utiliza spectrul radio în benzile de frecvențe 3600-3800 MHz (una din așa numitele licențe WiMAX), urmând ca și restul să fie puse la vânzare prin licitație în perioada următoare [67].
Deocamdată, implementările au vizat foarte puțin partea de mobilitate, operatorii concentrându-se pe dezvoltarea unei rețele WiMAX de tip fix (IEEE 802.16d-2001). Acest lucru a fost favorizat si de permanentele dezbateri pe marginea procesului de certificare WiMAX impus de Forumul WiMAX.
Practic, acest proces structurat pe mai multe nivele a permis abordări diferite din partea furnizorilor de echipamente.
Imaginată ca o piramidă de nivele, certificarea nu a impus, inițial, o anumită tendință, oferind posibilitatea ca fiecare producător să intre în procesul de certificare de la ce nivel dorește. Se putea alege fie o certificare de nivel 1 – nivel ce se referea în principal la partea radio, fie o certificare de nivel 2 – legat de servicii fie de un nivel superior – nivelul specific aplicațiilor.
Astfel, interoperabilitatea a devenit o problemă, iar, ca și urmare, implementările au întărziat să apară – vorbim de implementări pe scară largă.
Cea mai importantă (până la momentul redactării acestei lucrări) implementare rămâne rețeaua dezvoltată de Sprint-Nextel în SUA. Este una dintre implementările de referință până acum, însă, au început deja să apară semnale și din alte părți.
Un exemplu ar fi Austria, unde WiMAX Telecom a început deja dezvoltarea unei astfel de rețele. Apoi, în Africa de Sud, Telkom se află în stadiu avansat al proiectării și implementării unei rețele WiMAX.
După cum se poate observa, tehnologia WiMAX nu ține cont de criterii geografice sau politice, urmând o evoluție cu un ritm ridicat în ceea ce privește implementările.
Am expus toată această situație pentru a evidenția contextul în care propun implementarea planului de securitate. Aceasta este perioada propice pentru a propune diferite abordări și modele practice (pornind de la teorie) și în care erorile se pot corija mult mai ușor.
Dacă ar fi să facem o paralelă cu dezvoltarea unui software de tip open-source, am putea spune că suntem în perioada de testare specifică versiunii beta (celei de dinainte de prima versiune oficială), perioadă în care toți dezvoltatorii sunt invitați să ofere comentarii, să contribuie la identificarea și soluționarea problemelor.
Aceeași situație o putem considera și în cazul rețelelor WiMAX, astfel încât planul va fi un instrument care va ajuta îmbunătățirea întregii securități a rețelei.
Mod de abordare
Pentru a construi acest plan voi considera o abordare de tip concentric. Ilustrarea acestei abordări se poate regăsi în Fig. 6.1
Figura 6.1 Construirea unui plan de securitate utilizând o abordare de tip concentric
După cum se poate observa, acest tip de abordare plasează utilizatorul în centrul întregii implementări. Nivelele următoare sunt cele corespunzătoare celor din modelul de referință – ASN, CSN – cu mențiunea că, în acest caz, pentru anumite componente diferențierea, din punctul de vedere al plasării în anumite zone, nu mai este atât de clară.
Mă gândesc, în acest caz, la stațiile de bază și la ASN-GW care pot face parte din zone diferite sau pot fi gândite ca un singur echipament care să înglobeze toate funcțiile celor două entități.
Înainte de a continua cu prezentarea acestui mod de abordare și cu dezvoltarea planului în sine, trebuie să remarcăm o contradicție.
În general, planificarea unei rețele precum și implementarea ulterioară urmează o direcție inversă celei propusă de mine. Orice operator și/sau furnizor de servicii își dezvoltă întâi o rețea nucleu (core) foarte puternică capabilă să suporte rate de transfer ridicate și să asigure servicii de interconectare și interoperabilitate între diferite tehnologii [67][29].
Acest mod de implementare este ilustrat în Fig. 6.2.
Figura 6.2 Ilustrarea modului de abordare pentru implementarea unei rețele nucleu pentru operator și/sau furnizor de servicii
Astfel, operatorul implementează un nivel numit nivelul nucleu (core) al întregii rețele, urmând ca apoi, prin intermediul buclei locale, să conecteze viitorii clienți și să le ofere diferite servicii. Așa cum se poate observa, experiența utilizatorului este considerată ca fiind ultima etapă de dezvoltare. În acest fel, operatorul își asigură suportul unei rețele puternice, capabile să ofere serviciile pe care le cere componenta principală a ultimului nivel – utilizatorul.
Acest tip de implementare este una logică și normală, atât din punct de vedere al construcției întregii arhitecturi, cât și din punctul de vedere al unor dezvoltări ulterioare. Extinderea fiecărui nivel (buclă locală, servicii, noi echipamente utilizate) trebuie să beneficieze de un fundament puternic – și anume de un nivel nucleu foarte bine construit și organizat.
Atunci, de ce am ales ca planul de securitate să urmeze aceeași dezvoltare tip concentric, dar în sens invers?
În primul rând, majoritatea atacurilor adresate unei rețele de telecomunicații (cu sau fără fir) vizează, în primul rând, utilizatorul final. Chiar dacă atacul se realizează prin intermediul rețelei operatorului și conține etape în care este îndreptat către echipamente aparținând acestuia, scopul final este accesul la informațiile utilizatorului. Breșele de securitate sunt exploatate pentru a obține informații confidențiale (conturi de bancă, informații specifice unor companii etc) care țin tocmai de utilizatorul final. Prin urmare, cred eu, este normal ca în centrul dezvoltării să se afle utilizatorul. Toate celelalte nivele trebuie să se constituie ca un înveliș de protecție pentru utilizator și să limiteze aproape total eventualele intruziuni și atacuri asupra sistemelor aparținând acestuia. Chiar dacă ținta finală este construirea unui plan pentru securitatea rețelei (așa cum am menționat și în titlul acestei lucrări), am dorit să realizez toată această construcție menținând focusul asupra utilizatorului final – cel care va beneficia de rețea în sine și cel care trebuie protejat.
Datorez acest mod de gândire în principal experienței acumulate în cadrul operatorilor (furnizori de servicii), care construiesc orice nouă capabilitate pentru rețeaua existentă bazându-se pe specificațiile serviciilor pe care le vor oferi clienților și pe baza feedback-ului primit din partea acestora.
Nivelul următor este cel reprezentat de stațiile mobile. Acestea pot fi echipamente specifice unui anumit producător (din domeniul tehnologiei WiMAX) sau echipamente dotate cu chipset-uri specifice acestui tip de comunicație (laptop, PDA etc.).
Așa cum se poate observa, am separat entitatea denumită utilizator de stațiile mobile. Acest lucru este necesar întrucât, în anumite situații, în spatele unei stații mobile se poate afla o întreagă altă rețea (cum ar fi, de exemplu, o rețea Wi-Fi). În sprijinul acestei afirmații putem aduce situația unui tren aflat în mișcare. În interiorul trenului, poate exista o rețea fără fir tip Wi-Fi (bazată pe IEEE 802.11). Toate punctele de acces ale acestei rețele vor fi legate la un echipament de agregare (switch, router) care, la rândul lui, va fi conectat la o stație mobilă WiMAX. Prin intermediul punctelor de acces (Wi-Fi) și, apoi, prin stația mobilă WiMAX și, mai departe, stație de bază etc. călătorii vor putea accesa adrese din Internet sau chiar vor putea, utilizând echipamente specifice, să realizeze convorbiri tip VoIP. Evident, pe măsură ce trenul se deplasează, SM se va asocia cu alte SB din alte rețele aparținând altor operatori. Deci separarea utilizator – SM este în conformitate cu situații reale posibile.
Următorul nivel este cel al stațiilor de bază. Așa cum se poate observa, stațiile de bază sunt figurate separat de ASN-GW.
Din punctul meu de vedere, cele două echipamente trebuie să fie două entități diferite. Pentru a ne asigura că planul de securitate este unul open (așa cum am dorit), cred eu că singurul profil care poate permite acest lucru este profilul C din cele trei propuse de Forumul WiMAX. Acest profil specifică faptul că funcțiile de administrare ale resurselor radio, precum și funcțiile specifice mobilității, sunt împărțite între ASN-GW și SB, cu un rol mai important pentru SB (care va deține controlul de ansamblu).
Pentru profilul B (în care SB și ASN-GW fac parte din aceeași entitate care va implementa toate funcțiile necesare) există riscul să avem de-a face cu o „cutie neagră” în care să nu putem separa funcțiile radio de cele specifice ASN-GW ceea ce ar determina un management dificil pentru componentele de securitate din această zonă. Și, în plus, ar contrazice conceptul de „deschis” (open) pe care l-am impus pentru planul de securitate.
Profilul A (în care funcțiile de administrare ale resurselor radio, precum și funcțiile specifice mobilității, sunt împărțite între ASN-GW și SB, cu un rol mai important pentru ASN-GW care va deține controlul de ansamblu) reduce mult rolul stației de bază, aducând riscul ca managementul puterii (pe care l-am explicat anterior) să nu fie făcut corect, iar SB să capete un rol apropiat de cel al punctului de acces din rețele Wi-Fi (emițător/receptor radio). Cum SB reprezintă una din componentele importante în procesele de autentificare/autorizare, pe care le-am prezentat anterior în detaliu, cred eu că rolul SB în cadrul planului de securitate trebuie să fie unul important.
Mai nou, în versiunea 1.5 al NRM, Forumul WiMAX a renunțat la profilul A, dezvoltând specificațiile doar pentru profilele B și C [52][66]. Prin urmare, așa cum am spus, profilul C este cel mai potrivit.
ASN-GW sunt figurate la granița dintre nivelul stațiilor de bază și nivelul numit generic ASN (deși, în cadrul modelului de referință, ASN includea și stațiile de bază). Motivul este următorul: am considerat că ASN-GW va asigura, în primul rând, legătura între sistemul radio (format din SB și SM) și următoarea componentă din ASN (server-ul de acces). În acest fel, pare că ne depărtăm puțin de la modelul de referință, dar, de fapt, eu urmez scopul – securitatea rețelei – și doresc creșterea rolului server-ului de acces.
Acest server (așa cum am arătat în secțiunea 6.3.4) este definitoriu pentru realizarea cadrului necesar procesului de AAA. Ținând cont de faptul că am în vedere construirea unui plan pentru o rețea comercială (și nu una de laborator), procesul de AAA va fi nelipsit și, prin urmare, foarte important.
Așa cum se poate observa, server-ul de acces este figurat împreună cu serverul care îndeplinea funcțiile pentru procesul de AAA (server-ul de AAA). Forumul WiMAX menționa (conform RFC 2904, vezi sectiunea 6.3.4) că serverul de acces se comportă ca un client pentru server-ul de AAA, el priminind cererile de autentificare de la SM și activând serviciul pentru SM în caz de aprobare a cererii. Eu cred, însă, că totuși cele două servere ar trebui să constituie o singură entitate – eventual un singur echipament cu mai multe module incluse. Nu are rost să sepărăm cele două echipamente și să aducem un risc în plus din punct de vedere al securității (legătura dintre ele, două echipamente care trebuie securizate) în condițiile în care majoritatea echipamentelor de telecomunicații (care sunt axate pe partea de acces/autentificare/autorizare) oferă toate aceste funcții înglobate de la început (cazurile majoritare) sau prin adăugarea unui modul (câteva excepții).
Practic, această entitate (echipament) – care va suplini server-ul de acces și server-ul de AAA – va putea oferi un management unificat al politicilor de securitate [29] – incluzând aici cele de autentificare, de activare a serviciilor sau de gestionare a conturilor de client și a accesului la ele.
Acest echipament va constitui singurul punct de acces între rețeaua WiMAX și rețeaua nucleu a operatorului și va filtra toate cererile de acces pentru realizarea de conexiuni (la Internet, la rețele tip VPN etc.).
Ultimul nivel figurat este cel al celorlalte server-e ( de e-mail, SIP etc.) care precede rețeaua nucleu. Eu cred că toate aceste servere trebuie să fie separate (așa cum se întâmplă și acum) mai ales că unele pot lipsi, în funcție de specificul operatorului.
Aceste servere pot face parte din rețeaua nucleu a operatorului. Însă, cum unele se pot afla spre exemplu, în rețeaua Internet, eu le-am figurat ca aparținând CSN, fidel, oarecum, modelului de referință. Așa cum am spus, acest lucru ține mai mult de specificul rețelei. Putem avea spre exemplu o rețea de tip VPN în care server-ul de mail este în sediul central, iar utilizatorul se va conecta, utilizând tehnologia WiMAX, la rețeaua operatorului pentur a accesa acest server. În acest caz, server-ul de mail nu este în rețeaua nucleu a operatorului, ci se află tot pe nivelul utilizator (dintr-o altă locație). Așadar, nu mai aparține nici măcar de CSN, însă se comportă tot ca o componentă din CSN, filtrând accesul la e-mail-uri pentru utilizatori.
Am considerat că dincolo de acest ultim nivel se află deja rețeaua Internet (sau, în puține cazuri, o rețea magistrală – backbone). Deși, evident, mai sunt câțiva „pași” până acolo (cum ar fi rețeaua nucleu a operatorului), din punctul de vedere al utilizatorului, ea este transparentă, iar din punctul meu de vedere, dorim să construim un plan de securitate pentru rețeaua fără fir (interdependent, într-adevăr) tip WiMAX și nu dorim să intrăm în amănunte legate de securitatea celorlalte rețele care nu sunt legate direct cu aceasta.
Prin urmare, planul de securitate ar presupune arhitectura ilustrată în Fig. 6.3.
Figura 6.3 Arhitectura specifică planului interdependent de securitate
După cum se poate observa, am eliminat două conexiuni marcate prin cele două puncte de referință (specifice modelului de referință) – R8 și R4 – și am adăugat alte două conexiuni marcate prin R9 și R10. Astfel, nu am mai considerat legătura între SB (R8), precum și legătura între două ASN-GW (R4). În plus, am adăugat două noi puncte de referință, care nu apar în modelul de referință. Este vorba de legătura dintre rețeaua utilizatorului/utilizator și SM (R9), precum și de legătura către rețeaua nucleu a operatorului (R10).
Echipamentul marcat prin „Echipament de acces și AAA” este tocmai acel echipament care va îngloba funcțiile server-ului de acces precum și ale server-ului de AAA (separate în modelul de referință).
Am considerat ca o conexiune separată (R9) legătura dintre utilizator (rețea utilizator) și SM tocmai pentru a continua ideea de abordare tip concentric pentru alcătuirea planului de securitate, o abordare având în centrul utilizatorul generic (așa cum am menționat deja).
Părerea mea este că, deși este ignorată, această conexiune (R9) este un element foarte important care nu poate lipsi din nici o strategie de securitate (care se va concretiza într-un plan). Chiar dacă această zonă de rețea (ce face parte din CPE) este independentă de tehnologia WiMAX, eu am avut în vedere (așa cum voi preciza și în prima etapă a planului) ca traficul care intră în rețeaua WiMAX să nu fie deja unul viciat (trafic provenit de la un atacator). Așa cum am menționat, planul de securitate este unul interdependent, deci depinde de planul de securitate pentru rețelele interconectate cu rețeaua WiMAX. Acesta este și motivul pentru care, în planul de securitate, nu am ignorat, așa cum vom vedea, (chiar dacă nu am dezbătut pe larg – din motivele menționate acolo) securitatea rețelei nucleu (principale a operatorului).
Un alt element important este eliminarea legăturilor directe între SB și între ASN-GW. Ele vor comunica numai prin intermediul echipamentului de acces și AAA. Rețeaua de legătură (dintre ASN-GW și echipamentul de acces) nu va permite comunicația directă între ASN-GW. În ceea ce privește SB, ele nu vor avea nici măcar legătură fizică directă (nici radio, nici fixă) astfel încât nu se pune problema unui trafic nefiltrat (de către ASN-GW sau de către alt echipament – așa cum vom vedea ulterior) din punctul de vedere al securității.
Am delimitat (în Fig. 6.3) – utilizând A, B, C, etc. – zonele pe care le voi considera în definirea planului de securitate. Acest lucru, combinat cu un studiu de caz, îmi va permite să evidențiez mult mai ușor avantajele acestui tip de plan (care are ca și rezultat o arhitectură specifică). Am dorit să prezint încă de la început această arhitectură (specifică planului) tocmai pentru a sublinia încă o dată că doresc să avem un rezultat final palpabil, un cadru complet (plan plus arhitectură) care să poată fi aplicat în momentul dezvoltării unei rețele fără fir bazată pe tehnologia WiMAX.
Construirea planului de securitate – etape exemplificate printr-un studiu de caz
Revenind la cele două figuri (6.1 și 6.3), putem observa că prima etapă în definirea acestui plan este strâns legată de utilizatorul generic. Înainte de a detalia aceste etape, trebuie să menționez că, pentru cadrul general, am considerat că rețeaua nucleu a operatorului/furnizorului de servicii este deja implementată. În general, majoritatea operatorilor beneficiază de o rețea de tip IP MPLS pusă deja la punct pentru partea nucleu, iar dezvoltarea unei noi rețele WiMAX se va face din această perspectivă și din dorința de a oferi servicii noi de bandă largă.
Chiar și în cazul apariției unui nou furnizor de servicii, care va debuta chiar cu implementarea unei rețele tip WiMAX, nu constituie o excepție, pentru că este puțin probabil ca, în prealabil, acesta să nu se fi asigurat că beneficiază de suportul unei rețele de interconectare (inclusă în rețeaua nucleu) bine dezvoltată.
Apoi, pentru a exemplifica mult mai ușor etapele de construire pentru acest plan, voi considera și un caz concret. Operatorul Y primește o cerere de interconectare pentru o sută de
locații din partea Companiei (Client) X. Aceste locații sunt într-o arie geografică destul de largă, iar operatorul decide implementarea unei rețele fără fir bazată pe tehnologia WiMAX (mai ales datorită funcționării în NLOS) care să asigure interconectarea locațiilor clientului la rețeaua operatorului. Evident că rețeaua WiMAX dezvoltată va putea fi folosită pentru furnizarea de servicii și pentru alți clienți. Faptul că am ales ca motiv pentru implementarea acestei rețele WiMAX cererea de conectare primită nu limitează, ci dimpotrivă, se apropie de situația reală în care majoritatea operatorilor de telecomunicații nu aleg implementarea unei tehnologii noi decât în cazul în care, în urma unui studiu de piață, se observă o cerere pentru această tehnologie și un beneficiu evident. Eu am substituit această etapă și am oferit direct motivație de implementare.
Revenind la cazul concret, trebuie spus că respectivul client va avea printre alte cerințe, posibilitatea ca anumite locații să nu comunice decât cu un centru zonal, anumiți angajați să se poată autentifica din orice locație și, mai mult, o anumită echipă de consultanți, care beneficiază de echipamente capabile de comunicații WiMAX (laptop, PDA etc) să se poată conecta oricând (chiar și în mers), mai ales că operatorul va construi această rețea WiMAX în așa fel încât să acopere o suprafață mare.
Vom avea mai multe locații răspândite prin toată țara, legate la patru centre zonale (specifice celor patru zone istorice ale României). Locațiile dintr-o anumită zonă nu vor putea comunica decât cu centrul zonal. Centrele zonale pot comunica între ele și, în plus, sunt legate de un sediu central care coordonează tot.
Această organizare este ilustrată în Fig. 6.4. Nu am mai figurat și utilizatorii mobili care vor trebui să se poată conecta de oriunde (în aria de acoperire a rețelei WiMAX) la anumite servere prezente în diferite centre zonale sau locații.
Pornind de la acest proiect și de modul de abordare tip concentric (prezentată în Fig. 6.1), voi dezvolta pas cu pas planul de securitate, precum și arhitectura specifică acestuia (ca și model general)
Figura 6.4 Studiu de caz – interconectarea locațiilor pentru un client prin intermediul unei rețele WiMAX dezvoltate de un operator
Etapa 1 – Nivel utilizator – zona A
În prima parte, pentru securizarea conexiunii marcate R9, operatorul va trebui să se asigure de implementarea unor politici clare de securitate pentru comunicația la nivel de locație client. Deși pare o țintă greu de atins – mai ales prin prisma restricționării accesului la anumite informații (legate de organizarea rețelei interne, politici etc) – operatorul trebuie să responsabilizeze clientul din punctul de vedere al securității.
Pentru a asigura securitatea și fiabilitate comunicației pentru client, operatorul trebuie să se asigure că traficul provenit de la client nu este unul deja viciat (cadre false, atacuri din interior de tip flooding etc). Și, mai ales, trebuie să aducă la cunoștința clientului acest lucru.
Situația este similară celei în care dorim transmiterea unui plic de la domiciliul personal la reședința noastră din altă zonă a țării. Dacă plicul este deja puțin desfăcut (nu este lipit bine), nu are adresa clară sau este deteriorat, riscurile ca el să se piardă sau să fie interceptat și citit cresc foarte mult.
Prin urmare, clientul trebuie să se asigure că traficul care „pleacă” dintr-o locație este în conformitate cu politicile de securitate agreate între cele două părți – operator/furnizor de servicii – client.
Pentru cazul meu, probabil că soluția agreată de interconectare va fi un IP VPN (în care delimitările impuse de comunicare între locații se vor face prin intermediul instanțelor de tip VRF lite – Virtual Routing and Forwarding).
Mai mult, recomandarea operatorului este, ca într-o locație, să existe o singură stație utilizator pentru conectarea la stațiile de bază. Observăm că planul (și arhitectura aferentă) pe care o propunem se adresează implementării unei rețele mixte – WiMAX fix (IEEE 802.16d-2001) și WiMAX mobil (IEEE 802.16e-2005). Pentru conectarea locațiilor se poate folosi o SU (specifică pentru partea fixă a tehnologiei), în timp ce pentru utilizatorii (echipa de consultanți, cum am numit-o eu) conectarea trebuie să se realizeze chiar și dacă se află și într-un tren în mișcare,spre exemplu (ei devenind „stații mobile – SM” specifice părții mobile a tehnologiei WiMAX). În acest fel, aduc încă o dovadă în favoarea diferențierii între nivelul utilizator și nivelul stațiilor utilizator (mobile sau nu) – SM/SU, diferențiere exemplificată în Fig. 6.11.
În momentul în care clientul cunoaște aspectele legate de necesitatea securizării propriului trafic, urmează momentul stabilirii unor politici de securitate pentru interconectare. Acestea se vor referi la modul de acces pentru utilizatori la rețeaua companiei în care lucrează, la accesul pentru utilizatorii mobili, la crearea unor profile specifice în funcție de drepturile pe care le are fiecare angajat.
Ce înseamnă acest lucru?
Pentru fiecare utilizator final, rețeaua operatorului este transparentă. Pentru el, computer-ul la care lucrează este „legat direct” cu server-ul care ține anumite date specifice și care se află în celălalt colț al țării. Dar, pentru ca utilizatorul să poată accesa acest server, dincolo de politicile interne ale companiei, trebuie să primească un acces la această „legătură directă”.
Practic, vorbim de autentificare, autorizare – procesul de AAA. Acest proces se va desfășura în interiorul rețelei operatorului (vom vedea unde) și, prin urmare, modul de autentificare, autorizare etc. trebuie agreat între cele două părți. Toate aceste detalii formează politica de securitate între client și operator.
Operatorul poate furniza, spre exemplu, un model de listă de control pentru client, prin intermediul căreia acesta să poată alege opțiunea cea mai bună pentru politica de securitate comună.
Un exemplu în acest sens este oferit în tabelul 6.15. Acesta este un exemplu sumar, fiecare operator fiind liber să-și personalizeze această listă în funcție de specificul clienților, precum și de serviciile pe care le poate oferi. Astfel, dacă nu dispune de mijloace de monitorizare a traficului, este evident că nu va trebui să regăsim acest punct în listă.
Recomandarea mea este, pe cât posibil, această listă să fie cât mai cuprinzătoare și să acopere cât mai multe aspecte (poate fi una standard aplicată pentru toți clienții). Mai mult, ea poate cuprinde și recomandări organizatorice/administrative sau recomandări tehnice (nu numai de securitate) pentru modul în care clientul alege să-și implementeze propria rețea. Toate acestea vor ajuta la scopul final pe care l-am dorit pentru această etapă – traficul care va „intra” în rețeaua operatorului va fi unul corect și fără problemele menționate.
Pentru exemplul nostru, eu recomand folosirea unei singure stații radio (SU) pentru fiecare locație. Aceasta ar urma să se conecteze cu un echipament de agregare a tuturor celorlalte legături între dispozitivele (laptop-uri, computere, AP etc.) aflate în locația respectivă. Acest echipament poate fi, spre exemplu, un switch sau un router (cu module cu porturi ethernet).
În acest fel, managementul politicilor interne de securitate precum și aplicarea politicii stabilite anterior (între client și operator) se vor desfășura mult mai ușor.
Etapa 2 – nivelul stațiilor radio (SM/SU) și nivelul stațiilor de bază – zona B
În acest moment, putem considera ca prima etapă a planului s-a încheiat și că avem rezultatul scontat („plicul” în stare foarte bună). Operatorul poate trece la dezvoltarea rețelei fără fir bazată pe tehnologia WiMAX.
În cadrul acestei dezvoltări, din punctul de vedere al securității, recomand folosirea tuturor mecanismelor descrise în capitolul 5. Mă refer la utilizarea protocolului PKMv2 (mai ales că avem și mobilitate), a autentificării mutuale, a certificării X509 etc. Cum toate aceste detalii au fost deja prezentate, eu voi insista pe anumite caracteristici importante pentru planul meu de securitate.
În primul rând, recomandarea mea este ca pentru dezvoltarea rețelei WiMAX, operatorul/furnizorul de servicii să folosească echipamente de la un singur producător. Deși aceasta pare că limitează și contravine principiului nostru declarat de open (pentru plan), eu cred că pot apărea probleme de interoperabilitate – certificate diferite etc. Așa cum menționam și la partea dedicată principiilor pentru crearea acestui plan (mai precis, principiul interoperabilității), certificarea WiMAX (a Forumului WiMAX) a ridicat și încă ridică probleme. Faptul că este permis unui producător să intre în procesul de certificare de la un anumit nivel încolo (nu neapărat de la cel fizic) – încă nu ne oferă certitudinea unei funcționări corecte a unei SU aparținând unui producător cu o SB a altui producător. De aici și recomandarea noastră.
Pentru stațiile mobile (laptop-uri dotate cu chipset ce permite comunicația WiMAX), autoritățile în domeniu au dat asigurări că nu se pune problema interoperabilității mai ales că vorbim totuși de mobilitate.
Așadar, revenind, SU (fix) și SB ar trebui să aparțină aceluiași furnizor de echipamente.
A doua caracteristică este cea legată de frecvența de funcționare pentru această rețea radio (rețeaua WiMAX). Deja am discutat despre licențele WiMAX și de dreptul de a folosi un anumit spectru radio. Recomandarea mea este achiziționarea (dacă este posibil, evident) a unei astfel de licențe.
În țara noastră există deja rețele fără fir tip Frequency Hopping sau chiar OFDM care utilizează un spectru radio din zona 3,5 GHz. Nu mai discutăm de 5.7 GHz – zona spectrului considerat liber. Cum tehnologia WiMAX este bazată tot pe OFDM, există riscul ca, nefolosind un spectru licențiat (special WiMAX), să avem interferențe puternice sau chiar bruiaj din partea unor competitori. Problema interferențelor există și acum dar nu are rost să o agravăm prin folosirea unui spectru nelicențiat.
Astfel, reducând riscul legat de interferențe și bruiaj, alături de eliminarea eventualelor probleme legate de procesul de certificare (din cadrul autentificării mutuale pentru partea radio), totul adăugat cadrului de autentificare/autorizare/ criptare specific rețelei WiMAX (și prezentat anterior) ne va ajuta să securizăm și conexiunea marcată prin punctul de referință R1 (vezi Fig. 6.3).
Interdependența pe care am pretins-o planului de securitate este dovedită prin legătura strânsă dintre rezultatele primei etape și modul de implementare pentru următoarele etape (inclusiv cea de care discutăm în acest moment). Practic, opțiunile clientului legate de politica de securitate definită în prima etapă vor influența dezvoltările ulterioare (etapele ulterioare ale planului).
Un exemplu în acest sens este alegerea ca și criteriu de autentificare a adresei MAC.
Cum adresa MAC este inclusă și în certificatul specific SM folosit la identificare, vom regăsi acest criteriu și pentru partea radio, dar și pentru partea strict legată de autentificarea utilizatorului final (în cadrul IP VPN-ului).
Apoi, am ceru pentru planul meu o dezvoltare de tip open-source. Așa cum am menționat în capitolul anterior, încă mai sunt breșe legate de securitatea la nivel radio (pentru tehnologia WiMAX). Laboratoarele din lumea întreagă lucrează la reducerea acestor vulnerabilități, situația fiind oarecum similară cu momentele de dezvoltare pentru un software open-source. Prin urmare, și planul nostru permite eventuale „upgrade-uri” datorate noilor descoperiri, nefiind din acest punct un plan închis. El poate „crește”, se poate dezvolta respectând astfel principiile de open-source și fiind, prin urmare, el însuși un plan open.
Etapa 3 – nivelul generic ASN – zona C
În acest punct avem rețelele clientului din diferite locații conectate la o rețea WiMAX. De fapt, încă nu putem considera că avem o rețea WiMAX, ci mai multe rețele locale fără fir ce folosesc tehnologia WiMAX, dar care sunt izolate (nu sunt interconectate).
În cadrul acestei etape trebuie să definim prima „interfață” de interconectare pentru a obține o rețea WiMAX în adevăratul sens al cuvântului. Este vorba de introducerea echipamentului denumit ASN-GW.
Recomandarea mea este ca echipamentul să se afle în același site (aceeași locație) cu SB. Practic, între SB și ASN-GW (conexiunea R6) să fie o legătură fizică directă (un cablu Ethernet, spre exemplu).
Așa cum am spus, mă voi axa pe profilul C (definit de Forumul WiMAX) – în care funcțiile de administrare ale resurselor radio, precum și funcțiile specifice mobilității, sunt împărțite între ASN-GW și SB, cu un rol mai important pentru SB (care va deține controlul de ansamblu). ASN-GW va fi un echipament din categoria small care nu va îndeplini decât câteva funcții de bază – va asigura accesul la managementul SB, va furniza date legate de legătura fizică, va face legătura SB (și implicit, SM și utilizator) cu următorul element important – echipamentul de acces. Dacă îmi este permisă o recomandare – mă gândesc că echipamentul ASN-GW poate fi un router Cisco® 18xx (1841) sau 28xx (2811) sau un router Juniper® J2300. Am dat aceste exemple pentru a clarifica și mai bine ce categorie de echipamente am în vedere pentru ASN-GW.
De ce avem nevoie de acest echipament, mai ales că el pare a fi mai mult un „conector inteligent”?
Răspunsul îl putem deduce deja din expunerile anterioare. Rețelele operatorilor înglobează diferite tehnologii și, evident, diferite echipamente. Toate aceste echipamente au interfețe de interconectare diferite, care nu întotdeauna sunt în concordanță cu interfețele prezente la SB (WiMAX). Putem avea, spre exemplu, interfețe tip GigabitEthernet pentru o SB (cazul cel mai des întâlnit în momentul de față) și interfețe tip E1 pentru următorul echipament (eventual un echipament radio tip PDH sau SDH). Atunci este nevoie de un echipament în care să putem introduce diferite module cu diferite interfețe. Și acesta este ASN-GW.
Nu este mai puțin adevărat că producătorii de echipamente (WiMAX sau nu) au decis să adauge module pentru noile echipamente. Totuși, prin utilizarea acestui tip de arhitectură (cu ASN-GW) se reduce foarte mult riscul unei nepotriviri de interfețe (nu numai fizice ci și ca date tehnice – vezi diferența Ethernet și GigabitEthernet).
În plus majoritatea SB au o interfață de administrare (management) separată astfel încât se poate crea o cale alternativă specială pentru managementul SB – așa numitul management în afara benzii (out-of-band).
Din punctul de vedere al operatorului, acest lucru poate părea o cheltuială inutilă, mulți fiind de părere că un management in-band (adică prin intermediul legăturii prin care are loc transferul de date) este de ajuns. Totuși, recomandarea mea este ca pentru administrarea SB (și, implicit, al SM/SU) să existe o cale de comunicație separată.
Avantajele sunt mult mai mari – operativitate în intervenții, operațiuni de management al rețelei cum ar fi load-balancing (operatorul poate alege să „oblige” o SU să se asocieze unei alte SB în cazul în care SB curentă este suprasolicitată) și multe altele. În plus, redundanța aduce întotdeauna avantaje și, prin urmare, două posibilități de management (in și out-of-band) aduc un plus de fiabilitate și stabilitate pentru orice rețea.
Așadar, planul are în vedere realizarea acestei conexiuni separate pentru administrarea SB, plasarea unui ASN-GW (echipament din categoria celor menționate) în același site cu SB (conectare directă) precum și creerea unor politici de securitate sumare aplicabile la nivelul ASN-GW. Iau în considerare, în acest sens, aplicarea unor liste de acces simple sau a unor limitări la nivel general pentru SB și SM/SU asociate.
Etapa 4 – nivel generic CSN – zona D
Deja, în acest punct, planul dorit (cu arhitectura specifică) începe să se contureze, dar tot nu avem o rețea WiMAX în adevăratul sens al cuvântului. Rețeaua de interconectare există (este de presupus ca infrastructura operatorului este capabilă să asigure interconectarea fizică). Nu avem însă interconectare la nivel logic (nici pentru rețelele WiMAX „locale” și nici pentru locațiile clientului). Ne lipsește o entitate care să permită acest tip de interconectare. Este vorba de ceea ce eu am numit – „echipament de acces și AAA”.
Chiar dacă această zonă nu ține neapărat de rețeaua WiMAX, părerea mea este că pentru construirea unei rețele complete de tip WiMAX (si a planului aferent de securitate) nu trebuie să lipsească analiza acestei zone. Acesta este, cred eu, și motivul pentru care modelul NRM propus de Forumul WiMAX nu ignoră această zonă considerată non-WiMAX.
Mai mult, deși în accepțiunea Forumului WiMAX [44][45][66], ASN-GW ar putea îndeplini și rolul unui server de AAA, părerea mea este că pentru un astfel de rol e necesar un echipament separat sau, cazul cel mai frecvent, poate, un echipament nucleu existent deja în rețeaua operatorului. Operațiunile de AAA sunt, în opinia mea, unele dintre cele mai importante (fundamentale chiar) pentru o rețea nouă (WiMAX) mai ales când ne referim și la o rețea wireless (unde suspiciunile sunt și mai multe). Așa cum am menționat și la etapa anterioară, ASN-GW ar fi un echipament din categoria small care, aflat în același site cu SB, nu ar trebui să îndeplinească decât câteva funcții de bază (deja menționate) anterior.
Recomandarea mea este, ca pentru această entitate, să alegem un singur echipament. În momentul în care redactez această teză, există pe piața telecomunicațiilor foarte multe echipamente din categoria așa numită nucleu care pot îndeplini toate funcțiile cerute de mine în cadrul acestui plan de securitate. Pentru a exemplifica și mai mult la ce categorie de echipamente mă refer, voi apela iar la două exemple. Este vorba de routere Cisco® seria 7000 sau Juniper® seria M (M20, M40).
Practic, acest echipament va fi plasat în puncte cheie și va agrega mai multe rețele locale fără fir tip WiMAX determinând constituirea a ceea ce putem numi rețeaua globală WiMAX a operatorului. Totodată, acest echipament va include funcțiile server-ului de acces precum și ale server-ului de AAA (prezentate anterior).
Un prim câștig (față de propunerea Forumului WiMAX) este legat de posibilitatea de a proviziona (configura) mult mai ușor politici complexe și mult mai sigure de AAA pe un echipament din cele propuse de mine pentru acestă zonă decât pe unul de categoria ASN-GW.
În plus, pentru un operator, așa cum spuneam, rolul de server AAA poate fi preluată chiar de o placă inclusă special într-un echipament modular apartinând rețelei nucleu. Un alt câștig indubitabil este cel legat de partea de mobilitate.
Așa cum am arătat în capitolul anterior, NRM propune 2 categorii de mobilitate: micromobilitate (SM se asociază pe rând cu SB aflate în același ASN) și macromobilitate (SM se asociază cu SB din ASN diferite). Dacă am urma accepțiunea Forumului WiMAX și ASN-GW ar conține și serverul AAA, transferul de informații (de profil) pentru utilizatorul mobil ar fi mult mai dificil. În primul rând, ar trebui o conexiune foarte bună (bandă asigurată, sigură etc.) între ASN-GW astfel încât să se poată asigura o migrare eficientă. Apoi, datele transferate între ASN-GW conțin informații foarte importante pentru client (datele folosite pentru autentificare!). Deci, conexiunea între ASN-GW ar trebui să fie una foarte bine securizată – ceea ce este mult mai dificil din punct de vedere operator. Iar, transferând datele de la un ASN-GW la altul, procesul de autentificare s-ar repeta (la o scară mai mică) întrucât noul ASN-GW trebuie să accepte și să confirme noul (pentru el) utilizator într-un mod transparent pentru acesta.
Prin soluția propusă, dacă ne adresăm micromobilității, cel mai probabil, ASN-GW vor fi conectate la același echipament de acces și AAA (care va deservi o zonă ASN). Deci, SM nu va schimba decât informații legate de conexiunea radio cu noua SB. Autentificare utilizatorului se va face prin intermediul aceluiași echipament (de AAA) care are deja aceste date. Nu va mai fi nevoie de nici un transfer de date de autentificare cu atât mai puțin de securizarea acestui transfer. Procesul de migrare (roaming) între diferite celule sau zone de acoperire va fi simplu și eficient. În plus, părerea mea este că, spre deosebire de NRM, adaugare unui echipament din categoria small care nu va îndeplini decât câteva funcții de bază (ASN-GW la scară redusă) și mutarea funcției de server AAA către un alt echipament aflat în CSN (echipament de acces și AAA) va îmbunătăți securitate și performanța rețelei. Așa cum spuneam, vor fi mai multe nivele de securizare (politici sumare la nivel de ASN-GW) precum și transfer mult mai bun de informații necesare migrării.
Dacă voi face apel din nou la experiența acumulată în cadrul marilor operatori, trebuie să spun că la o astfel de împărțire (ASN-GW și echipament de acces și AAA) a mai contribuit un aspect: instalarea și (de cele mai multe) configurarea SB și a (eventualelor) echipamente din site dedicate (în cazul meu, ASN-GW) se face de către un integrator și este un proces standardizat. Site-ul operatorului are deja legătura către rețeaua nucleu, iar integratorul (subcontractorul) instalează și conectează echipamentele la site. Din acest punct de vedere, este recomandat ca tot ceea ce înseamnă configurare avansată (ce include politicile de pe un server de AAA) să se realizeze de către centrul de operațiuni (NOC-ul) al operatorului. Acest lucru se întâmplă în arhitectura propusă de mine (cu echipamentul de acces și AAA).
Mai mult, în cazul NRM, SB ar trebui conectată direct la site – ceea ce ar putea conduce la o problemă de interconectare la nivel fizic (posibile nepotriviri de interfețe etc.). Adăugând echipamentul acela de tip small (mic) de care vorbeam la etapele anterioare (ASN-GW așa cum îl consider eu) se elimină și aceste posibile probleme și se asigură și un control mult mai bun asupra configurațiilor și asupra noilor instalări.
Dacă ne adresăm macromobilității, situația este din nou mult mai bună. În condițiile în care SM se va asocia SB din ASN diferite, aceasta poate înseamna, conform arhitecturii, CSN diferite și, prin urmare, echipamente de acces și AAA diferite.
Am spus poate pentru că dacă vom avea mai multe ASN conectate la același CSN vom avea situația deja prezentată anterior.
Revenind, în cazul mai multor echipamente de acces și AAA, va trebui să existe un transfer de date de profil (credentials) pentru utilizatorul aflat în roaming.
Dacă se aplică principiile de care menționam și ținem cont și de experiența din cadrul operatorilor, echipamentul de acces și AAA – fie că va fi unul separat fie că va fi unul deja existent (sau un nou modul în acesta) – va face parte din rețeaua nucleu a operatorului. Această zonă poate fi considerată una dintre cele mai solide din întreaga rețea – din toate punctele de vedere: securitate, rate de transfer etc. De cele mai multe ori, suportul fizic pentru conexiunile dintre echipamentele din această zonă este fibra optică (ce asigură rate de transfer ridicate), se asigură redundanță conexiunilor și back-up pentru echipamente. Deci, oricum, suntem într-o situație mult mai bună decât în cazul transferului între ASN-GW.
Prin urmare, în ambele situații de mobilitate (atunci când utilizatorul dorește să poată comunica în timpul migrării), propunerea mea (conformă cu planul de securitate) asigură o comunicare optimizată, eficientă și securizată mult mai bine decât în accepțiunea Forumului WiMAX.
Arhitectura finală (pentru cazul nostru) rezultată în urma aplicării etapelor planului de securitate este prezentată în Fig. 6.5.
Figura 6.5 Studiu de caz – interconectarea locațiilor pentru un client prin intermediul unei rețele WiMAX dezvoltate de un operator – arhitectură finală (rezultată în urma aplicării planului interdependent de securitate)
Întrebarea care se pune pentru această etapă este legată de oportunitatea folosirii unui nou echipament pentru acces și pentru procesul de AAA sau dacă se poate folosi pentru acest lucru un echipament din rețeaua nucleu a operatorului.
Deși se poate alege cea de-a doua opțiune, recomandarea mea este folosirea unui nou echipament special pentru dezvoltarea unei rețele WiMAX. Echipamentul va face parte din rețeaua nucleu a operatorului. Justificarea este strâns legată de capacitatea de procesare și de agregare (și, implicit, de ceea ce ne interesează pe noi – securitatea rețelei). Astfel, cum echipamentul ar urma să realizeze autentificarea utilizatorilor (fie prin intermediul unui serviciu de tip RADIUS, fie prin alte metode) , operațiuni de administrare a politicilor de securitate (care vor fi, în majoritate, implementate la acest nivel) precum și operații de routare a traficului pentru noua rețea WiMAX (vezi cazul instanțelor VRF folosite în exemplul anterior), procesorul echipamentului va fi foarte solicitat.
În acest punct, voi face din nou mențiunea referitoare la partea de mobilitate. În cazul unui utilizator aflat în roaming (mobil), avem cele două cazuri posibile tratate anterior – de micro și macromobilitate. Practic, pentru micromobilitate acest echipament de acces și AAA (separat) va agrega informații provenite dintr-un ASN cu mai multe SB. Avantajele (deja menționate) sunt evidente: lipsa transferului de date de profil utilizator (credential) întrucât acestea sunt deja au fost procesate de echipamentul de acces și AAA, la care sunt conectate toate ASN-GW. Pentru macromobilitate, faptul că echipamentul de acces și AAA va face parte din rețeaua nucleu a operatorului va determina o comunicație solidă și foarte bine securizată.
Mai mult, recomandarea Forumului WiMAX în care se plasează un server de AAA în CSN fără o analiză detaliată nu este foarte exactă. Așa cum menționam încă de la început, propunerea mea de plan de securitate ține cont de faptul că operatorul are deja o rețea nucleu dezvoltată și plasează exact echipamentul de acces și AAA. Diferența față de accepțiunea Forumului WiMAX este dată tocmai de îmbunătățirile pe parte de mobilitate pe care le aduce propunerea mea, precum și de faptul că integrarea noi rețele WiMAX în cadrul rețelei „mari” a operatorului se va realiza mult mai ușor, pe câteva etape clare.
Dacă, pe lângă toate acestea, adăugăm funcțiile pe care le realiza inițial echipamentul (înainte de noua implementare), există riscul depășirii capacității de procesare a echipamentului și, implicit, blocarea lui, pierdere de trafic etc.
Înainte de a trece la partea finală pentru acest plan de securitate (cu arhitectura aferentă), haideți să vedem care ar fi pașii pe care i-ar parcurge un nou client care dorește să se conecteze folosind rețeaua WiMAX a operatorului. Vom considera cazul unui utilizator mobil (mult mai interesant din punctul de vedere al securității rețelei).
Pentru început, primul pas este legat strict de asocierea cu SB în a cărui arie de acoperire se află. Acest pas include procese pe care le-am detaliat deja pe parcursul tezei – procesul de autentificare (cu obișnuitul schimb de certificate X509 și autentificarea mutuală). Vorbim de autentificare la nivel de rețea WiMAX, urmată de alocarea de CID-uri (cele 3 de bază). Din punct de vedere al calității serviciului, în cadrul acestui pas, SM i se va da acces doar la un profil de bază de tip „cel mai bun serviciu posibil” (Best-Effort) (cu o rată minimă, suficientă pentru schimbul de mesaje ce precede autentificarea finală și autorizarea).
Urmează apoi autentificarea la nivel de utilizator care înseamnă trimiterea unei cereri de autentificare până la echipamentul de acces și AAA. În cazul în care cererea este acceptată, pe baza contului specific pentru utilizator (care a permis autentificare), i se va asocia un nou profil de calitate a serviciului (cu alți parametrii) specific pentru acest utilizator.
Utilizatorul, însă, nu va beneficia încă de acest nou profil. Mai întâi are loc încă un pas – schimbul de mesaje pentru stabilirea cheilor necesare (TEK, KEK etc.). Acest schimb are loc utilizând tot acel profil de bază. Rațiunea de la baza acestei decizii este legată tot de securitate – utilizatorului nu îi se permite să facă trafic până nu se stabilesc cheile de
criptare și atunci nu are nici un rost să îi se ofere accesul la noul profil doar pentru un schimb de mesaje de control și management.
După stabilirea acestor chei, mai urmează încă un pas care implică o comunicare cu echipamentul de acces și AAA – utilizatorul solicită o adresă IP care poate fi alocată de server-ul DHCP înglobat în echipamentul nou sau de un server DHCP aflat undeva în rețeaua nucleu a operatorului. Nu se pune problema securității întrucât utilizatorul este deja autentificat.
Ultimul pas înainte de începerea traficului util înseamnă aplicarea efectivă a profilului de calitate a serviciului (QoS) alocat la pasul 2 astfel încât utilizatorul va începe să comunice folosind acești noi parametrii ai profilului (așa cum este, de altfel, normal).Toți acești pași sunt ilustrați în Fig. 6.6.
Figura 6.6 Pașii pe care îi urmează un nou utilizator mobil care dorește să beneficieze de servicii de bandă largă prin intermediul noii rețele WiMAX
Etapa finală – rețeaua nucleu – zona E
În Fig. 6.3, am notat cu R10 punctul de referință pentru conexiunea echipamentului de acces cu rețeaua nucleu. Din punctul meu de vedere (legat de securitate), această conexiune nu are cerințe speciale și poate fi realizată după regulile pe care operatorul le-a urmat când a dezvoltat rețeaua nucleu.
Totuși, aș dori ca și în acest caz să fac o recomandare. Ar fi indicat ca în interiorul rețelei nucleu să existe un echipament care să conțină o replică a datelor aflate în echipamentul de acces și AAA. Replicarea nu se va face permanent ci doar la un interval de timp stabilit de operator astfel încât operatorul să beneficieze de posibilitatea de a restaura datele pierdute în caz de defectare a unui echipament de acces. Replicarea datelor va conferi fiabilitate noi rețele create și poate fi privită ca o componentă importantă a planului de securitate.
În plus, în cazul unui atac masiv (care ar duce la pierderi de date), operatorul ar avea o copie de siguranță care i-ar permite repunerea rapidă în funcțiune a serviciilor oferite.
Exemplificarea procesului de autentificare pentru arhitectura propusă de planul de securitate
În Fig. 6.7 am prezentat un model de arhitectură bazată pe planul de securitate introdus anterior. În tabelul 6.8 am detaliat și pașii pe care îi urmează, pentru autentificare, un utilizator. Am avut în vedere 2 scenarii posibile:
Fie operatorul dezvoltă o rețea WiMAX și oferă servicii pe baza ei către utilizatorul final (și atunci pașii 4 și 5 din tabel nu se mai aplică). Operatorul este și ISP.
Fie operatorul dezvoltă o rețea WiMAX și oferă doar servicii către diferiți ISP (și atunci pașii 4 și 5 sunt valabili). Operatorul este doar NAP.
Fig. 6.7 – Arhitectura de rețea propusă de planul de securitate (detalii de autentificare)
Tabelul 6.8 Pașii din procesul de autentificare
În cazul în care avem scenariul b), echipamentul de acces și AAA va deveni și SSG (Service Selection Gateway), iar între el și server-ul de AAA aparținând diferiților ISP se va comunica prin conexiuni tip VPN (L2TP/IPSec). În cazul în care se va folosi L2TP, se va stabili câte o sesiune tip PPP pentru fiecare SM/SU în parte.
Pentru ambele scenarii, echipamentul de acces și AAA va fi responsabil de autentificarea utilizatorului precum și de alocarea adresei IP pentru PC-ul din spatele SU sau pentru SM (PC-ul cu chip WiMAX mobil încorporat, spre exemplu).
Pentru scenariul b), în momentul în care echipamentul de acces și AAA va primi o adresă globală IP de la server-ele ISP-ului (care oferă serviciul) și va trebui să construiască o schemă de tip NAT (adresă IP alocată de el -> adresă IP globală).
Pentru ambele scenarii, când SU/SM se va deconecta, pentru o anumită perioadă, contul nu va fi deconectat automat (autentificarea nu se va pierde). Dacă în timpul acestei perioade (care este configurabilă), SM/SU nu reapare (reconectează) la SB, atunci conexiunea va fi oprită (cu echipamentul de acces și AAA) și SM/SU va trebui să se reautentifice la o nouă apariție în rețea.
Diagramele aferente procesului de autentificare (autentificare nouă, autentificare după deconectare/reconectare) sunt prezentate în fig. 6.9, 6.10 și, respectiv, 6.11
Fig. 6.9 – Procesul de autentificare (pentru un nou utilizator)
Fig. 6.10 – Reautentificarea unui utilizator înainte de deconectare
Fig. 6.11 – Reautentificare utilizatorului după deconectare
SISTEMUL DE TAXARE PENTRU O ARHITECTURA WIMAX OBȚINUTĂ ÎN URMA APLICĂRII PLANULUI DE SECURITATE
Introducere
Convergența „vechii” rețele Internet cu noile tendințe de mobilitate înregistrate în cadrul rețelelor de telecomunicații poate determina modificarea în esența a unor modele de oferte de servicii, precum și apariția unor noi categorii de servicii cu metodele de taxare aferente.
Această situație este posibilă și datorită liberalizării pieței telecomunicațiilor, fapt ce a permis ca un anumit furnizor de servicii să poată folosi infrastructura unui operator contra unei taxe stabilite de comun acord. Astfel, utilizatorul se poate înregistra la o anumită rețea (mobilă, WiMAX, Wi-Fi) folosind o cartelă pre-plătită sau chiar gratuit – în funcție de acordul pe care l-a încheiat cu un anumit furnizor de servicii.
Prin urmare, sistemele de taxare – taxare, facturare, contabilitate (charging, billing, accounting) au evoluat în concordanță cu noua situație. Dacă la începutul ultimei decade a secolului trecut, operatorul național fix era singurul care oferea servicii de telecomunicații, iar procesul de taxare era unul relativ simplu și clar, evoluția către comunicații 3G sau WiMAX precum și apariția unor noi operatori și furnizori a determinat o modificare substanțială a acestui proces, pe care l-am numit generic – proces de taxare.
În fapt, el cuprinde 3 etape:
Taxare (Charging) – contorizarea și taxare utilizatorului pentru un anumit serviciu
Facturare (Billing) – reconciliere serviciu-taxe, aplicarea politicilor de facturare și emiterea facturii
Contabilitate (Accounting) – contabilitate/evidență a tuturor facturilor si a statisticilor pentru un anumit utilizator
Practic, dacă ar fi să rezumăm, furnizorul de servicii (care poate fi diferit de operatorul rețelei de suport) anunță tarifele pentru un anumit serviciu, precum și metoda de taxare (la minut, la trafic etc.), trece la contorizarea individuală a serviciului pentru fiecare utilizator, iar periodic emite o factură de plată pentru serviciul respectiv (charging și billing). Pentru fiecare utilizator există un cont dedicat în care, în orice moment, se pot regăsi orice informații legate de perioada de utilizare pentru un anumit serviciu, de facturi sau de plăți restante – accounting.
Experiența arată că toată operațiunea generică de taxare (deci cele 3 etape menționate) se realizează, de obicei, prin intermediul unei singure platforme. Sunt foarte puțini operatorii care preferă să separe cele 3 etape și să implice mai multe sisteme dedicate în acest domeniu.
Explicația este relativ simplă – interoperabilitatea unor sisteme de acest fel trebuie să fie aproape de perfecțiune și, în plus, furnizorii importanți de echipamente de charging, billing și accounting (taxare, facturare, contabilitate) oferă o singură platformă capabilă să îndeplinească acest rol de taxare.
De multe ori, imaginea asociată acestei platforme este cea a unei „cutii negre” programabile care primește trafic pe de o parte și emite factura pe cealaltă în funcție de anumite detalii specifice – costuri, mod de taxare etc. Accesul la protocoalele utilizate în cadrul acestei „cutii” este restricționat, ceea ce duce la lipsa unei imagini exacte a funcționării în detaliu a platformei.
Totuși, pentru cazul rețelelor fără fir – GSM, Wi-Fi, WiMAX – situația a determinat anumite schimbări față de procedura inițială (menționată anterior). Astfel, întreg procesul de autentificare pentru un utilizator, inclus inițial în „rolurile” pe care le putea îndeplini platforma de taxare, a fost preluat în totalitate de echipamente specifice doar acestui proces ( procesul de AAA), urmând ca ele să comunice cu platforma și să certifice că un anumit utilizator poate folosi serviciul.
Trebuie să fac o mențiune foarte importantă în acest punct. Se poate observa că accounting-ul (contabilitatea) este prezentă atât în cazul platformei de taxare cât și în cadrul procesului separat de AAA. Este vorba, însă, de două operațiuni complementare dar separate. Astfel, un utilizator poate „trece” de filtrul impus de server-ul de AAA dar nu va primi acces la un anumit serviciu (din portofoliul pe care îl deține) tocmai datorită filtrului impus de etapa de accounting (contabilitate) din procesul de taxare.
Ca și exemplu la îndemână este cel legat de un client rău-platnic din cazul GSM. Utilizatorul va putea primi apeluri, fără a putea iniția vreunul (până când nu își achită datoriile). Deci, el va fi autentificat de rețea dar va fi restricționat de la anumite servicii prin intermediul filtrului impus de platforma de taxare.
Motivul pentru care am ținut să subliniez aceste diferențe este legat de faptul că, de multe ori, pașii de accounting (contabilitate) sunt cumulați, ceea ce poate determina anumite erori de raționament, mai ales când se dorește construirea unui protocol nou de comunicație pentru operațiunea de taxare. Astfel, pe lângă confirmarea primită de la server-ul de AAA, va trebui să includem și o confirmare de tip Bill ACK prin care să certificăm accesul la serviciul dorit de utilizator.
Revenind însă la evoluția platformei de taxare (charging, billing și accounting), trebuie spus că, pentru rețelele bazate pe tehnologia WiMAX, întregul proces de taxare ridică anumite probleme.
În primul rând, se pune întrebarea, la fel ca la orice rețea fără fir, ce tip de taxare ar fi mai avantajos de adoptat – taxare la timpul petrecut în rețea sau la volumul de trafic?
După cum știm, rețelele GSM se bazează pe cel de-al doilea model pentru comunicațiile de voce (principiul „plătim ce vorbim”), în timp ce pentru transferul de date putem considera că se aplică o versiune „mixtă” a celor două modele. Practic, transferul de date se taxează și la volum de date transferate dar și la timpul de utilizare al conexiunii GPRS (spre exemplu).
Pentru rețeaua WiMAX, având în vedere faptul că este o tehnologie nouă (măcar din punct de vedere al implementărilor), soluția unei taxări bazate pe timpul petrecut în rețea nu se poate lua în considerare. Mai mult, o astfel de soluție nu mai este agreată decât în foarte puține cazuri și pentru celelalte rețele fără fire (wireless), iar accentul pe mobilitate pus în cazul rețelelor WiMAX impune renunțarea la această posibilă tentativă de taxare.
Prin urmare, procesul de taxare (cu toate cele 3 etape menționate – charging, billing, accounting) se va construi pe principiul taxării volumului de date transferate (număr de Mbiți transferat, spre exemplu) pentru un anumit utilizator.
Considerând capitolele anterioare, în care am prezentat aspectele legate de autentificare, autorizare și criptare pentru rețelele WiMAX, voi încerca să construiesc în continuare un protocol de comunicație ce poate fi folosit în procesul de taxare. Construcția se va baza pe pașii descriși pentru autentificare și va ține seama permanent de scopul nostru propus încă de la începutul acestei teze – securitatea rețelelor fără fir (cu aplicabilitate și pentru comunicația necesară pentru taxare – charging, billing și accounting).
Preliminarii
În anul 1998, un grup de cercetători de la Universitatea Națională din Singapore a dezvoltat un nou protocol general pentru operațiunea de facturare (billing) pentru dispozitive mobile aflate în alte rețele decât cele de bază (în cazul migrării).
Etapele acestui protocol includ atât pe cele dedicate operațiunii de facturare (billing) cât și pe cele specifice autentificării. Protocolul prezintă comunicația între 3 entități – Home Server, Foreign Server și Mobile User. O descriere detaliată a acestui protocol poate fi regăsită în documentul dedicat (vezi bibliografie)[31].
Pornind de la acest protocol – care nu are în vedere un anumit tip de comunicație sau tehnologie – voi construi un nou protocol dedicat rețelelor WiMAX, un protocol general valabil însă exemplificat pe arhitectura specifică planului de securitate.
Controlul și taxarea utilizatorilor
Încă de la începutul acestei teze, am subliniat un fapt extrem de important și anume faptul că orice dezvoltarea a unei tehnologii noi și a rețelei aferente trebuie să țină cont de toate celelalte tehnologii deja existente. Rețele operatorilor nu mai au în vedere principiul mono-tehnologiei – o singură tehnologie pentru transmisiuni. Dimpotrivă, complexitatea este una dintre trăsăturile definitorii pentru orice rețea și pentru serviciile aferente.
Din acest motiv, orice sistem de monitorizare și control aparținând operatorului va fi multifuncțional, cu multe componente – într-un cuvânt, complex. Important pentru mine în cadrul acestei teze este sistemul de taxare și de control al taxării utilizatorilor.
Din punctul de vedere al amplasării în cadrul unei rețele, platforma de taxare se poate afla fie la granița dintre rețeaua de acces a operatorului și așa numita rețea nucleu, fie (cazuri mai puțin întâlnite) chiar în rețeaua nucleu. Cum, și din punctul de vedere al logicii succesiunii operațiunilor, ar fi mai simplu ca utilizatorul să fie validat și introdus în procesul de taxare (începutul taxării) înainte de a accesa resursele mari ale operatorului, voi considera cazul în care platforma este la graniță. Fig. 6.12 exemplifică acest tip de arhitectură. Întrucât ne-am ocupat de comunicațiile fără fir – atât comparativ cât și concurențial între WiMAX și celelalte tehnologii fără fir (wireless) – voi considera în exemplificare doar acest tip de rețele.
Figura 6.12 Amplasarea (zonei) platformei de taxare în cadrul unei rețele – pentru rețele fără fir
Modelul de împărțire pentru diferitele zone din cadrul rețelei prezentat în Fig. anterioară nu este nici unicul și nici foarte formalizat. Practic, împărțirea este mai mult intuitivă și bazată pe exemplele obținute de la diferiți operatori. De asemenea, modelul are la bază și arhitectura propusă de modelul de securitate impus de Forumul WiMAX
Prima zonă – zona de acces (bucla locală) – este o zonă care nu comportă nici un fel de dezbateri. Clienți se pot conecta prin intermediul telefoanelor mobile (GSM), laptop-urilor
(Wi-Fi) sau prin intermediul stației utilizator – SU (WiMAX). Reamintesc că pentru simplificarea expunerii avem în vedere doar rețele fără fir.
Următoarea zonă – zona de agregare – este o zonă impusă de complexitatea rețelei (așa cum am amintit încă de la începutul acestui capitol). Multitudinea tehnologiilor aduce cu sine necesitatea unei agregări a conexiunilor pentru a optimiza folosirea resurselor existente (echipamente, conexiuni, capacități de procesare etc.). Chiar dacă am separat punctele de multiplexare în funcție de conexiunile primite (GSM, WiMAX), separarea este una logică – realizată pentru o mai bună evidențiere. În realitate, un echipament poate îngloba și funcții specifice unui GGSN și unui ASN-GW.
Cea de-a treia zonă – zona de graniță între acces și nucleu – este o zonă extrem de importantă. Dacă analizăm elementele componente – sisteme de monitorizare și control și sisteme de taxare – obținem și motivația pentru care am modelat astfel împărțirea pe zone a unei rețele.
Înainte de a permite accesul către rețeaua nucleu (core) și de a oferi serviciile cerute, operatorul trebuie să verifice, să autentifice și să filtreze utilizatorii. Trebuie să asigure securitatea conexiunilor și posibilități de deviere (redundanță) a traficului în caz de nevoie. Toate aceste operațiuni nu trebuie să aibă loc în cadrul rețelei nucleu (core) a operatorului. Nu putem, spre exemplu, permite unui utilizator să ajungă până la un router din rețeaua nucleu pentru a fi verificat fără a aplica în avans metode de filtrare/verificare.
Apoi, monitorizarea rețelei trebuie făcută dintr-un punct din care să putem avea date suficiente, să nu afectăm funcționarea rețelei și să putem primi mult mai ușor alerte din orice parte a rețelei. Evident, o monitorizare se poate face și din rețeaua nucleu (core). Dar oare nu ar fi mai bine să degrevăm această parte foarte importantă în furnizarea serviciilor de alte cerințe care pot fi îndeplinite și în alte zone? Cum ar fi, spre exemplu, zona de graniță (edge) a unei rețele.
Practic, această zonă tampon (dacă o putem numi astfel) joacă un rol foarte important în securitatea întregii rețele și, în plus, oferă posibilități de a prelua și alte funcțiuni pentru a reduce încărcarea anumitor zone ale rețelei.
Tot în această zonă am plasat și serviciile de taxare. Pentru această parte, însă, este necesară o mică dezbatere.
Platforma de taxare este considerată ca o componentă aparte în majoritatea rețelelor operatorilor, atât din punct de vedere funcțional cât și din punct de vedere integrare. Din acest motiv, locul acestei platforme în ansamblul rețelei nu a putut fi unul clar definit. Putem accepta plasarea ei în partea nucleu sau în zona tampon. O putem considera ca fiind separată și, prin urmare, fără necesitatea definirii unei locații exacte.
Din perspectiva analizei mele, plasarea platformei nu este o chestiune atâta de importantă. De ce spun acest lucru?
Studiind documentele de design oferite de producătorii importanți din acest domeniu (billing) – AMDOCS, COMVERSE etc.- se poate observa o separare foarte interesantă.
Sistemul de taxare (nu contează producătorul) are mai multe componente – pentru stocare a datelor (de taxare pentru clienți), pentru reconciliere, pentru tratare a excepțiilor, pentru calcul efectiv etc.
În plus, sistemul poate avea și un modul de colectare a evenimentelor (event collection). Practic, acesta este modulul care înregistrează toate schimbările – conectarea/deconectarea unui utilizator, trecerea la un alt serviciu (spre exemplu voce-date), excepții, încercări de fraudă etc. Toate acestea sunt tratate ca evenimente și sunt codate în funcție de componenta care le va trata mai departe. Am spus „poate” întrucât acest modul poate să nu aparțină de platformă, să fie doar interconectat și să conlucreze cu aceasta oferind informațiile necesare.
În Fig. 6.13 este oferit un exemplu pentru această împărțire – cazul platformei de taxare oferită de AMDOCS. Se poate observa că modulul de colectare al evenimentelor nu aparține de platformă (fiind al unei terțe părți).
Figura 6.13 – Colectarea evenimentelor pentru platforma de taxare oferită de AMDOCS.
Revenind la zona noastră de graniță, ceea ce eu am figurat ca și servicii de taxare poate constitui de fapt zona în care se colectează evenimentele necesare operațiunii de taxare. Aici se înregistreză apariția unor noi utilizatori, se anunță deconectarea altora sau modificarea unor servicii. Repet – este vorba doar de o colectare și direcționarea de evenimente nu și de tratarea lor. Această funcție este rezervată platformei de taxare în sine.
Acest modul (sistem) de colectare de evenimente este unul foarte important și foarte interesant. Așa cum menționam încă de la începutul demersului legat de partea de taxare pentru rețele WiMAX, specificațiile unei platforme de taxare nu sunt chiar atât de ușor de aflat, cu atât mai puțin modul ei de funcționare. Foloseam, în acel punct, sintagme precum „cutie neagră”, „soluții proprietare închise” etc.
Prin urmare, interconectarea cu un modul (sistem) separat care, în plus, să poată fi capabil să furnizeze către platformă informații în formatul cerut nu pare a fi un lucru foarte simplu de făcut. Acesta este și motivul pentru care m-am ferit să folosesc strict termenul de „sistem”. Datorită complexității specificațiilor, de multe ori, acest modul poate aparține chiar furnizorilor soluției de taxare (cum este cazul AMDOCS sau COMVERSE). Se evită astfel probleme de interconectare și de funcționare.
Totuși, scopul meu declarat a fost reducerea sarcinilor asignate platformei de taxare și, în final, reducerea influenței mari pe care o au în anumite momente furnizorii de platforme de taxare.
Mai mult, dezvoltarea unor rețele bazate pe o tehnologie mai nouă (așa cum este cazul WiMAX) poate fi un bun prilej să găsim o nouă soluție care să ne ajute să înglobăm parte din funcțiunile realizate până acum de platforma de taxare într-un echipament de rețea (cum ar fi, în cazul nostru, echipamentul de acces și AAA). Sau, dacă nu se poate să ajustăm pentru toate tehnologiile deja existente, măcar pentru tehnologia nouă să obținem ceea ce ne-am propus – o comunicare mult mai directă între platforma de taxare și echipamentele aferente rețelei bazate pe noua tehnologie, fără a fi necesar un alt modul personalizat și construit de furnizorul soluției de taxare.
Protocolul de taxare – CUANTAX
Elemente introductive
Înainte de a începe construcția propriu-zisă (pas cu pas) a protocolului, aș vrea să prezint, sumar, câteva elemente introductive.
În primul rând, obiectivul acestui protocol este de a asigura o integrare ușoară a rețelei WiMAX cu platforma de taxare a operatorului, oferind suportul necesar comunicației între echipamentul de acces și AAA și platforma de taxare a operatorului.
Pentru a defini acest protocol, eu nu voi imagina un nou proces de autentificare ci mă voi folosi de cel descris în capitolele anterioare De asemenea, pentru criptarea datelor și a cheilor, voi folosi metodele descrise în capitolul 5 (AES-CCM).[11] Practic, etapele nu vor diferi până la un anumit punct, de unde voi introduce procese specifice operațiunilor de taxare (charging, billing și accounting).
Prin urmare, acest protocol va funcționa în ipoteza în care pentru autentificare se va folosi procesul de autentificare mutuală, iar pentru criptare algoritm de tip CCM alături de criptare tip AES.
Entitățile între care voi analiza comunicația și pentru care voi încerca să aplic protocolul sunt stația mobilă (SM), stația de bază (SB), echipamentul de acces și AAA precum și, cu un rol secundar în cadrul acestui protocol, platforma de taxare (billing, charging și accounting).
De ce un rol redus pentru platformă ? Dorim totuși să implementăm un protocol de comunicație care să poată fi folosit în operația generică de taxare.
În primul rând, pe mine mă interesează modul în care informația necesară pentru taxare ajunge la această platformă și nu cum este ea procesată în interiorul platformei – cum se alcătuiește factura, ce prețuri ale serviciilor se aplică etc. Profilul de utilizator (căci de el vorbim) este cel care va ajuta la taxare, iar, pentru mine, important este modul în care se măsoară „consumul” pe care îl are un anumit utilizator (bandă, trafic etc) și cum îl putem identifica și asocia unui profil anume. Toate aceste procese se bazează pe mesajele schimbate la un anumit moment de timp (la începutul comunicației, în principal) de diferitele entități implicate.
Așadar, mă interesează cum ajung mesajele la platforma de taxare (billing etc.) nu și cum sunt ele procesate în interiorul ei.
Evident, nu pot exclude platforma întrucât trebuie să știu ce tip de informații de intrare necesită și ce poate oferi. Rolul ei va fi deci unul de „partener de comunicație” în acest caz.
Așa cum menționam în introducere, modul de taxare va fi unul bazat pe trafic. Cuanta de taxare va avea, prin urmare, ca și unitate de măsură cea specifică traficului de date (biți) cu multiplii sau submultiplii (în funcție de operator și de modul în care acesta dorește să măsoare – Mb, kb etc).
Din punct de vedere al stivei de nivele, vorbim de comunicație la nivel rețea între SM și SB și între SB și echipamentul de acces și AAA.
Setul de mesaje folosit (pe care îl voi detalia ulterior) este:
MSJ1 [TAX(i), DIM(i), TIMP(i)] unde i numărul cuantei utilizate (i=1…..n ), cu TAX(i) – rata de taxare pentru cuanta i și cu DIM(i) – dimensiunea cuantei i. (de la echipamentul de acces și AAA către SM)
CRIPTRMSJ1 [TIMP(i), TAX(i), adresa MAC a SM] (între SM și SB)
CRIPTMSJ2[TAX(i), identificator (SM), TIMP(i), REZVERIF] (între SB și echipamentul de acces și AAA)
Așa cum spuneam, voi avea în vedere procesul de autentificare mutuală și voi vedea cum putem introduce etapele protocolului meu în pașii descriși în fig. 6.6 (figură din care prezint din nou doar prima parte – vezi fig. 6.14).
Figura 6.14 Pașii pe care îi urmează un nou utilizator mobil care dorește să beneficieze de servicii de bandă largă prin intermediul noii rețele WiMAX – partea de autentificare
După cum se poate observa, procesul de autentificare va rămâne cel descris de mine, cu o singură mențiune: în cadrul procesului de obținere a cheii de autentificare (AK), se foloseau două chei separate – MSK (Master Session Key) și PSK (Pairwise Master Key).[11][29] Din ultima se obținea AK (vezi 5.5.5.2). Voi reține aceste două chei și voi detalia cum le voi folosi în capitolul următor.
Descrieri procedurale – schimbul de mesaje pentru CUANTAX
În momentul în care procesul de înregistrare (autentificare) este complet și se stabilesc cheile necesare transferului de date (TEK etc), rețeaua la care utilizatorul mobil (SM) s-a înregistrat trebuie să înceapă să aloce și să furnizeze resurse necesare comunicației.
În acest punct, echipamentul de acces și AAA a autentificat SM și a „anunțat” SB că autentificarea a avut loc și că e în regulă. Cheile de care discutam anterior – MSK și PSK sunt deja „cunoscute” între SB și SM și pot fi folosite. MSK este furnizată chiar de echipamentul de AAA (vezi fig. 6.6).
Resursele alocate pentru noul utilizator trebuiesc divizate în cuante măsurabile. Fiecare cuantă o voi denumi „cuantă de taxare”. Așa cum am menționat deja, această cuantă se va referi la traficul de date pentru fiecare utilizator (taxăm traficul de date și nu prezența în rețea).
Pentru început, este necesar să informez utilizatorul despre modul de taxare (rata sau preț), cuanta de taxare aplicată (dimensiune) și felul cum va fi înregistrat. Vom nota cu i numărul cuantei utilizate (i=1…..n ), cu TAX(i) – rata de taxare pentru cuanta i și cu DIM(i) – dimensiunea cuantei i. Fiecare cuantă va avea și o marcă de timp – necesară pentru unicitate și pentru verificări și statistici. Această marcă o voi nota cu TIMP(i).
Prin urmare, următorul mesaj (MSJ) care trebuie transmis (după negocierea cheilor) va fi: MSJ1 [TAX(i), DIM(i), TIMP(i)]. Mesajul va fi transmis de echipamentul de acces si AAA către SM.
Întrebarea firească în acest punct este – De ce nu se transmite acest mesaj direct de la platforma de taxare? Nu introducem o mică întârziere dacă vom avea o etapă intermediară în care echipamentul de acces si AAA (cum l-am numit eu generic) va fi nevoit să comunice cu această platformă și să „anunțe” că are un nou utilizator autentificat cu un anumit profil și să „ceară” informații legate de modul de taxare (generic vorbind) pentru acest profil și, implicit, pentru utilizatorul nou?
Răspunsul nu poate decât să definească un compromis. Este necesară etapa intermediara echipament AAA –> platformă taxare din rațiuni de securitate.
Nu pot permite ca un utilizator, fie el și autentificat, să comunice direct cu platforma de taxare. Traficul către această platformă ar crește exponențial, iar riscurile asemenea.
În plus, eu vreau ca mesajele transmise (aparținând protocolului nostru de taxare – CUANTAX) să fie criptate. Nu există nici o cheie de criptare „agreată” între SM și platforma de taxare. Practic, traficul ar trebui „filtrat” tot de prima entitate care poate face acest lucru – și aceasta este echipamentul de acces și AAA.
În acest punct, ne putem aminti de cele două chei – MSK și PSK folosite în procesul de autentificare.
Pentru a cripta acest prim mesaj (MSJ1), voi folosi MSK – cheia master a sesiunii cunoscută atât de SM și de echipamentul de acces, cât și de SB. Voi obține un mesaj criptat pe care îl vom nota CRIPTMSJ1 cu parametrii deja menționați. Acesta va fi mesajul care va fi transmis către SM.
După recepționarea mesajului, SM va folosi MSK pentru a decripta mesajul recepționat. După obținerea MSJ1, SM va ști toate informațiile legate de taxare și va putea decide dacă este de acord sau nu.
În cazul în care nu este de acord, poate opri comunicația imediat. Evident, nu vom mai avea alte mesaje transmise (utilizatorul trebuind să întrerupă transmisiunea). Fiind vorba de un protocol automat, nu vom avea mesaje de negociere a tarifelor.
În cazul în care utilizatorul (SM) este de acord, va trimite un mesaj de răspuns – RMSJ1. Acesta va avea parametrii [TIMP(i), TAX(i), adresa MAC a SM] și va fi criptat cu PMK (Pairwise Master Key).
Vom avea deci CRIPTRMSJ1 [TIMP(i), TAX(i), adresa MAC a SM] – mesaj transmis, de această dată, către SB. Acest mesaj va fi ceea ce se poate numi cerere de autorizare a taxării. SM confirmă că este de acord cu modul de taxare și cere să i se aloce resurse și să i se permită traficul de date.
De ce se transmite către SB și nu direct către echipamentul de acces și AAA?
Să nu uităm că scopul este ca procesul de taxare să fie unul securizat. Aceasta înseamnă accesul la resurse să fie permis doar utilizatorilor autentificați, dar și ca planul de taxare aplicat să fie cel corect pentru utilizatorul care a trecut prin procesul de autentificare.
Dacă am fi trimis direct la echipamentul de acces, fie mesajul ar fi trebuit să fie mult mai complex, conținând mai multe chei de verificare, fie echipamentul ar fi trebuit să aibă o evidență a certificatelor fiecărei SM, adrese MAC și multe altele.
Practic, cu ajutorul CUANTAX (și a procedurii propuse de mine), vom folosi rezultatele procesului de autentificare mutuală pentru a verifica și a fi siguri că TAX (rata de taxare) este cea corectă pentru SM și, mai mult, că este vorba de aceeași SM autentificată anterior și nu de una pirat.
Deci, SB va primi CRIPTRMSJ1 și, utilizând PMK, va decripta mesajul. Ba mai mult, va putea verifica cheia de autentificare AK folosită în comunicația cu SM și va putea certifica autenticitatea SM (încă o dată în plus). După cum știm, AK se obținea cu ajutorul PMK și a adresei MAC (vezi subcapitolul 5.5.5.2).
Dacă PMK (utilizată pentru a decripta CRIPTRMSJ1) și adresa MAC (recepționată în cadrul aceluiași mesaj) nu corespund cu cele utilizate în a obține, în pașii anteriori, AK, este clar că putem asista la un posibil atac sau putem avea un utilizator fals care încearcă să ia locul utilizatorul autentificat anterior.
În cazul în care SB certifică autenticitatea SM va trimite un mesaj – MSJ2 – către echipamentul de acces și AAA pe care îl vom numi confirmarea taxării. Acest mesaj va avea parametrii [TAX(i), identificator (SM), TIMP(i), REZVERIF]. Identificatorul de SM poate fi adresa MAC a SM sau certificatul SM – SB le deține pe amândouă. Probabil că mult mai ușor va fi să trimită adresa MAC pentru a evita operațiunea de comparare (match) între adresa MAC și certificat.
Parametrul denumit REZVERIF va putea avea două valori – 0 sau 1. În cazul nostru (SB certifică), valoarea parametrului va fi 1.
Astfel, se poate deduce foarte ușor faptul că, în cazul unei nepotriviri în verificarea efectuată de SB, parametrul REZVERIF va fi 0.
Așa cum se poate observa, SB nu are dreptul, în cazul unei probleme, să renunțe la pachet. SB trebuie să trimită mai departe pachetul, cu semnalizarea corespunzătoare, către echipamentul de acces și AAA. Acest lucru este necesar pentru a încheia bucla astfel încât echipamentul de acces să știe că mesajul original a fost recepționat.
În cazul în care nu ar primi răspuns (datorită faptului că SB ar renunța la pachet în urma verificării), echipamentul de acces ar „presupune” că primul mesaj (MSJ1) nu a fost recepționat și atunci ar retransmite mesajul.
Astfel, încărcarea rețelei ar crește iar riscurile ar fi și mai mari – eventuala SM pirat ar tot primi mesaje legate de taxare cu parametrii aferenți și ar putea utiliza informațiile obținute.
În plus, echipamentul de acces trebuie să fie cel care decide dacă, în urma unei semnalizări negative (SB avertizează că nu este SM dorit), va retrimite MSJ1 dar cu alți parametrii corespunzători noului SM. Aceasta situație va fi valabilă numai în cazul în care, datorită unui număr mare de SM, poate apărea situația (puțin probabilă, într-adevăr) în care planul tarifar anunțat să fi fost destinat altui SM. Prin intermediul mecanismului prevăzut de CUANTAX (protocol construit de mine) se dă posibilitatea remedierii acestei erori.
Revenind la mesajul trimis de SB – MSJ2 [TAX(i), identificator (SM), TIMP(i), REZVERIF] – acesta va fi criptat din nou cu MSK, rezultând CRIPTMSJ2[TAX(i),
identificator (SM), TIMP(i), REZVERIF]. Acesta va fi, practic, mesajul transmis către echipamentul de acces și AAA.
Acesta va verifica mesajul și, dacă e confirmat (prin câmpul de REZVERIF) și conține parametrii inițiali (TAX(i)) atunci va permite alocarea resurselor. Din acest punct, SM va putea solicita adresa IP, va putea efectua trafic etc.
Schimbul de mesaje este prezentat și în Fig. 6.15
Figura 6.15 Schimbul de mesaje pentru protocolul CUANTAX pentru o rețea ce se bazează pe tehnologia WiMAX (pentru un utilizator autentificat)
Analiza de securitate pentru protocolul CUANTAX
Analiza de securitate va include două categorii de posibile evenimente – una legată de securitatea mesajelor trimise și una legată de fluxul de comunicație.
Astfel, pentru prima categorie, cea legată de mesaje, așa cum am menționat, ele vor fi criptate cu ajutorul celor două chei MSK și PMK (folosite anterior și în procesul de autentificare). Cele două chei sunt specifice și unice pentru fiecare sesiune inițiată de un SM nou apărut în rețea.[11][29] Deci, din acest punct de vedere, nivelul de securitate este unul ridicat.
Apoi, mesajul trimis de la SM la SB față de cel trimis de echipamentul de acces la SM nu folosesc aceeași cheie de codare, ceea ce reduce riscul ca un atacator să poată reconstitui anumite informații pe baza mesajului de răspuns (reply).
Am adăugat pentru fiecare mesaj o „ștampilă” de timp tocmai pentru a preveni un atac de tipul man-in-the-middle[11][29], SB sesizând eventualele neconcordanțe în urma primirii unui mesaj fals. Mai mult, ținând cont de faptul că echipamentul de acces va primi multe mesaje de confirmare a taxării, marca temporală se dovedește un instrument extrem de util în separarea mesajelor.
În același timp, verificarea suplimentară efectuată la nivel de SB, pe baza AK și pe baza adresei MAC a SM, aduce cu sine măsuri suplimentare în ceea ce privește eventualitatea unui atac.
În cazul în care un operator nu consideră ca fiind de ajuns măsurile de securitate impuse (criptarea cu cheile folosite, marca de timp), poate opta pentru a mai cripta încă o dată mesajele de la SM și de la SB. Așa cum se poate observa și din fig.6.15, negocierea cheilor TEK, KEK etc. [11][31][29] are loc înainte de schimbul de mesaje specifice protocolului CUANTAX. Flexibilitatea din punct de vedere creștere nivel de securitate este, astfel, asigurată.
Pentru cea de-a doua categorie de evenimente – legate de fluxul de comunicație – trebuie să analizăm două puncte de vedere: eventualele zone vulnerabile precum și posibilitatea optimizării fluxului.
Ca și zone vulnerabile, una dintre cele mai importante, evident, este zona radio – comunicația SM <-> SB. În primul rând, ar fi riscurile menționate (interceptare, atac etc.) pentru care avem soluțiile deja prezentate.[11] Protocolul este unul deschis și beneficiază, practic, de toate cheile negociate anterior lui (în procesele anterioare). În funcție de dorința operatorului, se poate opta, așa cum am spus, pentru schimbarea metodei de criptare, păstrându-se doar structura mesajelor. Opinia mea este că, pentru moment, criptarea sugerată anterior este cel mai bun compromis între securitate și overhead-ul (informația adițională) ce poate apărea prin adăugarea unor noi metode de securizare. Cele două chei utilizate au avantajul unicității și sunt generate de un echipament exterior (echipamentul de AAA generează MSK, iar PMK se obține din MSK).[31] Prin urmare, eu consider că, deși SM a fost deja autentificată, introducerea pașilor (de la SB), pe care i-am menționat deja, aduce un plus consistent securității întregului proces.
În ceea ce privește optimizarea fluxului, am luat în considerare posibilitatea ca SB să fie inclusă în schimbul de mesaje încă de la începutul transmisiunii. Astfel, echipamentul urma să trimită MSJ1 la SB, urmând ca SB să trimită mai departe mesajul, după ce îl decripta și îl cripta cu o altă cheie (TEK spre exemplu).
Procedând în acest mod, reducerea riscurilor ar fi nesemnificativă în comparație cu întârzierile introduse de-a lungul întregului proces. În plus, ne vom confrunta (în acest caz) și cu o creștere a gradului de ocupare pentru resursele SB (nevoită să mai proceseze încă un tip de mesaje). Astfel, dacă MSJ1 se dorește a fi interceptat, el poate fi interceptat fie că vine de la SB, fie că vine de la echipamentul de acces și AAA (prin intermediul SB însă fără ca SB să-l mai proceseze). Mai mult, MSK e o cheie mai puțin folosită (față de TEK) și mult mai puțin luată în considerare (pentru moment) în ceea ce privește atacurile. Criptarea folosind această cheie este, prin urmare, mai sigură [29].
În ceea ce privește comunicația echipament de acces – platformă de taxare, aceasta este redusă la minim. A trebuit să țin cont de faptul că practica general întâlnită este ca platforma de taxare (billing,charging și accounting) să aibă funcții strâns legate de aceste operații, urmând să preia cât mai multe informații de profil și de acces de la un alt echipament adițional (în cazul meu, echipamentul de acces și AAA) [31].
Din punctul meu de vedere, am dorit să prezint un protocol specific comunicației (pentru taxare) WiMAX până la echipamentul de acces. Am făcut această alegere tocmai pentru faptul că dincolo de acest echipament se poate folosi fluxul existent (pentru GSM spre exemplu, sau pentru alte comunicații IP). Practic, informațiile solicitate de la platforma de taxare (rata de taxare etc.) și obținute pentru ea (confirmări, profile etc.) de către echipamentul de acces și AAA utilizat de mine în rețele de tip WiMAX, sunt similare cu cele deja vehiculate în rețelele de tip GSM etc. (evident, la nivel general și de principiu) [31][31]. Termenul de cuantă se folosește și în rețele GSM, iar marca de timp reprezintă un parametru important (ca să dăm doar câteva exemple) [29][31][31].
Prin urmare, fluxul oferit de protocolul CUANTAX este, din punctul meu de vedere, pentru moment, optimizat pentru o eficiență, flexibilitate și securitate la nivel ridicat.
Avantaje și dezavantaje pentru protocolul CUANTAX
Trebuie menționat, încă de la început, că protocolul oferit presupune o pierdere de minim o cuantă. Astfel, în cadrul procesului, cuanta i este una care nu va fi taxată. Mai mult, dacă nu se mai așteaptă confirmarea de la SB și se emite deja un mesaj în care se mai trimite o dată modul de taxare (presupunând poate că mesajul de la SB are o întârziere datorită încărcării rețelei), atunci pierderile vor fi de mărimea a două cuante folosite la taxare (i, i+1). Acest lucru se întâmplă mai ales dacă este vorba de o rețea supraîncărcată. Este o pierdere pe care operatorul va trebui să și-o asume (și un dezavantaj).
Din păcate, datorită securității și modului de funcționare, nu putem elimina cuanta pierdută. Oricum, din punct de vedere legal, este necesar ca utilizatorul să accepte modul de facturare și atunci este necesar să i se prezinte modul de taxare. Deci, pasul acesta nu poate fi eliminat.
Apoi, există posibilitatea ca SM să accepte o factură și să trimită confirmare, urmând ca apoi să nege această confirmare și să trimită un mesaj de întrerupere (imediat după confirmare). Evident, mesajul cu i+1 va fi emis, urmând ca apoi, după primirea mesajului de întrerupere, echipamentul de acces și AAA să taie accesul SM. Taxare cuantei i+1 se poate imputa utilizatorului, dar acesta poate susține faptul că mesajele au fost trimise simultan și, teoretic, nu ar trebui să plătească. Acest punct rămâne a fi soluționat cu ajutorul liberului arbitru.
Totuși, protocolul permite protecție și pentru SM. Astfel, există posibilitatea ca SM să primească o cotație (o descriere a modului de taxare) pentru resurse deja alocate.
Astfel, în rețele mari și încărcate există posibilitatea ca două cereri concurente pe aceleași resurse să vină consecutiv, aducând riscul de suprataxare (overcharging) din partea operatorului. Introducerea pasului de confirmare a taxării ajută ca SM (și, implicit, utilizatorul) să fie protejată în această situație, putând refuza taxarea. Dacă taxarea s-ar fi făcut fără notificarea SM, practic utilizatorul ar fi fost taxat pe resurse pe care nu le putea folosi. Prin urmare, avantajul mecanismului propus de CUANTAX este evident.
Același raționament se poate aplica și în cazul în care SM „intră” în rețea, este autentificată, dar se razgândește. Astfel, refuză taxarea și anunță că părăsește rețeaua. Prin
urmare, orice comunicație cu această SM se poate întrerupe fără alte pierderi – atât din partea operatorului cât și din partea utilizatorului (excluzând, evident, cuanta i folosită inițial).
Prin urmare, mecanismul protocolului CUANTAX aduce cu sine avantaje consistente, dar și un dezavantaj legat de netaxarea unei cuante (datorată pasului de confirmare). Eu cred însă că un astfel de compromis aduce cu sine eliminarea multor riscuri de securitate și nu numai (riscuri deja descrise anterior – overcharging etc.).
Protocolul CUANTAX – limbajul comun pentru sisteme diferite
Dincolo de analizele teoretice, întotdeauna trebuie să avem în vedere partea practică și îmbunătățirile efective pe care le poate aduce un nou protocol de comunicare.
După cum știm deja, introducerea unei componente noi într-o comunicație (fie că este vorba de un protocol, de o tehnică de modulație sau de o metodă de codare) poate determina creșterea complexității întregului sistem.
Astfel, după prezentarea generală și analiza detaliată a noii componente, este convingerea mea că avem nevoie de o plasare concretă a acesteia, cu o descriere cât mai clară a îmbunătățirilor aduse, atât în prezent cât și pentru dezvoltări ulterioare.
Acesta este și motivul pentru care, în ultima parte a lucrării mele, doresc să ofer o imagine cât mai apropiată de situația reală precum și beneficiile aferente (dincolo de cele pur teoretice).
Pentru a putea realiza ce mi-am propus, trebuie să definesc puțin întregul context.
Detaliile și limitările situației curente
Încă de la începutul aceste teze, ideea pe care am dorit să o subliniez (și pe care am reamintit-o pe tot parcursul demersului meu) este că, în condițiile actuale, apariția unei noi tehnologii nu poate fi tratată separat față de tehnologiile existente.
Dincolo de partea pur teoretică, analiza acestei tehnologii se face comparativ cu situația curentă, iar implementările practice (rețelele) vor trebui înglobate în rețelele complexe deja existente. Așa cum spuneam (și cum se poate observa și statistic) sunt foarte puțini operatori care dezvoltă complet separat o rețea de tip WiMAX fără a folosi resursele deja existente.
În plus, tendința clară este de a oferi servicii integrate – comunicații totale (total communication) – astfel încât un client să poată beneficia de servicii GSM, WiMAX etc. toate de la același operator.
Nu mai menționez aici avantajele sau dezavantajele unei astfel de abordări. Ele sunt subiecte de dezbatere pentru majoritatea conferințelor și forumurilor telecom din ultima perioadă.
Foarte important este că:
Rețeaua bazată pe tehnologia WiMAX va fi parte a unei rețele complexe a operatorului și va trebui să folosească resursele deja existente pentru anumite operații printre care și taxarea. Deci, va trebui să se integreze cu platforma existentă de taxare.
Clientul va trebui să primească o singură factură, însă, în caz de nevoie, operatorul va trebui să poată răspundă punctual la reclamații. Adică să poată separa evenimentele ce aparțin de rețeaua GSM sau cele ce țin de rețeaua WiMAX.
Pentru primul punct menționat, trebuie să spun că, pentru o rețea de telefonie mobilă, evenimentele care ajung la o platformă de taxare pot veni de la:
echipamente tip GGSN (Gateway GPRS Support Node) sau SGSN (Serving GPRS Support Node) pentru operațiunile de comutație dintr-o rețea de tip 3G
alte echipamente adiționale rețelelor fără fir cum ar fi cele pentru SMSC (Short Message Service Centre)
elemente de rețea cum ar fi serverele RADIUS, platforme de comerț online, servere pentru jocuri etc.
Aceste evenimente (în funcție de echipamentul care trimite) pot conține:
notificări pentru începutul unui transfer de date (raportate de GGSN)
notificări pentru începerea/terminarea unei convorbiri (raportate de MSC – Centru mobil de comutare – Mobile Switching Centre)
notificare privind o tranzacție comercială realizată prin intermediul unei platforme de comerț online (raportate de serverul care susține această platformă) etc.
De asemenea, în general, aceste evenimente vor conține următoarele atribute (printre altele):
atribute de taxare – care conțin unitatea de măsură și de volum
atribute de direcționare – pentru a permite direcționarea și tratarea corectă a evenimentului de către componentele aferente ale platformei
atribute de identificare – ce țin de identificarea clientului (ca și exemplu – numărul de telefon)
atribute general – ce tratează anumite cerințe speciale, cum ar fi date pentru sistemele fraudă etc.
Introducerea unei tehnologii WiMAX și construirea unei rețele bazate pe această tehnologie vor trebui să se supună acestor reguli pentru taxare. Platforma de taxare va trebui să primească de la noua rețea și de la noile echipamente evenimente care să conțină notificările necesare (conectare/deconectare etc) și, mai ales, atributele dorite pentru a putea fi tratate corect.
Și toate aceste cerințe, dacă este posibil, să fie îndeplinite de către un echipamente deja inclus în rețea, fără a fi necesare dezvoltări ulterioare.
În acest mod, evităm cerințe suplimentare adresate furnizorului de platformă de taxare, cerințe care, evident, vor aduce costuri noi și un timp de implementare suplimentar.
Soluționarea cerințelor prin folosirea CUANTAX
În subcapitolele anterioare introduceam protocolul de taxare CUANTAX și menționam eu că principalele echipamente implicate în această comunicație premergătoare și ajutătoare pentru taxare sunt SM, SB și echipamentul de acces și AAA. Toate aceste echipamente sunt deja necesare rețelei bazate pe tehnologia WiMAX, cu amendamentul că echipamentul de acces și AAA poate fi sau nu un echipament separat de restul rețelei. În analiza pe care am realizat-o în capitolul 5, am arătat că funcțiile acestui echipament pot fi înglobate de echipamente deja existente – cum ar fi cele care îndeplinesc rolul de GGSN (ca și exemplu). Deci, și din acest punct de vedere, suntem în scopul pe care mi l-am impus – folosirea pe cât posibil a resurselor existente în rețea.
Spuneam de asemenea (în subcapitolul dedicat protocolului meu de taxare) că, pentru criptare, protocolul folosește 2 chei aparținând tehnologiei WiMAX – PMK (Pairwise Master Key) și MSK (Master Session Key) – fără a apela la alte instrumente de codare ce ar trebui implementate separat. Nu există nici o cheie de criptare „agreată” între SM și platforma de
taxare. Practic, traficul ar trebui „filtrat” tot de prima entitate care poate face acest lucru – și aceasta este echipamentul de acces și AAA.
Primul mesaj transmis avea următoare componența: MSJ1 [TAX(i), DIM(i), TIMP(i)]. Mesajul va fi transmis de echipamentul de acces si AAA către SM imediat după ce utilizatorul a fost autentificat. Am notat cu i numărul cuantei utilizate (i=1…..n ), cu TAX(i) – rata de taxare pentru cuanta i și cu DIM(i) – dimensiunea cuantei i. Fiecare cuantă va avea și o marcă de timp – necesară pentru unicitate și pentru verificări și statistici. Această marcă o voi nota cu TIMP(i).
Ce putem observa din analiza acestui mesaj?
Acest mesaj poate fi generat de un eveniment (utilizator nou autentificat în rețea) și conține atribute ca – unitate de măsură și volum (TAX(i), DIM(i)), timp (TIMP(i)). În plus, va fi și criptat asigurându-se securitatea comunicației.
În acest punct ne putem gândi că protocolul asigură modul de comunicare impus de limitările situației curente (prezentate anterior). Lipsesc atributele de identificare, dar trebuie să ținem cont că primul mesaj nu implică și participarea platformei de taxare – practic este un mesaj inițial (primul pas în proces) care va ajuta ulterior la obținerea informațiilor dorite.
Următorul mesaj este practic răspunsul SM. Acest mesaj pe care eu l-am denumit CRIPTRMSJ1 are următoarele componente [TIMP(i), TAX(i), adresa MAC a SM]. Mesajul va fi transmis, de această dată, către SB.
Acest mesaj va fi ceea ce se poate numi cerere de autorizare a taxării. SM confirmă că este de acord cu modul de taxare și cere să i se aloce resurse și să i se permită traficul de date. În cadrul acestui mesaj apare și atributul de identificare – adresa MAC a SM (cel mai în măsură identificator într-o rețea WiMAX).
Reluând, de ce se transmite către SB și nu direct către echipamentul de acces și AAA? Pentru că, de acolo, informația ar putea ajunge direct la platforma de taxare.
Să nu uităm că scopul meu este ca procesul de taxare să fie unul securizat. Aceasta înseamnă accesul la resurse să fie permis doar utilizatorilor autentificați, dar și ca planul de taxare aplicat să fie cel corect pentru utilizatorul care a trecut prin procesul de autentificare.
Dacă am fi trimis direct la echipamentul de acces, fie mesajul ar fi trebuit să fie mult mai complex, conținând mai multe chei de verificare, fie echipamentul ar fi trebuit să aibă o evidență a certificatelor fiecărei SM, adrese MAC și multe altele.
Practic, cu ajutorul CUANTAX (și a procedurii propuse), vom folosi rezultatele procesului de autentificare mutuală pentru a verifica și a fi siguri că TAX (rata de taxare) este cea corectă pentru SM și, mai mult, că este vorba de aceeași SM autentificată anterior și nu de una pirat.
În cazul în care SB certifică autenticitatea SM va trimite un mesaj – MSJ2 – către echipamentul de acces și AAA pe care îl vom numi confirmarea taxării. Acest mesaj va avea parametrii [TAX(i), identificator (SM), TIMP(i), REZVERIF]. Identificatorul de SM poate fi adresa MAC a SM sau certificatul SM – SB le deține pe amândouă. Probabil că mult mai ușor va fi să trimită adresa MAC pentru a evita operațiunea de match între adresa MAC și certificat.
Parametrul denumit REZVERIF va putea avea două valori – 0 sau 1. În cazul nostru (SB certifică), valoarea parametrului va fi 1.
Astfel, se poate deduce foarte ușor faptul că, în cazul unei nepotriviri în verificarea efectuată de SB, parametrul REZVERIF va fi 0.
În acest punct, la echipamentul de acces și AAA ajunge un mesaj care certifică evenimentul (utilizatorul vrea să folosească resursele rețelei și trebuie taxat), cu atribute de taxare (unitate de măsură și volum (TAX(i))), identificare (adresa MAC a SM), generale (rezultate verificare SM).
În plus, echipamentul de acces trebuie să fie cel care decide dacă, în urma unei semnalizări negative (SB avertizează că nu este SM dorit), va retrimite MSJ1 dar cu alți parametrii corespunzători noului SM. Aceasta situație va fi valabilă numai în cazul în care, datorită unui număr mare de SM, poate apărea situația (puțin probabilă, într-adevăr) în care planul tarifar anunțat să fi fost destinat altui SM. Prin intermediul mecanismului prevăzut de CUANTAX (protocol construit de mine) se dă posibilitatea remedierii acestei erori.
Deci, echipamentul de acces și AAA – sau echipamentul din rețea care îndeplinește funcțiile aferente – are toate informațiile necesare pentru a se transforma în ceea ce am numit „modul de colectare a evenimentelor” (event collection) pentru platforma de taxare.
Adică, folosind protocolul CUANTAX, putem să îndeplinim limitările impuse de o rețea existentă (așa cum le-am descris anterior), putem avea notificări pentru evenimente și, mai ales, le putem avea cu atributele cerute.
Singurul pas care trebuie adăugat ar fi transmiterea informației legate de eveniment către platforma de taxare. Numai că aici putem beneficia de suportul deja existent.
Conform dezideratului propus – acela de a folosi resursele existente – putem considera situația în care echipamentul care preia operațiunile de AAA pentru rețeaua WiMAX este unul care îndeplinește deja și alte roluri în rețea (GGSN spre exemplu). În acest caz, este evident faptul că între echipamentul respectiv și platforma de taxare există deja comunicație bazată pe un protocol. Nu trebuie decât preluate informațiile care au fost deja transmise prin CUANTAX, încapsulate conform protocolului respectiv și transmise către platforma de taxare.
Cazul mai puțin optimist – în care avem nevoie de un echipament separat de acces și AAA pentru rețeaua bazată pe tehnologia WiMAX – și, deci, nu există o comunicație deja stabilită între acesta și platforma de taxare, putem extinde CUANTAX adaugând un mesaj MSJ3 cu parametrii doriți (TAX(i), adresa MAC a SM…..).
Acest lucru va presupune schimbări și în interfața platformei de taxare, însă nu foarte mari. Modul de compunere pentru acest protocol permite o înglobare mai ușoară a lui în comunicațiile deja existente.
Concluzionând, pot spune că protocolul CUANTAX se dovedește un instrument foarte util în operațiunile premergătoare taxării, vehiculând exact informațiile dorite și impuse de standardele actuale.
Analiză experimentală
Pentru arhitectura din Fig. 6.7, am urmărit care sunt mesajele schimbate de entitățile implicate (SM, SB, echipamentul de acces și AAA) în procesul de autentificare.
Pentru operatorul care are implementată o astfel de soluție, echipamentele sunt:
SM și SB – Alvarion (802.16e)
ASN-GW – Router Cisco 2821 (sau 2811)
Echipament de access și AAA – Router Cisco 760X (7604 sau 7606)
Pentru experimentul nostru, am recreat arhitectura la o scară mai mică și am folosit:
PC conectat la SM
SM și SB – Alvarion (802.16e)
ASN-GW – Router Cisco 1841
Echipament de access și AAA – Switch Cisco 2950 + server de AAA de la Bridgewater
Software pentru interceptare pachete (sniffer) – Wireshark 1.0 (fost Ethereal) [73]
Captura s-a realizat pe interfața de AAA, iar standardul utilizat a fost 802.16e (WiMAX mobil). Arhitectura pentru aranjamentul de laborator se regăsește în Fig. 6.16. Protocolul folosit a fost RADIUS.
Partea de DHCP nu am mai urmărit-o, dar SM primește adresă IP doar prin DHCP de la SB (o adresă privată) care are server de DHCP încorporat (pentru echipamentele pe care le-am folosit). SB poate fi configurată și ca DCHP Relay – pentru a permite unui alt server de DHCP să ofere adrese IP pentru SM (fiind chiar într-una din situațiile deja menționate în cazul planului de securitate). SB nu poate avea decât IP static (pentru echipamentul pe care l-am folosit eu).
R1841 folosit nu va avea o configurație foarte complicată – va conține (printre altele) doar o listă de acces de bază (pentru a permite accesul pachetelor venite de la SB). O parte din configurația R1841 este prezentată în anexa C.
Un alt fapt interesant de menționat – și care reprezintă o motivație în plus pentru planul nostru – este faptul că toată configurația de profil de utilizator (chiar și pentru serviciul fluxului de comunicație) se realizează în echipamentul de acces și AAA (server-ul Bridgewater în cazul nostru).
În felul acesta, avem o soluție de configurare centralizată (avantaj deja menționat de mine), iar server-ul de AAA va trimite detaliile către SB și în felul acesta SB va știu ce CID-uri să aloce pentru SM cu userul și parola X.
Deci, practic, ce se configura în ASN-GW anterior, în acest moment se poate configura în echipamentul de acces și AAA.
Pentru a sublinia și mai clar acest avantaj, am inclus în configurația R1841 și partea de RADIUS (prezentă anterior în ASN-GW), configurație care poate migra acum cu ușurință la echipamentul de acces și AAA (centralizat).
În situația de laborator, nu am putut avea un echipament de nivelul routerului Cisco 760x si am apelat la server-ul de AAA de la Bridgewater.
Configurația de AAA se poate face, centralizat (subliniez încă o dată) în echipamentul de acces și AAA (router nucleu așa cum am sugerat anterior, care poate deveni și SSG – vezi fig. 6.7).
Mesajele prezentate sunt preluate din fișierul de captură (prezentat în totalitate în anexa D). Atributele sunt detaliate cu explicațiile aferente.
În cazul experimentului, NAS (Network Access Server) pentru SM este SB, ea fiind cea care trimite cererea de acces către RADIUS. Practic, între SM și server-ul de AAA se va deschide un tunel pentru o comunicare cât mai securizată.
Apoi, deși protocolul CUANTAX (pe care l-am definit anterior) nu are încă o implementare detaliată – urmând să dezvolt această implementare în lucrările mele ulterioare, am oferit la final o (posibilă) mostră de schimburi de mesaje pentru acest protocol.
Schimbul de mesaje se va face (așa cum am spus deja) între SM, SB și echipamentul de acces și AAA.
Figure 6.16 Arhitectura de laborator pentru o rețea WiMAX (conformă cu planul de securitate)
Schimbul de mesaje
Pentru autentificare:
Câmpurile din mesaje vor fi cele originale (ne-traduse), urmând să ofer explicațiile aferente.
Mesajul inițial cerere de acces
Frame 1 (251 bytes on wire, 251 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
Unde pentru Frame 1 avem detalierea:
Arrival Time: Apr 27, 2009 10:16:05.219003000
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 251 bytes
Capture Length: 251 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:radius:eap]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Iar pentru Radius Protocol vom avea (detaliat):
Radius Protocol
Code: Access-Request (1)
Packet identifier: 0xb7 (183)
Length: 209
Authenticator: 4C08200E50F7A35552AC6F974EAD011A
Attribute Value Pairs
AVP: l=48 t=User-Name(1): {am=1}[anonimizat]
User-Name: {am=1}[anonimizat]
AVP: l=53 t=EAP-Message(79) Last Segment[1]
EAP fragment
Extensible Authentication Protocol
Code: Response (2)
Id: 1
Length: 51
Type: Identity [RFC3748] (1)
Identity (46 bytes): {am=1}[anonimizat]
AVP: l=18 t=Message-Authenticator(80): AA6F22A46E50661DC0D53D144F3119E8
Message-Authenticator: AA6F22A46E50661DC0D53D144F3119E8
AVP: l=5 t=NAS-Identifier(32): NPU
NAS-Identifier: NPU
AVP: l=8 t=Calling-Station-Id(31): \000\020\347\n\375\344
Calling-Station-Id:
AVP: l=14 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=8 t=WiMAX-BS-Id(46) C=0x00: 0002004FB2
WiMAX-BS-Id: 0002004FB2
AVP: l=6 t=NAS-Port(5): 183
NAS-Port: 183
AVP: l=6 t=NAS-Port-Type(61): Unknown(27)
NAS-Port-Type: Unknown (27)
AVP: l=6 t=Framed-MTU(12): 2000
Framed-MTU: 2000
AVP: l=6 t=Service-Type(6): Framed-User(2)
Service-Type: Framed-User (2)
AVP: l=13 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=7 t=WiMAX-GMT-Timezone-offset(3) C=0x00: 0
WiMAX-GMT-Timezone-offset: 0
Mesajul de challenge
Acest tip de mesaj este folosit fie pentru a solicita informații suplimentare fie atunci când între utilizator (PC) și serverul de AAA se stabilește un tunel securizat iar detaliile utilizatorului (credentials) sunt ascunse de NAS – așa cum este și cazul nostru.
Frame 2 (120 bytes on wire, 120 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
Unde Radius Protocol detaliat este:
Radius Protocol
Code: Access-challenge (11)
Packet identifier: 0xb7 (183)
Length: 78
Authenticator: 77A1114A0FCE8C8D9CCAFBFB868F5B39
Attribute Value Pairs
AVP: l=32 t=State(24): 4257530001000E2F001E0001061271821FE3469E4D8F61C3…
State: 4257530001000E2F001E0001061271821FE3469E4D8F61C3…
AVP: l=8 t=EAP-Message(79) Last Segment[1]
EAP fragment
Extensible Authentication Protocol
Code: Request (1)
Id: 2
Length: 6
Type: EAP-TTLS [RFC5281] (21)
Flags(0x20): Start
TTLS version 0
AVP: l=18 t=Message-Authenticator(80): AF80640B8C575FCBB0D1A0732E7D190E
Message-Authenticator: AF80640B8C575FCBB0D1A0732E7D190E
Mesajul 2 de cerere de acces
Practic, prin intermediul acestui mesaj se cere stabilirea tunelului securizat între PC și server-ul de AAA. Acest lucru îl vom sesiza imediat când vom vedea că, printre protocoalele utilizate, va apărea și SSL (Secure Socket Layer). Mai mult, în cazul acestor tipuri de conexiuni (SSL sau TLS), se stabilește o paradigmă (denumită CipherSuites) în care se arată ce combinație de algoritmi de criptare se va folosi în comunicație. Așa cum vom vedea și în detalierea de mai jos a mesajului, pe lângă această mențiune a algoritmilor utilizați, clientul și server-ul schimbă, prin intermediul mesajelor de tip client hello și server hello diferite coduri necesare.
Frame 3 (294 bytes on wire, 294 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
Unde pentru Frame 3 avem detalierea:
Frame 3 (294 bytes on wire, 294 bytes captured)
Arrival Time: Apr 27, 2009 10:16:05.292021000
[Time delta from previous captured frame: 0.071509000 seconds]
[Time delta from previous displayed frame: 0.071509000 seconds]
[Time since reference or first frame: 0.073018000 seconds]
Frame Number: 3
Frame Length: 294 bytes
Capture Length: 294 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:radius:eap:ssl]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Iar pentru Radius Protocol vom avea (detaliat):
Radius Protocol
Code: Access-Request (1)
Packet identifier: 0xb8 (184)
Length: 252
Authenticator: 79A403B9057780BA78F41CB977540D75
Attribute Value Pairs
AVP: l=48 t=User-Name(1): {am=1}[anonimizat]
User-Name: {am=1}[anonimizat]
AVP: l=64 t=EAP-Message(79) Last Segment[1]
EAP fragment
Extensible Authentication Protocol
Code: Response (2)
Id: 2
Length: 62
Type: EAP-TTLS [RFC5281] (21)
Flags(0x0):
TTLS version 0
Secure Socket Layer
TLSv1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 51
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 47
Version: TLS 1.0 (0x0301)
Random
gmt_unix_time: Jan 1, 1970 02:00:59.000000000
random_bytes: 2E41F0E0F76769A3BB79B77680327220E5BACED3920426D8…
Session ID Length: 0
Cipher Suites Length: 8
Cipher Suites (4 suites)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
AVP: l=18 t=Message-Authenticator(80): E3425C96AD3372C432F3DBE7D1CF72E0
Message-Authenticator: E3425C96AD3372C432F3DBE7D1CF72E0
AVP: l=5 t=NAS-Identifier(32): NPU
NAS-Identifier: NPU
AVP: l=6 t=NAS-IP-Address(4): 10.10.135.82
NAS-IP-Address: 10.10.135.82 (10.10.135.82)
AVP: l=8 t=Calling-Station-Id(31): \000\020\347\n\375\344
Calling-Station-Id:
AVP: l=14 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=8 t=WiMAX-BS-Id(46) C=0x00: 0002004FB2
WiMAX-BS-Id: 0002004FB2
AVP: l=6 t=NAS-Port(5): 184
NAS-Port: 184
AVP: l=6 t=NAS-Port-Type(61): Unknown(27)
NAS-Port-Type: Unknown (27)
AVP: l=6 t=Framed-MTU(12): 2000
Framed-MTU: 2000
AVP: l=6 t=Service-Type(6): Framed-User(2)
Service-Type: Framed-User (2)
AVP: l=13 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=7 t=WiMAX-GMT-Timezone-offset(3) C=0x00: 0
WiMAX-GMT-Timezone-offset: 0
AVP: l=32 t=State(24): 4257530001000E2F001E0001061271821FE3469E4D8F61C3…
State: 4257530001000E2F001E0001061271821FE3469E4D8F61C3…
Mesajul 2 de challenge
Mesajul acesta este trimis de serverul de AAA tocmai pentru a cere detalii suplimentare – în acest caz, certificatele necesare stabilirii conexiunii autentificate (tunelului) precum și cele necesare autentificării. Nu voi prezenta decât o parte din mesajul de RADIUS (o mostră reprezentativă).
Frame 4 (1146 bytes on wire, 1146 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
Unde pentru Frame 4 avem detalierea:
Frame 4 (1146 bytes on wire, 1146 bytes captured)
Arrival Time: Apr 27, 2009 10:16:05.295583000
[Time delta from previous captured frame: 0.003562000 seconds]
[Time delta from previous displayed frame: 0.003562000 seconds]
[Time since reference or first frame: 0.076580000 seconds]
Frame Number: 4
Frame Length: 1146 bytes
Capture Length: 1146 bytes
[Frame is marked: False]
[Protocols in frame [truncated]: eth:ip:udp:radius:eap:ssl:pkcs-1:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:x509sat:pkcs-1:x509ce:pkcs-1:pkcs-1:x509sat:x509sat:x509sat:x509sat:x5]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Iar pentru Radius Protocol vom avea (parțial detaliat):
Radius Protocol
Code: Access-challenge (11)
Packet identifier: 0xb8 (184)
Length: 1104
Authenticator: A84038A0E2A8D0D00A9134FB9E1440E8
Attribute Value Pairs
AVP: l=32 t=State(24): 4257530001000E2F001E0001061223D50DC1CC70F47CF893…
State: 4257530001000E2F001E0001061223D50DC1CC70F47CF893…
AVP: l=255 t=EAP-Message(79) Segment[1]
AVP: l=255 t=EAP-Message(79) Segment[2]
AVP: l=255 t=EAP-Message(79) Segment[3]
AVP: l=255 t=EAP-Message(79) Segment[4]
AVP: l=14 t=EAP-Message(79) Last Segment[5]
EAP fragment
Extensible Authentication Protocol
Code: Request (1)
Id: 3
Length: 1024
Type: EAP-TTLS [RFC5281] (21)
Flags(0xC0): Length More
TTLS version 0
Length: 1609
[EAP-TLS Fragments (1609 bytes): #4(1014), #6(595)]
[Frame: 4, payload: 0-1013 (1014 bytes)]
[Frame: 6, payload: 1014-1608 (595 bytes)]
Secure Socket Layer
TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 74
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 70
Version: TLS 1.0 (0x0301)
Random
gmt_unix_time: Apr 27, 2009 10:12:56.000000000
random_bytes: 790F45AAB0C923682FC26E6055ED838006106B4EA6347542…
Session ID Length: 32
Session ID: C0A8663AA353F67DBE1474D7C0CF3C72F1F527C02D63C0EA…
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Compression Method: null (0)
TLSv1 Record Layer: Handshake Protocol: Certificate
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 1516
Handshake Protocol: Certificate
Handshake Type: Certificate (11)
Length: 1512
Certificates Length: 1509
Certificates (1509 bytes)
Certificate Length: 658
Certificate (pkcs-9-at-emailAddress=[anonimizat],id-at-commonName=server,id-at-organizationalUnitName=rd,id-at-organizationName=accton,id-at-localityName=hsinchu,id-at-stateOrProvinceName=taiwan,id-at-countryName=tw)
signedCertificate
version: v3 (2)
serialNumber: 2
signature (md5WithRSAEncryption)
issuer: rdnSequence (0)
validity
subject: rdnSequence (0)
subjectPublicKeyInfo
extensions: 1 item
algorithmIdentifier (md5WithRSAEncryption)
Padding: 0
encrypted: 29C038B4E683C1BFD516FA0B59A13BE9468E03AD2988899A…
Certificate Length: 845
Certificate (pkcs-9-at-emailAddress=[anonimizat],id-at-commonName=ca,id-at-organizationalUnitName=rd,id-at-organizationName=accton,id-at-localityName=hsinchu,id-at-stateOrProvinceName=taiwan,id-at-countryName=tw)
signedCertificate
version: v3 (2)
serialNumber: 0
signature (md5WithRSAEncryption)
issuer: rdnSequence (0)
validity
subject: rdnSequence (0)
subjectPublicKeyInfo
extensions: 3 items
algorithmIdentifier (md5WithRSAEncryption)
Padding: 0
encrypted: 4E63D5121049D6FE6A6A3E3357BD00019C53668A70C06954…
TLSv1 Record Layer: Handshake Protocol: Server Hello Done
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 4
Handshake Protocol: Server Hello Done
Handshake Type: Server Hello Done (14)
Length: 0
AVP: l=18 t=Message-Authenticator(80): DCAB39DEAB0465A5511752D2C293C9E0
Mesajul 3 de cerere de acces
Practic, prin intermediul acestui mesaj se certifică stabilirea tunelului și se cere acces. Dupa acest mesaj, ar trebui (dacă totul e în regulă) să urmeze acceptul server-ului. Dacă nu, server-ul (așa cum a fost si cazul experimentului meu) mai cere informații suplimentare.
Frame 5 (238 bytes on wire, 238 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
Unde Radius Protocol detaliat va fi:
Radius Protocol
Code: Access-Request (1)
Packet identifier: 0xb9 (185)
Length: 196
Authenticator: 79A403B9057780BA78F41CB977540D75
Attribute Value Pairs
AVP: l=48 t=User-Name(1): {am=1}[anonimizat]
User-Name: {am=1}[anonimizat]
AVP: l=8 t=EAP-Message(79) Last Segment[1]
EAP fragment
Extensible Authentication Protocol
Code: Response (2)
Id: 3
Length: 6
Type: EAP-TTLS [RFC5281] (21)
Flags(0x0):
TTLS version 0
AVP: l=18 t=Message-Authenticator(80): CBA0E9BE30261BA2E956BE3AF4D35A8A
Message-Authenticator: CBA0E9BE30261BA2E956BE3AF4D35A8A
AVP: l=5 t=NAS-Identifier(32): NPU
NAS-Identifier: NPU
AVP: l=6 t=NAS-IP-Address(4): 10.10.135.82
NAS-IP-Address: 10.10.135.82 (10.10.135.82)
AVP: l=8 t=Calling-Station-Id(31): \000\020\347\n\375\344
Calling-Station-Id:
AVP: l=14 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=8 t=WiMAX-BS-Id(46) C=0x00: 0002004FB2
WiMAX-BS-Id: 0002004FB2
AVP: l=6 t=NAS-Port(5): 185
NAS-Port: 185
AVP: l=6 t=NAS-Port-Type(61): Unknown(27)
NAS-Port-Type: Unknown (27)
AVP: l=6 t=Framed-MTU(12): 2000
Framed-MTU: 2000
AVP: l=6 t=Service-Type(6): Framed-User(2)
Service-Type: Framed-User (2)
AVP: l=13 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=7 t=WiMAX-GMT-Timezone-offset(3) C=0x00: 0
WiMAX-GMT-Timezone-offset: 0
AVP: l=32 t=State(24): 4257530001000E2F001E0001061223D50DC1CC70F47CF893…
State: 4257530001000E2F001E0001061223D50DC1CC70F47CF893…
Mesajul de acceptare a cererii de acces
Acesta este mesajul prin care server-ul de AAA acceptă cererea de la utilizator. (Nu am mai prezentat mesajele de challenge suplimentare inițiate de server-ul de AAA pentru a obține diferite informații).
Frame 11 (238 bytes on wire, 238 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
Unde pentru Frame 11 avem detalierea:
Frame 12 (678 bytes on wire, 678 bytes captured)
Arrival Time: Apr 27, 2009 10:16:05.845323000
[Time delta from previous captured frame: 0.018482000 seconds]
[Time delta from previous displayed frame: 0.018482000 seconds]
[Time since reference or first frame: 0.626320000 seconds]
Frame Number: 12
Frame Length: 678 bytes
Capture Length: 678 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:radius:eap]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Iar pentru Radius Protocol vom avea (parțial detaliat):
Radius Protocol
Code: Access-Accept (2)
Packet identifier: 0xbc (188)
Length: 636
Authenticator: 5E3FD8B8F610DF1AF2D04F7C021AE18A
[This is a response to a request in frame 11]
[Time from request: 0.018482000 seconds]
Attribute Value Pairs
AVP: l=24 t=Class(25): 4257530001000E2F00160002030701000000F4070300
Class: 4257530001000E2F00160002030701000000F4070300
AVP: l=12 t=Vendor-Specific(26) v=Microsoft(311)
VSA: l=6 t=MS-MPPE-Encryption-Policy(7): Encryption-Required(2)
MS-MPPE-Encryption-Policy: Encryption-Required (2)
AVP: l=12 t=Vendor-Specific(26) v=Microsoft(311)
VSA: l=6 t=MS-MPPE-Encryption-Types(8): RC4-128(4)
MS-MPPE-Encryption-Types: RC4-128 (4)
AVP: l=58 t=Vendor-Specific(26) v=Microsoft(311)
VSA: l=52 t=MS-MPPE-Send-Key(16): DF08DE4B3507B1B6E099B1408CCE85F60A8284FABBEBF45C…
MS-MPPE-Send-Key: DF08DE4B3507B1B6E099B1408CCE85F60A8284FABBEBF45C…
AVP: l=58 t=Vendor-Specific(26) v=Microsoft(311)
VSA: l=52 t=MS-MPPE-Recv-Key(17): EC93AF47234332CCF9631E860AA92C439C1A623C68FB6309…
MS-MPPE-Recv-Key: EC93AF47234332CCF9631E860AA92C439C1A623C68FB6309…
AVP: l=30 t=Vendor-Specific(26) v=Alvarion Ltd.(12394)
VSA: l=24 t=Unknown-Attribute(1): 010653475F310304000104061E1E1E1E06061E1E1EFE
Unknown-Attribute: 010653475F310304000104061E1E1E1E06061E1E1EFE
AVP: l=41 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=35 t=WiMAX-AAA-Session-Id(4) C=0x00: 4141454141414141744436323771727A626549724F547072…
WiMAX-AAA-Session-Id: 4141454141414141744436323771727A626549724F547072…
AVP: l=91 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=85 t=WiMAX-MSK(5) C=0x00: CDB64F81308CA3BD44C6E0510D07B9B2087762876229210A…
WiMAX-MSK: CDB64F81308CA3BD44C6E0510D07B9B2087762876229210A…
AVP: l=13 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=7 t=WiMAX-hHA-IP-MIP4(6) C=0x00: 10.10.135.83
WiMAX-hHA-IP-MIP4: 10.10.135.83 (10.10.135.83)
AVP: l=43 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=37 t=WiMAX-MN-hHA-MIP4-Key(10) C=0x00: 982025EB006B997EA38B9CC1BF13BC24E2A4573CA0CBB4B9…
WiMAX-MN-hHA-MIP4-Key: 982025EB006B997EA38B9CC1BF13BC24E2A4573CA0CBB4B9…
AVP: l=13 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=7 t=WiMAX-MN-hHA-MIP4-SPI(11) C=0x00: EBBF0A36
WiMAX-MN-hHA-MIP4-SPI: EBBF0A36
AVP: l=43 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=37 t=WiMAX-FA-RK-Key(14) C=0x00: 9D03CD38D0CDD4008CC43991F328C1CFB9632F247B49D8AC…
WiMAX-FA-RK-Key: 9D03CD38D0CDD4008CC43991F328C1CFB9632F247B49D8AC…
AVP: l=43 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=37 t=WiMAX-HA-RK-Key(15) C=0x00: 8F7BC2ED99FC97F10AC6876FB1FF0D71957D47D667C5CC95…
WiMAX-HA-RK-Key: 8F7BC2ED99FC97F10AC6876FB1FF0D71957D47D667C5CC95…
AVP: l=13 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=7 t=WiMAX-HA-RK-SPI(16) C=0x00: 1962808
WiMAX-HA-RK-SPI: 1962808
AVP: l=13 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=7 t=WiMAX-HA-RK-Lifetime(17) C=0x00: 55055
WiMAX-HA-RK-Lifetime: 55055
AVP: l=36 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=30 t=WiMAX-Packet-Flow-Descriptor(28) C=0x00: 6 TLV(s) inside
TLV: l=4 t=WiMAX-Packet-Data-Flow-Id(1): 1
WiMAX-Packet-Data-Flow-Id: 1
TLV: l=3 t=WiMAX-Direction(4): Bi-Directional(3)
WiMAX-Direction: Bi-Directional (3)
TLV: l=3 t=WiMAX-Transport-Type(6): IPv4-CS(1)
WiMAX-Transport-Type: IPv4-CS (1)
TLV: l=3 t=WiMAX-Uplink-QOS-Id(7): 1
WiMAX-Uplink-QOS-Id: 1
TLV: l=3 t=WiMAX-Downlink-QOS-Id(8): 1
WiMAX-Downlink-QOS-Id: 1
TLV: l=11 t=Unknown-Attribute(11): 010301020301040303
Unknown-Attribute: 010301020301040303
AVP: l=24 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=18 t=WiMAX-QoS-Descriptor(29) C=0x00: 4 TLV(s) inside
TLV: l=3 t=WiMAX-QoS-Id(1): 1
WiMAX-QoS-Id: 1
TLV: l=3 t=WiMAX-Schedule-Type(4): Best-Effort(2)
WiMAX-Schedule-Type: Best-Effort (2)
TLV: l=3 t=WiMAX-Traffic-Priority(5): 0
WiMAX-Traffic-Priority: 0
TLV: l=6 t=WiMAX-Maximum-Sustained-Traffic-Rate(6): 250000
WiMAX-Maximum-Sustained-Traffic-Rate: 250000
AVP: l=13 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=7 t=WiMAX-FA-RK-SPI(61) C=0x00: 974124817
WiMAX-FA-RK-SPI: 974124817
AVP: l=6 t=Session-Timeout(27): 120
Session-Timeout: 120
AVP: l=6 t=Termination-Action(29): RADIUS-Request(1)
Termination-Action: RADIUS-Request (1)
AVP: l=6 t=EAP-Message(79) Last Segment[1]
EAP fragment
Extensible Authentication Protocol
Code: Success (3)
Id: 6
Length: 4
AVP: l=18 t=Message-Authenticator(80): 302D052376C19FA194368ACDEF32E98D
Message-Authenticator: 302D052376C19FA194368ACDEF32E98D
Pentru fluxul de pachete transmise, avem următorii parametrii descriptivi (care pot fi conFig.ți încă de la început în server-ul de AAA):
TABEL 6.17 – Parametrii fluxului de pachete (pentru WiMAX)
Mesajul de accounting request
După ce a fost permis accesul, un mesaj de accounting request este trimis pentru pentru a semnala că utilizatorul va începe să se servească de dreptul de acces acordat. În acest punct se înregistrează parametrii precum identificatorul utilizatorului, adresa de rețea, identificatorul de sesiune de comunicație etc.
Frame 13 (304 bytes on wire, 304 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius-acct (1813), Dst Port: radius-acct (1813)
Radius Protocol
Unde pentru Frame 13 avem detalierea:
Frame 13 (304 bytes on wire, 304 bytes captured)
Arrival Time: Apr 27, 2009 10:16:13.809844000
[Time delta from previous captured frame: 7.964521000 seconds]
[Time delta from previous displayed frame: 7.964521000 seconds]
[Time since reference or first frame: 8.590841000 seconds]
Frame Number: 13
Frame Length: 304 bytes
Capture Length: 304 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:radius]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Iar pentru Radius Protocol vom avea (parțial detaliat):
Radius Protocol
Code: Accounting-Request (4)
Packet identifier: 0x16 (22)
Length: 262
Authenticator: 63F7A8B6CBE6E91875A985C4274A5160
[The response to this request is in frame 14]
Attribute Value Pairs
AVP: l=48 t=User-Name(1): {am=1}[anonimizat]
User-Name: {am=1}[anonimizat]
AVP: l=6 t=NAS-IP-Address(4): 10.10.135.82
NAS-IP-Address: 10.10.135.82 (10.10.135.82)
AVP: l=6 t=Framed-IP-Address(8): 30.30.30.30
Framed-IP-Address: 30.30.30.30 (30.30.30.30)
AVP: l=24 t=Class(25): 4257530001000E2F00160002030701000000F4070300
Class: 4257530001000E2F00160002030701000000F4070300
AVP: l=8 t=Calling-Station-Id(31): \000\020\347\n\375\344
Calling-Station-Id:
AVP: l=5 t=NAS-Identifier(32): NPU
NAS-Identifier: NPU
AVP: l=6 t=Acct-Status-Type(40): Start(1)
Acct-Status-Type: Start (1)
AVP: l=50 t=Acct-Session-Id(44): 00-10-E7-0A-FD-E4150\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000
Acct-Session-Id: 00-10-E7-0A-FD-E4150
AVP: l=6 t=Acct-Authentic(45): RADIUS(1)
Acct-Authentic: RADIUS (1)
AVP: l=34 t=Acct-Multi-Session-Id(50): AAEAAAAAtD627qrzbeIrOTprhoVkpQ==
Acct-Multi-Session-Id: AAEAAAAAtD627qrzbeIrOTprhoVkpQ==
AVP: l=6 t=NAS-Port-Type(61): Unknown(27)
NAS-Port-Type: Unknown (27)
AVP: l=12 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=6 t=WiMAX-Beginning-Of-Session(22) C=0x00: 1
WiMAX-Beginning-Of-Session: 1
AVP: l=12 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=6 t=WiMAX-IP-Technology(23) C=0x00: Reserved-0(0)
WiMAX-IP-Technology: Reserved-0 (0)
AVP: l=13 t=Vendor-Specific(26) v=WiMAX(24757)
VSA: l=7 t=WiMAX-GMT-Timezone-offset(3) C=0x00: 0
WiMAX-GMT-Timezone-offset: 0
AVP: l=6 t=Event-Timestamp(55): Jul 9, 2007 04:44:07.000000000
Event-Timestamp: Jul 9, 2007 04:44:07.000000000
Mesajul de răspuns pentru accounting request
Iată și răspunsul server-ului de AAA.
Frame 14 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius-acct (1813), Dst Port: radius-acct (1813)
Radius Protocol
Unde pentru Frame 14 avem detalierea:
Frame 14 (62 bytes on wire, 62 bytes captured)
Arrival Time: Apr 27, 2009 10:16:13.811329000
[Time delta from previous captured frame: 0.001485000 seconds]
[Time delta from previous displayed frame: 0.001485000 seconds]
[Time since reference or first frame: 8.592326000 seconds]
Frame Number: 14
Frame Length: 62 bytes
Capture Length: 62 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:radius]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Iar pentru Radius Protocol vom avea (parțial detaliat):
Code: Accounting-Response (5)
Packet identifier: 0x16 (22)
Length: 20
Authenticator: AED7429AB68ABC81F7612CF113BFA4DD
[This is a response to a request in frame 13]
[Time from request: 0.001485000 seconds]
Pentru Protocolul CUANTAX (mesaje generale)
Așa cum am menționat deja, după finalizarea procesului de autentificare și după stabilirea cheilor între SM și SB (TEK, KEK etc.), putem avea un schimb de mesaje specifice pentru protocolul CUANTAX. Aceste mesaje vor avea ca scop stabilirea unor parametrii între utilizator și echipamentul de acces și AAA astfel încât aceasta să poată juca rolul modului de colectare de evenimente pentru platforma de taxare. Nu mai revin (am explicat anterior în lucrare ce înseamnă acest lucru) ci vreau doar să ofer o posibilă mostră de mesaje schimbate în acest sens.
Primul mesaj – CRIPTMSJ1 (vezi subcapitolul 6.7.4.2)
Frame 15
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: cuantax (10001), Dst Port: cuantax (10002)
Cuantax Protocol
Unde pentru Frame 15 putem avem detalierea:
Frame 15
Frame Number: 15
Frame Length: x bytes
Capture Length: x bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:pkm:cuantax]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Iar pentru Cuantax Protocol vom avea (parțial detaliat):
Cuantax Protocol
Code: ….
Packet identifier: z
Length: l
Attribute Value Pairs
AVP: l=1 t=tax (z):
Rata taxare x per kb
AVP: l=2 t=dim (z):
Dimensiune cuanta=1 kb
AVP: l=3 t=timp (z):
Marca de timp
…………………………………….
signedCertificate
version: v3 (2)
serialNumber: 2
signature (md5WithRSAEncryption)
Ulterior, în momentul în care voi detalia implementarea acestui protocol, câmpurile aferente vor fi mult mai ușor de intuit în fisierul de captură. Întrucât varianta implementării practice este mult dificilă pentru început, mi-am propus ca și pas imediat următor, cât mai multe simulări posibile (atât pentru componența mesajelor de protocol cât și pentru comunicația între echipamente utilizând CUANTAX) prin intermediul NS (Network Simulator) [71]. Acesta a ajuns deja la versiunea 2.35 și oferă suport pentru simulări pentru protocoale noi (sau deja existente) peste rețele de tip wireless sau wired. Fiind vorba de un software open-source care se poate instala și folosi (prin intermediul Cygwin pentru Windows sau direct pentru distribuțiile de Linux) pe orice mașină, se încadrează foarte bine în tot procesul de dezvoltare al unui nou protocol.
Concluzii și comentarii
Experimentul pe care l-am realizat în laborator nu a făcut decât să confirme ceea ce am afirmat pe tot parcursul dezvoltării planului de securitate – procesul de autentificare, precum și transferul datelor de la un server de AAA la altul (în cazul utilizatorilor mobili) este mult mai ușor în configurația propusă de planul meu. Așa cum am văzut, în prealabil, SB este recunoscută ca un NAS pentru noul nostru client.
În cadrul acestei etape, are loc o minimă verificare a noii SM apărute (radio etc.) urmând ca, după validare, SB să transmită cererea de acces pentru noul utilizator către server-ul de AAA.
Practic, într-o formulare mai puțin academică, SB se comportă ca un „paznic” al rețelei, fiind prima poartă de acces (NAS). După o primă validare, pentru a valida dacă utilizatorul poate accesa resursele rețelei precum și ce profil trebuie alocat acestuia, SB trebuie să primească detalii și confirmări de la server-ul de AAA. Mai apoi, așa cum am văzut și din experiment, după primele verificări, SB va fi „exclusă” din comunicația dintre client și server-ul de AAA (tunelul SSL) – în sensul că partea de credentials (detalii autentificare utilizator) va fi ascunsă NAS (SB în cazul nostru). Mai mult, stabilirea acestui tunel va permite echipamentului de acces și AAA să trimită direct către SM și primul mesaj aparținând protocolului CUANTAX (ceea ce nu poate decât să ajute și să confirme funcționalitatea protocolului). Care este diferența față de NRM propus de Forumul WiMAX?
În primul rând, rolul pentru ASN-GW (Routerul Cisco în cazul nostru) este unul redus și limitat (mai mult pe parte de acces simplu în rețea). În cazul nostru, NAS-ul este chiar SB care stabilește o legătură directă cu server-ul de AAA. Astfel vom avea fiecare SB cu ASN GW dedicat, legate apoi la un echipament de acces și AAA care va asigura autentificare/autorizarea utilizatorilor. Se elimină astfel un pas intermediar (un ASN-GW dedicat mai multor SB) care ar fi adus complexitate mai mare din punct de vedere configurații și politici de securitate. Folosind arhitectura propusă de mine (prin planul de securitate), vom avea o politică centralizată de acces (AAA) pe un singur echipament (poate, deja existent în rețeaua nucleu a operatorului). Acest echipament se va comporta ca un echipament de acces (cu rol și de server de AAA), filtrând traficul și asigurând o verificare atentă și corectă a accesului la rețea pentru un nou utilizator. Mai mult, așa cum am arătat și în partea finală din analiza experimentală, el va putea, folosind protocolul CUANTAX, să-și asume și rolul de modul colector de evenimente pentru platforma de taxare. O astfel de configurație va permite și personalizări specifice operațiunilor de taxare, prin combinarea parametrilor stabiliți în timpul autentificării cu detaliile necesare taxării. Mă gândesc, spre exemplu, la un utilizator cu cartelă pre-plătită (prepaid) care se va autentifica pentru accesul la rețea trecând tot prin etapele pe care le-am evidențiat în cadrul experimentului. Dar, după autentificare, presupunând că suma (creditul) disponibilă pe cartelă nu mai este suficientă pentru trafic, cu ajutorul protocolului CUANTAX, atât SM cât și echipamentul de acces și AAA (devenit, în acest caz, modul colector de evenimente pentru platforma de taxare) vor fi informați de această situație și vor proceda în consecință – oprirea traficului, păstrarea liberă a resurselor rețelei (care, în mod normal, după autentificare, ar fi fost alocate pentru noul utilizator).
Deci, după cum se poate vedea, în cadrul arhitecturii propuse, avem, pentru situațiile de excepție, o adaptabilitate și o flexibilitate mult mai bună decât în cazul modelului general propus de Forumul WiMAX. Toate acestea se adaugă avantajelor deja menționate pe tot parcursul lucrării – securitate îmbunătățită, transfer sigur și rapid al datelor de profil (credentials) pentru utilizatorii mobili etc.
CONCLUZII ȘI CONTRIBUȚII
Securitatea (mai ales în zona telecomunicațiilor) a constituit întotdeauna un subiect sensibil. Dincolo de implicațiile evidente – legate de confidențialitate, siguranță și protecție – influența cerințelor de securitate s-a resimțit în toate celelalte direcții. Nu puteam găsi un exemplu mai bun decât cel oferit în cadrul tezei mele de doctorat – am dorit să construiesc un plan de securitate, am oferit o viziune de ansamblu și un foarte bun punct de pornire prin intermediul planului deschis de securitate, însă a trebuit să mă concentrez în final pe partea de taxare ca și una dintre componentele întregului plan propus anterior.
Structura lucrarii este una usor didactica. Asa cum mentionam si in introducere, tehnologia WiMAX a avut si are parte de pareri mai putin favorabile chiar inainte de a si demonstra posibilul potentialul prin implementari la scara larga.
Prin urmare, încă din primul capitol am dorit sa văd care este locul acestei tehnologii în gama tehnologiilor fara fir. Am prezentat, pentru toate acestea, cateva detalii teoretice relevante tocmai pentru ca in finalul capitolului sa pot analiza deopotriva competitorii precum si aliatii WiMAX. In condițiile în care o noua tehnologie încearcă să se impună intr-o zona foarte dinamică (zona de acces), este foarte important sa vedem ce dezavantaje și, mai ales, ce avantaje aduce în comparație cu celelalte tehnologii din aceeași zonă.
Datorită faptului că vorbim de o tehnologie nouă, întreaga parte teoretică aferentă nu are încă o sistematizare specifică, cum este cazul, spre exemplu, zonei de Wi-Fi (802.11). Mai mult, referindu-ma la partea de securitate, am constatat că există chiar un deficit în zona securității rețelei WiMAX. Deși sunt destule lucrări care fac referire la chestiuni de securitate, se poate remarca o concentrare asupra unor elemente punctuale cum ar fi autentificarea mutuală, certificatele utilizate, cheile de criptare etc. Acesta este și motivul pentru care (consecvent structurii didactice), am oferit sistematizat detalii necesare construirii fundamentului teoretic pentru dezvoltările ulterioare. Astfel, am prezentat evoluția familiei de standarde IEEE 802.16, tocmai pentru a sublinia nivelul de maturitate la care a ajuns întregul concept din punct de vedere standardizare. Această scurtă trecere prin istorie a fost necesară pentru a arăta apoi, care este structura nivelelor adresate (fizic și legătură de date) și care au fost modificările aduse prin introducerea unei noi versiuni a standardului (pentru nivel sau pentru subnivelul impactat). Dincolo de subnivelul de securitate (cel mai important din punctul de vedere al subiectului în sine), am arătat că, pentru o analiză de securitate, trebuie să avem în vedere și alte zone care, aparent, nu au o influență foarte evidentă. Cel mai bun exemplu în acest sens este schema de management a puterii. Pentru o stație mobilă identificăm 3 stări specifice (față de legătura cu stația de bază) – starea activă (comunicare permanentă), starea de inactivitate (stația mobilă nu se asociază) și starea de repaus (stare de indisponibilitate pentru stația mobilă). Pentru fiecare din aceste stări, implicațiile din punct de vedere securitate sunt altele și trebuie luate în considerare separat (ceea ce am și făcut).
Apoi, urmărind lista de versiuni de standard (802.16g spre exemplu), am aflat că IEEE a definit un nou subnivel de convergență a pachetelor – GPCS Generic Packet Convergence Sublayer -, subnivel care are rolul facilita transferul informației de management de la nivelele superioare către cele inferioare, fără a decoda, însă, antetul pachetului. Este evident faptul că orice astfel de modificare va avea un impact semnificativ și în analiza de securitate și, prin urmare, planul de securitate pe care l-am dezvoltat a trebuit să țină cont și de aspectele de acest gen (chiar dacă, așa cum se întâmplă în acest caz, IEEE 802.16g este abia în curs de publicare). Așadar, o astfel de viziune asupra evoluției istorice a familiei de standarde 802.16 – cu accentuarea elementelor relevante pentru securitate – era absolut necesară.
Așa cum am menționat încă din titlu, am avut în vedere securitatea rețelei de acces fără fir bazată pe tehnologia WiMAX. Datorită acestei chestiuni, am prezentat sistematizat, într-un capitol separat, detaliile legate de arhitectura și performanța rețelelor WiMAX. Deși aceste tipuri de detalii există disparat în cărțile de specialitate, gruparea lor nu a fost, în opinia mea, cea mai potrivită (mai ales din perspectiva unei analize de securitate). Pentru a putea analiza în detaliu o tehnologie (mai ales în zona comunicațiilor) este necesară o descriere clară a arhitecturilor de rețea – cu avantaje și dezavantaje -, a modelelor de propagare și a problemelor de performanță. Pentru fiecare secțiune în parte, am urmărit amănuntele importante din punctul de vedere al securității. Spre exemplu, în literatura dedicată tehnologiei WiMAX, cererile de servicii de comunicație pot fi inițiată atât de stația mobilă cât și de stația de bază. Chiar dacă din punctul de vedere al schimbului de mesaje, situația este cunoscută, o analiza a vulnerabilităților (din punct de vedere securitate) pe care le are un astfel de proces (cerere de serviciu) nu a fost prezentată detaliat până acum. Apoi, formatul mesajului MAC-PDU, mecanismele de transmisiune etc – sunt detalii care nu lipsesc din nici o lucrare dedicată WiMAX. Însă, care este contribuția lor la eventuale breșe de securitate sau la soluții relevante în acest sens, nu avem clar sistematizat în literatura aferentă.În acest punct, exemplul cel mai relevant mi se pare cel al mecanismului de retransmisie (considerat, inițial, ca o componentă opțională). Este un fapt dovedit că orice retransmisie crește foarte mult riscurile din punct de vedere securitate (prin repetarea unui mesaj care astfel, poate fi interceptat și, mai ales, descifrat mult mai ușor). Prezența acetui tip de mecanism trebuie tratată cu mare atenție și în detaliu, fiind foarte important în orice analiză de securitate. Faptul că, până de curând, a fost considerat opțional în implementările tehnologice (echipamente dedicate) a contribuit la lipsa unor descrieri clare si concludente în această zonă.
Marșând pe ideea de securitate a rețelelor în general, am ajuns la concluzia că termeni precum „securitate”, „confidențialitate”, „protecție a datelor” se regăsesc în tot ceea ce înseamnă strategie de dezvoltare a unei infrastructuri de telecomunicații. Ei definesc (sau, cel puțin, încearcă să definească) un mod de abordare care, până la începutul deceniului, nu era considerat a fi necesar. Anterior evoluției fulminante a domeniului telecomunicațiilor, ideea de securitate se confunda cu ideea de securitate fizică a echipamentelor ce conțineau date importante. Singura metodă de „furt” sau de „atac” era strâns legată de prezența „atacatorului” la locul „faptei” mai ales pentru că nu exista comunicare cu lumea exterioară (prin intermediul unei rețele, spre exemplu).Odată cu apariția rețelei INTERNET și, în același timp, cu dezvoltarea conceptului de comunicare la distanță (la nivel tehnic și nu numai), situația s-a schimbat radical. Totuși, de-a lungul evoluției rețelelor de telecomunicații, ideea de securitate, de perimetru de securitate a luat diverse forme, în funcție de schimbările apărute la nivel de domeniu al telecomunicațiilor.Când schimbările au avut loc gradual, ele au trecut, de multe ori, „neobservate”.Dar, în final, ele au determinat o schimbare în esență a întregii viziuni asupra securității rețelei.Acesta este și unul dintre motivele pentru care am considerat necesară definirea unui nou plan pentru securitatea rețelelor WiMAX. Ideea de imunitate individuală este deja una depășită, astfel încât eu am considerat o abordare de tip global în ceea ce privește asigurarea securității unei noi rețele. Astfel, fidel acestui tip de abordare, am prezentat detaliat noile instrumente de detecție și verificare specifice pentru asigurarea securității unei rețele, subliniind avantajele și dezavantajele acestora în raport cu noua viziune (globală) asupra securității.
Apoi, trebuie menționat faptul că toată această schimbare a fost determinată și de factori practici – cum ar fi eliminarea monopolului buclei locale. Tocmai de aceea am considerat necesară o scurtă analiza a conceptului de buclă locală, oferind căteva detalii semnificative legate de sistemul de Acces fix fără fir (FWA – Fixed Wireless Access). Trebuie spus că tehnologia WiMAX este una dintre principalele componente ale acestui sistem, fiind una dintre principalele tehnologii de acces.
Am menționat anterior abordarea de tip global. Totuși, acest tip de abordare se va sprijini pe elementele de imunitate individuală. Mă refer, în acest caz, la soluțiile punctuale pentru anumite breșe de securitate identificate încă din stagiile incipiente ale familiei de standarde IEEE 802.16. Toate aceste elemente au constituit, de fapt, din punctul meu de vedere, baza de pornire pentru orice dezvoltări ulterioare. Tocmai de aceea, concentrându-mă pe ceea ce am numit procesele de AAA (authorization, authentication, accounting), am prezentat sistematizat problemele deja identificate precum și soluțiile oferite în ultimele versiuni de standard. Așa cum spuneam, cel puțin în cazul rețelei WiMAX, imunitatea individuală nu ridică așa de multe probleme. Un exemplu concludent este cel legat de autentificarea mutuală. Cum este și normal, stația de bază trebuie să autentifice numai utilizatorii de bună credință pentru că, altfel, riscă să transmită informații către un posibil atacator, oferind o breșă de securitate nesperată pentru acesta. Această chestiune avea parțial o rezolvare prin procesul inițial de autentificare.
Pe de altă parte, ulterior, în urma unor analize, s-a simțit nevoia ca și stația mobilă să autentifice la rândul său că SB cu care comunică este una corectă și nu una falsă (aparținând unui eventual atacator), pentru a nu transmite acesteia informații confidențiale. În acest punct a fost dezvoltată, ca soluție punctuală pentru această problemă, autentificarea mutuală. Deci, deși modul de abordare este depășit (soluții punctuale, imunitate individuală), eu am adunat, sistematizat și prezentat toate aceste detalii pentru ca să le pot folosi ulterior în demersul pe care mi l-am propus. Ele nu pot fi și nici nu trebuie să fie ignorate,constituind, așa cum am zis, o excelentă bază de plecare.
Tot în cadrul acestei sistematizări a bazei de plecare, am prezentat în detaliu și cheile folosite în procesele de autentificare/autorizare (cheia de autentificare AK etc.) și în procesul de criptare al comunicației, precum și modul lor de obținere. Foarte important de reținut este că 2 din cele două chei folosite în procesul de autentificare – MSK și PSK – le voi folosi și ulterior în criptarea mesajelor protocolului de taxare CUANTAX (propus ulterior).
Așa cum spuneam, toata această prezentare are un dublu rol – adunarea și sistematizarea tuturor informațiilor relevante pentru securitatea rețelelor de acces (specific apoi pentru rețelele bazate pe tehnologia WiMAX) precum și (fiind vorba de o tehnologie nouă) crearea unei componente didactice pentru întreaga lucrare, ținând cont că subiectul propus este unul foarte puțin tratat în literatura de specialitate. Tocmai de aceea, înainte de trece la construcția planului de securitate și la definirea protocolului de taxare, am prezentat Modelul de referință al rețelei (NRM – Network Reference Model) propus de Forumul WiMAX pentru rețelele tip WiMAX. El a constituit, de fapt, scheletul pe care mi-am bazat dezvoltarea și propunerile de îmbunătățire ulterioare.
Scopul meu a fost să ofer o variantă îmbunătățită a modelului propus de Forumul WiMAX. Nu s-a pus problema înlocuirii acestui model. Am avut în vedere faptul că orice model oferit de o organizație internațională pentru o rețea de telecomunicații nu poate acoperi în detaliu toate părțile componente și toate aspectele importante pentru acea rețea. Acel model va reprezenta doar fundamentul dezvoltărilor ulterioare, comportând modificări specifice și speciale pentru cazul abordat.
Planul de securitate propus în ultima parte a lucrării oferă, practic, o soluție centralizată de administrare a întregului proces de autentificare în rețelele WiMAX (o chestiune foarte sensibilă mai ales pentru partea de mobilitate) și o îmbunătățire evidentă a securității întregii rețele.
Acest lucru se realizează (sumarizând) în două mari etape.
Prima dintre ele se referă la plasarea utilizatorului în centrul întregii implementări. În general, planificarea unei rețele precum și implementarea ulterioară urmează o direcție inversă celei propuse. Orice operator și/sau furnizor de servicii își dezvoltă întâi o rețea nucleu performantă, urmând ca apoi, prin intermediul buclei locale, să conecteze viitorii clienți și să le ofere diferite servicii. Așa cum se poate observa, impactul asupra utilizatorului este considerat ca fiind ultima etapă de dezvoltare. În acest fel, operatorul își asigură suportul unei rețele puternice, capabile să ofere serviciile pe care le cere componenta principală a ultimului nivel – utilizatorul. Totuși, opinia mea este că, în acest caz, abordarea concentric este mult mai potrivită. În primul rând, majoritatea atacurilor adresate unei rețele de telecomunicații (cu sau fără fir) vizează, în primul rând, utilizatorul final. Chiar dacă atacul se realizează prin intermediul rețelei operatorului și conține etape în care este îndreptat către echipamente aparținând acestuia, scopul final este accesul la informațiile utilizatorului. Breșele de securitate sunt exploatate pentru a obține informații confidențiale (conturi de bancă, informații specifice unor companii etc) care țin tocmai de utilizatorul final. Prin urmare, cred eu, este normal ca în centrul dezvoltării să se afle utilizatorul. Toate celelalte nivele trebuie să se constituie ca un înveliș de protecție pentru utilizator și să limiteze aproape total eventualele intruziuni și atacuri asupra sistemelor aparținând acestuia. Chiar dacă ținta finală este construirea unui plan pentru securitatea rețelei (așa cum am menționat și în titlul acestei lucrări), am dorit să realizez toată această construcție menținând focusul asupra utilizatorului final – cel care va beneficia de rețea în sine și cel care trebuie protejat.
Cea de-a doua etapă dintre cele două menționate anterior se referă la degrevarea ASN-GW de rolul de server de AAA și mutarea acestei funcții către un echipament (deja) existent (pe care l-am numit echipament de acces și AAA). Acest echipament va fi cel care va administra toate comunicațiile înspre și dinspre noua rețea WiMAX, el fiind responsabil de toată partea de autorizare/autentificare și de transferul datelor de profil (credentials) ale utilizatorului către celelalte echipamente implicate (server-ul de AAA al unui ISP etc.). Prin soluția propusă, dacă ne adresăm micromobilității (mobilitate a utilizatorului în cadrul aceluiași ASN (aceeași rețea de acces)) , cel mai probabil, ASN-GW vor fi conectate la același echipament de acces și AAA (care va deservi o astfel de zonă ASN). Deci, stația mobilă nu va schimba decât informații legate de conexiunea radio cu noua stație de bază. Autentificare utilizatorului (operațiunea de AAA) se va face prin intermediul aceluiași echipament (de AAA) care are deja aceste date. Nu va mai fi nevoie de nici un transfer de date de autentificare cu atât mai puțin de securizarea acestui transfer. Procesul va fi simplu și eficient.
Dacă ne adresăm macromobilității (mobilitate a utilizatorului în ASN-uri diferite (rețele de acces diferite)) , situația este din nou mult mai bună. În condițiile în care stația mobilă se va asocia la stații de bază din ASN diferite, aceasta poate înseamna, conform arhitecturii, CSN diferite și, prin urmare, echipamente de acces și AAA diferite. Am spus poate pentru că dacă vom avea mai multe ASN conectate la același CSN vom avea situația deja prezentată anterior. Revenind, în cazul mai multor echipamente de acces și AAA va trebui să existe un transfer de date de profil (credentials) pentru utilizatorul mobil.
Dacă se aplică principiile pe care le-am menționat și ținem cont și de experiența dobândită în activitatea din cadrul operatorilor, echipamentul de acces și AAA – fie că va fi unul separat fie că va fi unul deja existent (sau un nou modul în acesta) – va face parte din rețeaua nucleu a operatorului. Această zonă poate fi considerată una dintre cele mai solide din întreaga rețea – din toate punctele de vedere: securitate, rate de transfer etc. De cele mai multe ori, suportul fizic pentru conexiunile dintre echipamentele din această zonă este fibra optică (ce asigură rate de transfer ridicate), se asigură redundanță conexiunilor și back-up pentru echipamente. Deci, oricum, suntem într-o situație mult mai bună decât în cazul transferului între ASN-GW (dacă ar avea și rol de server de autentificare).
Modelul oferit de Forumul WiMAX (NRM) specifică plasarea server-ului de AAA în modulul CSN, urmând ca toate ASN-GW să comunice cu aceasta. Nu se oferă însă o poziționare concretă unde ar trebui plasat acest server și, mai ales, dacă ar putea fi chiar unul dintre echipamentele existente (prezente în rețeaua operatorului). Așa cum menționam încă de la început, propunerea mea de plan de securitate ține cont de faptul că operatorul are deja o rețea nucleu dezvoltată și plasează exact echipamentul de acces și AAA. Diferența față de accepțiunea Forumului WiMAX este dată tocmai de îmbunătățirile pe care le aduce pe parte de mobilitate precum și de faptul că integrarea noi rețele WiMAX în cadrul rețelei „mari” a operatorului se va realiza mult mai ușor, pe câteva etape clare.
Mai mult, un alt aspect important e legat de faptul că, deși implementarea rețelei WiMAX în sine este făcută de un operator, furnizarea serviciilor (folosind noua rețea) se poate realiza prin intermediul mai multor furnizori de servicii diferiție (ISP). Aceștia vor plăti o taxă de acces (de folosire a buclei locale) către operator. Arhitectura propusă, prin care mai multe stații de bază cu ASN-GW aferente se conectează la un echipament de acces și AAA (care poate fi deja un router nucleu) îmbunătățește nu numai securitatea în sine (prin prezența unor politici centrale de gestionare a accesului) ci și comunicația în totalitatea ei (transferul detaliilor necesare de la operator la ISP-iști se face mult mai ușor și mai sigur). În exemplificarea procesului de autentificare pentru arhitectura propusă de planul de securitate, am menționat și această posibilitate, oferind descrierea pașilor pe care îi parcurge un utilizator pentru a se putea autentifica și pentru a putea face trafic. Tocmai de aceea eu cred că planul de securitate oferă un model mult mai apropiat de realitate (fiind bazat și pe tendințele de dezvoltare impuse de marii operatori).
Mai mult, planul în sine aduce avantaje și din privința utilizatorilor nomadici și a celor mobili. Întotdeauna am considerat relevant exemplul unui utilizator aflat într-un tren în mișcare. Acesta (utilizatorul) se poate connecta fie direct la rețeaua WiMAX (prin placa PCMCIA sau USB Dongle – în rol de SM) fie prin intermediul unei rețele de tip Wi-Fi, care operează la nivelul întregului tren și care se conectează, la rândul ei, prin intermediul unui singur SM la o rețea WiMAX.
Din punctul de vedere al autentificării, pentru prima situație vorbim de un utilizator mobil, pentru cea de a doua de unul nomad. Folosind arhitectura propusă de planul de securitate, în momentul în care trenul trece dintr-o celulă acoperită de o SB la o altă celulă și altă SB, partea de autentificare este foarte simplă (ținând mai mult de asocierea radio între SM și SB), întrucât autentificarea la nivel de AAA este ținută de echipamentul de acces și AAA (de exemplu, un router nucleu care asigură și accesul către core).
Mai mult, chiar dacă se trece într-o celulă conectată la un alt echipament de acces și AAA, transferul de credentials între aceste echipamente (nucleu) se realizează mult mai ușor, putând fi, spre exemplu, incluse într-un update care se transmite periodic între aceste echipamente (o eventuală tabelă cu utilizatorii conectați, ei fiind deja configurați prin politica de securitate globală). Și exemplele pot continua.
Așa cum spuneam, o mențiune importantă este legată de faptul că am considerat că dezvoltarea unei noi rețele WiMAX se face de către un operator major (care are deja experiență în domeniu). Acesta beneficiază deja de sisteme și platforme complexe – cum ar platforma de taxare. Acesta este și motivul pentru care, în dezvoltarea planului de securitate și, mai ales, ulterior, a protocolului de taxare am ținut cont (și am amintit permanent) de integrarea noii rețele, de folosirea platformelor existente și, implicit, de reducerea problemelor ce pot apărea. De fapt, acesta este și motivul pentru care am ales ca, în finalul lucrării, să mă concentrez pe definirea unui protocol de taxare (pe care l-am denumit CUANTAX). Scopul acestui protocol este de a ajuta la integrarea rețelei WiMAX în rețeaua mare a operatorului și la folosirea platformei de taxare existente pentru operațiunile aferente și pentru serviciile oferite prin intermediul noii rețele. Acest deziderat se realizează prin adresarea unei probleme fundamentale în cazul tuturor platformelor de taxare – colectarea informațiilor necesare taxării.
Sistemul (sau platforma) de taxare (nu contează producătorul) are mai multe componente – pentru stocare a datelor (de taxare pentru clienți), pentru reconciliere, pentru tratare a excepțiilor, pentru calcul efectiv etc.
În plus, sistemul are și un modul de colectare a evenimentelor (event collection). Practic, acesta este modulul care înregistrează toate schimbările – conectarea/deconectarea unui utilizator, trecerea la un alt serviciu (spre exemplu voce-date), excepții, încercări de fraudă etc. Toate acestea sunt tratate ca evenimente și sunt codate în funcție de componenta care le va trata mai departe. În general, modulul de colectare al evenimentelor nu aparține de platformă (fiind al unei terțe părți).
În cazul apariției unei noi tehnologii (și a unei noi rețele aferente) în portofoliul operatorului, este necesară fie modificarea unui modul de colectare existent astfel încât să poată trata și evenimentele primite de la noua rețea, fie construirea unui nou modul specific. Cum prima soluție este (conform experienței) una foarte costisitoare, am avut în vederea cea de-a doua posibilitate. Numai că, și în acest caz, am redus la maxim modificările.
Practic, folosind CUANTAX (protocolul de taxare) cu mesajele aferente, echipamentul de acces și AAA se poate transforma în modul de colectare de evenimente pentru platforma de taxare.
Studiind documentația din domeniu (de la producători importanți – AMDOCS, COMVERSE etc.), am aflat că evenimentele necesare unei platforme de taxare trebuie să conțină patru categorii importante de atribute. Acestea sunt atribute de taxare, de direcționare, de identificare și generale (pentru sisteme de fraudă). Construcția protocolului CUANTAX (mesaje, fluxul de comunicare etc.) a avut în vedere tocmai obținerea acestor informații. Adaugând în cadrul mesajelor câmpuri cu atribute legate de unitatea de măsură și volum (deci atribute de taxare), cu adresa MAC a stației mobile (deci atribute de identificare) etc., am definit un protocol capabil să asigure suportul necesar pentru îndeplinirea rolului de modul de colectare de evenimente pentru echipamentul asignat (echipamentul de acces și AAA).
Mai mult, criptarea mesajelor specifice protocolului se face prin folosirea a două chei (MSK și PSK) deja definite în cadrul procesului anterior de autentificare a utilizatorului.
Prin urmare, foarte multe elemente folosite în cadrul mesajelor acestui protocol sunt deja știute (negociate) între entitățile implicate (mai ales că sunt aceleași din procesul de autentificare): stația mobilă, stația de bază și echipamentul de acces și AAA. Acesta este și motivul pentru care analizele de securitate și de randament (eficiență) ale protocolului au relevat rezultate foarte bune (măcar la nivel teoretic).
Singurul pas care trebuie adăugat ar fi transmiterea informației legate de eveniment către platforma de taxare. Numai că în acest punct ne putem baza pe noțiunile teoretice și practice deja prezentate în literatura de specialitate.
Conform dezideratului propus – acela de a folosi resursele existente – putem considera situația în care echipamentul care preia operațiunile de AAA pentru rețeaua WiMAX este unul care îndeplinește deja și alte roluri în rețea (GGSN spre exemplu). În acest caz, este evident faptul că între echipamentul respectiv și platforma de taxare există deja comunicație bazată pe un protocol. Nu trebuie decât preluate informațiile care au fost deja transmise prin CUANTAX, încapsulate conform protocolului respectiv și transmise către platforma de taxare.
În cazul mai puțin optimist – în care avem nevoie de un echipament separat de acces și AAA pentru rețeaua bazată pe tehnologia WiMAX – și, deci, nu există o comunicație deja stabilită între acesta și platforma de taxare, putem extinde CUANTAX adaugând un mesaj MSJ3 cu parametrii doriți (TAX(i), adresa MAC a SM…..).
Acest lucru va presupune schimbări și în interfața platformei de taxare, însă nu foarte mari. Modul de compunere pentru acest protocol permite o înglobare mai ușoară a lui în comunicațiile deja existente. Concluzionând, pot spune că protocolul CUANTAX se dovedește un instrument foarte util în operațiunile premergătoare taxării, vehiculând exact informațiile dorite și impuse de standardele actuale.
În ultima parte a lucrării, am oferit și rezultatele unui experiment de laborator , care a simulat (la scară mică) arhitectura aferentă planului de securitate propus. Am capturat și prezentat mesajele schimbate între stația mobilă, stația de bază și server-ul de AAA (autentificare/autorizare), subliniind detaliile pe care le-am evidențiat (teoretic) și pe parcursul lucrării. Toate aceste mesaje confirmă dezvoltarea teoretică anterioară, evidențiind aspectele mai mult sau mai puțin sensibile pe care le-am explicat în capitolele dedicate.
Alături de mesajele schimbate în timpul procesului de autentificare, am dorit să ofer și o (posibilă) mostră a mesajelor aparținând protocolului CUANTAX. Fiind vorba, așa cum am spus, de o tehnologie nouă cu puține implementări (ba chiar cu destule obstacole de înfruntat, conform cu ultimele conferințe în domeniu), posibilitățile de testare și de dezvoltare (pentru protocol) au fost destul de limitate. Am vrut, însă, să anticipez puțin conținutul lucrărilor mele viitoare care vor avea în vedere dezvoltarea detaliată și implementarea practică a protocolului.
Prin urmare, sumarizând, iata care au fost principalele direcții pe care le-am avut în vedere, precum și contribuțiile aferente:
securitatea reprezintă un capitol important în dezvoltarea unei noi tehnologii. Provocările sunt și mai mari în momentul în care implementările importante (pe scară largă) sunt încă insuficiente pentru a oferi rezultate relevante– cum este și cazul tehnologiei WiMAX.
acesta a fost si motivul pentru care m-am concentrat pe dezvoltarea unui plan de securitate în etape dedicate fiecărei zone de rețea, păstrând cât mai mult legătura cu zona practică și folosind noțiunile teoretice deja publicate (în standarde sau lucrări de specialitate).
abordarea a fost una de tip concentrică, având în mijlocul ei utilizatorul și nu rețeaua de bază (de core) așa cum se întâmplă în abordările clasice. Am considerat că este mult mai eficient în acest mod din două motive:
Tehnologia WiMAX este considerată ca făcând parte din zona tehnologiilor de acces și, de aceea, majoritatea operatorilor care implementează rețele bazate pe această tehnologie au deja o rețea de core foarte bine pusă la punct și bine securizată
Atacurile vizează și, mai ales, afectează în final utilizatorul chiar dacă, intermediar, sunt afectate diferite zone de rețea ale operatorului (cu echipamentele aferente). Orice nefuncționare a rețelei se răsfrânge asupra utilizatorului și orice breșă de securitate este folosită de către atacator pentru a obține date confidențiale ale…utilizatorului. Chiar și în cazul în care atacatorul dorește să pirateze și să folosească resursele gratis, el afectează alți clienți plătitori de bună credință
Planul de securitate propus a avut ca punct de pornire modelul de referință (NRM) propus de Forumul WiMAX (am folosit, așa cum am menționat, ca punct de pornire, modelele și noțiunile teoretice existente). Fată de NRM, am ales să reduc mult rolul ASN-GW la câteva funcții de bază (va asigura accesul la managementul SB, va face legătura SB cu următorul element important – echipamentul de acces etc.) Acest echipament va răspunde practic nevoilor de interconectare între diferite tehnologii de backhauling deja existente în rețeaua operatorului
Am introdus, prin intermediul planului propus, un nou echipament – denumit echipament de acces și AAA.(diferit față de propunerea NRM) Acesta va prelua rolul de server de AAA (autentificare etc.) și se va ocupa de tot ceea ce înseamnă acces pentru utilizator în noua rețea WiMAX. Iată câteva avantaje (deja enumerate în capitolul dedicat):
Configurarea unor politici centralizate de securitate
Transfer mult mai eficient și mai sigur pentru detaliile de profil (credentials) ale utilizatorilor mobili – atât pentru micro cât și pentru macro mobilitate
Posibilitate de a oferi furnizarea serviciilor (folosind noua rețea) prin intermediul mai multor ISP care plătesc o taxă de acces operatorului care a dezvoltat rețeaua WiMAX
Consecvent principiului că dezvoltarea unei noi rețele de acces WiMAX va fi făcută de către un operator existent, am construit și am propus, în finalul lucrării, un protocol de taxare (CUANTAX). Acesta este menit să ajute la integrarea mult mai simplă a noi rețele WiMAX în rețeaua mare a operatorului prin folosirea platformelor de taxare existente.
Integrarea se face prin transformarea echipamentului de acces și AAA, folosind CUANTAX, în modul colector de informații pentru platforma de taxare. De fapt, aceasta reprezintă etapa principală în conectarea noii rețele (și în taxarea utilizatorilor noi) la sistemul existent de taxare. O mențiune în acest punct – mesajele protocolului CUANTAX vor fi criptate utilizând 2 chei create în procesul de autentificare.
Pentru o demonstrație clară a mesajelor schimbate în timpul autentificării, am oferit și rezultatele unui experiment realizat în cadrul laboratorului. Arhitectura folosită în cadrul experimentului a constituit o replică la scară mică a arhitecturii propuse de planul de securitate. Concluziile au fost aceleași: folosind acest plan de securitate, comunicația devine mult mai sigură, mult mai eficientă și mult mai simplu de monitorizat din toate punctele de vedere (politici centralizate etc.)
Acest plan de securitate, cu arhitectura aferentă, nu va constitui neapărat răspunsul la toate întrebările și problemele de securitate, însă este convingerea mea că va fi un pas înainte important în dezvoltarea unor rețele de acces WiMAX mult mai sigure. O dovadă în acest sens este și faptul că un operator important din România a ales să dezvolte o rețea WiMAX utilizând o astfel de arhitectură (precum cea propusă de planul de securitate).
PERSPECTIVE
Ca și planuri de viitor (perspective), așa cum am menționat, am în vedere dezvoltarea detaliată a protocolului CUANTAX (cu ajutorul simulărilor software etc.) și, evident, perfecționarea planului de securitate în funcție de noile (eventuale) probleme apărute.
Totuși, dincolo de toate aspectele evoluționiste, aș dori să fac următoarea remarcă – ultimii ani au înregistrat o schimbare radicală a modului de abordare în ceea ce privește securitatea rețelelor. Dacă până la începutul noului secol, atenția se îndrepta spre dezvoltarea individuală a fiecărei componente implicate în acest proces al telecomunicațiilor, ultima perioadă a adus cu sine o focalizare asupra integrării diferitelor tehnologii, dar mai ales asupra stabilirii unor strategii globale care să aibă în vedere mai mult imaginea de ansamblu și mai puțin pe cea individuală.
Deși opiniile sunt împărțite cu privire la această tendință de globalizare, din punctul de vedere al rețelelor de telecomunicații, toată această nouă tendință s-a concretizat în planuri unificate de implementare și dezvoltare pentru noi rețele de mari dimensiuni, precum și în strategii de integrare între componentele deja existente.
În urma evaluării noilor direcții de dezvoltare, s-a ajuns la concluzia că, fără o viziune de ansamblu asupra întregii situații, orice dezvoltare ulterioară comportă riscuri mari care nu mai pot fi prevăzute.
Acesta a fost și cazul securității în întreg domeniul telecomunicațiilor (și, specific, în cadrul rețelelor fără fir). Experiența a arătat că nu mai este de ajuns o securizare a fiecărei componente (proces care a dat, la nivel local, rezultate foarte bune) ci este necesar un plan global de securitate care să adune toate aceste elemente într-o construcție sigură și stabilă. Evoluția tehnologiei a permis ca, la nivel local, breșele de securitate să fie eliminate pas cu pas, iar posibila vulnerabilitate a componentei specifice de rețea (sau a rețelelor de mici dimensiuni) să fie redusă spre cote foarte mici.
Totuși, în momentul, „asamblării” acestor componente s-a constatat că, la nivel global, rețeaua de telecomunicații nu mai oferă același procentaj de siguranță pe care îl regăseam la nivel local. Prin urmare, dezvoltarea unei strategii globale de securitate, a unui plan de ansamblu era imperios necesară. Și, dacă este să urmărim ultimele conferințe din domeniul telecomunicațiilor, noua direcție este clară – nimic nu mai poate fi dezvoltat, implementat fără a ține seama de interoperabilitate, integrare, dependență, unificare etc.
Acesta este și motivul pentru care am ales, ca pentru teza mea, să dezvolt un plan interdependent de securitate pentru întreaga rețea. Am ales rețele create pe baza tehnologiei WiMAX întrucât implementarea acestor tipuri de rețele este încă la început, tehnologia WiMAX fiind privită ca un pas important în evoluția rețelelor fără fir.
Tot ca planuri de viitor, aș dori integrarea acestui plan celui deja existent pentru rețelele 3G, în condițiile în care tendința este de a oferi utilizatorilor servicii unificate bazate pe rețele fără fir. Astfel, probabil, următorul pas va fi o integrare a rețelei WiMAX peste rețelele 3G deja existente. Așadar, și planul meu va trebui să fie capabil să se integreze în strategia de securitate a rețelelor 3G.
Nu în ultimul rând, trebuie să subliniez faptul că am ales ca planul meu să fie unul deschis (open). De altfel, așa cum am arătat pe parcursul tezei, avantajele sunt mult mai mari și, în plus, cred eu, epoca „soluțiilor închise/proprietare” urmează să apună în curând.
Acesta este și motivul pentru care am ales să ofer și o alternativă/îmbunătățire pentru operațiunile premergătoare taxării. Construcția pas cu pas nu poate elimina aceste zone (cum este cea de taxare) foarte importante mai ales în procesul de dezvoltare a unei rețele noi.
Nu pot încheia fără a aminti că trăim într-o epocă a „vitezei” și evoluțiile fulminante ale tehnologiei pot determina schimbări radicale de viziune asupra anumitor aspecte ce păreau foarte clar definite. Promit să revizuiesc acest plan în funcție de aceste schimbări și invit specialiștii în domeniu să completeze sau să corijeze eventualele elemente care necesită acest lucru. Nimeni nu este perfect însă totdeauna trebuie să tindem spre perfecțiune!
BIBLIOGRAFIE
S. Luuikkanen, „Emerging Technologies in Mobile and Wireless Data Network Evolution”, University of Technology, Helsinki, 2003
T. Karygiannis, L. Owens, „Wireless Network Security”, NIST, Technology Administration, U.S. Department of Commerce, 2004 (ediție revizuită)
D.D. Boom, „Denial of Service Vulnerabilities in IEEE 802.16 Wireless”, teză de doctorat, Naval Postgraduate School, 2004
F. Ohrman, „WiMAX Handbook:Building 802.16 Wireless Networks”, Editura McGraw-Hill, NewYork, SUA, 2005
T. Choi, „Accounting, Charging and Billing for NGN Services and Networks”, ITU-T NGN Technical Workshop, Martie 2005, Korea
(http://www.itu.int/ITU-T/worksem/ngntech/presentations/s6-choi.pdf)
J. Wang, „Real-time billing throughput analysis of wireless telecommunication systems”, IEEE, 2005 (bluehawk.monmouth.edu/~jwang/GPRS_Billing_final.pdf)
S. Schwartz, „FHSS vs. DSSS – Seminars” – www.sorin-schwartz.com, 2006
S.Wattanachai, „Security Architecture of the IEEE802.16 Standard for Mesh Networks”, Royal Institute of Technology, Universitatea din Stockholm, 2006
J. Geier, „Wireless Networking HandBook”, Editura Macmillian Editors, 2006
H. Chou, „802.16 & 802.11 Security Overview”, Australian Information Security Conference, 2006
M. Barbeau, „WiMAX/802.16 Threat Analysis”, School of Computer Science, Universitatea Carleton, Canada, 2006
S. Xu, M. Matthews, C. Huang, „Security Issues in Privacy and Key Management Protocols of IEEE 802.16”, Departamentul de știință al University of South Carolina, 2006
„Campus Network Design Fundamentals” – Cisco Press, 2006
D.Pang, L. Tian, „Overview and Analysis of IEEE802.16e Security”, Chinese Academy of Sciences, 2006
F.Liu, Z. Zheng, Z. Lin, „Achieving QoS for IEEE802.16 in Mesh Mode”, School of Electronics and Information Engineering, Tongji University, Shanghai, China, 2006
D. Vladimir, S. Dmitry, „WiMAX – Local Networks Course Project”, Universitatea Tehnică din Praga, Cehia, 2006
H. Ventura, „DIAMETER, next generation’s AAA protocol”, teza de masterat, Institutionen för Systemteknik, LINKÖPING, 2006 (revizuit)
WiMAX Billing and CRM, White Paper, ARIA, 2006, www.ariasystems.com
„Billing for Mobile Wireless Data Services”, White Paper, Cisco Press, 2006, www.cisco.com
U. Foll, C. Fan, G. Carle, F. Dressler, M. Roshandel, „Service-Oriented Accounting and Charging for 3G and B3G Mobile Environments”, University of Tubingen, Germania, 2006
J.G. Andrews, A. Ghosh, R. Muhamed, „Fundamentals of WiMAX – Understanding Broadband Wireless Networking”, Editura Prentice Hall, 2007
„IEEE Standard for Local and Metropolitan Area Networks, Part 16 – Air Interface for Fixed Broadband Wireless Access Systems”, IEEE, Martie 2007
R. L. Freeman, „Radio System Design for Telecommunications”, Ediția a 3-a, Editura John Wiley Inc., 2007
Alcatel-Lucent, „WiMAX with Alcatel Lucent – Enabling a world of wireless broadband”, ISCTE, Portugal, 2007
S. Schwartz, „IPSec Basic” – Seminars – www.sorin-schwartz.com, 2007
„Mobile WiMAX Solutions – Leading the momentum forward” – White Paper – Fujitsu, 2007
S.Ahson, M. Ilyas, „WiMAX Applications”, CRC Press, 2007
Mobile WiMAX Security – White Papers – AIRSPAN, REDLINE, SPRINT-NEXTEL, 2007-2008, www.airspan.com, www.redlinecommunications.com, www.sprint.com
„Is Your AAA Up to the WiMAX Challenge” – White Paper – Bridgewater Systems, 2007, www.bridgewatersystems.com
E. Fernandez, M. Van Hilst, J.C. Pelaez, „Patterns for WiMAX Security”, Florida Atlantic University, 2007
W.-L. Wang, C.-W. Wu, „A Protocol for Billing Mobile Network Access Devices Operating in Foreign Networks”, National University of Singapore și Proceedings of WET ICE, 1998, (revizuita 2007 odată cu lansarea „US Patent 7240112 – Service Quality Monitoring Process”)
M. Koutsopoulou and others,”A Platform for charging, billing&accounting in future mobile networks”, University of Athens, 2007
S. Rizvi, R. Sircar, N. Chaudhari, „Open Platform WiMAX”, Conferința WiMAX Forum din Hawaii, 1 februarie 2007
S. Fluhrer, I. Mantir, A. Shamir, „Weakness in Key Scheduling Algorithm of RC4”, Cisco Press, 2007
E. Tews, R. Weinmann, A. Pyshkin, „Breaking 104 bit WEP in less than 60 seconds”, TU Darmstadt, FB Informatik, Darmstadt, Germany, 2007
A. Klein, „Attacks on RC4 stream cipher”, TU Darmstadt, FB Informatik, Darmstadt, Germany, 2007
„A comparative analysis of Mobile WiMAX deployment alternatives in the Access Network”, WiMAX Forum (Doug Gray), 2007, www.WiMAXforum.org
„Nortel WiMAX Conectivity Service Network (CSN)”, White Paper, Nortel, 2007, www.nortel.com
E. Angori, E. Borcoci, S. Mignanti, C. Nardini, G. Landi, N. Ciulli, G. Sergio, P. Neves, „Extending WiMAX technology to support End to End QoS guarantees”, Mai 2007
N. Ansari, „WiMAX Security: Privacy Key Management”, Sendai International Workshop on Network Security and Wireless Communications, 2007
Senza Fili Consulting, „Building End-to-End WiMAX Networks”, White Paper, 2007, www.senzafiliconsulting.com
J. Cushnie, D. Hutchinson, H. Oliver, „Evolution of charging and billing for GSM and future mobile internet services”, University of Lancaster, 2007
C.-T. Dogaru, „Rețele WiMAX – Convergență și simplitate”, NetworkWorld Nr.5/2007 pag. 12-13 și www.networkworld.ro
„Mobile WiMAX Security” – White Papers – ALVARION (2007, 2008, 2009), www.alvarion.com
S.Ahson, M. Ilyas, „WiMAX – Standards and Security”, CRC Press, 2008 – versiune revizuită
„Deployment of mobile WiMAX by Operators with Existing 2G&3G Networks” – White Paper – Forumul WiMAX, 2008, www.WiMAXforum.org
D. Maidment, „IEEE802.16j Overview”, prezentare, WiMAX World Event, octombrie 2008
„Mobile WiMAX Tower (Rural Development)”, White Paper, ALVARION, 2008, www.alvarion.com
„Building Secure Wireless Area Networks”, White Paper, Colubris Network Inc., 2008, www.colubris.procurve.com
D. Ciochina, S. Condrachi, „Video Surveillance Applications using WiMAX as a wireless access technology”, International Conference on COMMUNICATIONS, 2008, pag. 323-327
„Analysis Techniques for WiMAX Network Design Simulation”, White Paper, EDX Wireless, 2008, www.edx.com
Senza Fili Consulting, „Building Future-Proof Fixed and Mobile WiMAX Core Networks”, White Paper, 2008, www.senzafiliconsulting.com
C.T. Dogaru, T. Petrescu, „Security Problems for IEEE802.16 (WiMAX) Standard”, International Conference on COMMUNICATIONS (COMM2008), 2008, pag. 375-380 www.comm2008.ncit.pub.ro
C.T. Dogaru, „Calitatea serviciului – wireless sau wired”, NetworkWorld, pag. 4-6 și www.networkworld.ro , 2008
C.T. Dogaru, „Dezvoltarea unui plan pentru securitatea rețelei”, ComputerWorld Nr.11/2008, pag 16-18 și www.computerworld.ro
C.T. Dogaru, „Interconectarea rețelelor WiMAX”, NetworkWorld Nr.3/2008, pag 10-12 și www.networkworld.ro
C.T. Dogaru, „Monopolul buclei locale pe cale de dispariție”, NetworkWorld Nr.4/2008, pag. 6-7 și www.networkworld.ro
C.T. Dogaru, T. Petrescu, „WiMAX 802.16 Network Security Aspects”, Constanta Maritime University Annals, year 9, vol. 11, 2008, pag 227-232
C.Joys (Alcatel Lucent), „WiMAX Solutions – End to End Architectures and Services”, 2009
„Amdocs Billing Release 7.5 Documentation – Introduction, Activation Manager, Error Manager” – AMDOCS, 2009 (www.amdocs.com)
„Amdocs Billing Release 7.5 Security Documentation” – AMDOCS, 2009 (www.amdocs.com)
C.T. Dogaru, T. Petrescu, „WiMAX 802.16 Network – Secure Communications”, Buletinul Științific al Politehnicii București, Seria C, nr. 2, 2009, pag.27-38
C.T. Dogaru, „3 provocări adresate operatorilor pentru lansarea serviciilor WiMAX”, NetworkWorld Nr.5/2009, pag. 4-6 și www.networkworld.ro
C.T. Dogaru, „WiMAX vs. Rețele fără fir – Competiție sau complementaritate”, www.jurnaltelecom.ro , 2009
C.T. Dogaru, T. Petrescu, „WiMAX Network Security Plan – Open Target for New Implementations”, International Conference on COMMUNICATIONS (COMM2010), 2010, comm2010.ncit.pub.ro
Familia de standarde IEEE802.16, http://www.ieee802.org/16/netman/ – cu paginile:
IEEE802.16h – http://wirelessman.org/pubs/80216h.html
IEEE802.16g – http://wirelessman.org/pubs/80216g.html
IEEE802.16-2004 – http://wirelessman.org/pubs/80216-2004.html
IEEE802.16 (BWMAN) – http://standards.ieee.org/getieee802/802.16.html
Forumul WiMAX, http://www.WiMAXforum.org/ – cu paginile:
Raportul lunar din industrie – http://www.WiMAXforum.org/resources/monthly-industry-report
http://www.WiMAXforum.org/resources/documents/marketing/whitepapers
WiMAX Forum Roaming Models White Paper
Deployment of Mobile WiMAX Networks by Operators with Existing 2G & 3G Networks
Can WiMAX Address Your Applications?
WiMAX: The Business Case for Fixed Wireless Access in Emerging Markets
„RFC 2094, RFC 5154, RFC 5181” – preluate de pe www.faqs.org/rfcs/
Comunitatea WiMAX, www.WiMAX.com – cu paginile:
Whitepapers – http://www.WiMAX.com/research/whitepapers
Noutăți – http://www.WiMAX.com/commentary/news/WiMAX_industry_news
Cercetare – http://www.WiMAX.com/research/commerce/catalog/researchproducts
„WiMAX-Vision Papers”, publicate pe www.WiMAX-vision.com
„Strategia guvernamentală de dezvoltare a comunicațiilor electronice în bandă
largă în România pentru perioada 2009-2015”, www.mcsi.ro/Minister/Domenii-de-activitate-ale-MCSI/Comunicatii-electronice/Strategii
Simulator software pentru rețele de telecomunicații „NS – 2” – http://nsnam.isi.edu/nsnam/
Mediu virtual Linux pentru Windows „CYGWIN” – http://www.cygwin.com/
Software pentru analiza protocoalelor de rețea „WIRESHARK (fost ETHEREAL)” – http://www.wireshark.org/
ANEXA A – ALGORITMUL Dot16KDF
Algoritmul Dot16KDF se utilizează pentru modul de criptare AES-CTR. Pseudocodul acestui algoritm este următorul:
Dot16KDF (key,astring,keylength) // generează o cheie de lungime keylength –//folosind astring și criptată cu key
{
result=null;
Kin=Truncate (key,160);
For (i=0;i<=int(keylength-1)/160;i++) {
result=result | SHA-1( i| astring | keylength | Kin);// criptarea astring cu key //utilizând metoda SHA-1
}
return Truncate (result, keylength);
}
unde key reprezintă o cheie de criptare
astring reprezintă un octet de date utilizat pentru generarea cheii secrete
keylength reprezintă lungimea cheii care va fi generată
ANEXA B – PSEUDOCODUL ALGORITMULUI RIJNDAEL
Cipher(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)])
begin
byte state[4,Nb]
state = in
AddRoundKey(state, w[0, Nb-1])
for round = 1 step 1 to Nr–1
SubBytes(state)
ShiftRows(state)
MixColumns(state)
AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])
end for
SubBytes(state)
ShiftRows(state)
AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])
out = state
end
ANEXA C – CONFIGURAȚIA PARȚIALĂ PENTRU R1841 DIN EXPERIMENTUL DE LABORATOR (vezi fig. 6.16)
C1841#sh run
C8141#sh running-config
Building configuration…
Current configuration : 9595 bytes
!
version 12.4
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname C8141
!
boot-start-marker
boot-end-marker
!
security authentication failure rate 3 log
logging buffered 51200 debugging
enable secret 5 $1$2hOG$22.s.WWYewaHtNxcr1cbj.
enable password 7 0822455D0A16
!
aaa new-model
!
aaa authentication login default group radius
aaa authentication login no_radius local
aaa authentication ppp default group radius
aaa authorization network default group radius
aaa authorization network ssg_aaa_author_internal_list none
aaa accounting network default start-stop group radius
!
aaa nas port extended
aaa session-id common
clock timezone PCTime 2
clock summer-time PCTime date Mar 30 2003 3:00 Oct 26 2003 4:00
no ip source-route
ip tcp synwait-time 10
!
……………………………………………………………………..
!
interface GigabitEthernet0/0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
duplex auto
speed auto
no mop enabled
!
interface GigabitEthernet0/0.1
description $TOBS
encapsulation dot1Q 1 native
ip address 192.168.200.223 255.255.255.0
……………………………………………………………………………….
interface GigabitEthernet0/1
description $TOAAA
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
duplex auto
speed auto
!
interface GigabitEthernet0/1
encapsulation dot1Q 1 native
ip address 10.10.128.249 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
……………………………………………
!
interface Vlan1
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip route-cache flow
!
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1
ip route 192.168.170.0 255.255.255.0 192.168.160.220 permanent
!
!
ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
ip access-list extended test
permit ip 192.168.200.0 0.0.0.255
………………………………………
line con 0
privilege level 15
logging synchronous
login authentication no_radius
transport output telnet
line aux 0
transport output telnet
line vty 0 4
privilege level 15
logging synchronous
login authentication no_radius
transport input telnet ssh
line vty 5 15
privilege level 15
transport input telnet ssh
!
end
ANEXA D – FIȘIERUL DE CAPTURĂ DIN EXPERIMENTUL REALIZAT
No. Time Source Destination Protocol Info
1 0.000000 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=183, l=209)
Frame 1 (251 bytes on wire, 251 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
2 0.001509 10.10.128.250 10.10.135.82 RADIUS Access-challenge(11) (id=183, l=78)
Frame 2 (120 bytes on wire, 120 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
3 0.073018 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=184, l=252)
Frame 3 (294 bytes on wire, 294 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
4 0.076580 10.10.128.250 10.10.135.82 RADIUS Access-challenge(11) (id=184, l=1104)
Frame 4 (1146 bytes on wire, 1146 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
5 0.157880 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=185, l=196)
Frame 5 (238 bytes on wire, 238 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
6 0.160230 10.10.128.250 10.10.135.82 RADIUS Access-challenge(11) (id=185, l=677)
Frame 6 (719 bytes on wire, 719 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
7 0.418252 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=186, l=394)
Frame 7 (436 bytes on wire, 436 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
8 0.435005 10.10.128.250 10.10.135.82 RADIUS Access-challenge(11) (id=186, l=137)
Frame 8 (179 bytes on wire, 179 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
9 0.533152 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=187, l=345)
Frame 9 (387 bytes on wire, 387 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
10 0.537509 10.10.128.250 10.10.135.82 RADIUS Access-challenge(11) (id=187, l=200)
Frame 10 (242 bytes on wire, 242 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
11 0.607838 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=188, l=196)
Frame 11 (238 bytes on wire, 238 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
12 0.626320 10.10.128.250 10.10.135.82 RADIUS Access-Accept(2) (id=188, l=636)
Frame 12 (678 bytes on wire, 678 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
13 8.590841 10.10.135.82 10.10.128.250 RADIUS Accounting-Request(4) (id=22, l=262)
Frame 13 (304 bytes on wire, 304 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius-acct (1813), Dst Port: radius-acct (1813)
Radius Protocol
No. Time Source Destination Protocol Info
14 8.592326 10.10.128.250 10.10.135.82 RADIUS Accounting-Response(5) (id=22, l=20)
Frame 14 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius-acct (1813), Dst Port: radius-acct (1813)
Radius Protocol
BIBLIOGRAFIE
S. Luuikkanen, „Emerging Technologies in Mobile and Wireless Data Network Evolution”, University of Technology, Helsinki, 2003
T. Karygiannis, L. Owens, „Wireless Network Security”, NIST, Technology Administration, U.S. Department of Commerce, 2004 (ediție revizuită)
D.D. Boom, „Denial of Service Vulnerabilities in IEEE 802.16 Wireless”, teză de doctorat, Naval Postgraduate School, 2004
F. Ohrman, „WiMAX Handbook:Building 802.16 Wireless Networks”, Editura McGraw-Hill, NewYork, SUA, 2005
T. Choi, „Accounting, Charging and Billing for NGN Services and Networks”, ITU-T NGN Technical Workshop, Martie 2005, Korea
(http://www.itu.int/ITU-T/worksem/ngntech/presentations/s6-choi.pdf)
J. Wang, „Real-time billing throughput analysis of wireless telecommunication systems”, IEEE, 2005 (bluehawk.monmouth.edu/~jwang/GPRS_Billing_final.pdf)
S. Schwartz, „FHSS vs. DSSS – Seminars” – www.sorin-schwartz.com, 2006
S.Wattanachai, „Security Architecture of the IEEE802.16 Standard for Mesh Networks”, Royal Institute of Technology, Universitatea din Stockholm, 2006
J. Geier, „Wireless Networking HandBook”, Editura Macmillian Editors, 2006
H. Chou, „802.16 & 802.11 Security Overview”, Australian Information Security Conference, 2006
M. Barbeau, „WiMAX/802.16 Threat Analysis”, School of Computer Science, Universitatea Carleton, Canada, 2006
S. Xu, M. Matthews, C. Huang, „Security Issues in Privacy and Key Management Protocols of IEEE 802.16”, Departamentul de știință al University of South Carolina, 2006
„Campus Network Design Fundamentals” – Cisco Press, 2006
D.Pang, L. Tian, „Overview and Analysis of IEEE802.16e Security”, Chinese Academy of Sciences, 2006
F.Liu, Z. Zheng, Z. Lin, „Achieving QoS for IEEE802.16 in Mesh Mode”, School of Electronics and Information Engineering, Tongji University, Shanghai, China, 2006
D. Vladimir, S. Dmitry, „WiMAX – Local Networks Course Project”, Universitatea Tehnică din Praga, Cehia, 2006
H. Ventura, „DIAMETER, next generation’s AAA protocol”, teza de masterat, Institutionen för Systemteknik, LINKÖPING, 2006 (revizuit)
WiMAX Billing and CRM, White Paper, ARIA, 2006, www.ariasystems.com
„Billing for Mobile Wireless Data Services”, White Paper, Cisco Press, 2006, www.cisco.com
U. Foll, C. Fan, G. Carle, F. Dressler, M. Roshandel, „Service-Oriented Accounting and Charging for 3G and B3G Mobile Environments”, University of Tubingen, Germania, 2006
J.G. Andrews, A. Ghosh, R. Muhamed, „Fundamentals of WiMAX – Understanding Broadband Wireless Networking”, Editura Prentice Hall, 2007
„IEEE Standard for Local and Metropolitan Area Networks, Part 16 – Air Interface for Fixed Broadband Wireless Access Systems”, IEEE, Martie 2007
R. L. Freeman, „Radio System Design for Telecommunications”, Ediția a 3-a, Editura John Wiley Inc., 2007
Alcatel-Lucent, „WiMAX with Alcatel Lucent – Enabling a world of wireless broadband”, ISCTE, Portugal, 2007
S. Schwartz, „IPSec Basic” – Seminars – www.sorin-schwartz.com, 2007
„Mobile WiMAX Solutions – Leading the momentum forward” – White Paper – Fujitsu, 2007
S.Ahson, M. Ilyas, „WiMAX Applications”, CRC Press, 2007
Mobile WiMAX Security – White Papers – AIRSPAN, REDLINE, SPRINT-NEXTEL, 2007-2008, www.airspan.com, www.redlinecommunications.com, www.sprint.com
„Is Your AAA Up to the WiMAX Challenge” – White Paper – Bridgewater Systems, 2007, www.bridgewatersystems.com
E. Fernandez, M. Van Hilst, J.C. Pelaez, „Patterns for WiMAX Security”, Florida Atlantic University, 2007
W.-L. Wang, C.-W. Wu, „A Protocol for Billing Mobile Network Access Devices Operating in Foreign Networks”, National University of Singapore și Proceedings of WET ICE, 1998, (revizuita 2007 odată cu lansarea „US Patent 7240112 – Service Quality Monitoring Process”)
M. Koutsopoulou and others,”A Platform for charging, billing&accounting in future mobile networks”, University of Athens, 2007
S. Rizvi, R. Sircar, N. Chaudhari, „Open Platform WiMAX”, Conferința WiMAX Forum din Hawaii, 1 februarie 2007
S. Fluhrer, I. Mantir, A. Shamir, „Weakness in Key Scheduling Algorithm of RC4”, Cisco Press, 2007
E. Tews, R. Weinmann, A. Pyshkin, „Breaking 104 bit WEP in less than 60 seconds”, TU Darmstadt, FB Informatik, Darmstadt, Germany, 2007
A. Klein, „Attacks on RC4 stream cipher”, TU Darmstadt, FB Informatik, Darmstadt, Germany, 2007
„A comparative analysis of Mobile WiMAX deployment alternatives in the Access Network”, WiMAX Forum (Doug Gray), 2007, www.WiMAXforum.org
„Nortel WiMAX Conectivity Service Network (CSN)”, White Paper, Nortel, 2007, www.nortel.com
E. Angori, E. Borcoci, S. Mignanti, C. Nardini, G. Landi, N. Ciulli, G. Sergio, P. Neves, „Extending WiMAX technology to support End to End QoS guarantees”, Mai 2007
N. Ansari, „WiMAX Security: Privacy Key Management”, Sendai International Workshop on Network Security and Wireless Communications, 2007
Senza Fili Consulting, „Building End-to-End WiMAX Networks”, White Paper, 2007, www.senzafiliconsulting.com
J. Cushnie, D. Hutchinson, H. Oliver, „Evolution of charging and billing for GSM and future mobile internet services”, University of Lancaster, 2007
C.-T. Dogaru, „Rețele WiMAX – Convergență și simplitate”, NetworkWorld Nr.5/2007 pag. 12-13 și www.networkworld.ro
„Mobile WiMAX Security” – White Papers – ALVARION (2007, 2008, 2009), www.alvarion.com
S.Ahson, M. Ilyas, „WiMAX – Standards and Security”, CRC Press, 2008 – versiune revizuită
„Deployment of mobile WiMAX by Operators with Existing 2G&3G Networks” – White Paper – Forumul WiMAX, 2008, www.WiMAXforum.org
D. Maidment, „IEEE802.16j Overview”, prezentare, WiMAX World Event, octombrie 2008
„Mobile WiMAX Tower (Rural Development)”, White Paper, ALVARION, 2008, www.alvarion.com
„Building Secure Wireless Area Networks”, White Paper, Colubris Network Inc., 2008, www.colubris.procurve.com
D. Ciochina, S. Condrachi, „Video Surveillance Applications using WiMAX as a wireless access technology”, International Conference on COMMUNICATIONS, 2008, pag. 323-327
„Analysis Techniques for WiMAX Network Design Simulation”, White Paper, EDX Wireless, 2008, www.edx.com
Senza Fili Consulting, „Building Future-Proof Fixed and Mobile WiMAX Core Networks”, White Paper, 2008, www.senzafiliconsulting.com
C.T. Dogaru, T. Petrescu, „Security Problems for IEEE802.16 (WiMAX) Standard”, International Conference on COMMUNICATIONS (COMM2008), 2008, pag. 375-380 www.comm2008.ncit.pub.ro
C.T. Dogaru, „Calitatea serviciului – wireless sau wired”, NetworkWorld, pag. 4-6 și www.networkworld.ro , 2008
C.T. Dogaru, „Dezvoltarea unui plan pentru securitatea rețelei”, ComputerWorld Nr.11/2008, pag 16-18 și www.computerworld.ro
C.T. Dogaru, „Interconectarea rețelelor WiMAX”, NetworkWorld Nr.3/2008, pag 10-12 și www.networkworld.ro
C.T. Dogaru, „Monopolul buclei locale pe cale de dispariție”, NetworkWorld Nr.4/2008, pag. 6-7 și www.networkworld.ro
C.T. Dogaru, T. Petrescu, „WiMAX 802.16 Network Security Aspects”, Constanta Maritime University Annals, year 9, vol. 11, 2008, pag 227-232
C.Joys (Alcatel Lucent), „WiMAX Solutions – End to End Architectures and Services”, 2009
„Amdocs Billing Release 7.5 Documentation – Introduction, Activation Manager, Error Manager” – AMDOCS, 2009 (www.amdocs.com)
„Amdocs Billing Release 7.5 Security Documentation” – AMDOCS, 2009 (www.amdocs.com)
C.T. Dogaru, T. Petrescu, „WiMAX 802.16 Network – Secure Communications”, Buletinul Științific al Politehnicii București, Seria C, nr. 2, 2009, pag.27-38
C.T. Dogaru, „3 provocări adresate operatorilor pentru lansarea serviciilor WiMAX”, NetworkWorld Nr.5/2009, pag. 4-6 și www.networkworld.ro
C.T. Dogaru, „WiMAX vs. Rețele fără fir – Competiție sau complementaritate”, www.jurnaltelecom.ro , 2009
C.T. Dogaru, T. Petrescu, „WiMAX Network Security Plan – Open Target for New Implementations”, International Conference on COMMUNICATIONS (COMM2010), 2010, comm2010.ncit.pub.ro
Familia de standarde IEEE802.16, http://www.ieee802.org/16/netman/ – cu paginile:
IEEE802.16h – http://wirelessman.org/pubs/80216h.html
IEEE802.16g – http://wirelessman.org/pubs/80216g.html
IEEE802.16-2004 – http://wirelessman.org/pubs/80216-2004.html
IEEE802.16 (BWMAN) – http://standards.ieee.org/getieee802/802.16.html
Forumul WiMAX, http://www.WiMAXforum.org/ – cu paginile:
Raportul lunar din industrie – http://www.WiMAXforum.org/resources/monthly-industry-report
http://www.WiMAXforum.org/resources/documents/marketing/whitepapers
WiMAX Forum Roaming Models White Paper
Deployment of Mobile WiMAX Networks by Operators with Existing 2G & 3G Networks
Can WiMAX Address Your Applications?
WiMAX: The Business Case for Fixed Wireless Access in Emerging Markets
„RFC 2094, RFC 5154, RFC 5181” – preluate de pe www.faqs.org/rfcs/
Comunitatea WiMAX, www.WiMAX.com – cu paginile:
Whitepapers – http://www.WiMAX.com/research/whitepapers
Noutăți – http://www.WiMAX.com/commentary/news/WiMAX_industry_news
Cercetare – http://www.WiMAX.com/research/commerce/catalog/researchproducts
„WiMAX-Vision Papers”, publicate pe www.WiMAX-vision.com
„Strategia guvernamentală de dezvoltare a comunicațiilor electronice în bandă
largă în România pentru perioada 2009-2015”, www.mcsi.ro/Minister/Domenii-de-activitate-ale-MCSI/Comunicatii-electronice/Strategii
Simulator software pentru rețele de telecomunicații „NS – 2” – http://nsnam.isi.edu/nsnam/
Mediu virtual Linux pentru Windows „CYGWIN” – http://www.cygwin.com/
Software pentru analiza protocoalelor de rețea „WIRESHARK (fost ETHEREAL)” – http://www.wireshark.org/
ANEXA A – ALGORITMUL Dot16KDF
Algoritmul Dot16KDF se utilizează pentru modul de criptare AES-CTR. Pseudocodul acestui algoritm este următorul:
Dot16KDF (key,astring,keylength) // generează o cheie de lungime keylength –//folosind astring și criptată cu key
{
result=null;
Kin=Truncate (key,160);
For (i=0;i<=int(keylength-1)/160;i++) {
result=result | SHA-1( i| astring | keylength | Kin);// criptarea astring cu key //utilizând metoda SHA-1
}
return Truncate (result, keylength);
}
unde key reprezintă o cheie de criptare
astring reprezintă un octet de date utilizat pentru generarea cheii secrete
keylength reprezintă lungimea cheii care va fi generată
ANEXA B – PSEUDOCODUL ALGORITMULUI RIJNDAEL
Cipher(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)])
begin
byte state[4,Nb]
state = in
AddRoundKey(state, w[0, Nb-1])
for round = 1 step 1 to Nr–1
SubBytes(state)
ShiftRows(state)
MixColumns(state)
AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])
end for
SubBytes(state)
ShiftRows(state)
AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])
out = state
end
ANEXA C – CONFIGURAȚIA PARȚIALĂ PENTRU R1841 DIN EXPERIMENTUL DE LABORATOR (vezi fig. 6.16)
C1841#sh run
C8141#sh running-config
Building configuration…
Current configuration : 9595 bytes
!
version 12.4
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname C8141
!
boot-start-marker
boot-end-marker
!
security authentication failure rate 3 log
logging buffered 51200 debugging
enable secret 5 $1$2hOG$22.s.WWYewaHtNxcr1cbj.
enable password 7 0822455D0A16
!
aaa new-model
!
aaa authentication login default group radius
aaa authentication login no_radius local
aaa authentication ppp default group radius
aaa authorization network default group radius
aaa authorization network ssg_aaa_author_internal_list none
aaa accounting network default start-stop group radius
!
aaa nas port extended
aaa session-id common
clock timezone PCTime 2
clock summer-time PCTime date Mar 30 2003 3:00 Oct 26 2003 4:00
no ip source-route
ip tcp synwait-time 10
!
……………………………………………………………………..
!
interface GigabitEthernet0/0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
duplex auto
speed auto
no mop enabled
!
interface GigabitEthernet0/0.1
description $TOBS
encapsulation dot1Q 1 native
ip address 192.168.200.223 255.255.255.0
……………………………………………………………………………….
interface GigabitEthernet0/1
description $TOAAA
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
duplex auto
speed auto
!
interface GigabitEthernet0/1
encapsulation dot1Q 1 native
ip address 10.10.128.249 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
……………………………………………
!
interface Vlan1
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip route-cache flow
!
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1
ip route 192.168.170.0 255.255.255.0 192.168.160.220 permanent
!
!
ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
ip access-list extended test
permit ip 192.168.200.0 0.0.0.255
………………………………………
line con 0
privilege level 15
logging synchronous
login authentication no_radius
transport output telnet
line aux 0
transport output telnet
line vty 0 4
privilege level 15
logging synchronous
login authentication no_radius
transport input telnet ssh
line vty 5 15
privilege level 15
transport input telnet ssh
!
end
ANEXA D – FIȘIERUL DE CAPTURĂ DIN EXPERIMENTUL REALIZAT
No. Time Source Destination Protocol Info
1 0.000000 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=183, l=209)
Frame 1 (251 bytes on wire, 251 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
2 0.001509 10.10.128.250 10.10.135.82 RADIUS Access-challenge(11) (id=183, l=78)
Frame 2 (120 bytes on wire, 120 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
3 0.073018 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=184, l=252)
Frame 3 (294 bytes on wire, 294 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
4 0.076580 10.10.128.250 10.10.135.82 RADIUS Access-challenge(11) (id=184, l=1104)
Frame 4 (1146 bytes on wire, 1146 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
5 0.157880 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=185, l=196)
Frame 5 (238 bytes on wire, 238 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
6 0.160230 10.10.128.250 10.10.135.82 RADIUS Access-challenge(11) (id=185, l=677)
Frame 6 (719 bytes on wire, 719 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
7 0.418252 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=186, l=394)
Frame 7 (436 bytes on wire, 436 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
8 0.435005 10.10.128.250 10.10.135.82 RADIUS Access-challenge(11) (id=186, l=137)
Frame 8 (179 bytes on wire, 179 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
9 0.533152 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=187, l=345)
Frame 9 (387 bytes on wire, 387 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
10 0.537509 10.10.128.250 10.10.135.82 RADIUS Access-challenge(11) (id=187, l=200)
Frame 10 (242 bytes on wire, 242 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
11 0.607838 10.10.135.82 10.10.128.250 RADIUS Access-Request(1) (id=188, l=196)
Frame 11 (238 bytes on wire, 238 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
12 0.626320 10.10.128.250 10.10.135.82 RADIUS Access-Accept(2) (id=188, l=636)
Frame 12 (678 bytes on wire, 678 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius (1812), Dst Port: radius (1812)
Radius Protocol
No. Time Source Destination Protocol Info
13 8.590841 10.10.135.82 10.10.128.250 RADIUS Accounting-Request(4) (id=22, l=262)
Frame 13 (304 bytes on wire, 304 bytes captured)
Ethernet II, Src: Breezeco_22:df:63 (00:10:e7:22:df:63), Dst: Crossbea_26:b6:49 (00:03:d2:26:b6:49)
Internet Protocol, Src: 10.10.135.82 (10.10.135.82), Dst: 10.10.128.250 (10.10.128.250)
User Datagram Protocol, Src Port: radius-acct (1813), Dst Port: radius-acct (1813)
Radius Protocol
No. Time Source Destination Protocol Info
14 8.592326 10.10.128.250 10.10.135.82 RADIUS Accounting-Response(5) (id=22, l=20)
Frame 14 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Crossbea_26:b6:49 (00:03:d2:26:b6:49), Dst: Breezeco_22:df:63 (00:10:e7:22:df:63)
Internet Protocol, Src: 10.10.128.250 (10.10.128.250), Dst: 10.10.135.82 (10.10.135.82)
User Datagram Protocol, Src Port: radius-acct (1813), Dst Port: radius-acct (1813)
Radius Protocol
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Securitatea Retelelor de Acces Fara Fir (ID: 123828)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.