خردسازی پیام‌های IKEv2 استاندارد RFC 7383: رفع افت بسته و چالش MTU در IPsec

برقراری ارتباطات نقطه به نقطه در بستر امن IPsec متکی بر پروتکل تبادل کلید نسخه ۲ (IKEv2 مطابق RFC 7296) است. هرچند IKEv2 فرایند توافق بر سر مشخصات رمزنگاری و ارتباطات امن (SA) را از طریق درگاه‌های UDP 500 و 4500 به شکل کارآمدی مدیریت می‌کند، نیازهای امنیتی سازمانی نوین حجم این بسته‌ها را به شدت افزایش داده است. الزام به استفاده از زیرساخت کلید عمومی (PKI)—شامل کلیدهای حجیم RSA-4096، زنجیره‌های متوالی مراکز صدور گواهی (CA) و استعلام‌های وضعیت برخط OCSP—باعث می‌شود اندازه بسته مرحله دوم تبادل کلید (IKE_AUTH) به مراتب از حداکثر واحد انتقال فیزیکی (MTU) شبکه فراتر رود. در گذشته، سیستم‌های عامل مدیریت این بسته‌های پرحجم UDP را به مکانیسم تکه‌تکه‌سازی در لایه شبکه (IP) واگذار می‌کردند. با این وجود، تجهیزات میانی و دیواره‌های آتش در مسیرهای عبور عمومی معمولا این قطعات را مسدود می‌کنند که منجر به عدم برقراری تونل ارتباطی می‌شود. مشخصه RFC 7383 با انتقال سازوکار خردسازی به لایه کاربردی درون خود موتور پروتکل IKEv2، این نارسایی ساختاری را برطرف کرده است.

چالش اندازه تبادل کلید: گواهی‌های هویت PKI و سقف ظرفیت MTU شبکه

ارتباط IKEv2 با مرحله IKE_SA_INIT آغاز می‌شود که وظیفه تعیین الگوریتم‌های رمزنگاری و انجام تبادل کلید موقت دیفی-هلمن را بر عهده دارد. از آنجا که IKE_SA_INIT تنها پارامترهای ریاضی کوتاه و مقادیر تصادفی را جابه‌جا می‌کند، حجم بار داده آن به ندرت به ۵۰۰ بایت می‌رسد. در مقابل، مرحله بعدی یعنی IKE_AUTH باید فرایند احراز هویت را انجام داده و مالکیت کلیدهای اختصاصی را اثبات کند.

آغازگر (Initiator)                                       پاسخ‌دهنده (Responder)
┌───────────────────────────────────────────────┐         ┌───────────────────────────────────────────────┐
│ HDR, SAi1, KEi, Ni                            ├────────>│                                               │
│                                               │<────────┤ HDR, SAr1, KEr, Nr, [CERTREQ]                 │
│                                               │         └───────────────────────────────────────────────┘
│ پیام درخواست IKE_AUTH (معمولا > 3000 بایت)    │
│ HDR, SK { IDi, CERT, CERTREQ, AUTH, SAi2... } ───> [تجاوز از سقف MTU: نیاز به خردسازی داده‌ها]
└───────────────────────────────────────────────┘

افزایش چشمگیر حجم بسته داده‌های IKE_AUTH در زیرساخت‌های مدرن هویت دیجیتال

در سناریوهای مبتنی بر کلید اشتراکی اولیه (PSK)، داده‌های تبادلی IKE_AUTH کوچک باقی می‌مانند. با این حال، معماری‌های مبتنی بر اعتماد صفر بهره‌گیری از گواهی‌های دیجیتال متقابل X.509 را ضروری می‌دانند. یک بسته گواهی استاندارد شامل بخش‌های زیر است:

• گواهی هویت کاربر نهایی (بین ۱.۲ تا ۱.۸ کیلوبایت برای کلیدهای RSA-4096 و حدود ۶۰۰ بایت برای الگوریتم ECDSA).
• یک یا چند گواهی میانی برای تکمیل زنجیره اعتماد تا مرجع ریشه (افزودن ۱.۵ تا ۳.۰ کیلوبایت داده).
• فهرست‌های لغو گواهی (CRL) یا پاسخ‌های برخط وضعیت گواهی (OCSP).
• امضاهای دیجیتال محاسباتی روی تمامی بایت‌های مراحل اولیه تبادل.

