الخلاصة

  • إذا انتهت صلاحية جميع روابط الأمان المنطبقة على RSVP، توصي المسودة بإخطار الإدارة ومعاملة الرابطة الأخيرة كأن عمرها غير محدود إلى أن تُمدد أو تُحذف أو تُستبدل.
  • لا يعني الاستمرار أن التشفير القديم صار آمناً؛ بل يمنع الرجوع إلى رسائل غير موثقة ويتفادى قطع حجوزات قائمة بما قد يوسّع عطلاً في الشبكة.
  • لا يكتمل تبديل المفتاح بمجرد إدخال مفتاح جديد، بل يتطلب رابطة بديلة فعالة في النطاق نفسه، وتداخلاً زمنياً كافياً، وساعات موثوقة، وإتمام المصافحة لدى كل مستقبِل.

انتهى المفتاح عند منتصف الليل. وبعد ثانية واحدة، بقي على الموجّه أن يقرر مصير الرسالة التالية. هذه الثانية هي المسافة بين السياسة المكتوبة والحالة التي تنفذ فعلاً.

نُشرت المراجعة 02 من RSVP Cryptographic Authentication Version 2 في 27 سبتمبر 2026، وهي الآن في مرحلة النداء الأخير داخل مجموعة عمل TEAS. ما زالت Internet-Draft تستهدف احتمال التحول إلى Proposed Standard؛ ليست RFC ولا دليلاً على نشر فعلي لدى شبكة بعينها. وإذا اعتمدت، فستحل محل RFC 2747 وRFC 3097.

تسمّي المسودة الحالة بوضوح «الحالة المرضية». تكون كل روابط الأمان القادرة على حماية تبادل RSVP قد انتهت. الرجوع إلى وضع بلا مصادقة غير مقبول، لكن تعطيل الحجوزات الجارية قد يسبب خللاً أوسع. لذلك ينبغي للنظام إرسال إشعار بانتهاء آخر رابطة، وفي الوقت نفسه معاملتها كأن لها عمراً غير محدود إلى أن تمدد الإدارة مدتها، أو تحذفها، أو تضبط رابطة جديدة.

كانت القاعدة موجودة في المراجعة 01؛ لم تضفها المراجعة 02. الخبر هو أن النص الذي يحمل هذا التوازن وصل إلى مرحلة المراجعة الحالية. انتهاء الصلاحية هنا علامة على انتقال لم يكتمل، لا أمراً آلياً بإيقاف الخدمة.

يستخدم RSVP، كما عرّفه RFC 2205 ووسّعه RFC 3209 للهندسة المرورية، للإشارة إلى حجوزات الموارد. تحمي المسودة الرسائل قفزةً بقفزة عبر كائن INTEGRITY. ويقصد بالمرسل والمستقبِل نظاما RSVP المتجاوران في تلك القفزة، لا بالضرورة طرفا التطبيق.

يحمل الكائن معرّف مفتاح بطول 48 بت، ورقم تسلسل بطول 64 بت، وبيانات المصادقة. يجمع المستقبِل معرّف المفتاح مع عنوان المرسل لاختيار رابطة بعينها. كما تحتوي الرابطة على التحويل التشفيري، ومفتاح المصادقة، والواجهات أو الأقران، ووقت البداية والنهاية. وكل رابطة أحادية الاتجاه.

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

يخلق رقم التسلسل مشكلة بعد إعادة التشغيل. يجب أن يبقى فريداً ومتزايداً طوال عمر المفتاح. وإذا فقد المستقبِل موضعه الحالي، فقد تبدو رسالة قديمة جديدة. لذلك تلزم المسودة التطبيقات بدعم Integrity Handshake، وتوصي بتفعيله افتراضياً. يرسل المستقبِل قيمة cookie غير قابلة للتنبؤ، ويعيدها المرسل مع رقم تسلسله الحالي داخل رد محمي.

على كل جلسة RSVP أن تستخدم هذه المصافحة أو تحفظ حالة التسلسل في تخزين ثابت. يقدّم RFC 4086 وRFC 8937 أساس العشوائية، لكنهما لا يثبتان أي المستقبلين أتم التبادل فعلاً.

تبديل المفتاح فترة تداخل، لا لحظة منفردة. يجب أن يدعم التطبيق رابطتين متزامنتين على الأقل. تبدأ الجديدة قبل نهاية القديمة، ويكون التداخل ضعف مقدار عدم اليقين بين الساعات على الأقل؛ وتذكر المسودة أن خمس دقائق تكفي غالباً. ثم يتعين على كل مستقبِل إجراء المصافحة على الرابطة الجديدة.

لهذا لا تكفي عبارة «تم ضبط المفتاح الجديد». يجب أن تنطبق الرابطة البديلة على نطاق الاتصال نفسه، وأن تصبح فعالة وفق ساعة موثوقة، وأن يستخدمها المرسل ويختارها المستقبِل، وأن تبدأ من رقم تسلسل آمن. من دون واحد من هذه الإيصالات، يعرض المخزون مفتاحين بينما لا تكون عملية الانتقال قد اكتملت.

يدخل الوقت نفسه ضمن سطح الثقة. تطلب المسودة تزامناً كافياً، وتوصي بمصادقة آلية توزيع الوقت. يصف RFC 5905 بروتوكول NTPv4، لكن وجود إعداد NTP لا يثبت الانحراف الفعلي ولا سلامة مصدر الوقت.

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

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

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

تبقى إدارة المفاتيح خارج نطاق المسودة. يجب دعم التوزيع اليدوي، ويمكن إدخال مدة لا نهائية يدوياً مع أن ذلك غير مستحسن. وتوفر IANA سجلاً للتحويلات التشفيرية. يبقى التوافق مع HMAC-MD5 ظاهراً في الصيغة، بينما يشرح RFC 6151 حدود ذلك الإرث. مرونة الخوارزميات لا توصل السر الجديد إلى الجيران الصحيحين.

ينبغي أن يتتبع الحد الأدنى من السجل عملية الانتقال نفسها: معرّف المفتاح وعنوان المرسل، نطاق القرين والواجهة، التحويل، وقتا البداية والنهاية، معرّف البديل، نافذة التداخل، انحراف الساعة، قائمة المستقبلين، حالة مصافحة كل واحد، أول رسالة قُبلت بعد الانتهاء، تسليم الإنذار والإقرار به، والفعل الذي أنهى الاستثناء. لا يوضع السر في السجل، لكن يجب حفظ أصل الحالة.

يفصل هذا السجل بين إنشاء المفتاح، وتفعيل الرابطة، وتهيئة كل مستقبِل بأمان، وتوقف القديمة عن كونها الخيار الوحيد القابل للاستخدام. الحدث الأخير وحده يثبت اكتمال التبديل.

تقدم أولوية الشيفرة العاملة لدى Heng Lu قاعدة القراءة: التاريخ رمز، أما معالجة الحزم فهي الحالة الفعلية. وتسمح المواصفة الأولية الدنيا للبروتوكول المشترك بأن يبقى ضيقاً ويكشف نقطة القرار من دون الاستيلاء على السياسة المحلية. وتحول طبقات الواقع دون مساواة كلمة «منتهي» بدليل أن الثقة توقفت فعلاً.

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

المصادر