Bezpečnost optimalizace cesty v MIPv6

Transkript

1 Rok / Year: Svazek / Volume: Číslo / Number: Bezpečnost optimalizace cesty v MIPv6 Securing Route Optimization in MIPv6 Michal Skořepa michal.skorepa@phd.feec.vutbr.cz Fakulta elektrotechniky a komunikačních technologií VUT v Brně Abstrakt: Článek se zabývá problematikou zabezpečení aktualizace vazby v protokolu Mobile IPv6 při použití optimalizace cesty. Při aktualizaci vazby s korespondujícím uzlem potřebuje mít tento uzel jistotu, že aktualizace vazby byla iniciována opravdu tím mobilním uzlem, za kterého se půpdce zprávy vydává. K tomu je využata technika zpětné směrovatelnosti. Abstract: The paper deals with securing the binding update message in Mobile IPv6 protocol with route optimization. When the correspondent node receives the binding update message it needs to verify that the originator of the message is the mobile node which it seems to be. For this purpose the return routability procedure is utilized.

2 Bezpečnost optimalizace cesty v MIPv6 Ing. Michal Skořepa 1 1 Fakulta elektrotechniky a komunikačních technologií VUT v Brně michal.skorepa@phd.feec.vutbr.cz Abstrakt Protokol Mobile IPv6 umožňuje uzlům v sítích pracujících na protokolu IPv6 pohybovat se mezi podsítěmi s různým prefixem, aniž by musel měnit svou IP adresu. Díky tomu umožňuje zachovat TCP spojení aktivní i během pohybu a umožňuje mobilnímu uzlu zůstat dosažitelným na stále stejné IP adrese. V rámci tohoto protokolu pak existují dva způsoby komunikace mezi mobilním uzlem a jeho protějškem. Data mohou být buď tunelována přes centrální uzel v domovské síti mobilního uzlu domovského agenta, nebo mohou být přenášena mezi komunikujícími uzly přímo. Druhá možnost zásadně ovlivňuje koncové zpoždění dat, ovšem vyžaduje implementaci protokolu Mobile IPv6 i na straně uzlu, se kterým mobilní uzel komunikuje. Tento způsob ovšem přináší jistá bezpečnostní rizika. Tento článek tato rizika popisuje a uvádí způsob jejich minimalizace. 1 Úvod v domovské síti MN, opatřeny přídavným záhlavím a tunelovány do aktuálního umístění MN. Pakety v opačném směru, tedy zasílané od MN k CN, jsou zpětně tunelovány opět k HA. Odtud jsou standardně směrovány k CN. Přídavné záhlaví obsahuje ve směru CN MN v poli zdrojové adresy adresu HA a v poli cílové adresy CoA adresu MN. V opačném směru je jako zdrojová adresa uvedena CoA, cílová adresa je adresa HA. Druhým způsobem komunikace mezi MN a CN je optimalizace cesty [1], [2], [3]. Optimalizace cesty již vyžaduje na straně CN implementaci protokolu MIPv6 (viz Obrázek 1b). V případě, že MN provede roaming do libovolné cizí sítě, je vazba mobilního uzlu aktualizovaná nejen v HA, ale i v CN. CN má poté informace o CoA příslušející danému MN a data mezi MN a CN jsou potom směrována v síti přímo, bez využití HA. K tomu je využito rozšířeného záhlaví protokolu IPv6, které kromě zdrojové a cílové adresy nese navíc informace o domovské adrese MN. Protokol Mobile IP je protokolem třetí vrstvy referenčního modelu ISO/OSI, který umožňuje uživatelům mobilních služeb (mobilním uzlům) zůstat dostupnými nezávisle na jejich pohybu v prostředí IP. Bez podpory mobility v protokolech IP (IPv4 nebo IPv6) by datový provoz určený mobilnímu uzlu, v případě, že se tento uzel pohybuje mimo svou domovskou síť, nemohl být doručen. Pro zachování stálé dostupnosti by v takovém případě musel mobilní uzel změnit svou IP adresu při každé změně umístění v rámci prostředí IP. To by ovšem mělo za následek rozpad všech spojení transportní vrstvy a všech vrstev vyšších. Protokol Mobile IP umožňuje mobilnímu uzlu pohybovat se mezi jednotlivými IP sítěmi bez změny své domovské adresy. Pohyb mobilního uzlu je díky tomuto protokolu transparentní pro vyšší vrstvy a pakety určené tomuto uzlu pak mohou být v síti směrovány nezávisle na tom, kde se nachází. Protokol Mobile IP je použitelný jak pro zajištění mobility v rámci jednoho přístupového média, tak i napříč různými přístupovými médii (např. Wi-Fi, Bluetooth, UMTS, Ethernet, atd.). 2 Optimalizace cesty v MIPv6 Protokol MIPv6 definuje dva způsoby komunikace mezi mobilním uzlem (MN) a korespondujícím uzlem (CN). První z nich je znám jako obousměrné tunelování (viz Obrázek 1a). Tento způsob komunikace nevyžaduje žádnou podporu MIPv6 na straně CN a pohyb MN je tedy pro něj transparentní. CN využívá pro komunikaci s MN jeho domovskou adresu. Pakety vysílané CN k MN jsou zachyceny domovským agentem (HA) Obrázek 1: Způsoby přenosu dat mezi MN a CN: a) obousměrné tunelování, b) optimalizace cesty 43 1

