تجزئة رسائل IKEv2 في RFC 7383: معالجة سقوط الحزم وحل مشكلات MTU في IPsec

يرتكز تأسيس الأنفاق المشفرة الآمنة بين النقاط الشبكية عبر حزمة بروتوكولات IPsec على الإصدار الثاني من بروتوكول تبادل المفاتيح عبر الإنترنت (IKEv2، المعيار RFC 7296). وعلى الرغم من كفاءة بروتوكول IKEv2 في التفاوض على مفاتيح التشفير والارتباطات الأمنية (SAs) عبر منفذي UDP 500 و4500، فإن المتطلبات الأمنية المؤسسية الحديثة تسببت في تضخم ملحوظ لأحجام الحزم. وأدى الاعتماد الموسع على البنية التحتية للمفاتيح العامة (PKI)—بما تتضمنه من مفاتيح RSA-4096 وسلاسل جهات إصدار الشهادات الوسيطة (CAs) واستجابات فحص حالة الشهادات عبر OCSP—إلى دفع حزم مرحلة المصافحة الثانية (IKE_AUTH) لتجاوز وحدة النقل القصوى (MTU) للشبكة المادية. وتاريخيا، أوكلت أنظمة التشغيل تجزئة هذه الحزم الضخمة إلى طبقة بروتوكول الإنترنت (IP). بيد أن الأجهزة الشبكية الوسيطة تسقط حزم IP المجزأة بانتظام، ما يسفر عن فشل صامت في إتمام الاتصال. ويعالج المعيار RFC 7383 هذا التحدي عبر دمج التجزئة مباشرة ضمن طبقة التطبيق داخل بروتوكول IKEv2 نفسه.

معضلة حجم حزم المصافحة: شهادات PKI وعوائق سعة وحدة النقل القصوى MTU

تبدأ جلسة IKEv2 بتبادل رسائل IKE_SA_INIT للتفاوض على خوارزميات التشفير وإنجاز تبادل مفاتيح ديفي-هيلمان المؤقتة. ولأن هذه المرحلة تتبادل قيما رياضية موجزة وأرقاما عشوائية فقط، فإن حجم حمولتها نادرا ما يتجاوز 500 بايت. غير أن المرحلة اللاحقة 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 الرقمية تفرض إضافة بيانات تفصيلية واسعة:

• شهادة هوية العميل الرقمية (تتراوح بين 1.2 و1.8 كيلوبايت لمفاتيح RSA-4096، أو نحو 600 بايت لمفاتيح ECDSA).
• شهادة أو أكثر لجهات التوثيق الوسيطة لتأكيد سلسلة الثقة وصولا إلى الجذر (تضيف ما بين 1.5 و3.0 كيلوبايت).
• قوائم إلغاء الشهادات (CRL) أو رموز استجابة بروتوكول فحص حالة الشهادات الرقمية (OCSP).
• التوقيعات الرقمية المعتمدة والمحسوبة على كامل بايتات مرحلة التبادل الأولية.

وعند تغليف هذه المعطيات داخل حمولة مشفرة (SK، النوع 46) متبوعة بمتجهات التهيئة ورموز التحقق من السلامة (ICV)، فإن حجم رسالة IKE_AUTH يرتفع عادة ليلامس 3500 إلى 5000 بايت. ويتخطى هذا الرقم سقف 1500 بايت المعتاد في شبكات IPv4، والحد الأدنى الإلزامي في IPv6 البالغ 1280 بايتا.

أسباب إسقاط الأجهزة الشبكية الوسيطة للحزم المجزأة على طبقة بروتوكول الإنترنت

حينما يرسل النظام حزمة UDP بحجم 4000 بايت عبر منفذ شبكي ذي وحدة نقل قصوى تبلغ 1500 بايت، يقسم مكدس الشبكة في نظام التشغيل البيانات إلى أجزاء IP متعاقبة:

1. الجزء الأول: يضم ترويسة IP (20 بايتا)، وترويسة UDP (8 بايتات)، وترويسة IKEv2 (28 بايتا)، و1472 بايتا من البيانات المشفرة.
2. الأجزاء اللاحقة: تضم ترويسة IP وبقية شرائح البيانات فقط، مع غياب تام لترويسة طبقة النقل UDP.

