1. GİRİŞ

Günümüzde kablosuz ağ yatırımları ve kablosuz ağlar üzerinde yapılan araştırmalar hızla yükselmektedir. Kablosuz ağ bağlantılarının giderek normalleştiği yaşantımızda, son kullanıcılar artık kesintisiz ve ucuz kablosuz ağ bağlantısı beklentisindedir.  Bu ihtiyacı karşılamak için ise kablosuz ağlar arasında hızlı dolaşım imkanı sağlayacak sistemlerin dizaynı ve kullanımı gerekmektedir. Mobil IPv4 bu ihtiyaç doğrultusunda geliştirilmiş, IETF tarafından standartlaştırılmış bir protokoldür [1]. Bu bildirinin konusu Mobil IPv4 olduğundan, bildiri boyunca Mobil IP, Mobil IPv4’u anlatmak için kullanılacaktır.

Bir sabit IP (home address) ve bir geçici IP (care-of address) arasında tünelleme yaparak konuşulmasını sağlayan Mobil IP protokolü, kullanıcının herhangi bir ağ üzerinden internete çıkabildiği durumlarda kendine gelen mesajları alıp cevap verebilmesini sağlar.

Kullanıcıların ve servis sağlayıcıların anahtar dağıtımını düzenleme, muhasebe bilgilerini tutma ve hali hazırdaki yapılarına uyumlu olabilmeleri için AAA protokollerinin Mobil IP ile beraber kullanımına ihtiyaç duyulmuştur. Bu ihtiyaçlar doğrultusunda AAA protokollerinden beklenen uyumluluk belirlenmiş [2] ve  RADIUS [3], DIAMETER [4] protokollerine bu ihtiyaçlara uygun düzenlemeler önerilmiştir [5,6].

Bu düzenlemeler sayesinde kullanıcıların ve servis sağlayıcıların ihtiyaçları karşılansa da bu entegrasyon yeni oturum açma zamanında kritik bir uzamaya  neden olmuştur. Özellikle hızlı ve kesintisiz kablosuz ağ dolaşımı için kritik bir öneme sahip olun bu sureyi kısaltmak için bir çok çözüm önerilmiştir. Bu bildiride ki çözüm, bu sorunun ana gerekçelerini ortadan kaldırmayı hedeflemektedir. RFC 2977 [2] de açıklandığı üzere ilgili gecikmenin temel nedenlerinden biri uzak ağlar arası konuşma suresidir. AAA, özellikle RADIUS sistemlerinde önerilen düzenlemeler ve entegrasyon ile bu konuşmaların sayısı artmış ve buda oturum açma suresine yansımıştır. Bu bildirideki amacımız var olan protokollerin yapısını bozmadan, gerekli şartları tanımlayarak uzak ağlar arası konuşmaların sıralı değil, paralel yapılmasını sağlayarak oturum açma suresindeki gecikmeyi azaltmaktır.

Bildirin geri kalanı şu şekilde organize edilmiştir; Bolum 2 de geri plan bilgisi olarak Mobil IP, Mobil  IP-RADIUS yapıları anlatılmıştır. Bolum 3 de önerilen çözüm sunulmuştur. Bolum 4 de analitik performans analizi gösterilmektedir. Bolum 5, sonuç kısmıdır. Burada analitik modelin eksiklikleri ve ölçeklenebilirlik ihtiyacı tartışılmış ve gelecek çalışmalar anlatılmıştır. 6. bölümde referans verilen kaynakları bulmak mümkündür

2. Geri Plan Bilgisi

Bu bolümde Mobil IP ve Mobil IP-RADIUS protokolleri ile ilgili bilgi sunulacaktır. Önerimizi açıklamadan önce hali hazırdaki sistemi inceleyerek, ilgili protokollerdeki dialoglari not ediyor olacağız. Daha sonra, bir sonraki bolümde, bu dialoglarin sırasında önerdiğimiz değişikliği göstereceğiz.

A. Mobil IP

