امنیت نشست‌های BGP با پروتکل TCP-AO RFC 5925 و چرخش پویای کلیدهای MKT

پروتکل دروازه مرزی (BGP-4, RFC 4271) ستون فقرات ارتباطی شبکه جهانی اینترنت است و با برقراری اتصالات پایدار TCP روی پورت ۱۷۹ میان سیستم‌های خودمختار (AS)، تبادل جداول مسیریابی را ممکن می‌سازد. مسیریاب‌های مستقر در مراکز تبادل ترافیک اینترنت (IXP)، هاب‌های چندابری و خطوط اصلی سازمانی برای تبادل اطلاعات دسترس‌پذیری به این نشست‌ها متکی هستند. با این حال، از آنجا که نسخه پایه TCP فاقد سازوکارهای اعتبارسنجی رمزنگاری‌شده است، ترافیک صفحه کنترل همواره در معرض خطراتی چون جعل بسته، بازنشانی ناخواسته و تزریق‌های مخرب قرار دارد.

برای دهه‌ها، مدیران شبکه از استاندارد RFC 2385 (گزینه امضای TCP MD5) استفاده می‌کردند. اما نقایص ساختاری RFC 2385 مانع از تغییر کلیدها بدون قطع ارتباط می‌شد و همین امر اختلال در نشست‌های BGP و نوسانات شدید جداول مسیریابی را در پی داشت. کارگروه مهندسی اینترنت (IETF) استاندارد RFC 5925 را برای معرفی گزینه احراز هویت TCP (TCP-AO) به همراه استاندارد الگوریتم‌های رمزنگاری RFC 5926 تدوین کرد. TCP-AO با به‌کارگیری تاپل‌های کلید اصلی (MKT)، شماره‌های توالی گسترده، تنوع الگوریتم‌ها و چرخش بدون قطعی کلیدها، این موانع را برطرف می‌سازد.

آسیب‌پذیری زیرساخت مسیریابی: تزریق بسته‌های TCP RST و منسوخ شدن RFC 2385 MD5

پشته‌های استاندارد TCP اعتبار بسته‌ها را بر اساس ۴-تاپل IP و پنجره لغزان شماره‌های توالی بررسی می‌کنند. در خطوط پرسرعت، مهاجمی که بتواند شماره‌های توالی درون پنجره دریافت را تخمین بزند، می‌تواند بسته‌های ساختگی TCP RST یا SYN را تزریق کند (RFC 4953, RFC 5961). دریافت بسته جعلی RST در بازه مجاز پنجره باعث بسته شدن فوری سوکت توسط سیستم‌عامل می‌شود. برای نشست‌های BGP، این اتفاق به بازپس‌گیری سریع مسیرها و ایجاد تلاطم گسترده در مسیریابی شبکه می‌انجامد.

استاندارد RFC 2385 (Option Kind 19) تلاش کرد با استفاده از امضای MD5 و یک کلید مشترک بسته‌ها را ایمن کند. با وجود کاربرد وسیع، این استاندارد دارای ایرادهای جدی است:

1. فرسودگی الگوریتم رمزنگاری: الگوریتم MD5 در برابر حملات تصادم آسیب‌پذیر است. در RFC 2385 از هش مستقیم به جای ساختار استاندارد HMAC استفاده شده که با استانداردهای امنیتی مدرن همخوانی ندارد.
2. نبود چابکی الگوریتمی: الگوریتم MD5 در ساختار این گزینه ثابت شده و امکان ارتقای الگوریتم بدون تعریف یک گزینه کاملاً جدید در TCP وجود ندارد.
3. چالش چرخش کلیدها: هدر RFC 2385 فاقد فیلد شناسه کلید است. هنگام تعویض کلید، هر دو مسیریاب باید دقیقاً در یک لحظه تغییر را اعمال کنند. چنانچه یکی از دستگاه‌ها کلید را تغییر دهد در حالی که بسته‌هایی با امضای قبلی در مسیر باشند، اعتبارسنجی با شکست مواجه شده و ارتباط BGP قطع می‌شود.
4. آسیب‌پذیری در برابر بازپخش: RFC 2385 نمی‌تواند از بازپخش بسته‌ها در صورت چرخش شماره توالی یا اتصال‌های مجدد جلوگیری کند.

معماری بنیادین RFC 5925: ساختار هدر گزینه احراز هویت TCP

استاندارد RFC 5925 گزینه شماره ۲۹ (Option Kind 29) را جایگزین گزینه ۱۹ کرده است. هدر TCP-AO ساختاری فشرده و کارآمد را برای هماهنگی کلیدها و محافظت در برابر بازپخش فراهم می‌آورد:

