الخلاصة

  • تقترح draft-smyslov-ipsecme-ikev2-psp-02 إتمام مصادقة النظيرين داخل IKE SA بلا Child SA، ثم استخدام CREATE_CHILD_SA معدل يحمل Key Download في الاتجاهين؛ يرسل كل مستقبل المفتاح الذي سيستخدمه الطرف الآخر للإرسال إليه.
  • تثبت الاستجابة علاقة بين النظير الموثق ومحددات المرور وSPI ومعلمات PSP ومادة مفتاح مغلفة. لكنها لا تثبت تركيب المفتاح في NIC المرسل، ولا اشتقاقه وقبول ICV لدى المستقبل، ولا عبور حزمة واحدة.
  • لا يتيح PSP إبطالاً منفرداً للمفاتيح المشتقة، ويترك منع replay لطبقة أخرى. لذلك يحتاج تبديل SA والتدوير المزدوج والإخلاء وقرار الإعادة والنتيجة التطبيقية إلى إيصالات منفصلة.

التدوير الأول يغيّر المستقبل ولا يمحو الماضي

تملك NIC المستقبلة في PSP مفتاحين رئيسيين. عندما يصبح الثاني نشطاً، تُنشأ الارتباطات الجديدة تحته، لكن الارتباطات التي بدأت تحت الأول قد تستمر. يحتاج المستقبل إلى إبقاء المفتاح القديم كي يشتق مفاتيحها من SPI الموجود في الحزمة.

تقول مواصفة بنية PSP إن الإخلاء الفعلي لمفتاح رئيسي يتطلب «تدويراً مزدوجاً». يجب نقل الاتصالات القديمة إلى SA جديدة قبل التدوير التالي. الوصول إلى لحظة «المفتاح النشط تغير» ليس إذن دليلاً على أن الحقبة السابقة خرجت من التنفيذ.

تعالج draft-smyslov-ipsecme-ikev2-psp-02 وسيلة نقل مفاتيح SA الجديدة. نسختا HTML وXML تحددان التدفق نفسه، لكنهما لا تقدمان سجل انتقال المرور ولا إيصال حذف الحالة القديمة. كما أن قسم Security Considerations ما زال «To be added». ينبغي ألا يتحول هذا الفراغ إلى ضمان غير مكتوب.

المستقبل يختار مفتاحاً سيستخدمه المرسل

يصمم PSP جهة الاستقبال بحيث لا تخزن مفتاحاً مستقلاً لكل SA. تُشتق المادة من مفتاح رئيسي ومن SPI. تحدد البتة العليا من SPI أي مفتاح رئيسي يُستخدم، ويجب ألا يعاد استعمال SPI تحت المفتاح نفسه.

بما أن المستقبل وحده يعرف الحقبة النشطة، فهو الذي يختار SPI والمفتاح المتوافق معه. ثم يرسل المفتاح إلى النظير. يستخدم النظير هذه المادة عندما يرسل حركة باتجاه ذلك المستقبل. ولأن SA في PSP أحادية الاتجاه، يحتاج الاتجاه العكسي إلى مفتاح آخر اختاره المستقبل الآخر.

هذه الدلالة الاتجاهية أساسية. عندما يرسل A حمولة KD إلى B، لا يكون A قد جهز مسار إرساله؛ بل سلّم B ما يلزمه كي يرسل إلى A. إذا سجل النظام «تم تبادل المفتاح» بلا اتجاه، فقد تخفي صحة اتجاه واحد تعطل الاتجاه الآخر.

يشتق RFC 7296 مفاتيح Child SA العادية من أسرار IKE وnonces. يحتاج PSP إلى مادة يتحكم بها المستقبل، لذلك تعيد المسودة استخدام Key Download الوارد في RFC 9838 لتبادل أحادي بين نظيرين. النقل المحمي لا يساوي التركيب المحلي.

المصادقة تسبق تسليم السر