الجزء الأول (الإزاحة 0):
┌───────────┬────────────┬─────────────┬────────────────────────────────────┐
│ ترويسة IP │ ترويسة UDP │ ترويسة IKE  │ حمولة IKE_AUTH المشفرة (القسم 1)   │
└───────────┴────────────┴─────────────┴────────────────────────────────────┘

الجزء الثاني (الإزاحة 1472):
┌───────────┬───────────────────────────────────────────────────────────────┐
│ ترويسة IP │ حمولة IKE_AUTH المشفرة (القسم 2)                              │
└───────────┴───────────────────────────────────────────────────────────────┘
 (غياب ترويسة UDP: تعذر قراءة المنفذ المصدر والوجهة من قبل الجدران النارية)

ويولد هذا القصور الهيكلي إخفاقات اتصال مستمرة عبر مسارات الإنترنت:

• الجدران النارية التفاعلية وبوابات NAT: تتابع هذه الأجهزة التدفقات عبر 4 محددات (IP المصدر، IP الوجهة، منفذ المصدر، منفذ الوجهة). ولأن الأجزاء اللاحقة تفتقر لأرقام منافذ UDP، يعجز الجدار الناري عن ربطها بسجلات التحويل النشطة فيسقطها فورا.
• تشتت مسارات التوزيع المتعدد المتساوي (ECMP): تعتمد الموجهات الأساسية على تجزئة أرقام منافذ الطبقة الرابعة لتوزيع الحمل بين الكابلات المادية. ويؤدي غياب المنفذ إلى توجيه الأجزاء عبر مسارات مختلفة، مما يسبب وصولها دون ترتيب وانتهاء مهلة التجميع.
• قيود معايير IPv6: تحظر معايير IPv6 تماما قيام الموجهات الوسيطة بتجزئة الحزم؛ إذ تقتصر التجزئة على طرفي الاتصال حصرا عبر ترويسات التوسعة. وكثيرا ما تحجب الجدران النارية المؤسسية هذه الترويسات للوقاية من التهديدات.

ويترتب على ذلك اكتمال تبادل IKE_SA_INIT بيسر، في حين تختفي رسالة IKE_AUTH في الطريق دون أثر.

هندسة المعيار RFC 7383: آلية تجزئة الرسائل على طبقة التطبيق داخل بروتوكول IKEv2

يقدم المعيار RFC 7383، الصادر في نوفمبر 2014، نقلة نوعية عبر تحويل عملية التجزئة من الطبقة الثالثة (IP) إلى الطبقة السابعة (بروتوكول IKEv2 التطبيقي). وعوضا عن الاعتماد على مسار التوجيه المادي، يتولى بروتوكول IKEv2 تجزئة الحزم الضخمة إلى حزم UDP متكاملة قبل إرسالها إلى مقبس الشبكة.

إشعار تفاوض الدعم المتبادل 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 (النوع 53)

عند تفعيل هذه التقنية، لا تُغلف الرسائل كبيرة الحجم داخل الحمولة المشفرة المعتادة (SK، النوع 46). بدلا من ذلك، تقسم سلسلة البيانات الصريحة وتوضع كل شريحة داخل حمولة الأجزاء المشفرة (SKF، النوع 53):

                     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، النوع 35). وفي بقية الأجزاء اللاحقة، يضبط الحقل على القيمة صفر.
• رقم الجزء (16 بتا): عداد تسلسلي يبدأ تصاعديا حتى إجمالي الأجزاء.
• إجمالي الأجزاء (16 بتا): العدد الكلي للأجزاء المكونة للرسالة الأصلية.
• متجه التهيئة، والنص المشفر، ورمز ICV: يتمتع كل جزء بغلاف تشفيري منفصل ومستقل بذاته.

ولأن كل جزء يرسل كحزمة UDP متكاملة—بترويسة IP كاملة، وترويسة UDP (المنفذ 500 أو 4500)، وترويسة IKEv2 بسعة 28 بايتا—تتعامل الجدران النارية وموجهات NAT معها كحركة بيانات اعتيادية دون أي تجزئة في طبقة IP.

المعالجة التشفيرية: التحقق المستقل من كل جزء في مقابل إعادة التجميع الشاملة

يرتكز تصميم المعيار RFC 7383 على مبدأ تشفير وتوثيق كل جزء بصورة مستقلة تماما:

