Mérési útmutató a Mobil Távközlési és Informatikai Laboratórium méréseihez
Mobile IPv6 Route Optimization (MIPv6-RO) mérés
Mérés helye: Híradástechnikai Tanszék Mobil Távközlési és Informatikai Laboratórium (MCL) I.B.113. Összeállította: Schulcz Róbert Nagy Domonkos Utolsó módosítás: 2006. november 14.
9/1
Mobile IPv6 Route Optimization elméleti áttekintés
Bevezetés A Mobil IPv6, csak úgy mint az elődje azért lett kialakítva, hogy egy Mobile Node (MN) bárhol használhassa az otthoni IP címét. Ennek eléréséhez szükség van egy Home Agent-re (HA), ami a MN távollétében számon tartja a MN aktuális hálózati helyét, és a csomagokat átirányítja az aktuális címre, amit Care-of-Address-nek (CoA) nevezünk. Ha a MN messze van a HA helyéhez képest, akkor nagy overhead-et okozna, ha a csomagokat a HA érintésével háromszögelve küldenénk a Correspondent Node (CN) és a MN között. Ezért a CN bejegyezhet egy Binding-et (kötés), mely összerendeli a MN otthoni címét a CoA címmel. Így a csomagok közvetlenül mehetnek a CN és a MN között, amit Route Optimization-nek (RO) nevezünk. Ez persze azon túl, hogy nagyban csökkentheti a csomagok kézbesítési költségét, sajnos biztonsági kockázatot is jelent. Hiszen ha egy rosszindulatú felhasználó téves Binding bejegyzéseket képes létrehozni más hostokon, akkor könnyen eltérítheti egy legális felhasználónak szánt csomagokat vagy DoS támadást hajthat végre egy csomópont ellen az eredetileg nem neki szánt üzenetek odairányításával. A MIPv6 biztonságának kialakításakor az end-to-end alapelvet vették figyelembe, ezért a mobilitási állapotot a HA határozza meg, de a CN-nak is van soft mobilitási állapota. A MIPv6 úgy lett kialakítva, hogy a biztonság ne legyen rosszabb a jelenlegi IPv4 biztonságánál. Különböző megközelítést alkalmaztak a különböző kapcsolatok között. A MN és a HA között feltételezhető, hogy ismerik egymást, és előre megegyeztek bizonyos biztonsági paraméterekben, de a MN és a CN között nincs semmilyen előre kiosztott információ. A MIP-nek képesnek kell lennie, hogy a MN és a CN akkor is fenntartson egy szállítási rétegbeli viszonyt (TCP vagy UDP), ha a MN közben megváltoztatja az IP címét. Az alap ötlet, hogy a HA egy fix helyű proxy-ként működjön a MN számára. Ha a MN nincs otthon, akkor a HA elfogja a MN-nak szánt üzeneteket, és alagúton keresztül továbbítja a MN CoA címére. Ilyenkor a szállítási réteg a MN Home Address (HoA) címét használja a csomagok kézbesítésekor. Az alap megoldásban szükség lenne a folyamatos alagúton való továbbításra, ami jelentős teljesítmény visszaesést okozna. Ezért alakították ki a RO lehetőséget, ahol a MN Binding Update (BU) üzenetekben elküldi a CoA címét a CN-nak. Az RO alatt a CN logikailag az első router szerepét is betölti, hiszen már helyben átalakítja a HoA címet a CoA címre.
9/2
Veszélyek Ahogy azt már a bevezetésben is említettük, ha egy rosszindulatú felhasználó téves Binding bejegyzéseket képes létrehozni más hostokon, akkor könnyen eltérítheti egy legális felhasználónak szánt csomagokat vagy DoS támadást hajthat végre egy csomópont ellen az eredetileg nem neki szánt üzenetek odairányításával. Ehhez a támadónak mindenképpen aktívnak kell lennie, mert a Binding bejegyzések meghamisításához előbb utóbb be kell avatkoznia a hostok közötti kommunikációba.
Címlopás Ebben az esetben a támadó megpróbálja a MN HoA címére küldött csomagokat átirányítani egy általa felügyelt címre. Sok változata létezik, de itt csak az alap verzióval foglalkozunk. Ha nem volna semmilyen azonosítás a MN és a CN között, akkor egy támadó bármikor bárhonnan küldhetne hamis BU üzenetet a RO funkcióra alkalmas CN-nak. Ráadásul, ha a támadó a hamis CoA címet a saját hálózatából választja, akkor nem csak az elterelt forgalom fogadására lesz képes, hanem válaszolhat is az üzenetekre a hamis CoA címet használva. Egy bonyolultabb változatban a támadó mind a két félnek küldhet BU üzeneteket, és így a kommunikációt nem szakítja meg, csak beékeli magát a két fél közé, mint men-in-themiddle támadó. Így teljes kontroll alá vonhatja a két fél közötti kommunikációt, és könnyen módosíthat, elnyelhet vagy generálhat üzeneteket.
DoS támadás A DoS támadásnál vagy magát a MN-ot támadják meg, vagy egy csomópontra irányítják egy vagy több node forgalmát, amellyel akár teljesen megbénítható a támadás alatt lévő csomópont kommunikációja. Az első esetben a támadó két node között hamis BU üzenetekkel képes a csomagokat elirányítani egy random vagy egy nem létező címre, ezzel ellehetetlenítve közöttük a kommunikációt. Ez a támadás különösen veszélyes, mert statikus node-ok ellen is alkalmazható. Például egy DNS szerver is megbénítható vele. A második esetben a támadó hamis BU üzenetekkel irányított forgalommal árasztja el az áldozatot, ami a nem neki szánt csomagok tömkelegétől teljesen megbénulhat. A támadás nem csak egy csomópont, hanem egy hálózat ellen is alkalmazható, ha a hálózat egy vagy több tagját elárasztják az eredetileg nem oda küldött üzenetek. A támadás legegyszerűbb módja, ha a támadó tudja, hogy két csomópont között nagy adatforgalom van, és ezt irányítja át egy harmadikra, de ekkor gyorsan megszakad a két fél között a kapcsolat az ACK üzenetek hiánya miatt. Ennek elkerülésére a támadó feliratkozhat egy adatfolyamra (pl: video stream), és ezt átirányíthatja az áldozat címére. Így még ACK üzeneteket is képes küldeni, hogy ne szakadjon meg a kommunikáció.
9/3
A Route Optimization (RO) védelme A MIPv6 RO biztonsági mechanizmusát úgy alakították ki, hogy teljesen kiküszöböljék, vagy nagyban csökkentsék a jelenleg ismert veszélyek előfordulását. A cél az volt, hogy a statikus IPv4 biztonsági szintjét elérjék, és az ez által okozott overhead mértéke ne emelje meg túlzottan a csomagok kézbesítési költségét. Ennek eredménye nem egy hagyományos kriptográfiai protokoll lett. A tervezők feltételezik, hogy a routing infrastruktúra nem korrupt, és kihasználják, hogy egy megfelelően működő MN egyszerre elérhető a CoA és a HoA címén is. Továbbá a CN-ban felvett állapot csak pár percig érvényes.
Return Routability (RR) A RR azon alapul, hogy a node ellenőrzi van–e a megadott IP címen egy az általa küldött üzenetekre válaszolni képes csomópont. Ha az ellenőrzés nem sikerül, akkor vagy a routing infrastruktúra hibás vagy egy támadó zavarja a megfelelő kézbesítést. Ha viszont az ellenőrzés sikeres, akkor feltételezzük, hogy a megadott címen tényleg van egy node, aki fent akarja majd tartani a kapcsolatot. Az eljárás a HoA és a CoA ellenőrzéséből áll. Mind a két esetben először a Binding-et kezdeményező MN küld egy Home Test Init (HoTI) és egy Careof Test Init (CoTI) üzenetet a CN-nak, amellyel elindítja a Bindig létrehozásának folyamatát. A HoA ellenőrzés egy Home Test (HoT) üzenetet használ. A HoT csomagot a HA alagúton továbbítja a MN felé. A HoT egy kriptográfiailag előállított Home Keygen Token-t tartalmaz, amit egy hash függvénnyel generál a CN. A függvény konkatenálva kapja meg a CN titkos kulcsát, a HoTI (HoT Init) csomag forrás címét és egy nonce értéket: Home token = hash (Kcn | forrás cím | nonce | 0) A nonce indexe is belekerül a HoT csomagba, hogy a CN könnyebben kikereshesse majd a feldolgozásnál. A HoT üzenet először a CN és a HA között nyíltan van elküldve, tehát itt bárki megismerheti a tartalmát. Majd a HA továbbítja a MN-nak egy IPsec ESP által védett alagúton. A CoA ellenőrzés (CoT üzenet) a CN szempontjából nagyon hasonló az előzőhöz, csak itt nem a HoA-re hanem a CoA címre küldi a csomagot, és a hash bemenetének végén 1 szerepel a 0 helyett: Care-of token = hash (Kcn | forrás cím | nonce | 1) Ezzel biztosítjuk, hogy egyik token felhasználásával se lehessen előállítani a másikat. Ez a csomag végig nyíltan van továbbítva, ezért az út teljes hossza alatt fent áll a lehetősége a lehallgatásnak. Ha a MN megkapta a HoT és a CoT üzenetet is, akkor kiszámolja a Binding kulcsot, azaz a két token konkatenáltjának hash értékét: Kbm = hash (home token | care-of token)
9/4
Ezt a kulcsot használják majd a BU üzenetek hitelesítésére egészen addig, amíg érvényét nem veszti. Az üzenetek elküldéséből adódik, hogy egy támadó is előállíthatja a kulcsot, ha le tudja hallgatni a CoT és a CN és a HA között kézbesítendő HoT üzenetet, mert ezek teljesen nyíltan továbbítódnak.
A CN állapot nélküli marad, amíg nem érkezik meg az első BU. A DoS támadás erősségét gyengíti, hogy a HoTI és CoTI üzeneteket a CN-nak nem kell tárolnia, ezért a memória nagy elárasztás esetén sem telik be. Ha megérkezik az első BU, akkor a CN-nak el kell döntenie, hogy a MN tényleg létezik, és megkapta a HoT és COT üzeneteket vagy sem. Mivel a CN a kezdő állapotában van, amikor az első BU megérkezik, ezért a BU üzenetnek elég információt kell tartalmaznia egy legális állapot kialakításához. Az információk birtokában a CN pár memóriaolvasással és hash számolással előállítja a szükséges Kbm kulcsot, amivel ellenőrizheti a BU eredetét és hitelességét igazoló MAC értéket. Ezt a Kbm kulcsot fogják használni a nodok, amíg a MN nem változtatja meg a helyét vagy az egyik token élettartalma le nem jár.
Gyors lejáratú Binding-ek Egy Binding cache bejegyzés a HoT és CoT üzenetek elküldésekor lévő RR állapotot mutatja. Ha a HoT üzenet nagyon hosszú vagy végtelen érvényességű, akkor a támadónak lehetősége nyílhat egy Time Shifting támadásra jóval az üzenetek lehallgatása után is. Ennek kiküszöbölésére a Kbm kulcs korlátos ideig használható, ezért egy támadó egy megszerzett kulccsal csak korlátos ideig képes BU üzeneteket küldeni és Binding cache bejegyzéseket fenntartani. A gyors lejáratú Binding hátránya az overheaden kívül még az is, hogy a HA a rendszer single-point-of-failure tagja lesz.
9/5
Mérési környezet
A mérések elvégzéséhez az OMNeT++ szimulációs környezetben [3] megírt MIPv6 Route Optimization-t [1] [2] megvalósító programot kell használni. Ennek futtatásához a RO.exe fájlt kell elindítanunk. A program induláskor az alábbi paramétereket adhatjuk meg: -
Select network Ez a paraméter mindig az alapértelmezettel megegyező Route_Opt éték lesz.
-
Route_Opt.MN.update Ezzel a számmal adhatjuk meg, hogy a MN milyen gyakran kezdeményezzen kapcsolat frissítést. Mértékegysége: ms. Ha az adott feladat nem határozza meg külön, akkor 10 000-et, azaz 10 másodpercet kell megadni.
-
Route_Opt.Internet.maxDelay Itt lehet megadni, hogy a csomagok az Interneten való továbbítás közben maximálisan mennyit késsenek. Mértékegysége: ms. A késleltetések egyenletes eloszlással a maximum érték és annak tizede között helyezkednek el. Ha az adott feladat nem határozza meg külön, akkor 1000-et, azaz 1 másodpercet kell megadni.
-
Route_Opt.Internet.losingChance Ezzel a 0 és 100 közötti számmal adható meg, hogy hány százalékban vesszenek el a protokoll csomagjai az Internet csomópontban. Az adat csomag ettől függetlenül a szimuláció során soha sem veszhet el. Ha az adott feladat nem kéri külön, akkor nullára kell állítani a mérés során.
A program futása alatt a frissítéshez szükséges és a frissítések közötti időt lehet grafikusan megtekinteni. Mindkét adathalmazhoz két-két grafikon tartozik, ahol az utolsó pár értéket vagy az adatok eloszlását lehet megjeleníteni. Ehhez a Route_Opt/CN alatt kell az alábbi objektumok egyikét megnyitni: -
updateFrequency Ez a grafikon jeleníti meg a frissítések között eltelt utolsó néhány idő értéket.
-
updateFrequencyStats Itt tekinthetjük meg a frissítések között eltelt időközök statikus eloszlását.
-
updateTime Ez mutatja az utolsó néhány frissítéshez szükséges idő értéket.
-
updateTimeStats Itt láthatjuk a frissítési idők statikus eloszlását.
Az eloszlás grafikonok vizsgálatához a mérés során 100 000 kötésfrissítést kell lefutatni, amihez érdemes az Express módot használni. 9/6
A szimuláció végén megtudhatjuk a minimális, maximális és átlagos kötésfrissítési és kötések közötti időket. Továbbá megjeleníthetjük az összes sikeres és félbehagyott frissítést és az összes elveszett üzenet számát, ha meghívjuk a Finish() függvényt. A Finish() függvényt ikonnal hívhatjuk meg a főablakból. Ha viszont már egyszer meghívtuk, akkor az adott szimulációt nem folytathatjuk tovább. Az Internet csomópont kapuinak sorszáma és a csomagok címzett és feladó mezője is az alábbiak szerint van számozva:
Irodalom jegyzék
[1] Mobile IP version 6 (MIPv6) Route Optimization Security Design http://research.microsoft.com/users/tuomaura/Publications/nikander+-vtc2003f.pdf
[2] Mobile IP version 6 Route Optimization Security Design Background (RFC 4225) http://www.ietf.org/rfc/rfc4225.txt
[3] OMNeT++ http://www.omnetpp.org/
[4] OMNeT++ bevezető mérés http://kutfo.hit.bme.hu/oktatas/omnetbev.pdf
[5] Mobil IP OMNeT++ szimulációs mérés http://kutfo.hit.bme.hu/oktatas/MOBILIP.pdf
9/7
Ellenőrző kérdések
1. Hol és milyen üzeneteknél használ a MIP-RO protokoll titkosítást a vezérlő üzenetek küldésekor? 2. Mi a fő célja a MIP-RO protokollnak? 3. Milyen előre kiosztott közös titkok szükségesek a MN és a CN között? Mire szolgálnak ezek? 4. Miért nem lehet a MN környezetében egyszerű lehallgatással kijátszani a MIP-RO protokollt? 5. Okoz–e fennakadást az adatforgalomban, ha a kapcsolat kiépülése után a HA meghibásodik? Miért? 6. Bevezet–e a MIP-RO valamilyen protokoll specifikus titkosítást az adat csomagok védelmére? Ha igen, akkor mi a neve az eljárásnak? 7. Milyen nem DoS támadás képzelhető el a MIP-RO protokoll kijátszásával? 8. Milyen DoS támadások képzelhetők el a MIP-RO protokoll kijátszásával?
9/8
Mérési feladatok
1. Mi történik a szimulációban, ha a MN az init csomagokat előbb indítja el, minthogy az előző frissítés HOT üzenete megérkezett volna? 2. Jelenítse meg a négy elérhető grafikont futás közben 5% csomagvesztés esetén. Az updateTime grafikont állítsa be úgy, hogy csak a 2,5 és 3,5 sec közötti értékeket jelenítse meg pontokkal. Mind a négy grafikont másolja be a jegyzőkönyvbe! Értelmezze az eloszlás grafikonok jellegét! A két eloszlás grafikonon melyik időintervallumba esett a legtöbb üzenet? Pontosan hány üzenet esett bele? Mennyi volt a kötésfrissítéshez szükséges minimális, maximális és átlagos idő? Mennyi volt a kötésfrissítések közötti minimális, maximális és átlagos idő? Hány vezérlő üzenet veszett el, míg a kapcsolat 100 000 alkalommal frissült? 3. Csomagvesztés nélkül mennyi időnként kell kezdeményezni a kötésfrissítést, ha csak az esetek 50%-ban szeretnénk, hogy a protokoll sikeresen fusson le? Mennyi idő kellene 99%-hoz? Írja le mi alapján becsülte az értékeket, majd ellenőrizze, és méréssel finomítsa 1-2% pontosságúra! A végleges eredményeknél jegyezze fel a kötésfrissítések közötti átlag időket is! Mennyi időre lenne minimum szükség, hogy a protokoll mindig sikeresen fusson le? 4. Csomagvesztés nélkül és 10%-os csomagvesztés esetén is adja meg úgy a frissítési időt, hogy az átlagos frissítések között eltelt idő 10 másodperc legyen! Írja le, hogyan becsülte meg az időket, és ha szükséges finomítsa őket mérésekkel! Csomagvesztéses esetben hány csomag veszett el 100 000 sikeres frissítés alatt? Ebben az esetben mennyi volt a minimum és maximum idő két frissítés között?
9/9