Mobil IP, kullanıcıların IP adreslerini değiştirmeden, örneğin farklı ağlar arasında dolaşırken, aynı ip adresi üzerinden konuşmalarını sağlamak için tasarlanmış bir yapıdır. Çalışma prensibi özünde basit bir tünelleme yapısı içerir. Kullanıcı farklı ağlarda aldığı ipsini ana merkeze bildirir ve ana merkez kendisine gelen paketleri bu IP’ye doğru tüneller. Kullanıcının dışarı duyurduğu sabit ip aslında ana merkezdeki ipsidir.

Protokole daha detaylı bakarsak Şekil 1 de gözüken iletişimi elde ederiz. Dış Kullanıcı (Host) Mobil Kullanıcı’mızla (Mobile Node - MN) konumsak istediğinde paketleri kullanıcımızın sabit IP’sine (Homa Address - HoA) gönderir. Burada paketleri karşılayan Evdeki Aracı (Home Agent - HA), Mobil Kullanıcın şuan nerede olduğuna bakarak (Care-of Address - CoA), varsa aradaki Yabancı Aracı’ya (Foreign Agent - FA), yoksa direk Mobil Kullanıcı’ya gelen paketleri tüneller yani enkapsüle edip gönderir. Paketleri alan Yabancı Aracı veya Mobil Kullanıcı paketleri tünelden çıkarır. Yabancı Aracı paketleri açtıktan sonra Mobil Kullanıcıya göndermekle sorumludur. Orijinal Mobil IP protokolünde varlıkları zorunlu olamasa da, Yabancı Aracı’lar ağ erişimini denetlenmesi, Mobil Kullanıcılara IP dağıtılması veya NAT’lama yapılması gerektiği durumlarda yani çoğu zaman kullanılmaktadır.

Host= Dış Kullanıcı, HA= Evdeki Aracı, FA=Yabancı Aracı, MN= Mobil Kullanıcı, HoA=Sabit IP, CoA= Geçici IP

Şekil 1.  Mobil IP protokolünde kullanıcılar arası iletişim.

Mobil Kullanıcı gelen paketlere cevap göndermek istediğinde 2 seçeneği vardır. Paketler tekrar tünellenip Evdeki Aracı’ya gönderilebileceği gibi, direk gönderene de yollanabilir. Direk gönderene göndermesi durumunda, cevap tanınmayan bir yerden gelmiş olacağı için Dış Kullanıcı’nın gönderene güvenmesi gerektiği durumlarda sorunlar çıkacağı aşikardır. Şekil 1 de gösterilen yapıda Mobil Kullanıcı paketlerini Evdeki Aracı’ya göndermeden direk Dış Kullanıcıya göndermektedir.

HA= Evdeki Aracı, FA=Yabancı Aracı, MN= Mobil Kullanıcı, RRQ=Kayıt Talebi, RRP=Kayıt Cevabı

Şekil. 2.  Mobil IP oturum açma

Mobil Kullanıcı yeni bir ağa dahil olmak istediğinde bu ağa dahil olmak istediğini Evdeki Araci’ya bildirmesi gerekmektedir (bakınız Şekil 2). Mobil Kullanıcı ilgili Kayıt Talebi’ni (Registration Request - RRQ) yaratarak Yabancı Aracı’ya bildirir. Yabancı Araci bu talebi isleyerek ilgili Evdeki Aracı’ya gönderir. Evdeki Aracı gelen talepteki bilgileri daha önceden Mobil Kullanıcı ile arasında oluşturulmuş güvenlik ilişkisini kullanarak kriptolojik olarak inceler. Gönderilen bilgiler doğrultusunda Mobil Kullanıcın doğruluğu tespit edilir ve buna göre Geçici IP’si değiştirilir veya değiştirilmez. Sonucu bildirmek için Yabancı Aracı’ya Kayıt Cevabı yollanır (Registration Reply - RRP). Yabancı Aracı kayıt cevabini işler ve Mobil Kullanıcı’ya iletir.

Böylece, Mobil IP’nin orijinal çalışma prensibini göstermiş olduk. Bir sonraki kısımda Mobil IP iletişime RADIUS entegre edildiğinde nasıl bir yapı oluştuğunu  açıklıyor olacağız.

B. Mobil IP ve RADIUS

