GDOI: prečo kľúčový server nie je na vašej dátovej ceste

Skupinový kľúčový server distribuuje politiku a kľúče členom a členovia sami chránia premávku. Táto veta znie ako formalita, kým nejaký návrh nezačne považovať kontrolér za preposielací uzol pre každý chránený paket; potom topológia získa skok, ktorý nikdy nepotrebovala, a cesta premávky závisí od zariadenia, ktoré malo len vydávať stav. Povedať, kde sedí kľúčový server, a povedať, kadiaľ tečú dáta, sú dva rôzne diagramy a GDOI je postavený práve na tomto rozdiele. Otočiť to nie je malá chyba modelovania, pretože mení, čo sledujete a čo škálujete. Nasledujúce časti držia vlastné delenie protokolu.

Dva druhy bezpečnostného stavu

RFC 6407 definuje členskú výmenu ťahania na žiadosť o politiku a kľúčový materiál a výmenu tlaku, ktorá distribuuje politiku a aktualizácie kľúčov oprávneným členom. Obe spravujú bezpečnostné asociácie. Ani jedna nie je dátový tok aplikácie, takže úspešná výmena dokazuje len to, že kontrolný kanál fungoval. Člen sa môže čisto zaregistrovať, držať platné kľúče a napriek tomu nedokázať chrániť alebo preposielať premávku, ak je jeho dátová politika nesprávna. Tieto dve poruchy vyzerajú úplne inak, keď viete, ktorá výmena ktorú nesie.

Štandard tiež pomenúva bezpečnostnú asociáciu obnovy kľúčov, ktorá chráni správy o aktualizácii kľúčov, oddelene od dátových bezpečnostných asociácií, ktoré opisujú, ako členovia chránia premávku.

Sledujte výmeny, nie diagram

Pozrite sa, na čo slúži každá správa. Registrácia povie kontroléru, ktorý člen sa pýta, a vytvorí stav; obnova kľúčov povie členom, že sa politika alebo kľúče zmenili; potom chránená premávka aplikácie tečie medzi členmi pomocou nainštalovanej dátovej bezpečnostnej asociácie. Adresa kontroléra sa objavuje v prvých dvoch a v tretej sa vôbec nemusí objaviť.

Preto diagram rozhraní nakreslený podľa fyzickej susednosti tu klame. Rozhranie kontroléra je zdrojom riadenia, nie automaticky ďalší skok pre každý šifrovaný paket.

Tri záznamy, ktoré stoja za uchovanie

Zapíšte overenú registráciu člena a riadiaci zdroj, ku ktorému sa dostane, cestu, ktorá doručuje ďalšie aktualizácie kľúčov, a trasy a pripojenia, ktoré nesú chránenú premávku aplikácie. Tri záznamy, traja vlastníci a porucha v ktoromkoľvek z nich dáva iný príznak. Člen, ktorý sa zaregistruje a potom nikdy nedostane aktualizáciu, vyzerá rovnako ako člen registrovaný so zastaranou politikou, ak nemáte oba záznamy.

Uchovajte to vedľa konfigurácie, nie v niekoho pamäti. Zmeny členstva sú dosť zriedkavé na to, aby odôvodnenie vždy zmizlo do chvíle, keď je potrebné.

Rozhranie, pripojenie služby, cesta spracovania

Na bráne založenej na službách existuje ďalší rozdiel: adresa fyzického podkladu nie je to isté ako lokálne pripojenie služby a implementácia platformy rozhoduje, ako sa premávka dostane na jej cestu spracovania IPsec. Presunúť službu na fyzické rozhranie alebo pridať nesúvisiaci preklad, pretože chybová správa spomenula pravidlo rozhrania služby, je dohad oblečený ako oprava.

Prečítajte si vlastnú dokumentáciu platformy o tom, ako pripojenie služby prijíma premávku. Mechanizmus je špecifický pre dodávateľa, aj keď je protokol štandardný.

Štandardizované protokolové správy tiež nezakladajú kompatibilitu medzi dodávateľmi. Porovnajte požadované funkcie, atribúty politiky a asociácie, metódu overovania a presnú platformu a vydanie, skôr než predpokladáte, že dve implementácie budú spolupracovať.

Dostupnosť riadenia a preposielanie dát sú samostatné kontroly

Naplánujte dostupnosť kontroléra pre bežnú prevádzku, pre zmeny členstva a pre aktualizácie kľúčov. Výmena aplikácie, ktorá uspeje na už nainštalovanom stave, nedokazuje, že ďalšia registrácia alebo obnova dokáže dosiahnuť člena, a medzera sa zvyčajne objaví o hodiny neskôr ako tunel, ktorý prestane prijímať nových členov. Otestujte čerstvú registráciu, nielen fungujúcu reláciu.

Potom otestujte preposielanie zvlášť, bez kontroléra. Dve kontroly, dva výsledky a oveľa kratší spor o to, ktorá polovica je pokazená.