802.11r — Fast BSS Transition: Roaming'de Milisaniyelerin Mühendisliği

Problem: roaming neden yavaştı?

802.11 dünyasında roaming kararını ağ değil istemci verir. Telefon, el terminali ya da dizüstü bilgisayar, bağlı olduğu AP'nin sinyali zayıfladığında komşu kanalları tarar, daha iyi bir aday bulur ve ona geçer. Geçişin kendisi ise birkaç aşamadan oluşur: 802.11 open authentication, association ve ardından güvenlik katmanının yeniden kurulması. WPA2-Personal ağlarda bu son aşama yalnızca 4-way handshake'tir ve görece hızlıdır. Ancak WPA2/WPA3-Enterprise ağlarda istemci her yeni AP'de RADIUS sunucusuyla tam bir 802.1X/EAP değişimi yapmak zorundadır.

EAP-TLS ya da PEAP gibi yöntemlerde bu değişim, sertifika doğrulaması ve birden fazla RADIUS gidiş-dönüşü içerir. Sunucu aynı binada olsa bile süre tipik olarak 200 ile 800 milisaniye arasındadır; RADIUS bir veri merkezinde, WAN üzerinden erişiliyorsa saniyeyi aşabilir. Ses trafiği için ITU-T G.114 tavsiyesi tek yönlü gecikmenin 150 ms'yi geçmemesini önerir; Wi-Fi telefon üreticileri de roaming kesintisini 50 ms civarında tutmayı hedefler. Aradaki fark, bir hastanede hemşire çağrısının yarım saniye sessiz kalması ya da depoda el terminalindeki WMS oturumunun zaman aşımına düşmesi anlamına gelir.

İlk çözüm denemeleri PMK caching ve Opportunistic Key Caching (OKC) oldu. PMK caching, istemcinin daha önce bağlandığı AP'ye dönüşte anahtarı yeniden kullanmasını sağlar ama yeni bir AP'de işe yaramaz. OKC ise PMK'yı controller üzerinden tüm AP'lerle paylaşır; etkilidir fakat hiçbir zaman IEEE standardı olmamıştır ve istemci desteği tutarsızdır. 802.11r, 2008'de bu boşluğu standart bir mekanizmayla kapattı ve sonraki yıllarda 802.11-2012 ana standardına dahil edildi.

Anahtar hiyerarşisi: PMK-R0, PMK-R1 ve PTK

802.11r'ın kalbinde üç seviyeli bir anahtar hiyerarşisi vardır. İstemci ağa ilk kez bağlandığında normal 802.1X kimlik doğrulaması yapılır ve bir Master Session Key (MSK) üretilir. Bu MSK'dan PMK-R0 türetilir; PMK-R0'ı tutan varlığa R0 Key Holder (R0KH) denir; bu rol üreticiye ve mimariye özgüdür (controller tabanlı ağlarda çoğunlukla controller ile ilişkilidir, ancak bu genel bir kural değildir). PMK-R0'dan her R1 Key Holder (R1KH, tipik olarak AP) için ayrı bir PMK-R1 türetilir. Son olarak istemci ile AP, PMK-R1 ve iki tarafın nonce değerlerinden oturuma özel PTK'yı üretir.

Bu yapının güzelliği, ağır işin yalnızca bir kez yapılmasıdır. İstemci yeni bir AP'ye geçtiğinde RADIUS'a hiç gitmez; PMK-R1 hedef R1KH'de önceden bulunabilir (push modeli) ya da altyapının anahtar dağıtım modeline göre geçiş sırasında elde edilir/türetilir (pull modeli). Hiyerarşiyi bir arada tutan kavram Mobility Domain'dir (MDID). Aynı Mobility Domain içindeki AP'ler aynı R0KH'ye bağlıdır ve istemci FT'yi yalnızca bu domain sınırları içinde kullanabilir. Beacon ve probe response çerçevelerindeki Mobility Domain Information Element (MDIE), istemciye hangi AP'lerin aynı domain'e ait olduğunu söyler.

FT el sıkışması adım adım

Over-the-air FT'de istemci, klasik open authentication yerine doğrudan hedef AP'ye FT Authentication Request gönderir. Bu çerçeve, istemcinin nonce değerini, PMK-R0 adını ve MDIE bilgisini taşır. AP, ilgili PMK-R1'i bulur, kendi nonce değerini ekleyerek yanıt verir. Bu noktada her iki taraf PTK'yı hesaplayabilecek bilgiye sahiptir. Ardından gelen Reassociation Request/Response çifti, anahtarların doğruluğunu kanıtlayan MIC alanlarını taşır ve GTK da bu yanıtla teslim edilir. Sonuç: ayrı bir 4-way handshake'e gerek kalmadan dört çerçevede güvenli bağlantı.