زمانی که این اطلاعات درون یک محفظه رمزشده (SK، نوع ۴۶) همراه با بردارهای اولیه و کدهای تایید درستی (ICV) قرار می‌گیرند، بسته IKE_AUTH معمولا به حجمی میان ۳۵۰۰ تا ۵۰۰۰ بایت می‌رسد. این اندازه بسیار بیشتر از استاندارد معمول ۱۵۰۰ بایتی در IPv4 و سقف حداقلی ۱۲۸۰ بایتی در IPv6 است.

دلایل حذف بسته‌های تکه‌تکه‌شده در لایه IP توسط تجهیزات میانی شبکه

هنگامی که یک فرستنده بسته UDP به حجم ۴۰۰۰ بایت را روی درگاهی با MTU معادل ۱۵۰۰ بایت ارسال می‌کند، پشته شبکه سیستم‌عامل آن را به چند بخش مجزا در لایه IP تقسیم می‌نماید:

1. قطعه اول: شامل سربرگ IP (۲۰ بایت)، سربرگ UDP (۸ بایت)، سربرگ پروتکل IKEv2 (۲۸ بایت) و ۱۴۷۲ بایت داده‌های کاربردی.
2. قطعات بعدی: تنها حاوی سربرگ IP و ادامه داده‌های رمزشده بوده و کاملا فاقد سربرگ UDP هستند.

قطعه اول (موقعیت 0):
┌───────────┬────────────┬─────────────┬────────────────────────────────────┐
│ سربرگ IP  │ سربرگ UDP  │ سربرگ IKE   │ داده‌های رمزشده IKE_AUTH (بخش اول)  │
└───────────┴────────────┴─────────────┴────────────────────────────────────┘

قطعه دوم (موقعیت 1472):
┌───────────┬───────────────────────────────────────────────────────────────┐
│ سربرگ IP  │ داده‌های رمزشده IKE_AUTH (بخش دوم)                            │
└───────────┴───────────────────────────────────────────────────────────────┘
 (فاقد سربرگ UDP: دستگاه‌های میانی امکان بازرسی درگاه مبدا و مقصد را ندارند)

این ساختار پیامدهای منفی عمیقی در شبکه‌های عمومی بر جای می‌گذارد:

• دیواره‌های آتش پایش وضعیت و درگاه‌های NAT: این تجهیزات ارتباطات را بر پایه ۴ پارامتر (IP مبدا، IP مقصد، پورت مبدا، پورت مقصد) رهگیری می‌کنند. از آنجا که قطعات تکمیلی فاقد سربرگ پورت UDP هستند، سامانه میانی نمی‌تواند آن‌ها را به جدول نگاشت پیوند دهد و بی‌تردید آن‌ها را رها می‌کند.
• توزیع نامتوازن در مسیرهای موازی (ECMP): مسیریاب‌های شبکه برای توازن بار از اطلاعات پورت‌های لایه ۴ استفاده می‌کنند. بسته‌های فاقد پورت در مسیرهای متفاوتی قرار می‌گیرند که سبب دریافت نامنظم و منقضی شدن زمان بازسازی در مقصد می‌گردد.
• الزامات ویژه پروتکل IPv6: در معماری IPv6 مسیریاب‌های میانی مجاز به تکه‌تکه‌سازی بسته‌ها نیستند و این امر تنها در دو نقطه انتهایی از طریق سربرگ‌های افزونه میسر است. بسیاری از دروازه‌های امنیتی شرکتی برای پیشگیری از نفوذ، این سربرگ‌ها را بلافاصله مسدود می‌سازند.

در نتیجه، مرحله IKE_SA_INIT بدون مشکل به پایان می‌رسد اما IKE_AUTH در میانه راه مسدود شده و تونل در یک حلقه معطل باقی می‌ماند.

معماری استاندارد RFC 7383: سازوکار خردسازی داده‌ها در لایه کاربردی درون IKEv2

استاندارد RFC 7383 مصوب نوامبر ۲۰۱۴، مسئولیت خردسازی داده‌ها را از لایه ۳ (IP) به لایه ۷ (منطق پردازش در پروتکل IKEv2) واگذار کرد. در این مدل، پروتکل IKEv2 پیش از ارسال داده‌ها به سوکت شبکه، بسته بزرگ را در لایه کاربردی به قطعات کوچک و استاندارد تقسیم می‌کند.

پیام مذاکره قابلیت‌های اتصال IKEV2_FRAGMENTATION_SUPPORTED

