EFEKTYWNA BEZPIECZNA TRANSMISJA DANYCH W SIECIACH

mgr inż. Urszula Ostrowska
Wojskowa Akademia Techniczna, Wydział Elektroniki, Instytut Telekomunikacji,
ul. Gen. S. Kaliskiego 2, 00-908 Warszawa
tel.: 0-22 6830517, fax: 0-22 6839038,
e-mail: [email protected]
EFEKTYWNA BEZPIECZNA TRANSMISJA DANYCH
W SIECIACH WĄSKOPASMOWYCH
Wstęp
Proponowane w zaleceniach mechanizmy sieci IP są przeznaczone dla szybkich i
niezawodnych sieci lokalnych oraz jeszcze szybszych sieci szkieletowych miejskich i
rozległych. Obecnie uruchamiane są coraz to nowsze usługi jak telefonia VoIP,
telekonferencje, radio i telewizja. Usługi te niestety znacznie obciążają wykorzystanie łączy
dostępowych, mogą również powodować przeciążenia w sieci. Szerokopasmowe sieci IP są
podatne na przenoszenie zwiększonego ruchu, ale gdy usługi przenoszone są w radiowych
sieciach wąskopasmowych, realizacja usług telefonicznych i transmisji danych może być
utrudniona, a nawet niemożliwa. Dodatkowo projektanci i architekci protokołów rodziny
IPv6, aby uniknąć problemów z ograniczeniami funkcjonalnymi, wprowadzili do niego duże
nadmiary informacyjne, np. w celu realizacji adresacji. Czasami adresacja realizowana jest
wielopoziomowo - ma to miejsce, np. w przypadku wykorzystania protokołu IPSec w trybie
tunelowym [1-6]. W tym trybie pakiety są szyfrowane wraz z nagłówkami, a następnie
dołączany jest nowy nagłówek IPSec.
Opisana problematyka stała się przyczyną tego, że zajęłam się mechanizmami kompresji
nagłówków i multipleksacją pakietów IPv6 różnych usług. Proponowana przeze mnie metoda
kompresji i multipleksacji pozwala na znaczne zmniejszenie nadmiarowości informacyjnej,
a co za tym idzie zmniejszenie zapotrzebowania na przepustowość przez usługi VoIPv6
zabezpieczone mechanizmami IPSec.
1. Architektura protokołu IPSec
Architektura IPSec opisana została w RFC 2401 [13]. Głównym jej zadaniem jest
zapewnienie usług bezpieczeństwa w warstwie sieciowej pomiędzy dwoma użytkownikami
końcowymi. Podstawowymi komponentami architektury bezpieczeństwa IPSec są (rys.1.):
− protokoły bezpieczeństwa: protokół uwierzytelniania AH (Authentication Header) oraz
protokół szyfrowania ESP (Encapsulating Security Payload);
− asocjacje bezpieczeństwa SA (Security Association);
− zarządzanie kluczami (Key Management) „ręczne” i automatyczne;
− algorytmy wykorzystywane w szyfrowaniu i uwierzytelnianiu.
Architektura
Protokół
ESP
Protokół
AH
Algorytm
szyfrowania
Algorytm
uwierzytelniania
Dziedzina
implementacji
Zarządzanie
kluczami
Rys. 1. Zależności pomiędzy elementami architektury bezpieczeństwa RFC 2411 [6]
−
−
−
−
−
Protokół IPSec zapewnia:
integralność wiadomości (integrity) – otrzymana wiadomość nie została zmodyfikowana
w trakcie transmisji;
uwierzytelnianie wiadomości (authenticity) – identyfikację nadawcy za pomocą
kryptograficznego podpisanie danych;
ochronę przed powtórzeniem (reply protection) – gdy do stacji docelowej dociera
ponownie odebrany już pakiet, jest on przez nią odrzucony;
kontrolę dostępu (access control) – niemożność wynegocjowania parametrów
bezpieczeństwa powoduje odrzucenie połączenia;
poufność danych (confidentially) – zabezpiecza przed podsłuchem pasywnym, czyli
celowym lub przypadkowym dostaniem się informacji w niepowołane ręce dzięki
zastosowanym metodom kryptograficznym.
Rys. 2. Protokoły IPSec
Protokół IPSec korzysta z dwóch protokołów: protokołu nagłówka uwierzytelnienia (AH)
oraz protokołu szyfrowania wiadomości enkapsułowanych (ESP) (rys.2.). Protokoły ESP
i AH zostały opisane w dokumentach [14-15].
Protokół AH [7, 9-10] chroni cały pakiet IP przed modyfikacją - dane walidujące
zabezpieczają zarówno nagłówek, a więc adres nadawcy i odbiorcy, jak i samą zawartość
pakietu. Protokół ten nie zapewnia jednak tajności - dane nadal przesyłane są „otwartym
tekstem”. Protokół ESP [8-10] zapewnia integralność i tajność informacji poprzez
zakodowanie całości lub części pakietu IP i przesłaniu go jako danych zwykłego pakietu IP.
Rysunek 3 oraz 4 ilustruje opisane tryby.
2
Tryb tunelowy
AH
Oryginalny
nagłówek IP
Nowy
nagłówek IP
Nagłówki
dodatkowe
Hop-by-hop,
Dest,Routing
Nagłówek
warstwy wyższej
Oryginalny
nagłówek IP
AH
Pola zmienne:
- klasa ruchu
- etykieta ruchu
- adres S/D
Dane
Nagłówek
warstwy wyższej
Dest, Opcje
Dane
Pola stałe
Pola zmienne
Autoryzacja z wyjątkiem pól zmiennych
ESP
Oryginalny
nagłówek IP
Nowy
nagłówek IP
Nagłówki
dodatkowe
Nowe nagłówki
dodatkowe
Nagłówek
warstwy wyższej
ESP
Oryginalny
nagłówek IP
Dane
Nagłówki
dodatkowe
Nagłówek
warstwy wyższej
Dane
ESP Trailer
ESP
ICV
Szyfrowane
Ochrona integralności
Rys. 3. Tryb tunelowy
Tryb transportowy
AH
Oryginalny
nagłówek IP
Oryginalny
nagłówek IP
Nagłówki
dodatkowe
Hop-by-hop,
Dest,Routing
Nagłówek
warstwy wyższej
Dest
Opcje
AH
Pola zmienne:
- klasa ruchu
- etykieta ruchu
- adres S/D
Dane
Nagłówek
warstwy wyższej
Dane
Pola stałe
Pola zmienne
Autoryzacja z wyjątkiem pól zmiennych
ESP
Oryginalny
nagłówek IP
Oryginalny
nagłówek IP
Nagłówki
dodatkowe
Hop-by-hop,
Dest,Routing
ESP
Nagłówek
warstwy wyższej
Nagłówek
warstwy wyższej
Dane
Dane
ESP Trailer
ESP
ICV
Szyfrowane
Ochrona integralności
Rys. 4. Tryb transportowy
−
−
Powyżej opisane protokoły mogą pracować w dwóch trybach:
tryb tunelowy (Tunnel Mode) – w trybie tym cały pakiet IP (dane i nagłówki) zostaje
poddany ochronie oraz dołożony zostaje nowy nagłówek IP;
tryb transportowy (Transport Mode) – w trybie tym ochronie podlegają tylko nagłówki
warstw wyższych oraz dane.
2. Proponowany mechanizm kompresji nagłówków
Dla łączy wąskopasmowych (rys.5), które mogą występować w radiowych sieciach IPv6,
zaproponowano wykorzystanie urządzenia brzegowego - adaptera sieciowego NA.
Kompresja
nagłówka
IPSec
Dekompresja
nagłówka
IPSec
Kompresja
nagłówka IPv6
Dekompresja
nagłówka IPv6
RT
RT
Detekcja usług
Obsługa karty
LAN
NRT
Multipleksacja
usług
Detekcja usług
Obsługa
interfejsu IF
Obsługa
interfejsu IF
Rys. 5. Algorytm pracy NA
3
NRT
Obsługa karty
LAN
Zaimplementowano w nim procedurę dwupoziomowej kompresji nagłówka (rys.6, 7).
W pierwszej kolejności kompresji podlega oryginalny nagłówek IPv6, a w drugiej nagłówek
IPSec (procedura CopmIPSecv6). Wymiana pakietów IPv6 jest realizowana w trybie
tunelowym [1,6].
Przesyłane w sieci pakiety są klasyfikowane jako RT (ang. Real Time) , NRT (ang. Non
Real time) oraz sterujące. Klasyfikacja pakietów dla usług RT i NRT odbywa się na
podstawie zawartości pól Traffic_Class i Flow_Label, a w przypadku pakietów sterujących na
podstawie typu pakietu. Pakiety sterujące są wysyłane z największym priorytetem i w celu
zapewnienia prawidłowej jakości usługom RT są one segmentowane i multipleksowane.
Pakiety NRT również podlegają segmentacji i są wysyłane z najmniejszym priorytetem.
Rys. 6. Koncepcja dwupoziomowej kompresji nagłówków
LEGENDA:
1. Odebranie pakietu IPv6 z sieci LAN
2. Kompresja nagłówka IPv6
3. Szyfrowanie IPSec
4. Kompresja nagłówka IPSec
5. Wysłanie do sieci wąskopasmowej pakietu skompresowanego
W procedurze kompresji (rys.3) i dekompresji (rys.4) zostały wykorzystane interfejsy
gniazda. Gniazda są punktami końcowymi komunikacji pomiędzy jądrem systemu Linuks
a aplikacją. Interfejs gniazda umożliwia warstwom wyższym współdzielenie informacji
z warstwami transportowymi za pomocą globalnych struktur danych.
Rys. 7. Koncepcja dwupoziomowej dekompresji nagłówków
LEGENDA:
1. Odebranie pakietu IPv6 z interfejsu IF (z sieci wąskopasmowej)
2. Dekompresja nagłówka IPSec
3. Deszyfrowanie IPSec
4. Dekompresja IPv6
5. Wysłanie do sieci LAN pełnego pakietu
3. Środowisko badawcze oraz wyniki badań
Aplikacja NA (Network Adapter) [7-11] została zaimplementowana na platformie Linuks.
Została ona uruchomiona i przebadana w środowisku laboratoryjnym (rys.8). Sprawdzenie
poprawności pracy aplikacji zrealizowano w sieci IPv6. Pomiędzy stacjami abonenckimi
przesyłano pakiety ping6, które w początkowej chwili zostały poprzedzone pakietami
4
odkrywania otoczenia ND (Neighbor Discovery). Pakiety ping6 są obsługiwane przez NA
tak, jak usługi NRT, zaś pakiety ND są pakietami sterującymi.
Rys. 8. Stanowisko laboratoryjne
Opóźnienie pomiędzy pakietami NRT [s]
Badania zostały wykonane dla dwóch scenariuszy: przy włączonej procedurze
dwupoziomowej kompresji nagłówków (z CopmIPSecv6) oraz z kompresją
jednopoziomową (adresu oryginalnego IPv6, bez włączonego mechanizmu kompresji IPSec)
(rys.9). Na podstawie przeprowadzonych badań można stwierdzić, że procedura szyfrowania
wprowadza dodatkowe opóźnienie (porównanie opóźnienia dla 2 wykresów).
W początkowej fazie pracy aplikacji wymiana pakietów sterujących jest obciążona
największym opóźnieniem, gdyż adaptery sieciowe NA muszą się zsynchronizować (jest to
związane z utratą pojedynczego pakietu dla każdego kierunku transmisji). Następnie
wymieniane są pakiety ping6, dla których opóźnienie jest stałe. Wtedy, gdy zanotowany jest
wzrost opóźnienia (ok.7 pakietu), następuje przesłanie dodatkowego pakietu sterującego ND.
3
NA z CompIPSecv6
NA
2
1
0
0
2
4
6
8
10
Numer przesyłanego pakietu
Rys. 9. Charakterystyka opóźnień pakietów NRT i sterujących
Na rysunku 10 przedstawiono porównanie otrzymanych wyników jittera dla różnych
obciążeń sieci oraz przy włączonej lub wyłączone kompresji nagłówka IPSec. Usługi RT
zostały zrealizowane z wykorzystaniem aplikacji VoIPv6: PcPhone.
5
Jitter [ms]
350
NA z CompIPSecv6
NA z CompIPSecv6 oraz pakiet NRT = 107B
NA z CompIPSecv6 oraz pakiet NRT = 1300B
PcPhone
PcPhone oraz pakiet NRT = 107B
PcPhone oraz pakiet NRT = 1300B
300
250
200
150
100
50
0
0
10
20
30
40
50
60
70
80
90
100
Czas [s]
Rys. 10. Jitter pakietów VoIPv6 (danych RT) w sieci przy pracy z i bez kompresji IPSec
Na podstawie analizy charakterystyk można stwierdzić, że wartość jittera jest najmniejsza
wtedy, gdy procedura CompIPSecv6 jest włączona. Gdy brak jest procedury CompIPSecv6, nie
zapewniana jest priorytetyzacja usług RT, NRT i danych kontrolnych, dlatego wszystkie dane
przesyłane są jednocześnie. Np. gdy przesyłane były dane NRT o wielkości 1300B,
użytkownicy nie byli w stanie zrozumieć się, a połączenie po 30s było zrywane. Przy
włączonej procedurze CompIPSecv6 taka sytuacja nie ma miejsca.
4. Podsumowanie
Podsumowując, omówiona procedura CopmIPSecv6 zapewnia bezpieczny mechanizm
realizacji usług RT i NRT. Umożliwia ona kompresję nagłówków oryginalnych i nagłówków
IPSec. Dzięki temu w kanale wąskopasmowym można przenosić jednocześnie usługi RT
i NRT nie zakłócając mechanizmów standardowych protokołu IPv6. Procedura CopmIPSecv6
wykorzystuje standardowy mechanizm IPSec wkompilowany w system Linuks.
Do mechanizmów szyfrowania i deszyfrowania wykorzystany został interfejs fikcyjny.
Dzięki temu stacja robocza, na której pracuje aplikacja NA z procedurą CopmIPSecv6, nie
wymaga
stosowania
dodatkowych
interfejsów
sieciowych,
potrzebnych
do
szyfrowania/deszyfrowania IPSec.
Opóźnienie danych NRT wzrosło po dodaniu procedury CopmIPSecv6 do aplikacji NA.
Wzrost opóźnienia związany jest z czasem potrzebnym na szyfrowanie i deszyfrowanie
danych za pomocą IPSec.
Zaletą zaimplementowanej procedury jest priorytetyzacja usług. Na podstawie
przeprowadzonych badań można stwierdzić, że dane sterujące będą przesyłane zawsze w
pierwszej kolejności, niezależnie od tego, czy odbywa się transmisja danych RT czy też NRT.
W aplikacji została zrealizowana multipleksacja usług różnego typu. Dzięki temu
mechanizmowi, pomimo transmisji danych RT, przesyłane są także dane NRT. Dane NRT
przesyłane są pomiędzy danymi RT tylko wtedy, gdy ich transmisja nie spowoduje
przerwania połączenia RT.
W najbliższym czasie planowane są badania mechanizmu w wąskopasmowych sieciach
radiowych (łączność KF i UKF) oraz badanie wpływu metod szyfrowania na jakość usługi
6
RT. Dodatkowo należy przeprowadzić szczegółowe badania omówionego mechanizmu
w obecności mechanizmu adaptacji wielkości strumieni pakietów VoIP.
Bibliografia:
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
B.Singh, S.Sofat: Future of Internet Security – IPSec: 01/26/2005
S.Kent, R.Atkinson: Security Architecture for the Internet Protocol; IETF RFC 2401, 11.1998
R.Thayer, N.Doraswamy: IP Security Document Roadmap, RFC 2411, IETF 1998
S.Kent, R.Atkinson: IP Authentication Header, RFC 2402, IETF 1998
S.Kent, R.Atkinson: IP Encapsulating Security Payload (ESP), RFC 2406, IETF 1998
S.Kent, K.Seo: Security Architecture for the Internet Protocol; RFC 4301, 12.2005
U.Ostrowska: Koncepcja kompresji nagłówków IPSec usług czasu rzeczywistego w sieciach
wąskopasmowych, SECON 2006
U.Ostrowska: Efektywny bezpieczny mechanizm realizacji usług transmisji mowy i danych dla mobilnych
wąskopasmowych sieci IPv6 , KSTiT 2007
J.Jarmakiewicz, P. Łubkowski: Implementacja aplikacji adaptera sieciowego, ITK WAT raport badawczy
GRANT nr 0 T00A 16 25, Warszawa 2004
M.Amanowicz, M.Antweiler, J.Jarmakiewicz, J.Krygier, P.Łubkowski, T.Aurich, R.Bryś, M.Lies,
J.Milewski, P.Sevenich: Implementation of IPv6 protocol for tactical interoperable communications
networks, RTO TICNET PROJECT, Final Raport, Brussels NATO IST, 2006
J.Jarmakiewicz: Budowa modelu symulacyjnego łącza HF wykorzystującego adapter sieciowy. Weryfikacja
i walidacja modelu. WIŁ raport badawczy GRANT nr 0 T00A 16 25, Warszawa 2004
A.Metkowska , J.Jarmakiewicz: Mechanizm wspierania jakości usługi VoIP w warunkach przeciążeń sieci
IPv6, KSTiT 2007
S. Kent, K. Seo: Security Architecture for the Internet Protocol; RFC 4301, 12.2005
S.Kent, R.Atkinson: IP Authentication Header, RFC 2402, IETF 1998
S.Kent, R.Atkinson: IP Encapsulating Security Payload (ESP), RFC 2406, IETF 1998
7