يتفق الطرفان في IKE_SA_INIT على Key Wrap Algorithm، ويرسل المستجيب الداعم CHILDLESS_IKEV2_SUPPORTED. يتيح RFC 6023 إنشاء IKE SA من دون محاولة إنشاء Child SA فوراً.

لا تسمح المسودة بإنشاء PSP SA داخل IKE_AUTH. لو فعلت، لاضطر المبادر إلى إرسال مفتاح استقباله قبل اكتمال مصادقة المستجيب. لذلك تُنجز المصادقة أولاً، ثم تنتقل مادة PSP في CREATE_CHILD_SA لاحق.

هذا ترتيب أمني مهم، لكنه لا يثبت جاهزية العتاد. قد تمثل هوية IKE خدمة تحكم تدير عدة بطاقات أو وظائف افتراضية أو مسرعات. توثيق الخدمة لا يسمي تلقائياً الكائن الذي سينفذ التشفير.

كما أن الاتفاق على خوارزمية التغليف لا يجعل IKE SA مخصصة لـPSP؛ تنص المسودة على إمكان إنشاء SA من نوع ESP وPSP تحتها. القدرة والمصادقة والطلب والتسليم والتركيب حالات مختلفة.

الرسالة تربط المعاني ولا تبرمج بطاقة الشبكة

يحمل CREATE_CHILD_SA المعدل معرف بروتوكول PSP وتحويل PSP Parameters لا يزالان <TBA>، إضافة إلى Traffic Selectors وSPI وحمولة KD واحدة في كل اتجاه. يطابق SPI في Key Bag اقتراحاً، وتحمل SA_KEY المادة المغلفة بواسطة SK_w = prf+(SK_d, "Key Wrap for PSP").

هذه الروابط ممتازة للتدقيق: من هو النظير، وما المرور المقصود، وما SPI والمعلمة والمفتاح المغلف. لكنها تتوقف قبل واجهة البرنامج مع NIC.

يضم مستودع PSP المؤرشف تطبيقاً مرجعياً واختبارات، وتعرض المواصفة عدة تصاميم لمفاتيح الإرسال: جدول تدفق على الشريحة، قاعدة SA في الذاكرة، أو مفتاح/مرجع مع واصف الإرسال. تختلف السعة والتأخير والفشل في كل تصميم. وجود الكود العام لا يثبت منتجاً أو نشراً أو عملية تركيب ذرية.

ينبغي أن يربط إيصال التركيب SPI والاتجاه والخوارزمية والحقبة ببطاقة أو وظيفة أو صف أو كائن SA محدد، وأن يسجل نتيجة السائق من دون كشف المفتاح نفسه. عندها فقط يمكن القول إن مادة التحكم بلغت سطح التنفيذ الصحيح.

«بلا حالة» لا يعني بلا عهدة

يخفض PSP تخزين مفاتيح الاستقبال لكل SA، لكنه يحتفظ بالمفاتيح الرئيسية والحقبة النشطة ومساحة SPI وأعمار SA والتدوير. يحتفظ المرسل بمفاتيح الإرسال. وقد تحتفظ الطبقة العليا بقائمة SPI مسموح بها لكل socket.

يفصل RFC 4301 إدارة SA عن السياسة ومعالجة الحزم، ويفعل RFC 4303 الشيء نفسه مع ESP. يغير PSP موضع الحالة، ولا يلغي سلسلة السيطرة والتنفيذ.

ولا تتحول اعتبارات المقياس إلى benchmark. تتحدث مواصفة PSP عن ملايين الارتباطات ومعدلات عالية لتحديث المفاتيح، لكنها لا تقدم قياساً لبطاقة مسماة. قد ينجح IKE بينما تمتلئ جداول الإرسال أو تتراكم أوامر البرمجة.

الحزمة الاختبارية تمنح كل مرحلة صوتاً

تطلب المواصفة عدادات لنجاح TX/RX والحزم والبايتات، وفشل المصادقة أو التشفير، وأخطاء التنسيق واختيار المفتاح الرئيسي. كما تطلب علامة نجاح فك التشفير/المصادقة وإتاحة SPI للبرمجيات العليا.