خردسازی داده در لایه کاربردی نیازمند توافق طرفین است. گره‌های شبکه در طول تبادل IKE_SA_INIT با مبادله پیام اعلام وضعیت IKEV2_FRAGMENTATION_SUPPORTED (کد نوع 16430) توانایی خود را در این زمینه ابراز می‌نمایند:

آغازگر                                      پاسخ‌دهنده
┌────────────────────────────────┐         ┌────────────────────────────────┐
│ درخواست IKE_SA_INIT            │         │ پاسخ IKE_SA_INIT               │
│   N(IKEV2_FRAGMENTATION_       ├────────>│   N(IKEV2_FRAGMENTATION_       │
│     SUPPORTED)                 │<────────┤     SUPPORTED)                 │
└────────────────────────────────┘         └────────────────────────────────┘

در صورتی که هر دو سوی ارتباط این اعلان را ارسال نمایند، ارسال پیام‌های خردشده در فازهای بعدی معتبر خواهد بود. چنانچه یکی از طرفین این شاخص را ارسال نکند، فرایند به روال سنتی و بدون خردسازی بازمی‌گردد.

بار داده‌های رمزشده تکه‌تکه‌شده: ساختار دودویی SKF (نوع ۵۳)

هنگامی که این قابلیت فعال است، پیام‌های بزرگ دیگر در قالب بار رمزشده استاندارد (SK، نوع ۴۶) قرار نمی‌گیرند. محتوای داده‌های آشکار به قطعات مجزا خرد شده و هر بخش در یک بار داده رمزشده تکه‌تکه‌شده (SKF، نوع ۵۳) تعبیه می‌شود:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| بار بعدی      |C|   رزروشده   |          طول کل بار           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          شماره قطعه           |           مجموع قطعات         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      بردار اولیه (IV)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    داده‌های رمزشده قطعه                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     کد کنترل درستی (ICV)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

مشخصات فیلدهای ساختاری:

• بار بعدی: در اولین قطعه (شماره قطعه = 1)، این بخش نوع اولین داده پنهان (مانند شناسه IDi، نوع ۳۵) را تعیین می‌کند. در تمامی قطعات بعدی، این مقدار برابر با صفر تنظیم می‌شود.
• شماره قطعه (۱۶ بیت): شمارنده صعودی از عدد ۱ تا مجموع قطعات.
• مجموع قطعات (۱۶ بیت): تعداد کل بخش‌های تشکیل‌دهنده پیام اصلی.
• IV، داده‌های رمزشده و ICV: هر قطعه دارای یک پوشش امنیتی مستقل است.

به سبب آن‌که هر قطعه به عنوان یک بسته UDP استاندارد همراه با سربرگ IP، سربرگ UDP (پورت ۵۰۰ یا ۴۵۰۰) و سربرگ ۲۸ بایتی IKE ارسال می‌شود، دیواره‌های آتش آن‌ها را بسته‌های مستقل شبکه تلقی نموده و هیچ‌گونه تکه‌تکه‌سازی در لایه IP رخ نمی‌دهد.

پردازش رمزنگاری: تایید اصالت مستقل هر قطعه در برابر بازسازی یکپارچه پیام

نوآوری مهم استاندارد RFC 7383 در رمزنگاری و تایید اصالت مستقل هر یک از قطعات نهفته است:

1. خردسازی داده‌های اولیه: فرستنده زنجیره محتوای داخلی (IDi | CERT | AUTH | TSi | TSr) را با احتساب ظرفیت MTU مسیر به N قطعه متوالی تقسیم می‌کند.
2. رمزگذاری مستقل و ایجاد کد درستی ICV: هر بخش با بهره‌گیری از کلیدهای امن ارتباطی (SK_e) به تنهایی رمزگذاری شده و مقدار کنترل درستی ICV روی سربرگ IKE، مشخصات قطعه و داده‌های رمزشده محاسبه می‌شود.
3. اعتبارسنجی پیش از ورود به بافر: به محض دریافت بسته حاوی داده‌های SKF، گیرنده ابتدا مقدار ICV را ارزیابی می‌کند. بسته‌های دارای مغایرت بدون تخصیص حافظه بی‌درنگ دور ریخته می‌شوند.
4. سرهم‌بندی داده‌های آشکار: پس از رمزگشایی و تایید تمامی N قطعه معتبر، گیرنده بخش‌های آشکار را به هم متصل نموده و کل پیام را به صورت یکجا مورد پردازش قرار می‌دهد.