RADIUS’un Mobil IP sisteminde kullanım nedenlerinden bazıları var olan sistemlere entegrasyon, anahtar dağıtımında kolaylık, kullanıcı kimlik doğrulaması olarak gösterilebilir. RADIUS entegre edilmiş Mobil IP ile servis sağlayıcıların hali hazırdaki AAA sistemleri kullanılabilir olmaktadır. Bu sistemlerle Yabancı Aracı - Evdeki Aracı, Mobil Kullanıcı - Evdeki Aracı arasındaki güvenlik ilişkileri kurulu değilse hali hazırdaki Yabancı AAA Sunucu (Foreign AAA server - FAAA) -Evdeki AAA Sunucu (Home AAA server - HAAA) arasındaki ve Mobil Kullanıcı – Evdeki AAA Sunucu arasındaki güvenlik ilişkisi kullanılarak, talep edildiği zamanlarda üretilmesi mümkün olmaktadır.

HA= Evdeki Aracı, FA=Yabancı Aracı, MN= Mobil Kullanıcı, FAAA=Yabancı, AAA Sunucu, HAAA=Evdeki AAA Sunucu, RRQ=Kayıt Talebi, RRP=Kayıt Cevabı, AReq.=Erişim Talebi, ARep=Erişim Cevabı

Şekil. 3.  Mobil IP ve RADIUS seri iletişimi

RADIUS iletişimi Yabancı Aracı Mobil Kullanıcıdan Kayıt Talebi aldığında başlar (bakınız Şekil 3). Yabancı Aracı Mobil Kullanıcın kimliğini doğruladıktan ve gerekiyorsa ilgili anahtarları aldıktan sonra normal Mobil IP konuşmasına devam ederek Evdeki Aracı’ya Kayıt Talebi gönderir. Evdeki Aracı Evdeki AAA Sunucu ile konuşarak ilgili kimlik doğrulamasını ve gerekiyorsa anahtarları alarak bir Kayıt Cevabi oluşturarak Yabancı Aracıya gönderir. Yabancı Aracı bu cevabı işleyerek Mobil Kullanıcı’ya iletir.

Yabancı Aracı ile AAA sistemi arasındaki iletişim su şekilde isler, Yabancı Aracı kullanıcı doğrulamak ve ilgili anahtarları lazımsa almak için kendiyle ilişkili olan (genel olarak yakınında bulunan) Yabancı AAA Sunucu’ya bir Erişim Talep (Access Request - AReq) mesajı yollar. Yabancı AAA Sunucu kendinde, örneğin daha önceki bir sorgulamadan dolayı önbelleğinde, gerekli bilgiler olması durumunda bir Erişim Cevap (Access Reply - ARep) mesajı yaratarak Yabancı Aracı’ya iletir. Şekil 3’te anlatılan durumda ise Yabancı AAA Sunucu’nun bu bilgiye sahip olamaması durumunda aracı konuma geçerek ilgili Kayıt Talep mesajını Evdeki AAA Sunucu’ya ondan gelecek cevabı da Yabancı Aracı’ya ileteceği gösteriliyor.

Buraya kadar, var olan sistemler hakkında bir hatırlatma yapmış olduk. Bir sonraki bolümde önerilen sistemin detayları yer alacaktır.

3. Önerilen Çözüm

Önerdiğimiz yapı var olan hiçbir iletişimi kaldırmamaktadır. Bir önceki bölümde değinilen 10 adımlık Mobil IP ve AAA konuşması burada da mevcuttur. Önerilen sistem bu konuşmaların bazılarını paralel yapılmasını içermektedir. Şekil 4 üzerinden gidersek, bu paralellik 2. adımda, Yabancı Aracı’nın Mobil IP kayıt adımlarına (2-a) başlamadan önce Erişim Cevabı (ARep) beklememesi ile baslar. Burada cevaplanması gereken kritik bir soru vardır. Bu noktada Yabancı Aracı’nın AAA konuşmasını beklemeden Mobil IP konuşmasına başlaması protokollerin kurallarını bozar mı. Cevap hayırdır. Çünkü özünde Mobil IP ve RADIUS birbirinden bağımsız protokollerdir. Burada bağımlılığa neden olacak ihtiyaç Yabancı Aracı ile Evdeki Aracı arasında güvenlik ilişkisinin olmaması ve bu iliksinin kurulması için AAA konuşmaları ve kriptolojik işlemlere ihtiyaç duyulmasıdır. Bizim çalışmamızın varsayımı Yabancı Aracı ile Evdeki Aracı arasında güvenlik ilişkisinin hali hazırda var olabileceğidir.

