الخلاصة

  • تقترح المسودة الفردية draft-acee-lsr-ospfv3-deprecate-ah-00، المقدمة في 30 سبتمبر، عدم الاستمرار في استخدام رأس التوثيق AH من IPsec لحماية OSPFv3. وهي تنصح التنفيذات الجديدة بألا تضيفه، وتسمح للتنفيذات القديمة بالإبقاء عليه للتوافق، وتوجّه إلى ESP بتشفير NULL أو ذيل التوثيق المحدد سلفاً في RFC 7166. حالة الوثيقة في Datatracker هي Internet-Draft فردية نشطة وI-D Exists، لا تعديل نافذ لـ RFC 4552.
  • تجعل المسودة الاتفاق على مستوى الوصلة شرطاً للانتقال. ويوضح RFC 7166 أن اختلاف معرّف اقتران الأمان أو نوع التوثيق أو بصمة الرسالة قد يمنع قيام الجوار، بينما قد يقبل نمط انتقالي متساهل رزماً غير موثقة. وصول الجيران إلى حالة «متصل» ليس وحده دليلاً على استمرار سلامة التوثيق.

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

يجب ضبط صفة الخبر أولاً. تظهر عبارة «Link State Routing Working Group» على غلاف النص، لكن سجل Datatracker يصنفه وثيقة فردية نشطة وحالة IESG فيه I-D Exists. كما أن الغلاف يقول إنه سيحدّث RFC 4552 «إذا أُقرّ». لا يجوز تحويل هذه الصيغة المشروطة إلى إجماع عمل أو قرار معياري مطبق أو إلزام فوري للمشغلين.

البدائل موجودة قبل هذه المسودة. اشترط RFC 4552 دعم ESP في التنفيذات المتوافقة مع مواصفاته، وجعل AH خياراً غير إلزامي. وعرّف RFC 7166 ذيل توثيق لـ OSPFv3 لا يعتمد على IPsec. الجديد في سبتمبر هو اقتراح سحب AH من قائمة الاختيارات التي تُشجّع في هذا الاستخدام: لا تضيفه التنفيذات الجديدة، وقد تحتفظ به القديمة من أجل التوافق مع تنبيه المشغل إلى أنه أصبح غير مفضّل، وتبقى متطلبات ESP السابقة كما هي.

كلمة NULL في «تشفير ESP من نوع NULL» لا تعني غياب التوثيق. فهي تشير إلى عدم تشفير المحتوى بغرض السرية، فيما يمكن أن تستمر حماية سلامة الرزمة والتحقق منها. ولذيل التوثيق أيضاً آليات مفاتيح واقترانات أمان خاصة به. يحتج صاحب المسودة بأن مسار AH المنفصل يزيد عبء الكود وإدارة المفاتيح والإجراءات، ويصف استخدامه بأنه محدود. المصادر التي فُحصت لا تعرض إحصاء مستقلاً لحصة AH في شبكات OSPFv3 الفعلية؛ فلا يصح نشر هذا التقدير وكأنه قياس ميداني.

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

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

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

المصادر