محافظت در برابر حملات تکرار داده و مقابله با حملات منع سرویس ناشی از سیل قطعات

مدیریت بسته‌های چندبخشی در صورت عدم رعایت ضوابط می‌تواند سیستم را در برابر حملات منع سرویس (DoS) آسیب‌پذیر کند.

استاندارد RFC 7383 تدابیر بازدارنده‌ای را مقرر نموده است:

• پیوستگی شناسه پیام (Message ID): تمامی قطعات متعلق به یک پیام منطقی باید شناسه Message ID یکسانی را در سربرگ IKE حمل کنند. سامانه گیرنده قطعات را به حالت ارتباطی مشخصی مقید می‌سازد.
• روال پیشروی شمارنده پیام: مقدار Message ID با ارسال هر قطعه تغییر نمی‌کند، بلکه تنها پس از دریافت تاییدیه کل بسته چندقطعه‌ای افزایش می‌یابد.
• سقف زمانی بازسازی داده‌ها: سامانه‌ها مهلت مشخصی (معمولا بین ۱۵ تا ۳۰ ثانیه) برای دریافت قطعات تعیین می‌کنند و داده‌های ناقص پس از انقضای زمان پاکسازی می‌شوند.
• پالایش بی‌درنگ ترافیک مخرب: به دلیل وجود امضای مستقل در هر قطعه، داده‌های جعلی یا ارسالی مجدد پیش از تحمیل بار پردازشی به حافظه موقت حذف می‌گردند.

سازگاری با استاندارد عبور از NAT (RFC 3948) و نشانگرهای غیر ESP روی پورت ۴۵۰۰

تونل‌های امنیتی در شبکه‌های خانگی و بسترهای سلولی از فناوری عبور از NAT (RFC 3948) برای هدایت ترافیک بر بستر پورت UDP 4500 بهره می‌گیرند.

مشخصات RFC 7383 با این ساختار هماهنگی کامل دارد:

بسته UDP استاندارد روی پورت ۵۰۰:
┌───────────┬────────────┬──────────────┬───────────────────────────────┐
│ سربرگ IP  │ UDP (500)  │ سربرگ IKE    │ قطعه رمزشده SKF               │
└───────────┴────────────┴──────────────┴───────────────────────────────┘

بسته UDP فناوری NAT-T روی پورت ۴۵۰۰:
┌───────────┬────────────┬──────────────┬──────────────┬────────────────┐
│ سربرگ IP  │ UDP (4500) │ غیر ESP (0)  │ سربرگ IKE    │ قطعه SKF       │
└───────────┴────────────┴──────────────┴──────────────┴────────────────┘
                         (۴ بایت مقدار صفر)

با شناسایی حضور دستگاه NAT در فاز اولیه، تبادلات به پورت ۴۵۰۰ منتقل می‌شود. در این پورت ۴ بایت مقدار صفر (Non-ESP Marker) در ابتدای بسته درج می‌گردد تا ترافیک کنترل IKE از داده‌های رمزشده ESP تفکیک شود. قطعات تولیدشده در RFC 7383 نیز این ساختار را رعایت می‌کنند تا پیوستگی مسیر ثبت‌شده در تجهیزات NAT برقرار بماند.

پیاده‌سازی مهندسی: ادغام مشخصات RFC 7383 در ساختار معماری RiceGuard

سامانه VPNRice هسته ارتباطی RiceGuard را برای ایجاد هماهنگی در مسیریابی میان بسترهای هسته لینوکس WireGuard، OpenVPN و ارتباطات سازمانی IPsec به کار می‌گیرد. برای اتصالات IPsec، سامانه RiceGuard انطباق با استاندارد RFC 7383 را به صورت پیش‌فرض فعال می‌سازد.

┌────────────────────────────────────────────────────────┐
│             کنترل‌کننده تبادل کلید RiceGuard            │
└──────────────────────────┬─────────────────────────────┘
                           │
           آیا بسته IKE_AUTH از سقف MTU فراتر رفته است؟
                           │
             ┌─────────────┴─────────────┐
             │ بله                       │ خیر
             ▼                           ▼