3 Chce-li CN zaslat data na libovolnou IPv6 adresu, zkontroluje nejprve svou vazební tabulku, jestli se v ní nenachází záznam pro danou adresu. Pokud takový záznam nalezne, použije pro směrování rozšířenou hlavičku protokolu IPv6 (viz výše) a paket odešle na CoA příslušnou danému záznamu. Do rozšířeného záhlaví CN vloží i domovskou adresu MN. MN po přijetí paketu nahradí cílovou adresu (nastavenou na CoA) domovskou adresou z rozšířeného záhlaví, aby byla optimalizace cesty pro aplikaci transparentní. Odesílá-li paket MN, uvede jako zdrojovou adresu svou CoA a do rozšířeného záhlaví vloží vlastní domovskou adresu. CN, který tento paket přijme, pak nahradí zdrojovou IP adresu v podobě CoA domovskou adresou MN uloženou v rozšířeném záhlaví. To zajistí, aby aplikace běžící na straně CN neměla k dispozici informace o pohybu MN. 3 Bezpečnost optimalizace cesty V návrhu zabezpečení pro protokol Mobile IPv6 byly zvoleny různé přístupy pro zabezpečení komunikace mezi mobilním uzlem a jeho domovským agentem a mezi mobilním uzlem a uzly korespondujícími. V případě vztahu MN HA se předpokládá, že jsou si tyto dva prvky již předem navzájem známy, například díky správě administrátora. Oproti tomu existuje silný předpoklad, že mobilní a korespondující uzel nemají předem nic společného, což nevyžaduje žádnou konfiguraci korespondujícího uzlu [4], [5]. Z hlediska bezpečnosti bylo úkolem navrhnout protokol tak bezpečný, jako byl IPv4 internet v době návrhu tohoto protokolu, tedy v letech To znamená existenci malého zabezpečení proti útočníkům, kteří jsou schopni se včlenit mezi korespondující uzel a domovského agenta. Důvod pro tuto skutečnost je ten, že v Internetu roku 2001 byl uzel schopen přerušit, modifikovat nebo odposlouchávat provoz mezi dvěma uzly, byl-li schopen se připojit do komunikační cesty mezi nimi a nebylo-li použito zabezpečení IPsec. I při použití IPsec mohl útočník při nejmenším zahazovat pakety a blokovat tím komunikaci. 3.1 Rizika možnosti útoků Hlavním úkolem útočníka, využívajícího k útoku optimalizaci cesty v protokolu MIPv6, je zfalšovat vazební tabulku korespondujícího uzlu a způsobit tím doručování paketů na nesprávné adresy. To může narušit důvěrnost a integritu přenášených dat a způsobit odmítnutí služby (Denial-of-Service DoS) oběma komunikujícím stranám a také stanici, jíž jsou určeny nevyžádané pakety. Útočník může také zneužít zpráv aktualizace vazby (BU) k vyčerpání prostředků mobilního uzlu, domovského agenta nebo korespondujícího uzlu [5]. Uvažujeme zde pouze aktivní útočníky. To znamená, že pro zfalšování vazební tabulky musí útočník dříve či později vyslat jednu nebo více zpráv. Aktivní útoky jsou pro průměrného útočníka jednodušší, protože v tomto případě může útočník začít vysílat zprávy BU v jakémkoliv čase, zatímco u pasivních útoků musí čekat na vhodné zprávy vyslané koncovými uzly. Cílem útoku může být jakýkoliv uzel nebo síť v Internetu. Existují dva základní typy útoků. Útočník buď odklání, resp. krade, provoz určený či pocházející od daného uzlu, nebo se snaží způsobit DoS cílovému uzlu, popř. síti. Útoky zde uvedené jsou pouze základními druhy útoků. Podrobnější přehled je možno nalézt v [4] Útoky odcizením adresy IP adresy je nejběžnější nebezpečí v protokolu Mobile IPv6. V takovém případě útočník neoprávněně předstírá, že je daný uzel s danou IP adresou a pokouší se odcizit datový provoz určený této dané IP adrese. Tento útok ve své základní podobě vychází z toho, že pokud by zprávy BU nebyly žádným způsobem autentizované, mohl by útočník vysílat klamné BU odkudkoliv z Internetu. Potom by se všechny uzly podporující funkci CN v MIPv6 staly možnými terči útoku. Problém spočívá v tom, že není možné rozeznat, které adresy patří mobilním uzlům, které mohou oprávněně vysílat zprávy BU, a které patří stacionárním uzlům. Díky tomu je kterýkoliv uzel v Internetu napadnutelný, nehledě na to, zda je mobilní či nikoliv. Předpokládejme, že uzel A odesílá pakety uzlu B (viz Obrázek 2). Útočník může přesměrovat pakety na libovolný uzel C tak, že zašle BU uzlu A. Jako domovská adresa bude v této zprávě uvedena adresa uzlu B a adresa CoA bude adresa uzlu C. Jakmile uzel A obdrží tuto zprávu, začne pakety určené uzlu B odesílat na adresu uzlu C. Obrázek 2: Útok odcizením adresy Útočník si může zvolit, zda bude podvržená CoA jeho vlastní adresa, adresa z jeho lokální sítě, nebo jakákoliv jiná adresa. Nastaví-li jako CoA svou vlastní adresu, může přijímat pakety od uzlu A, odesílat na zpět potvrzení a způsobovat tak další škodu. Tímto způsobem může útočník předstírat, že je uzel B a unést tak relaci s uzlem A. Pokud navíc útočník pošle podvržené BU i uzlu B, předstírajíc že je uzel A, vstoupí tak do komunikace mezi ně tzv. útok mužem uprostřed (man-inthe-middle ). Díky tomu je útočník schopen vidět obsah paketů mezi A a B a modifikovat jejich obsah (pokud není aplikována některá z kryptografických metod) Útoky odmítnutím služby (DoS) Základní útok odmítnutí služby spočívá v tom, že útočník pomocí podvržených BU přesměruje veškerý provoz mezi dvěma uzly na náhodné (i neexistující) adresy. Tím naruší komunikaci mezi těmito uzly. Tento druh útoku je velmi významný především proto, že může postihnout kterýkoliv uzel 43 2