HA= Evdeki Aracı, FA=Yabancı Aracı, MN= Mobil Kullanıcı , FAAA=Yabancı, AAA Sunucu, HAAA=Evdeki AAA Sunucu, RRQ=Kayıt Talebi, RRP=Kayıt Cevabı, AReq.=Erişim Talebi, ARep=Erişim Cevabı

Şekil. 4.  Paralel RADIUS ve  Mobil IP iletişimi

Bu paralel konuşmalarda gönderilen ve alınan paketler 2. Bolümde anlattığımız gibidir. Tek farkı sıralamadır. Böylece akış aşağıdaki gibi olur;

(1) Mobil Kullanıcı, Yabancı Aracı’ya Kayıt Talebi yollar.
(2-a) Yabancı Aracı, Kayıt Talebi’nden aldığı data ile, bir RADIUS Erişim Talebi yaratıp Yabancı AAA Sunucu’suna gönderir.
(2-b) Paralelinde, Yabancı Aracı Kayıt Talebi  yaratıp Evdeki Aracı’ya gönderir.
(3-a) Eğer Yabancı AAA Sunucu’nun elinde Mobil Kullanıcı ile bilgi yoksa, Yabancı AAA Sunucu gelen talebi Evdeki AAA Sunucu’ya yollar.
(3-b) Paralelinde, Kayıt talebi kendine ulaştığında, Evdeki Aracı Mobil Kullanıcı’nın kimliğini doğrulamak ve gerekli anahtarları ve anahtar yaratıcı datayı almak için erişim talebini  Evdeki AAA Sunucu’ya yollar.
(4-a) Evdeki AAA Sunucu Mobil Kullanıcı‘nın kimliğini doğruladıktan sonra Erişim Cevabı’nı hazırlayıp Yabancı AAA Sunucu’ya gönderir.
(4-b) Paralelinde, Evdeki AAA Sunucu ilgili Erişim Cevabini  Evdeki Aracı’ya gönderir.
(5-a) Yabancı AAA Sunucu kendine gelen Erişim Cevabi’ni  Yabancı Aracı’ya iletir.
(5-b) Paralelinde, Evdeki Aracı Kayıt Cevabi’ni  hazırlar ve Yabancı Aracı’ya gönderir.
(6) Gelen cevaplara göre, Yabancı Aracı Kayıt Cevabı’nı hazırlar ve Mobil Kullanıcı’ya gönderir.

Bu yapı eğer Mobil Kullanıcı Evdeki AAA Sunucu tarafından doğrulanamazsa su anki sistemde var olan bir ekstra yük yaratacaktır. Bu durumda Yabancı Aracı gereksiz yere Evdeki Aracı’ya mesaj yollayıp Mobil IP kayıt sistemini başlatmak isteyecektir. Bu bir güvenlik açığı değildir çünkü Evdeki AAA Sunucu, Evdeki Aracı yada Mobil Kullanıcı ile arasında olması gereken güvenlik ilişkisinde sorunlar olduğunu bildirecektir. Böylece Yabancı Aracı kimlik doğrulama cevabıyla beraber, basarisiz kayıt mesajı da alacaktır. Bu sure zarfında Mobil Kullanıcı hala Yabancı Aracı’yı kullanamıyor olacaktır.

Sistem performans kaybını kimlik doğrulamasından olumsuz sonuç alacak kullanıcıların bağlanmaya çalışmasında yaşayacaktır. Hızlı kimlik ve erişim kontrol mekanizması yaratabilmek için bunun kabul edilebilir bir yük olduğunu düşünüyoruz.