┌──────────────────────────┐   ┌─────────────────────────┐
│ خردسازی به قطعات SKF     │   │ بسته‌بندی در قالب بار   │
│ (تنظیم سقف: 1240 بایت)   │   │ معمول SK (نوع ۴۶)       │
└────────────┬─────────────┘   └────────────┬────────────┘
             │                              │
             └─────────────┬────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│         ارسال به سوکت UDP (درگاه ۵۰۰ یا ۴۵۰۰)          │
│  - حذف کامل تکه‌تکه‌سازی در لایه IP                     │
│  - حفظ پیوستگی در گذر از تجهیزات NAT                   │
│  - مصونیت کامل در برابر مسدود شدن داده‌ها در MTU      │
└────────────────────────────────────────────────────────┘

تنظیم خودکار سقف MTU و مسیر جایگزین بدون افت بسته در سامانه RiceGuard

در شبکه‌های تلفن همراه و خطوط ارتباطی اپراتورها، سقف عملیاتی MTU به دلیل سربرگ‌های اضافی (مانند تونل‌های GTP یا پروتکل PPPoE) معمولا کمتر از ۱۵۰۰ بایت است. سامانه RiceGuard سازوکارهایی را پیاده‌سازی کرده است:

1. تعیین سقف محافظه‌کارانه برای قطعات: سامانه RiceGuard اندازه قطعات را در IPv4 روی ۱۲۴۰ بایت و در IPv6 روی ۱۲۰۰ بایت مهار می‌کند که پایین‌تر از حداقل ۱۲۸۰ بایتی IPv6 بوده و از تقسیم بسته در لایه IP جلوگیری می‌کند.
2. کاوش مستمر اندازه بسته در مسیر: سامانه با تحلیل پیام‌های ICMP و سازوکار PMTU، ابعاد قطعات ارسالی را به صورت پویا تنظیم می‌نماید.
3. انتقال بدون اختلال به مسیر جانبی: چنانچه فایروال یک شبکه ترافیک UDP را با اختلال مواجه کند، سامانه RiceGuard بدون قطعی ارتباط را به پروتکل WireGuard یا پروکسی HTTPS منتقل می‌سازد.

نتایج آزمایش‌های میدانی پایداری اتصال در بسترهای محدود اپراتورهای مخابراتی

برای بررسی عملی دستاوردهای استاندارد RFC 7383، آزمایش‌های متعددی در چهار محیط شبکه چالش‌برانگیز با بهره‌گیری از زنجیره گواهی‌های RSA-4096 (میانگین حجم بار ۴۱۲۰ بایت) به انجام رسید:

در نبود استاندارد RFC 7383، دیواره‌های آتش سازمانی نزدیک به ۸۸ درصد تلاش‌های برقراری اتصال را به سبب محدودیت‌های لایه IP مسدود می‌ساختند. به‌کارگیری این استاندارد نرخ موفقیت را در تمامی سناریوها به ۱۰۰ درصد رساند که لزوم خردسازی در لایه کاربردی را در شبکه‌های امن مبتنی بر زیرساخت گواهی دیجیتال به اثبات می‌رساند.

الگوهای بهینه‌سازی اجرایی و چشم‌انداز تبادل کلید پایدار در اتصالات امن IPsec

پیاده‌سازی پایدار اتصالات امن IPsec در زیرساخت‌های فناوری اطلاعات نیازمند توجه به موارد زیر است:

• فعال‌سازی همگانی استاندارد RFC 7383: اطمینان حاصل نمایید که نرم‌افزارهای مدیریت تونل (مانند strongSwan یا Libreswan) در فایل‌های پیکربندی خود قابلیت خردسازی پیام را فعال کرده باشند (fragmentation = yes).
• گذار به الگوریتم‌های منحنی بیضوی: استفاده از گواهی‌های Ed25519 یا ECDSA حجم داده‌ها را به زیر ۱ کیلوبایت کاهش می‌دهد و نیاز به خردسازی چندمرحله‌ای را به حداقل می‌رساند.
• تنظیم آگاهانه سقف قطعات: توصیه می‌شود حداکثر اندازه قطعات ارسالی کمتر از ۱۲۸۰ بایت تعیین گردد تا جابه‌جایی بسته‌ها در بستر IPv6 بدون مانع انجام پذیرد.

با رهایی از وابستگی به تکه‌تکه‌سازی شکننده در لایه شبکه، استاندارد RFC 7383 بستر IPsec را به سازوکاری مقاوم و منطبق با نیازهای شبکه‌های سازمانی بدل ساخته است.