Over-the-DS yönteminde ise istemci, FT isteğini mevcut AP'ye gönderir; mevcut AP bunu kablolu dağıtım sistemi üzerinden hedef AP'ye iletir. Teoride bu, istemcinin kanal değiştirmeden ön hazırlık yapmasını sağlar. Pratikte ise ek gecikme, üretici uygulamalarındaki farklılıklar ve sorun giderme zorluğu nedeniyle sahada çoğunlukla over-the-air tercih edilir. F2 olarak tasarımlarımızda, istemci envanteri aksi yönde bir gerekçe sunmadıkça over-the-DS'yi kapalı tutmayı öneriyoruz.

Sahada ölçülen fark

Laboratuvar ve saha ölçümlerimizde roaming süresini, istemcinin eski AP'ye son veri çerçevesini gönderdiği andan yeni AP üzerinden ilk veri çerçevesini aldığı ana kadar ölçüyoruz. Aşağıdaki değerler, aynı istemci ve aynı RF ortamında farklı güvenlik yöntemleriyle tipik olarak elde ettiğimiz aralıkları özetler. Gerçek değerler istemci sürücüsüne, RADIUS konumuna ve tarama davranışına göre değişir; burada önemli olan büyüklük sırasıdır.

Uyumluluk tuzakları ve adaptive FT

802.11r'ın en bilinen sorunu eski istemcilerdir. Bazı yazıcılar, barkod okuyucular, tıbbi cihazlar ve eski Windows sürücüleri, beacon içinde FT AKM'sini gördüklerinde SSID'ye hiç bağlanamaz ya da bağlandıktan sonra kararsız davranır. Bu yüzden üreticiler farklı modlar sunar: yalnızca FT (FT-only), FT ve klasik AKM'nin birlikte yayınlandığı karma mod ve Cisco'nun Adaptive 802.11r yaklaşımı gibi, FT'yi yalnızca desteklediğini bildiği istemcilere sunan akıllı modlar.

WPA3 ile birlikte tablo yeniden değişti. WPA3-Personal'da FT, SAE üzerine kurulu FT-SAE AKM'siyle çalışır; WPA3-Enterprise 192-bit modunda ise FT desteği istemci tarafında hala sınırlıdır. Dolayısıyla 802.11r'ı açmak tek bir onay kutusu değil, istemci envanterine dayalı bir mühendislik kararıdır.

• SSID tasarımında ses ve hareketli istemcileri ayrı, FT etkin bir SSID'de toplamak çoğu zaman en temiz çözümdür.
• Mobility Domain sınırlarını controller ya da site sınırlarıyla hizalayın; domain dışına çıkan istemci tam kimlik doğrulama yapar.
• 802.11r tek başına yeterli değildir: istemcinin iyi aday seçmesi için 802.11k komşu raporları, zamanında ayrılması için 802.11v BSS Transition gerekir.
• Hücre örtüşmesi %15-20 civarında değilse FT'nin hızı işe yaramaz; istemci geç roam eder ve kesinti RF kaynaklı olur.

Sorun giderme kontrol listesi

802.11r etkinleştirildikten sonra şikayet geliyorsa önce sorunun kimlik doğrulama mı yoksa RF mi olduğunu ayırın. Kablosuz paket yakalamada Authentication çerçevesinin Auth Algorithm alanı 2 (FT) olmalıdır; 0 görüyorsanız istemci FT kullanmıyordur. Reassociation Response'ta status code 53 (Invalid PMKID) veya 55 (Invalid FTIE) görülmesi, PMK-R1'in hedef AP'ye ulaşmadığını ya da Mobility Domain uyuşmazlığını gösterir.

Controller loglarında istemcinin aynı roaming içinde FT'den tam EAP'ye düştüğü durumlar, R0KH erişilebilirliği veya anahtar ömrü yapılandırması açısından incelenmelidir. Son olarak, roaming süresini ölçmeden 'roaming iyi' demeyin: ses istemcisinde MOS skorunu, el terminalinde uygulama zaman aşımını ve paket yakalamada çerçeveler arası süreyi birlikte değerlendirin. F2'nin CCIE Wireless ve CWNA sertifikalı mühendisleri, bu ölçümleri sahada yapıp kök nedeni raporlayan bir validasyon metodolojisi uygular.