4 v Internetu, včetně fixních uzlů infrastruktury, jako např. DNS servery. Dalším druhem DoS útoku je zaplavení. Při takové druhu útoku útočník ví, že mezi uzly A a B existuje velký datový tok a přesměruje tento tok na uzel C, čímž jej zahltí. Uzel A by ovšem v takovém případě brzy přestal data vysílat, protože by mu je uzel B nepotvrzoval. Při promyšlenějším druhu tohoto útoku by se útočník sám choval jako uzel B. Nejprve by sám tento velký datový tok vytvořil a poté by jej přesměroval na uzel C. Útočník by tak mohl i falšovat potvrzení segmentů (např. proto, že by znal počáteční pořadová čísla TCP segmentů). Tímto způsobem by mohl útočník vytvořit několik datových toků, všechny je přesměrovat na uzel C a tím jej zahltit. 3.2 Ochrana proti útokům Zabezpečení optimalizace cesty v protokolu MIPv6 bylo navrženo tak, aby poskytoval úroveň zabezpečení podobnou statickému IPv4 Internetu a zároveň způsobovalo přijatelnou režii v podobě paketů, zpoždění a zpracování v koncových uzlech. Výsledkem ovšem není kryptografický protokol, ale metoda, která ověřuje, že daný mobilní uzel je opravdu dosažitelný jak prostřednictvím svého domovského agenta, tak přímo, pomocí jeho CoA. Tato metoda se nazývá zpětné směrování (Return Routability RR) [4]. Základní mechanizmus zpětného směrování se skládá ze dvou kontrol kontroly domovské adresy a kontroly CoA adresy a následného bezpečného vytvoření vazebního záznamu. Mobilní uzel nejprve vyšle dvě zprávy příslušnému korespondujícímu uzly zahájení kontroly domovské adresy (Home Test Init - HoTI), která je zaslána přes domovského agenta, a zahájení testu CoA adresy (Care-of Test Init - CoTI), která je vyslaná přímo CN (viz Obrázek 3). Jako odpověď na tyto zprávy CN vyšle zprávy Home Test (HoT), jako odpověď na HoTI, a Care-of Test (CoT), jako odpověď na CoTI. Poté, co mobilní uzel obdrží obě tyto zprávy, odešle aktualizaci vazby BU korespondujícímu uzlu. Způsobe sestavení zpráv HoTI, CoTI, HoT, CoT a BU je podrobněji popsán v následujícím textu Kontrola domovské adresy Procedura kontroly domovské adresy v rámci RR je tvořena zprávami HoTI, HoT a následující aktualizací vazby BU. Procedura je na straně CN spuštěna přijetím zprávy HoTI. CN odpoví na zprávu HoTI zprávou HoT, kterou odešle na zdrojovou adresu uvedenou v HoTI. Touto adresou by měla být domovská adresa MN (HoA), a tím pádem se předpokládá, že HoT bude tunelována k MN přes HA. HoT obsahuje kryptograficky generovaný token, tzv. home keygen token (HKT), který tvořen výpočtem hashovaní funkce z klíče korespondujícího uzlu K cn, zdrojové adresy zprávy HoTI a jedinečného čísla nonce [4]. 0 Ve zprávě HoT je také vložen identifikátor nonce, díky kterému CN později patřičné nonce snáze identifikuje. Náhodné číslo nonce je tajné a je generováno s platností pro určitý interval. Z toho důvodu musí být indexováno. HKT umožňuje korespondujícímu uzlu rozpoznat, že zpráva BU, kterou následně přijme, byla vytvořena uzlem, který přijal zprávu HoT Kontrola Care-of adresy Kontrola Care-of adresy je ve své podstatě podobná kontrole domovské adresy. Rozdíl je v tom, že jako zdrojová adresa zprávy CoTI je uvedena CoA mobilního uzlu. Dále, token pro kontrolu CoA (Care-of keygen token - CKT) je vytvořen poněkud odlišným způsobem, aby nebylo možno jej zaměnit s tokenem pro kontrolu domovské adresy (HKT). Hash pro vytvoření CKT je vypočten z klíče korespondujícího uzlu, CoA mobilního uzlu a nonce [4] Bezpečné vytvoření vazebního záznamu Poté, co mobilní uzel přijme obě zprávy HoT a CoT, vytvoří vazební klíč K bm tak, že vypočítá hash spojených tokenů HKT a CKT. Obrázek 3: Tok dat metody zpětného směrování Tento klíč je poté použit pro zabezpečení zpráv BU po dobu, po kterou zůstává klíč v platnosti. Je ovšem nutno poznamenat, že klíč K bm je dostupný všem, kteří dokáží odposlechnout obě zprávy HoT i CoT. Tyto dvě zprávy jsou ovšem přenášeny v síti různými cestami, mezi MN a HA je HoT navíc přenášena šifrovaným tunelem. Je proto málo pravděpodobné, že by byl útočník schopen zachytit obě tyto zprávy. Korespondující uzel zůstává bezestavovým až do chvíle, kdy přijme aktualizaci vazby BU. To znamená, že CN neudržuje žádné záznamy o zprávách HoT a CoT, které vyslal. Tím předchází případným DoS útokům, protože nespotřebovává žádnou paměť pro vyslané HoT a CoT. Díky tomu ovšem musí BU obsahovat dostatek informací, aby mohl CN vytvořit relevantní vazební záznam. BU obsahuje zdrojovou IP adresu tj. CoA mobilního uzlu, domovskou adresu mobilního uzlu, identifikátory nonce a autentikační kód zprávy (Message Au- 43 3

5 thentication Code - MAC). MAC slouží k autentizaci zprávy BU výpočtem MAC funkce nad CoA, adresou CN, a vlastní zprávou BU. K tomu je použito klíč K bm. Po přijetí BU korespondující uzel znovu vytvoří tokeny HCT a CKT. K tomu použije domovskou adresu MN, jeho Care-of adresu, indexy použitých nonce a klíče Kcn. Z těchto tokenů CN vytvoří potřebný klíč K bm, pomocí kterého ověří MAC umístěný v BU a tím i autentičnost celé zprávy BU. 4 Závěr Tento článek shrnuje dostupné poznatky o zabezpečení optimalizace cesty v protokolu Mobile IPv6. Optimalizace cesty představuje velmi významný mechanizmus, který snižuje koncové zpoždění dat přenášených mezi uzly využívající protokol Mobile IPv6, a zároveň snižuje i zatížení domovské sítě mobilního uzlu, pohybuje-li se tento uzel mimo domovskou síť. Toho je dosaženo zainteresováním korespondujícího uzlu do protokolu Mobile IPv6. Při pohybu mimo domovskou síť pak mobilní uzel provádí aktualizaci vazby nejen u svého domovského agenta, ale i u všech uzlů, se kterými komunikuje. Díky tomu s nimi pak může komunikovat přímo, bez tunelování přes domovského agenta. Tato metoda ovšem představuje značná bezpečnostní rizika spočívající ve zneužití aktualizace vazby zasílané korespondujícím uzlům. Z toho důvodu je třeba tyto zprávy zabezpečit tak, aby korespondující uzel mohl ověřit, že aktualizace pochází opravdu od mobilního uzlu, se kterým komunikuje. Toho je dosaženo použitím metody zpětného směrování, kterou si korespondující uzel ověří, že daný mobilní uzel je dosažitelný jak pomocí své domovské adresy, tak pomocí příslušné Care-of adresy. Literatura [1] JOHNSON, D. B., PERKINS, C. E., ARKKO, J. Mobility support in IPv6. The Internet Engineering Force Task RFC 3775, June 2004 [2] RAAB, S.. Cisco: Mobilní IP technologie a aplikace, Grada, 2007, 299 s., ISBN: [3] SKOŘEPA, M. Route optimization in Mobile IPv6 protocol. In Proceedings of the 31th International Conference Telecommunications and Signal Processing p ISBN [4] NIKANDER, P., ARKKO, J., AURA, T., MONTENE- GRO, G. Mobile IP Version 6 Route Optimization Security Design Background. The Internet Engineering Force Task RFC 4225, December 2005 [5] NIKANDER, P., ARKKO, J., AURA, T., MONTENE- GRO, G. Mobile IP version 6 (MIPv6) Route Optimization Security Design. In Proceedings of the IEEE 58th Vehicular Technology Conference, 2003, Fall 2003, p ISBN