1. تقطيع النص الصريح: يجهز الطرف المرسل سلسلة الحمولات الصريحة (IDi | CERT | AUTH | TSi | TSr) ويحدد حجم التقطيع الملائم لسعة MTU، ثم يفرزها إلى N شريحة.
2. التشفير وحساب رمز ICV المستقل: تشفر كل شريحة بمفردها عبر مفاتيح جلسة IKE (SK_e)، ويحسب رمز التحقق ICV على ترويسة IKE وبيانات الجزء والنص المشفر معا.
3. التدقيق السريع قبل الحجز في الذاكرة: بمجرد وصول حزمة SKF، يتحقق الطرف المستقبل أولا من سلامة رمز ICV. فإذا تبين عدم تطابقه، تسقط الحزمة على الفور دون استهلاك سعة تخزين التجميع.
4. تجميع البيانات الصريحة: عند نجاح فك تشفير وتوثيق جميع الأجزاء، يدمج المستقبل شرائح النص الصريح لفك شفرة الرسالة كوحدة موحدة.

آليات الحماية من هجمات إعادة الإرسال والتصدي لهجمات حجب الخدمة بطوفان الأجزاء

قد يفتح التعامل مع الحزم المجزأة مجالا لمحاولات حجب الخدمة (DoS) في حال إغراق المستهدف بأجزاء ناقصة لاستنزاف الذاكرة.

ويطبق المعيار RFC 7383 ضوابط حماية صارمة:

• الارتباط بمعرف الرسالة (Message ID): تتشارك جميع أجزاء الرسالة المنطقية الواحدة نفس معرف Message ID داخل ترويسة IKE. ويربط الطرف المستقبل هذه الأجزاء بسجل الحالة المعتمد حصرا.
• تدرج عداد الرسائل: لا يزداد معرف Message ID مع كل جزء، بل يتم تحديثه فقط بعد اكتمال وصول وتأكيد كافة أجزاء الرسالة.
• مهلات تجميع محدودة: يحدد مكدس البروتوكول نافذة زمنية دقيقة لانتظار الأجزاء (غالبا بين 15 و30 ثانية). ويتم إخلاء الذاكرة فورا إذا انقضت المهلة دون اكتمال الحزمة.
• الاستبعاد الفوري للحزم الضارة: تتيح مصادقة ICV المستقلة لكل جزء إسقاط الحزم المزيفة على الفور دون إشغال موارد النظام.

التوافقية مع معيار عبور موجهات العناوين NAT-T وعلامات non-ESP على المنفذ 4500

تعتمد الأنفاق المشفرة عند العمل خلف موجهات الإنترنت المنزلي أو شبكات الهاتف المحمول على معيار عبور موجهات العناوين (RFC 3948) عبر المنفذ UDP 4500.

ويتكامل المعيار RFC 7383 مع هذه الآلية بصورة متسقة:

حزمة UDP اعتيادية على المنفذ 500:
┌───────────┬────────────┬──────────────┬───────────────────────────────┐
│ ترويسة IP │ UDP (500)  │ ترويسة IKE   │ جزء SKF المشفر                │
└───────────┴────────────┴──────────────┴───────────────────────────────┘

حزمة UDP بتقنية NAT-T على المنفذ 4500:
┌───────────┬────────────┬──────────────┬──────────────┬────────────────┐
│ ترويسة IP │ UDP (4500) │ علامة غير ESP│ ترويسة IKE   │ جزء SKF        │
└───────────┴────────────┴──────────────┴──────────────┴────────────────┘
                         (4 بايتات صفرية)

وعند استشعار وجود بوابة NAT في مرحلة التفاوض، تتحول الجلسة إلى المنفذ UDP 4500. ويسبق ترويسة IKE في هذا المنفذ حقل صفري بسعة 4 بايتات (Non-ESP Marker) لتمييز إشارات التحكم عن بيانات ESP المشفرة. وتلتزم أجزاء RFC 7383 بإرفاق هذه العلامة لحفظ استقرار جداول عناوين NAT.

التطبيق الهندسي الميداني: دمج المعيار RFC 7383 ضمن معمارية RiceGuard

ضمن منظومة تشغيل شبكة VPNRice، يتولى محرك RiceGuard إدارة التوجيه بين أنفاق نواة لينكس WireGuard وبروتوكول OpenVPN وأنظمة IPsec المؤسسية. وتلزم المنظومة بروتوكول IPsec بتطبيق المعيار RFC 7383 بصفة دائمة.