Sistemin sel (flood) ataklarından önemli ölçüde etkilenmeyeceğini düşünmekteyiz. Hali hazırdaki sistemde yanlış kayıt bilgisi ile FA-FAAA-HAAA iletişimi yaratılabilirken önerilen sistemde  FA-FAAA-HAAA ve  FA-HA-HAAA-HA-FA yaratılabilmektedir. Yani yaklaşık iki kat kapasite kaybına yol açılabilir. Gönderilen ve alınan paketlerinin büyüklüğü düşünülerek bu noktada 2 kat fazla kapasite kaybının önemsiz bir fark yaratacağını düşünmekteyiz.

4. Analitik analiz

Sistemin getireceği faydaları analitik olarak ele almak için bazı temel varsayımlar yapmak zorundayız. Analitik analiz ideal şartları varsayacağı için sistemde hali hazırda bir yük olmadığı, ağdaki bahsi gecen tüm ekipmanların (FA, FAAA, HAAA, HA) gelen paketleri beklemeden isleyecekleri ve [2]’de bahsedildiği üzere bağlantı hızlarının ön plana çıkacağını kabul ediyoruz. Bu yüzden bu bolümden çıkacak sonuçlar tamamen doğru olmak yerine fikir vermeyi amaçlamaktadır.

Mobil IP-RADIUS konuşmalarında temel sorunun yerel ağ’dan uzakta bulunan ağ’a ulaşmakta geçen süre olduğu gerçeğini kullanarak şöyle bir basitleştirmeye gitmemiz mümkündür; Yerel ağdaki konumsalar, ağlar arası konuşmadan çok ufak olacağı için yerel ağdaki konuşmaların suresini ve ağlar arası konuşmanın suresini aynı kabul edebiliriz.

Analitik hesapta kullanabilmemiz için yerel ağ konuşmalarına (MN-FA, FA-FAAA, HAAA-HA) X birim, ağlar arası konuşmalara (FA-HA, FAAA-HAAA) da Y birim diyebiliriz. Bu durumda hali hazırdaki yapıda alttaki diyaloglar geççiği için (bakınız Şekil 3)

MN-FA, FA-FAAA,  FAAA-HAAA, HAAA-FAAA, FAAA-FA, FA-HA, HA-HAAA, HAAA-HA, HA-FA, FA-MN

Bizim tanımımıza göre :

X + X + Y + Y + X + Y + X + X + Y + X = 6X + 4Y’lik bir konuşma zamanı geçmektedir.

Öte yandan, önerilen sistemde  (bakınız Şekil 4),  (1) ve (6) numaralı adımlar hariç diğer adımlar paralel yapıldığı için iki ayrı konuşma dallarının hesaplanması gerekmektedir.

FA-HA, HA-HAAA, HAAA-HA, HA-FA 1. dalı oluştururken,

 FA-FAAA, FAAA-HAAA, HAAA-FAAA, FAAA-FA 2. dalı oluşturmaktadır.

Değişkenlerimizi yerlerine yazdığımızda iki dalın da  2X + 2Y birim sure tuttuğunu görebiliriz.  (1) ve (6) adımlarını da eklediğimizde.Bu bizi 4X + 2Y birim sureye ulaştırmaktadır.

X’i ve Y’yi eşit ve 1 birim kabul edip aradaki farkı yavaş yavaş açarak Y’yi arttırdığımızda alttaki performans grafiği çıkmaktadır (bakınız Şekil 5). Göründüğü üzere Y’nin, yani ağlar arası konuşmanın tuttuğu sure, X’in yani ağ içi konuşmanın tuttuğu surenin 6 katına ulaştığında, toplam konuşma zamanı için gecen birim sure önerilen çözümümüzde var olan sistemin yarısı kadar sürmektedir.

Şekil 5 – Performans Grafiği

Farklı bir açıdan bakmak istediğimizde, sistemin performans kazancı, kullanılan sistem/önerilen sistem olarak tanımlanırsa şu denklem elde edilir:

6X+4Y/ 4X+2Y

Tekrar X ve Y yi 1 birim kabul edip Y yi arttırdığımızda Şekil 6’yı elde etmekteyiz.

Şekil 6.  Performans Kazancı