+---------------+---------------+---------------+---------------+
|  Kind = 29    |  Length = 16  |   KeyID       |  NextKeyID    |
+---------------+---------------+---------------+---------------+
|                     کد احراز هویت پیام (MAC)                   |
|                        (۹۶ بیت / ۱۲ بایت)                     |
+---------------+---------------+---------------+---------------+

شرح جزئیات فیلدهای هدر:

• Kind (۱ بایت): مقدار ۲۹ که نشان‌دهنده استفاده از استاندارد RFC 5925 است.
• Length (۱ بایت): طول کل گزینه (۴ بایت هدر به همراه طول فیلد MAC که برای مک ۹۶ بیتی برابر با ۱۶ بایت است).
• KeyID (۱ بایت): شناسه تاپل کلید اصلی (MKT) که فرستنده برای تولید MAC بسته فعلی از آن بهره برده است.
• NextKeyID (۱ بایت): شناسه MKT مورد تقاضای فرستنده برای تولید پاسخ‌ها توسط گیرنده. این فیلد کانال هماهنگی درونی را شکل می‌دهد.
• MAC (۱۲ بایت): تگ اعتبارسنجی رمزنگاری‌شده که بر روی شبه‌هدر TCP، هدر TCP (با گزینه‌های صفرشده) و محتوای داده محاسبه می‌شود.

جداسازی شناسه کلید از وضعیت اتصال به دستگاه‌ها اجازه می‌دهد هم‌زمان چندین کلید فعال را روی یک سوکت مدیریت کنند.

تاپل‌های کلید اصلی (MKT) و الگوریتم‌های رمزنگاری: مشخصات فنی RFC 5926

پیکربندی استاندارد RFC 5925 بر مبنای تاپل کلید اصلی (Master Key Tuple, MKT) سازمان‌دهی شده است. هر MKT یک ارتباط امن را میان دو مسیریاب تعریف می‌کند:

• محدوده ارتباط: نشانی‌های IP و پیشوندهای مبدأ و مقصد و پورت‌های اختیاری TCP.
• شناسه‌های کلید: فیلد SendID (کلید ارسالی) و فیلد RecvID (کلید مورد انتظار در دریافت).
• کلید اصلی: رشته‌ای محرمانه با آنتروپی و امنیت بالا.
• مجموعه رمزنگاری: الگوریتم احراز هویت پیام و تابع اشتقاق کلید مطابق با RFC 5926.

توابع اشتقاق کلید ترافیک (KDF) از طریق توابع شبه‌تصادفی

برای محافظت از کلید اصلی، در TCP-AO هرگز بسته‌ها با خود کلید اصلی امضا نمی‌شوند. استاندارد RFC 5926 توابع اشتقاق کلید (KDF) را با توابع شبه‌تصادفی (PRF) پیاده‌سازی می‌کند:

Traffic_Key = PRF(Master_Key, Context_String)

رشته زمینه پارامترهای پویای اتصال را یکپارچه می‌سازد:

Context = Direction || Send_ISN || Recv_ISN || Algorithm_ID

با پیوند کلیدها به شماره‌های توالی اولیه (ISN) و جهت انتقال، هر نشست از دو کلید مستقل یک‌طرفه استفاده می‌کند. افشای احتمالی یک کلید موقت نشست، کلید اصلی را به خطر نمی‌اندازد و امکان نفوذ در مسیر بازگشت را فراهم نمی‌سازد.

تحلیل مقایسه‌ای: عملکرد AES-128-CMAC در برابر HMAC-SHA-1-96 در تراشه‌های سخت‌افزاری

استاندارد RFC 5926 دو الگوریتم اجباری را تعیین کرده است: AES-128-CMAC-96 و HMAC-SHA-1-96:

در مسیریاب‌های کلاس تجاری، الگوریتم AES-128-CMAC به دلیل پشتیبانی سخت‌افزاری، تاخیر پایدار و بسیار پایینی را فراهم می‌کند.

حل چالش چرخش کلیدها: مهاجرت بدون قطعی و توقف اختلال نشست BGP

چرخش بدون وقفه کلیدها برجسته‌ترین دستاورد عملیاتی RFC 5925 است. خط‌مشی‌های امنیتی تعویض منظم رمزها را ضروری می‌دانند، اما پروتکل قدیمی RFC 2385 مستلزم قطعی سرویس بود. پروتکل TCP-AO این چالش را با یک سازوکار دقیق مرتفع می‌کند:

