GDOI: چرا سرور کلید روی مسیر دادهٔ شما نیست
یک کنترل‌کنندهٔ GDOI سیاست گروه و کلیدها را توزیع می‌کند؛ اعضا خود داده‌ها را محافظت می‌کنند. ثبت‌نام، تحویل تجدید کلید و ارسال نیازمند بررسی‌های جداگانه است.
سرور کلید گروه سیاست و کلیدها را میان اعضا توزیع می‌کند و اعضا خودشان ترافیک را محافظت می‌کنند. این جمله مانند یک تشریفات به نظر می‌رسد تا زمانی که طرحی کنترل‌کننده را به‌عنوان رله‌ای برای هر بستهٔ محافظت‌شده در نظر بگیرد؛ آنگاه توپولوژی گامی پیدا می‌کند که هرگز به آن نیاز نداشت و مسیر ترافیک به دستگاهی وابسته می‌شود که تنها قرار بود وضعیت را توزیع کند. گفتن اینکه سرور کلید کجاست و گفتن اینکه داده‌ها کجا جریان دارند دو نمودار متفاوت است و GDOI دقیقاً پیرامون همین تفاوت ساخته شده است. برعکس فهمیدن آن خطای کوچک مدل‌سازی نیست، زیرا تغییر می‌دهد چه چیزی را پایش می‌کنید و چه چیزی را مقیاس می‌دهید. بخش‌های زیر از تقسیم‌بندی خود پروتکل پیروی می‌کنند.
دو نوع وضعیت امنیتی
RFC 6407 تبادل کشیدن عضو را برای درخواست سیاست و مواد کلید تعریف می‌کند و تبادل فشردنی که سیاست و به‌روزرسانی‌های کلید را به اعضای مجاز توزیع می‌کند. هر دو انجمن‌های امنیتی را مدیریت می‌کنند. هیچ‌کدام جریان دادهٔ برنامه نیست، پس یک تبادل موفق فقط ثابت می‌کند که کانال کنترل کار کرده است. یک عضو می‌تواند به‌طور پاک ثبت‌نام کند، کلیدهای معتبر نگه دارد و با این حال اگر سیاست داده‌اش نادرست باشد نتواند ترافیک را محافظت یا ارسال کند. این دو شکست وقتی بدانید کدام تبادل کدام را حمل می‌کند کاملاً متفاوت به نظر می‌رسند.
استاندارد همچنین یک انجمن امنیتی تجدید کلید نام می‌برد که پیام‌های به‌روزرسانی کلید را محافظت می‌کند، جدا از انجمن‌های امنیتی داده که توصیف می‌کنند اعضا چگونه ترافیک را محافظت می‌کنند.
دنبال تبادل‌ها بروید، نه نمودار
ببینید هر پیام برای چیست. ثبت‌نام به کنترل‌کننده می‌گوید کدام عضو می‌پرسد و وضعیت ایجاد می‌کند؛ تجدید کلید به اعضا می‌گوید سیاست یا کلیدها تغییر کرده‌اند؛ سپس ترافیک محافظت‌شدهٔ برنامه با استفاده از انجمن امنیتی دادهٔ نصب‌شده میان اعضا جریان می‌یابد. نشانی کنترل‌کننده در دو مورد اول ظاهر می‌شود و لازم نیست اصلاً در سومی ظاهر شود.
به همین دلیل نمودار رابط‌هایی که بر پایهٔ مجاورت فیزیکی کشیده شده اینجا گمراه‌کننده است. رابط کنترل‌کننده یک منبع کنترل است، نه به‌طور خودکار گام بعدی برای هر بستهٔ رمزنگاری‌شده.
سه رکورد که ارزش نگه داشتن دارند
ثبت‌نام احرازشدهٔ عضو و منبع کنترلی که می‌تواند به آن برسد، مسیری که به‌روزرسانی‌های بعدی کلید را تحویل می‌دهد، و مسیرها و اتصالاتی که ترافیک محافظت‌شدهٔ برنامه را حمل می‌کنند را بنویسید. سه رکورد، سه مالک، و خرابی در هر یک از آن‌ها نشانهٔ متفاوتی تولید می‌کند. عضوی که ثبت‌نام می‌کند و سپس هرگز به‌روزرسانی دریافت نمی‌کند با عضوی که با سیاست کهنه ثبت‌نام کرده یکسان به نظر می‌رسد، مگر اینکه هر دو رکورد را داشته باشید.
این‌ها را کنار پیکربندی نگه دارید، نه در حافظهٔ کسی. تغییرات عضویت چنان کم‌اند که استدلال تا زمانی که لازم شود همیشه از میان رفته است.
رابط، اتصال سرویس، مسیر پردازش
روی دروازه‌ای مبتنی بر سرویس تمایز دیگری وجود دارد: نشانی زیرلایهٔ فیزیکی همان اتصال محلی سرویس نیست، و پیاده‌سازی سکو تصمیم می‌گیرد ترافیک چگونه به مسیر پردازش IPsec آن برسد. انتقال یک سرویس به رابط فیزیکی یا افزودن ترجمهٔ نامرتبط چون پیام خطایی به قاعدهٔ رابط سرویس اشاره کرده بود، حدسی است که جامهٔ تعمیر پوشیده است.
مستندات خود سکو را دربارهٔ اینکه اتصال سرویس چگونه ترافیک را دریافت می‌کند بخوانید. سازوکار حتی وقتی پروتکل استاندارد است به فروشنده وابسته است.
پیام‌های پروتکل استانداردشده نیز سازگاری میان فروشندگان را اثبات نمی‌کنند. پیش از فرض اینکه دو پیاده‌سازی با هم کار می‌کنند، ویژگی‌های لازم، صفات سیاست و انجمن، روش احراز هویت و سکوی و نسخهٔ دقیق را مقایسه کنید.
دسترس‌پذیری کنترل و ارسال داده دو بررسی جداگانه‌اند
دسترس‌پذیری کنترل‌کننده را برای بهره‌برداری عادی، برای تغییرات عضویت و برای به‌روزرسانی‌های کلید برنامه‌ریزی کنید. تبادل برنامه‌ای که روی وضعیت از پیش نصب‌شده موفق می‌شود ثابت نمی‌کند ثبت‌نام یا تجدید بعدی می‌تواند به عضو برسد، و این شکاف معمولاً ساعت‌ها بعد به‌صورت تونلی ظاهر می‌شود که پذیرش اعضای جدید را متوقف می‌کند. یک ثبت‌نام تازه را بیازمایید، نه فقط یک نشست کارکننده را.
سپس ارسال را جداگانه بیازمایید، با کنترل‌کننده بیرون از تصویر. دو بررسی، دو نتیجه، و بحثی بسیار کوتاه‌تر درباره اینکه کدام نیمه خراب است.