يمكن تشغيل canary محدود بعد التسليم. يُحفظ تبادل IKE وإقرار التركيب، ثم ترسل حزمة PSP معروفة. يسجل المرسل SPI وIV وزيادة TX. يسجل المستقبل حقبة المفتاح الرئيسي والاشتقاق وقرار ICV وزيادة RX. تؤكد الطبقة العليا وصول المحتوى المتوقع.

لا يثبت ذلك كل المرور المستقبلي، لكنه يربط الادعاء بحزمة فعلية. إذا زاد TX ولم يزد RX الموثق، يبحث التشغيل في المسار أو التغليف أو النسخة أو الحقبة أو ICV. وإذا نجح RX ولم تصل التطبيق، ينتقل البحث إلى قائمة SPI أو النقل أو التطبيق.

Rekey يبدأ فترة تداخل

يمكن لـREKEY_SA تسمية SA المراد استبدالها. النمط العام في IKEv2 هو إنشاء SA جديدة، نقل المرور، ثم حذف القديمة. استجابة الإنشاء لا تثبت النقل أو الحذف.

يحتاج السجل إلى SPI الجديد وإقرار تركيبه وأول حزمة مقبولة عليه وآخر حزمة على القديم وتغيير المصنف والحذف لدى الطرفين والخسارة أو إعادة الترتيب. وجود كائن جديد لا يعني أن مسار الإرسال اختاره.

ثم تأتي ساعة المفتاح الرئيسي. بعد التدوير الأول، تظل SA القديمة صالحة للاشتقاق. وقبل التدوير الثاني يجب نقلها. ولأن PSP لا يوفر إبطالاً منفرداً للمفاتيح المشتقة، فإن وسم «ملغى» في قاعدة الإدارة قرار لا أثر تشفيرياً له حتى تكتمل الهجرة والإخلاء.

replay مسؤولية انتقلت إلى طبقة أخرى

لا يقدم PSP حماية replay؛ يفترض أن يوفرها TCP أو نقل آخر. لا تغير مسودة IKEv2 هذا الحد. قد تكون الحزمة صحيحة ICV ومع ذلك تحتاج إلى حكم بأنها مكررة.

هذا لا يثبت أن أي نشر بعينه بلا حماية. يثبت فقط أن من يدعي رفض replay يجب أن يسمي الطبقة والحالة والملاحظة والقرار. لا يكفي وجود SPI أو IV أو نجاح المصادقة.

ينبغي أيضاً فصل replay الشبكي عن تكرار عملية تطبيقية. قد تقبل طبقة النقل الحزمة مرة واحدة بينما يعيد الطلب أثراً تجارياً. كل مستوى يحتاج دليله.

المراجعة 02 تجدد الوثيقة ولا تضيف ضماناً

تسجل واجهة Datatracker المراجعة 02 في 30 سبتمبر 2026 وانتهاءها في 3 أبريل 2027. تصفها صفحة الوثيقة بأنها Internet-Draft فردية نشطة، ويعرض السجل ثلاث مراجعات.

لا يغير الفرق عن 01 سوى التاريخ والرقم والانتهاء والرؤوس. النص التقني ثابت. يذكر الرأس أن المقصود Experimental، لكن Datatracker لا يسجل RFC أو stream أو AD مسؤولاً أو مستوى معياري. لا تعني إعادة النشر اعتماداً أو مراجعة أمنية أو تشغيلاً.

تظل القيم المطلوبة <TBA>. سجل IANA لمعلمات IKEv2 هو المرجع للقيم المخصصة؛ الطلب في المسودة ليس تخصيصاً.

المصادر والحدود

تعتمد المادة على نص/HTML/XML للمراجعة 02، وDatatracker، وRFC 7296، وRFC 6023، وRFC 9838، وRFC 4301، وRFC 4303، وIANA، ومستودع PSP ومواصفته. لا تثبت هذه المصادر تبنياً أو إنتاجاً أو أداءً أو امتثالاً أو ثغرة أو حادثاً أو نتيجة خدمة.