Tahmin edildiği üzere, ağlar arası konuşma ağ içi konuşmaya göre arttığında, ağ içi konuşma giderek ihmal edilebilir seviyeye gelmektedir. Böylece
 
6X+4Y/ 4X+2Y

olan performans kazancı

4Y/2Y

olarak sadeleşmektedir. Bu da bizim nerdeyse 2 kat bir hızlanma sağlayabildiğimizi göstermektedir. Bu aynı zamanda Şekil 6’da da rahatlıkla gözükmektedir. Şekil üzerinden bakıldığında, Y deki artış ile kazancımız giderek 2 ye yaklaşan bir grafik çizmektedir. Yine grafikten anlaşıldığı üzere, ağlar içi ve ağlar arası konuşma sureleri aynı kabul edilse bile bu bize 1,67 oranında bir kazanım getirmektedir.

Özetlemek gerekirse, analitik incelememiz sistem performansında önemli sayılabilecek ölçüde bir ilerleme sağlayabildiğimizi göstermektedir

5. Sonuç

Mobil IP farklı kablosuz ağ sistemlerine entegre olabilen, kabul edilmiş, kullanıcıların rahatlıkla farklı ağlar arasında gezmesini sağlayan bir kablosuz ağ dolaşımı çözümüdür.

Kullanıcılar ve servis sağlayıcılar açışından kolaylıkla uygulanması için RADIUS gibi AAA protokollerinin entegre edilmesiyle sistemin üzerine daha fazla gecikme yükü binmeye başlamıştır.

Bu konuda üretilen çözümlere ek olarak, belli varsayımlarla, bu bildiride yeni bir öneri getirilmiştir. Paralel AAA ve Mobil IP iletişimleriyle daha hızlı oturum açma surelerine ulaşılabildiği gösterilmiştir.

Önerdiğimiz sistemi üzerinde gecikmeye neden olmayacak kadar yük olan sistemler için analitik olarak formüle etmemiz ve incelememiz mümkündür. Bu incelemelerle önemli bir performans kazancı elde edebileceğimizi göstermiş bulunuyoruz.

Öte yandan, üzerinde gecikmeye neden olmayacak kadar yük olan sistemler varsaymak bilgi verici olsa da, gerçeğe çok yakın bir modelleme değildir. Gerçek bir modellemede ölçeklenebilirlik incelemesi yapabilmek de önemli bir unsurdur. Bu yüzden, bir çok kullanıcının olduğu bir sistemde, kullanıcı sayısı arttıkça var olan sistemler üzerindeki yük arttığında önerdiğimiz çözümün var olan çözümden farkını görebilmek için simülasyon çalışmaları yapmaktayız.

Bu bildirinin gelecekte yapılmasını öngördüğü çalışma; gerçekçi bir simülasyon analizi ile konunun ölçeklenebilirlik boyutunu da incelemektir. Bu konuda çalışmalarımız devam etmektedir.

6. Kaynaklar

[1] C. Perkins, ed., “IP Mobility Support for IPv4”. RFC3344, August 2002.
[2] S. Glass, T. Hiller, S. Jacobs, C. Perkins, “Mobile IP Authentication, Authorization, and Accounting Requirements”, RFC 2977, October 2000.
[3] C. Rigney, S. Willens, A. Rubens, W. Simpson , “Remote Authentication Dial In User Service (RADIUS)”, IETF Request For Comments, RFC 2865, June 2000.
[4 Pat R. Calhoun, H. Akhtar, J. Arkko, E. Guttman, Allan C. Rubbens, G. Zorn – “Diameter Base Protocol”, IETF Internet Draft, draft-ietf-aaa-diameter-08.txt, November 2001.
[5] M. Nakhjiri,  K. Chowdhury, Avi Lior, Kent Leung, “RADIUS Mobile IPv4 extensions”, draft-nakhjiri-radius-mip4-02.txt, October 2005.
[6] P. Calhoun, T. Johansson, C. Perkins, T. Hiller, Ed., P. McCann, “Diameter Mobile IPv4 Application”, RFC 4004, August2005.

Hazırlayan : Aykut Soner Demirkol ve M.Ufuk Çağlayan