1. پیکربندی اولیه: مدیران شبکه MKT جدید (KeyID = 2) را روی هر دو مسیریاب ثبت می‌کنند در حالی که تبادل داده‌ها با MKT (KeyID = 1) ادامه دارد.
2. اعلام آمادگی: مسیریاب A سوکت خود را برای ارسال NextKeyID = 2 تنظیم می‌کند، اما بسته‌های خروجی را همچنان با KeyID = 1 امضا می‌نماید.
3. همگام‌سازی مقصد: مسیریاب B با دریافت NextKeyID = 2، تاپل MKT-2 محلی را فعال کرده، امضای خروجی را به KeyID = 2 تغییر می‌دهد و NextKeyID = 2 را بازمی‌گرداند.
4. تثبیت نهایی: مسیریاب A با دیدن بسته‌های دارای KeyID = 2، امضای خروجی خود را کاملاً به KeyID = 2 منتقل می‌سازد.

پس از پایان چرخه، کلید قدیمی MKT-1 بدون ایجاد قطعی در پروتکل BGP یا از دست رفتن بسته‌ها حذف می‌شود.

مکانیسم ضد بازپخش: شماره‌های توالی گسترده و تاب‌آوری در برابر مسیرهای نفوذ

در پیوندهای پرسرعت ۱۰۰ و ۴۰۰ گیگابیتی، فضای شماره‌های توالی ۳۲ بیتی ظرف چند ثانیه تکمیل و دوباره از صفر آغاز می‌شود. این پدیده ترافیک را در معرض حملات بازپخش بسته‌های قدیمی قرار می‌دهد.

استاندارد RFC 5925 با معرفی شماره‌های توالی گسترده (SNE) از این رخداد پیشگیری می‌کند:

• هدر انتقالی بسته همچنان از شماره توالی استاندارد ۳۲ بیتی (SEQ) بهره می‌برد.
• هسته سیستم‌عامل یک شمارنده ۳۲ بیتی مکمل (SNE) را نگهداری می‌نماید.
• با عبور SEQ از مرز 0xFFFFFFFF به 0x00000000، شمارنده SNE افزایش می‌یابد.
• محاسبه مقدار MAC روی زنجیره ۶۴ بیتی (SNE || SEQ) صورت می‌گیرد و مانع از پذیرش بسته‌های تکراری می‌شود.

افزون بر این، TCP-AO در برابر نفوذهای کورکورانه مقاومت دارد. بسته‌های غیراستاندارد SYN که با هدف تخریب وضعیت نشست ارسال می‌شوند، قبل از پردازش توسط سیستم‌عامل با پارامترهای MKT بررسی و بی‌اثر می‌گردند.

پیاده‌سازی در هسته لینوکس: معماری CONFIG_TCP_AO و سوکت API

در گذشته نرم‌افزارهای متن‌باز ناچار به استفاده از MD5 بودند زیرا لینوکس از TCP-AO پشتیبانی نمی‌کرد. از نسخه ۶.۷ هسته لینوکس، ماژول CONFIG_TCP_AO به طور رسمی اضافه شد و امکاناتی هم‌رده با تجهیزات تخصصی شبکه ارائه داد.

گزینه‌های سوکت در هسته و ثبت تاپل‌های MKT با دستور Setsockopt

برنامه‌های کاربردی از طریق توابع اختصاصی setsockopt داده‌های MKT را به هسته معرفی می‌کنند:

struct tcp_ao_add cmd;
memset(&cmd, 0, sizeof(cmd));

cmd.tcpa_addr.ss_family = AF_INET;
((struct sockaddr_in *)&cmd.tcpa_addr)->sin_addr.s_addr = inet_addr("198.51.100.1");
cmd.set_current = 1;
cmd.keyid = 1;
cmd.next_keyid = 1;
cmd.alg_name = "cmac(aes128)";
cmd.keylen = 16;
memcpy(cmd.key, "SharedMasterSecret", 16);

setsockopt(sockfd, IPPROTO_TCP, TCP_AO_ADD_KEY, &cmd, sizeof(cmd));

هسته صحت داده‌ها را بررسی کرده، ساختار MKT را به سوکت متصل می‌کند و کلیدهای موقت را هنگام اتصال می‌سازد.

سازگاری عملیاتی با سامانه‌های FRRouting، BIRD و دیمن‌های مسیریابی سازمانی

نرم‌افزارهای مدرن مسیریابی از این رابط به خوبی پشتیبانی می‌کنند:

