EFEKTYWNA BEZPIECZNA TRANSMISJA DANYCH W SIECIACH WĄSKOPASMOWYCH

Transkrypt

1 mgr inż. Urszula Ostrowska Wojskowa Akademia Techniczna, Wydział Elektroniki, Instytut Telekomunikacji, ul. Gen. S. Kaliskiego 2, Warszawa tel.: , fax: , 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 Sec. 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 (Authentication Header) oraz protokół szyfrowania (Encapsulating Security Payload); asocjacje bezpieczeństwa SA (Security Association); zarządzanie kluczami (Key Management) ręczne i automatyczne; algorytmy wykorzystywane w szyfrowaniu i uwierzytelnianiu.

2 Architektura Protokół Protokół 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 () oraz protokołu szyfrowania wiadomości enkapsułowanych () (rys.2.). Protokoły i zostały opisane w dokumentach [14-15]. Protokół [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ół [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

3 Tryb tunelowy Pola zmienne: - klasa ruchu - etykieta ruchu - adres S/D Nowy Pola zmienne Hop-by-hop, Dest,Routing Dest, Opcje Pola stałe Autoryzacja z wyjątkiem pól zmiennych Nowy Nowe nagłówki Trailer ICV Szyfrowane Tryb transportowy Ochrona integralności Rys. 3. Tryb tunelowy Pola zmienne Hop-by-hop, Dest,Routing Dest Opcje Pola stałe Autoryzacja z wyjątkiem pól zmiennych Pola zmienne: - klasa ruchu - etykieta ruchu - adres S/D Hop-by-hop, Dest,Routing Trailer 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 ; 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 RT RT Dekompresja nagłówka IPv6 Detekcja usług NRT Multipleksacja usług Detekcja usług NRT Obsługa karty LAN Obsługa interfejsu IF Obsługa interfejsu IF Obsługa karty LAN Rys. 5. Algorytm pracy NA 3

4 Zaimplementowano w nim procedurę dwupoziomowej kompresji nagłówka (rys.6, 7). W pierwszej kolejności kompresji podlega oryginalny v6, 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

5 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 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 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 go pakietu sterującego ND. Opóźnienie pomiędzy pakietami NRT [s] 3 2 NA z CompIPSecv6 NA 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

6 Jitter [ms] 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 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. 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

7 RT. Dodatkowo należy przeprowadzić szczegółowe badania omówionego mechanizmu w obecności mechanizmu adaptacji wielkości strumieni pakietów VoIP. Bibliografia: [1] B.Singh, S.Sofat: Future of Internet Security IPSec: 01/26/2005 [2] S.Kent, R.Atkinson: Security Architecture for the Internet Protocol; IETF RFC 2401, [3] R.Thayer, N.Doraswamy: IP Security Document Roadmap, RFC 2411, IETF 1998 [4] S.Kent, R.Atkinson: IP Authentication Header, RFC 2402, IETF 1998 [5] S.Kent, R.Atkinson: IP Encapsulating Security Payload (), RFC 2406, IETF 1998 [6] S.Kent, K.Seo: Security Architecture for the Internet Protocol; RFC 4301, [7] U.Ostrowska: Koncepcja kompresji nagłówków IPSec usług czasu rzeczywistego w sieciach wąskopasmowych, SECON 2006 [8] U.Ostrowska: Efektywny bezpieczny mechanizm realizacji usług transmisji mowy i danych dla mobilnych wąskopasmowych sieci IPv6, KSTiT 2007 [9] J.Jarmakiewicz, P. Łubkowski: Implementacja aplikacji adaptera sieciowego, ITK WAT raport badawczy GRANT nr 0 T00A 16 25, Warszawa 2004 [10] 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 [11] 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 [12] A.Metkowska, J.Jarmakiewicz: Mechanizm wspierania jakości usługi VoIP w warunkach przeciążeń sieci IPv6, KSTiT 2007 [13] S. Kent, K. Seo: Security Architecture for the Internet Protocol; RFC 4301, [14] S.Kent, R.Atkinson: IP Authentication Header, RFC 2402, IETF 1998 [15] S.Kent, R.Atkinson: IP Encapsulating Security Payload (), RFC 2406, IETF