┌────────────────────────────────────────────────────────┐
│             وحدة التحكم في المصافحة RiceGuard          │
└──────────────────────────┬─────────────────────────────┘
                           │
           هل تتجاوز رسالة IKE_AUTH سعة MTU للمسار؟
                           │
             ┌─────────────┴─────────────┐
             │ نعم                       │ لا
             ▼                           ▼
┌──────────────────────────┐   ┌─────────────────────────┐
│ التجزئة إلى أجزاء SKF    │   │ التغليف في حمولة SK     │
│ (سقف التجزئة: 1240 بايتا)│   │ التقليدية (النوع 46)    │
└────────────┬─────────────┘   └────────────┬────────────┘
             │                              │
             └─────────────┬────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│         الإرسال عبر مقبس UDP (المنفذ 500 أو 4500)      │
│  - القضاء التام على تجزئة طبقة IP                      │
│  - توافق كامل مع مسارات موجهات العناوين NAT-T          │
│  - حماية تامة من ظاهرة الثقوب السوداء لسعة MTU         │
└────────────────────────────────────────────────────────┘

ضبط سقف وحدة النقل MTU تكيفيا ومسار الإسناد الخالي من فقدان الحزم في RiceGuard

غالبا ما تنخفض وحدة النقل MTU الفعلية في شبكات الهواتف 4G/5G عن سقف 1500 بايت نتيجة استهلاك الترويسات المغلفة (مثل GTP أو PPPoE). ولضمان نجاح الاتصال دائما، يتبع نظام RiceGuard ضوابط هندسية دقيقة:

1. الضبط الاحترازي لحجم الأجزاء: يحدد نظام RiceGuard الحد الأقصى لحجم أجزاء RFC 7383 عند 1240 بايتا لشبكات IPv4 و1200 بايت لشبكات IPv6، لتفادي الاقتراب من الحد الأدنى لبروتوكول IPv6.
2. استكشاف سعة المسار ديناميكيا: تراقب المنظومة إشعارات ICMP لاحتياج التجزئة وآلية اكتشاف MTU المسار لضبط أحجام المقاطع المتدفقة لحظيا.
3. مسار الإسناد الآمن: في حال فرضت جدران الحماية قيودا خاصة على حزم UDP المجزأة، يحول نظام RiceGuard الجلسة بانسيابية إلى WireGuard أو عبر وسيط HTTPS دون انقطاع الاتصال.

اختبارات الأداء الميدانية لاستقرار الاتصال عبر شبكات الاتصال المقيدة

لقياس فاعلية المعيار RFC 7383، أجريت اختبارات اتصال موسعة عبر 4 بيئات شبكية شاقة بالاعتماد على سلاسل شهادات RSA-4096 (متوسط حمولة IKE_AUTH بلغ 4120 بايتا):

وفي غياب المعيار RFC 7383، أجهضت الجدران النارية نحو 88% من محاولات الربط بسبب قواعد حظر تجزئة IP. وعند تشغيل RFC 7383، استقرت معدلات النجاح عند 100% في جميع البيئات التجريبية، مؤكدة القيمة المحورية للتجزئة على مستوى التطبيق لشبكات IPsec المعتمدة على شهادات PKI.

الممارسات الموصى بها والآفاق المستقبلية لرفع جاهزية مصافحة أنظمة IPsec

يتطلب تشغيل بنية IPsec التحتية بثبات استيفاء القواعد التشغيلية التالية:

• إلزامية تفعيل المعيار RFC 7383: تحقق من ضبط بوابات الوصول البعيد (مثل strongSwan أو Libreswan) لتفعيل تجزئة IKEv2 صراحة في ملفات الإعداد (fragmentation = yes).
• الانتقال إلى خوارزميات المنحنيات الإهليلجية: يقلص التحول إلى شهادات Ed25519 أو ECDSA P-256 حجم البيانات إلى أقل من كيلوبايت واحد، مما يخفف الحاجة إلى تعدد الأجزاء.
• اعتماد حدود تجزئة منضبطة: يوصى بضبط سقف أحجام الأجزاء دون 1280 بايتا لضمان انسياب الحزم دون عوائق عبر شبكات IPv6 وشبكات الهواتف المشفرة.

وبفصل سلامة المصافحة عن تجزئة بروتوكول الإنترنت في الطبقة الثالثة، يحول المعيار RFC 7383 بروتوكول IPsec إلى بنية تشفير متينة تفي بمتطلبات الشبكات الحديثة.