• سامانه FRRouting (FRR): دستوراتی در بخش router bgp برای تنظیم مستقیم شناسه‌ها، الگوریتم‌ها و رمزهای TCP-AO روی هر همسایه تعبیه کرده است.
• سامانه BIRD: پیکربندی اعتبارسنجی TCP-AO را در بلوک‌های پروتکل BGP امکان‌پذیر می‌سازد.
• سازگاری با تجهیزات گوناگون: مسیریاب‌های لینوکسی با هسته‌های جدید می‌توانند اتصالات منطبق بر RFC 5925 را با دستگاه‌های Cisco IOS-XR و Juniper Junos برقرار کنند.

مقایسه لایه‌های دفاعی: مقایسه TCP-AO و GTSM (RFC 5082) با تونل‌سازی IPsec

انتخاب راهکارهای امنیتی متناسب با ساختار شبکه اهمیت ویژه‌ای دارد:

مکانیزم GTSM (RFC 5082) با بررسی TTL = 255 در پیوندهای مستقیم عملکرد مطلوبی دارد اما در اتصالات چندهاپ کارایی ندارد. استاندارد IPsec رمزگذاری سرتاسری ایجاد می‌کند ولی بار پردازشی بالایی دارد. پروتکل TCP-AO انتخابی متوازن است که یکپارچگی داده‌ها را با کمترین تاخیر سخت‌افزاری تضمین می‌کند.

زیرساخت RiceGuard: مقاوم‌سازی صفحه کنترل BGP در گره‌های لبه‌ای چندابری

مجموعه VPNRice ترافیک کاربران را با اتکا به معماری پیشرفته RiceGuard ایمن می‌سازد. در لایه‌های زیرین تونل‌های رمزگذاری‌شده کاربران، یک شبکه Anycast جهانی قرار دارد که به ارائه‌دهندگان سطح یک (Tier 1) و مراکز تبادل ترافیک متصل است.

پایداری این شبکه گسترده مستلزم حفاظت از صفحه کنترل BGP است:

1. جلوگیری از قطع نشست‌ها: با فعال‌سازی TCP-AO در درگاه‌های مرزی، گره‌های RiceGuard بسته‌های جعلی RST ارسالی از شبکه‌های خارجی را مسدود می‌کنند.
2. چرخش خودکار MKT: کنترل‌کننده‌های مرکزی فرایند تعویض کلیدها را با سیگنال‌های NextKeyID استاندارد RFC 5925 بدون نیاز به توقف سرویس مدیریت می‌کنند.
3. دفاع چندلایه: نشست‌های BGP تحت حفاظت TCP-AO قرار دارند و داده‌های کاربران درون تونل‌های بهینه‌سازی‌شده WireGuard با کمترین تاخیر جابه‌جا می‌شوند.

این ساختار باعث می‌شود پایداری اتصالات کاربران در مواجهه با نوسانات شبکه‌های بالادستی حفظ گردد.

چک‌لیست استقرار در محیط عملیاتی: گذار ایمن از TCP MD5 به استاندارد RFC 5925

گروه‌های فنی و عملیاتی شبکه می‌توانند این گام‌ها را برای استقرار دنبال کنند:

• ارزیابی سیستم‌ها: اطمینان از اینکه سرورهای لینوکس دارای هسته ۶.۷ به بالا بوده و گزینه CONFIG_TCP_AO = y فعال باشد. بررسی سازگاری در سوئیچ‌های شبکه.
• ماتریس پیکربندی MKT: تدوین جدولی شامل شناسه‌های KeyID، نشانی‌های IP و کلیدهای با طول حداقل ۱۲۸ بیت.
• استانداردسازی الگوریتم: انتخاب AES-128-CMAC-96 به عنوان الگوریتم اصلی برای بهره‌مندی از شتاب‌دهنده سخت‌افزاری؛ نگهداری HMAC-SHA-1-96 تنها برای تجهیزات قدیمی.
• برنامه‌ریزی انتقال: تعیین یک بازه اولیه برای تغییر وضعیت نشست‌ها از RFC 2385 به TCP-AO؛ چرخه‌های بعدی کلید به صورت آنلاین انجام خواهد شد.
• اتوماسیون چرخش کلید: تدوین اسکریپت‌هایی برای ارسال سیگنال NextKeyID پیش از سررسید انقضای کلیدها.
• پایش آماری: بررسی شمارنده‌های هسته در مسیر /proc/net/netstat (نظیر TCPAOBadKey و TCPAOGood) به منظور کشف رفتارهای مشکوک در شبکه.